Как я могу убедить руководство справиться с техническим долгом?

Это вопрос, который я часто задаю себе, работая с разработчиками. До сих пор я работал в четырех компаниях, и мне стало известно о недостаточном внимании к поддержанию чистоты кода и решению технических проблем, которые препятствуют дальнейшему прогрессу в программном приложении. Например, первая компания, в которой я работал, написала базу данных с нуля, а не использовала что-то вроде MySQL, и это создало ад для команды при рефакторинге или расширении приложения. Я всегда старался быть честным и ясным с моим менеджером, когда он обсуждает прогнозы, но руководство, похоже, не заинтересовано в исправлении того, что уже есть, и ужасно видеть, как это влияет на моральный дух команды.

Что вы думаете о лучшем способе решения этой проблемы? Я видел, как люди собирали вещи и уходили. Затем компания становится вращающейся дверью, когда разработчики приходят и уходят и делают код еще хуже. Как вы сообщите об этом руководству, чтобы заинтересовать их в решении технических проблем ?

Когда я встретился с моим боссом, чтобы обсудить это, он сказал, что я должен включить рефакторинг во все мои оценки. Он сказал, что это не проблема, о которой он хочет думать. Вместо этого я должен справиться с этим.

Это не проблема, о которой руководство вообще хочет думать. Вы не инженеры, а вы. Просто сделайте это невысказанной частью всех ваших оценок, и вы обнаружите, что технический долг уменьшается.

Это никогда не будет идеальным, хотя. Техническая задолженность, например задолженность по кредитным картам, - это вложение в ускорение привлечения клиентов и ускорение завоевания доли рынка над конкурентами. Как и кредит, при правильном управлении он может сделать вас весьма успешным.

Как сказал Ганди, когда его спросили, сработает ли его тактика с кем-то вроде Гитлера. Он сказал: «Это будет трудно». Но я думаю, что есть справедливый аргумент, что ответ на самом деле «Нет». К сожалению, я не думаю, что вы пытаетесь сделать, можно сделать. Дело не в том, что я пытаюсь быть пессимистичным, скорее, я пытаюсь быть честным.

Проблема для меня не в том, что менеджеры нуждаются в убеждении. Лучшие уже понимают, что долг может быть убийцей, если не справиться. Но понимают они это или нет, являются ли они хорошими менеджерами или плохими, все они сталкиваются с давлением, чтобы доставить, и что поставка оценена их боссами против даты. Качество имеет значение только в том случае, если оно крайне плохое, в этом случае это вина разработчиков или очень хорошее, и в этом случае благодаря блестящему управлению. Качество просто должно быть «достаточно хорошим».

Мне кажется, мне нравится то, что Ренесис сказал в своем ответе, потому что он один из немногих, кто понимает, что менеджмент думает совсем не так, как инженер. И я думаю, что все мы видели прогресс в том, что компании становятся ориентированными на даты и более управляемыми проектами, в отличие от клиентов и качества. Под этим я подразумеваю типичные компании, а не настоящие компании, у которых хватит смелости сказать «это будет сделано, когда это будет сделано» (например, Apple Computer или id Software - и да, я понимаю, что иногда люди не свободны принять такой подход).

Но вот в чем дело: компании, которые выбирают подход, основанный на качестве, ... что вы заметили в них? Правильно, ими руководят инженеры, а не продавцы, маркетологи, менеджеры проектов или бухгалтеры. Подумайте о HP, Apple, ID, Google, Microsoft и IBM. Все началось и стало успешным благодаря инженерам, а не продавцам, хотя продавцы, безусловно, сыграли свою роль, и я уверен, что многие будут спорить о том, связана ли Microsoft с качеством :). И из тех, которые пошли вниз, ушли от руководству инженером. В этом заявлении есть целый ряд аргументов, поскольку существует множество технических компаний, которые в конечном итоге потерпели неудачу из-за неспособности адаптироваться к изменяющимся временам и управлять собственным ростом. Я не рассматриваю лидерство на основе инженерных разработок как причину этих неудач, для меня это s вопрос навыков и деловой хватки, которые не зависят от того, кто является разработчиком или бухгалтером. Тем не менее, я думаю, в целом, что в разработке есть преданность строгости подотчетности и дисциплины, которая приносит пользу компаниям, где инжиниринг является компонентом.

Серьезно, оглянись вокруг. ИТ-лидерство крайне не хватает. Фокус всегда на стоимости и времени, и редко на качестве, если это достаточно хорошо. ИТ-лидеры редко отчитываются перед генеральным директором, теперь это всегда финансовый директор. ИТ-специалисты зацикливаются на поддержке производства и все в большей степени обязаны руководителям проектов, которые сосредоточены на меньших, более легко усваиваемых и измеримых кусках, а не на существенных изменениях революционной ценности (не то, чтобы это обязательно было неправильно; разделяй и властвуй - это хорошо, но видение должен быть там для общей картины).

Извините, что так долго занимал этот пост, но, в конце концов, я думаю, что ваш вопрос о том, как заставить руководство заботиться о техническом долге, часто лучше решить, найдя правильного лидера, чем меняя существующего. По словам Ренесиса, объяснение технического долга стандартным мыслителям означает изменение фокуса на деньги и затраты, и я думаю, что при переводе многое теряется; даже если вы преуспели в этом, это будет иметь значение, только если его купит главный лидер компании. Убедить вашего менеджера среднего звена поступить правильно, вероятно, только уволят его.

Первое, что нужно сделать, это изменить формулировку. Называя его «техническим долгом», у руководства возникает идея, что его разрешение - это своего рода инвестиция, хотя на самом деле это больше похоже на вирус. (Я как Дейв Рэмси из технического долга.)

Разрешение на то, чтобы оно оставалось неоплаченным, сопряжено с огромными затратами, которые невозможно увидеть или легко определить количественно.

Перечислите следующие проблемы для управления:

• Оценки новых функций намного выше, чем они должны быть. Или вообще невозможно.
• Плохой код порождает больше плохого кода
• Список ошибок растет, даже если разработчики всегда их исправляют
• Члены команды уходят (само это может показать, что есть проблема, как объяснено в этом превосходном ответе )

Мое руководство фактически начало прилагать серьезные усилия для решения проблемы технического долга, что является одной из причин, по которой мне нравится работать там, но это долгосрочное усилие, и никогда не помешает напомнить им, почему усилия того стоят.

Один из способов, которым я продолжаю оказывать давление, - это когда меня просят о смете, и можно было бы сэкономить время, если бы мне не приходилось сталкиваться с конкретными техническими проблемами задолженности, я включаю это в свою смету . Например, « Эта ошибка займет у меня 2-3 дня, чтобы отследить ее, но если бы мы уже исправили эти 2 другие ошибки с« низким приоритетом », которые были в очереди навсегда, это, вероятно, заняло бы меньше одного». Часто, ответ будет идти вперед и исправить эти другие, пока вы на это.

Я также согласен с другими ответами о том, что просто считаю улучшения частью вашей работы и выполняйте их по мере необходимости, если это не слишком разрушительно. Моя текущая задача состоит в том, чтобы сделать дополнения к очень плохо спроектированному коду. Вместо того, чтобы добавлять беспорядок путем написания моего нового кода для соответствия, я трачу немного времени на консолидацию общей функциональности, поэтому отправка пакета становится вызовом функции одной строки вместо того, чтобы постоянно повторять 15 строк слегка измененного копирования и наклеить шаблон.

Я точно знаю, что это поможет сохранить здравомыслие какого-то сопровождающего в будущем. Я знаю, потому что я тот мейнтейнер сегодня. Тем не менее, я также считаю, что это ускорит мою текущую задачу по включению и отладке этой функции.

Другой метод, который я использовал в прошлом и должен повторить, - это сохранить рефакторинг ветки DVCS в отдельном рабочем дереве для того времени простоя, когда вы компилируете, ждете длинного теста или просто нуждаетесь в смене темпа для немного, когда ты перегорел на жуке. Пока вы время от времени сливаетесь с апстримом, чтобы не отклоняться слишком далеко, вы можете потратить столько времени, сколько захотите, на рефакторинг изменений с минимальными усилиями. 15 минут здесь и там в день действительно могут сложиться со временем.

Вы можете попробовать аналогию с кредитной картой. Спросите их: «Вы чувствуете себя комфортно, оставляя выписки по своей кредитной карте неоплаченными в течение длительного периода времени?

Менеджеры понимают затраты и выгоды, но (обычно) не технические термины, используемые нами, разработчиками. Термин «технический долг» уже был придуман, чтобы помочь преодолеть этот коммуникационный барьер, но вам, возможно, придется сформулировать его более четко. Большинство менеджеров очень хорошо знают (часто из собственного опыта), что просроченные платежи по кредитным картам растут с ужасной процентной ставкой, поэтому больно оставлять их неоплаченными. Это может помочь им понять серьезность проблемы, связанной с энтропией программного обеспечения.

Но если это не убеждает их, попробуйте собрать фактические доказательства и сделать некоторые расчеты. Например, сколько стоит компании - и наличными, и потерянным временем - заменить уволенного сотрудника.

Никто не даст денег за замену чего-то, что работает чем-то другим, что (при любой удаче) также работает.

Что вы можете сделать, это предложить заменить его чем-то, что делает больше, то есть объединить обслуживание технологического долга в модернизацию, которая приносит мгновенные и ощутимые выгоды для бизнеса.

Конечно, вы должны быть откровенны об этом, мы не говорим о том, чтобы «подкрадываться» к новому проекту здесь.

Я нахожу другую сторону, с которой разработчикам сложнее справиться. По сути, это сводится к следующему: для некоторых разработчиков уверенность в том, что ваш код - это лучший из возможных кодов, является предметом профессиональной гордости. Для других это просто другая работа, и цель состоит в том, чтобы сделать это быстро и вернуться домой.

Никакая убедительность не изменит эту ситуацию, и если вы введете обязательный стандарт качества кода, ваши девять-пять разработчиков найдут способ работы системы, в то время как ваши преданные разработчики неизбежно будут раздражены всей процедурой (которая не не нацелены на них, но нельзя сказать, что разработчик X должен подчиняться правилам, а Y может делать все, что он захочет).

Что работает, но все еще может быть очень неприятно, так это заставить ваших более преданных и знающих разработчиков следить за базой кода, вероятно, хороший компромисс между продвижением вперед и наведением порядка в том, что там есть.

Дело в том, что во многих компаниях, особенно с учетом текущей экономической ситуации, каждый час должен оплачиваться кому-то.

Или они быстро падают .

Если существующие клиенты не готовы платить за рефакторинг, что крайне маловероятно, если только оно не сопровождается значительно улучшенной производительностью или функциями. Тогда это не произойдет на старых кодовых базах. Возможно, вы сможете использовать его в бюджете для новых проектов, если у клиентов глубокие карманы, но если вам не нужно менять API-интерфейсы при рефакторинге, это будет бесполезно для более старых проектов и вполне может представить Ситуация, когда компания поддерживает две кодовые базы, что вызывает дополнительные головные боли и затраты.

Как инженер, я хотел бы реорганизовать старый код, который больше не подходит для конкретных целей, каждый раз, когда что-то устаревшее или устаревшее. Но, как сказали мне мои руководители во всех компаниях, в которых я когда-либо работал: «Кто заплатит?»

Я всегда стараюсь прибраться. Я не сделал, пока код не станет чистым. Проблема технического долга заключается в том, что большинство людей не понимают этого. Лучший способ справиться с этим - не накапливать ничего. Если ваши менеджеры доверяют вашим разработчикам решать, как решить проблему, вы можете сделать гигиену кода частью любой задачи программирования. Если вы никогда не регистрируете плохой код, вы не накапливаете долги. Если вы также следуете правилу бойскаутов (всегда оставляйте код чище, чем вы его нашли), ваш существующий долг будет медленно исчезать.

Я не рассматриваю рефакторинг как задачу, отдельную от реализации функций. Это неотъемлемая часть этого.

Если вы имеете дело с нетехническими менеджерами, было бы полезно, если бы вы могли превратить ваше обсуждение в термины, которые они понимают. Если вы сможете построить реалистичное обоснование положительной рентабельности инвестиций в работу, затраченную на погашение технического долга, вы можете получить что-нибудь. Это упражнение будет зависеть от ваших обстоятельств, но примером может быть что-то вроде этого:

Проанализируйте, сколько времени разработчики вынуждены тратить, чтобы помочь службе поддержки в решении производственных проблем, а затем расскажите, что исправление некачественного старого кода могло бы: A. уменьшить количество проблем с поддержкой, B. облегчить службе поддержки решение проблем, не переходя в разработку, и C. сократить время, затрачиваемое разработчиками на вопросы производства, когда они возникают. Поместите это в доллары, сэкономленные тем, что разработчики не были связаны работой поддержки. Также отметьте, что каждый час, потраченный разработчиком на поддержку, является «двойным ударом», потому что вы платите не только разработчику за поддержку, но и снижаете издержки, связанные с тем, что мог бы сделать этот разработчик (добавление новых функций и т. Д. .)

Да, некоторые из чисел будут вуду / дым-и-зеркалами ... это нормально, грязный секрет управления заключается в том, что они знают, что большинство чисел, которые они бросают, являются абсолютными БС. Пока вы им что-то даете казалось бы, конкретный для работы, так что они могут получить это в своих головах, у вас есть шанс для борьбы.

После этого объяснения технического долга ваше руководство должно быть убеждено погасить его:

Представьте, что у вас очень грязная кухня, полная дерьма. Прежде чем готовить еду, вы должны провести один час уборки. И так каждый раз, когда вы хотите поесть. Кроме того, при приготовлении еды вы должны быть особенно осторожны, чтобы убедиться, что дерьмо не выпадает из еды.

Кухня - это ваш код, еда - ваш продукт, а еда - ваш продукт.

Если они могут позволить себе дольше ждать внесения изменений без надежной сети модульных тестов, то в вашей компании что-то не так.

Это должен быть очень убедительный аргумент, с точки зрения оригинального продукта и бизнес-кейса, что я не мог использовать эти деньги сейчас, чтобы сделать что-то более важное для меня. Нравится вам это или нет, но ваш менеджмент или ваши клиенты платят за это, и вы должны быть в состоянии продать их, чтобы убедить их.

Давайте перефразируем это, чтобы позиционировать себя как клиента. Старая добрая ролевая игра.

Предположим, вы купили холодильник. И вы могли бы купить холодильник за 1000 долларов, который нормально работал у Acme Corp. Или холодильник за 2000 долларов у Acme Deluxe Fridges, который выглядел одинаково снаружи и имел те же технические характеристики, но имел более низкие затраты на обслуживание из-за более чистой внутренней архитектуры.

Как покупатель, что бы вы сами купили?

И что инженеры Acme Deluxe считают лучшим ответом?

« Технический долг » может быть непростым делом для представления руководству, поскольку они могут не видеть в этом необходимости. Вопрос может быть сформулирован так: есть ли в компании чемпион, чтобы заявить: «Послушайте, мы тратим здесь X% времени на работу над техническим долгом. Дайте нам 3 месяца, чтобы показать вам, что это работает хорошо», или что-то в этом роде. аналогичный. Там есть требование автономии, но есть и временные рамки, так как в противном случае руководство может задаться вопросом, как долго, пока они не увидят некоторые результаты, что является довольно опасной территорией.

Первый момент, однако, заключается в том, считают ли они это проблемой. Если человек с плохим зрением ничего не знает о очках и о том, какие изменения они могут обеспечить, как они могут понять, почему проверка зрения может быть полезной? Та же идея здесь, когда предмет довольно технический и, к сожалению, не так легко определить количественно.

Вы должны просто перестать жаловаться на это.

Вот почему:

1. Они никогда не планируют использовать программное обеспечение дольше года
2. это просто трата времени на настройку, если их план состоит в том, чтобы выбросить его потом
3. Есть некоторые реальные проблемы, которые нужно исправить сейчас
4. программистам просто нужно научиться справляться с обслуживанием, даже если это не всегда весело
5. Жаловаться на то, что вы лучше знаете, что нужно делать, высокомерно - кто-то другой принимает решение, и вы должны быть рады этому
6. Они все равно доверяют тебе писать хороший код

Так что лучший путь вперед - это:

1. Когда вам дадут новое задание, постарайтесь выполнить его как можно лучше в данный момент времени.
2. Напишите это отлично с первого раза. Если вам нужно изменить его впоследствии, вы допустили ошибку в первый раз, и любое изменение всегда идет в неправильном направлении - и это возможность обучения для программистов, когда вы делаете ошибки.
3. Не просите дополнительное время для этого, вы не получите его, есть сроки, которые вы знаете.

Я так понимаю, вы никогда не участвовали в проекте по переписыванию / замене или даже обновлению существующей системы.

Это одни из самых сложных проектов, которые можно успешно завершить. Вот некоторые проблемы, с которыми вы столкнетесь:

1. Деловые правила теряются во времени.
2. Документация и реализация полностью не синхронизированы.
3. То, что вы видите как ошибку, пользователи видят как функцию.
4. И наоборот, многие «особенности» будут рассматриваться пользователями как дефекты.
5. Вы не будете принимать участие пользователей - они будут рассматривать ваши «факты» как «ботаников, задающих глупые вопросы», они будут расценивать усилия по тестированию как пустую трата времени, они будут настаивать на добавлении новых функций, таким образом, удлинение проекта приведет к уже отставать от графика.
6. Скорее всего, исходный код не соответствует 100% с запущенным исполняемым файлом.
7. Пока ваш отдел возится с разработкой рефакторинга, бизнес на самом деле хочет, чтобы это не было сделано.
8. Скорее всего, ваш ре-факторинг будет включать в себя «более чистые улучшенные интерфейсы», что приведет к перетаскиванию других проектов в трясину поздних поставок и неудачных испытаний.
9. После того, как проект будет завершен (более 50% этих усилий потерпят неудачу полностью), вы потеряете всю кредитоспособность - вам нужно будет перейти в другую компанию в другом городе, чтобы найти кого-то, кто тоже готов выслушать вас.
10. Если проект «удастся», то все будут помнить, какой это был кошмар - вы .......

Я призываю вас избегать любых проектов переписывания / рефакторинга, таких как чума, они могут быть одними из самых удручающих в любой профессиональной карьере.

Есть много мудрости во фразе «Если это не сломано, не исправляйте это».

Что касается жизни, я не могу понять, почему некоторые люди так слепо боятся перемен - это похоже на недостаток уверенности в своих силах.

Вчера вечером я смотрел шоу в национальном парке Йосемити, и было отмечено, что с 1940 по конец 1990-х годов не выросло ни одного нового дерева секвойи. Было обнаружено, что причина была в том, что существовала строгая политика, запрещающая сжигание лесных пожаров, и что сосновые шишки секвойи нуждались в тепле от огня, чтобы открывать и выпускать свои семена.

Видите ли, пожар каждые десять лет или около того был здоровым. Он очистил все скопившиеся сухостой и ежевичник, чтобы сохранить существующие деревья (процессы) и освободить место для новых (функций).

Сейчас я работаю над проектом, в котором есть веские основания для перестройки: устаревшее программное обеспечение было написано исключительно с использованием веб-форм .NET. Практически вся бизнес-логика сочетается с логикой представления тегов HTML / server и не может быть расширена в другие приложения, когда бизнес вырос.

Управление стоит за задачей, потому что они имеют достаточное количество доверия к своим разработчикам, что, как я понимаю, является редкой роскошью.

Да, спросите себя, действительно ли необходима перестройка. Делайте все возможное, чтобы повторно использовать существующий код, который работает, где вы можете. При необходимости интегрируйте этот код в пересборку. Только не позволяйте никому убедить вас в том, что боязнь вносить смелые изменения - это единственный способ существовать как разработчик программного обеспечения.

Удачи!

Вы должны предоставить своему руководству финансовую причину для решения проблемы технического долга и основы для управления сокращением этого технического долга.

Поддержание технологической дорожной карты является одной из таких рамок. Начало работы с дорожной картой поможет вам избежать накопления технического долга, а также поможет уменьшить существующий долг.

Многие успешные долгосрочные проекты имеют связанные с этим руководящие комитеты и дорожные карты для руководства развитием. Это особенно полезно, когда участвуют несколько групп разработчиков и заинтересованных лиц.

Я предлагаю вам обсудить эту стратегию со своими менеджерами (и, если возможно, теми, кто принимает решения о том, куда тратятся деньги).

Общий подход к созданию и управлению дорожной картой прост, но он требует поддержки вашей команды управления. Сначала определите цель. Определите элементы технического долга и разработайте целевую системную архитектуру, которая сокращает элементы вашего технического долга. Помните, это не обязательно должно быть идеально, просто работоспособно и лучше, чем вы есть на данный момент. Примите во внимание программное обеспечение, средства разработки, аппаратные платформы, основные новые функции, которые могут быть добавлены в систему. Сделайте анализ затрат. Если у вас есть желаемая архитектура, каковы ощутимые преимущества от проведения рефакторинга? (Преимущества включают сокращение времени тестирования, более надежные программные продукты, более предсказуемые циклы разработки и т. Д.) Если вы сможете показать достаточно преимуществ для проведения рефакторинга, вы можете получить поддержку управления.

Получив дорожную карту и поддержку управления, разработайте серию шагов (также называемых планом), которые вам необходимо предпринять, чтобы достичь желаемого состояния. Это может быть хорошей идеей создать руководящий комитет, который ведет дорожную карту, обучает и обучает команды разработчиков дорожной карте и периодически рассматривает изменения на предмет архитектурной целостности.

Дорожные карты действительно полезны, и, возможно, 13-й вопрос по тесту Джоэла должен звучать так: «Есть ли у вас дорожная карта?»

Вот видео первого часа недавнего сеанса дорожной карты Red Hat Linux .

Уже будучи вовлеченным в серьезную переписку (не просто рефакторинг), я могу согласиться с тем, что привлечение финансовых ребят к соглашению было одним из главных препятствий. Чтобы преодолеть это препятствие, я должен был написать, представить и защитить отчет, в котором указывалось на ряд проблем, которые означали, что бизнес компаний в ближайшей и среднесрочной перспективе будет мертвым.

Ключевые факторы в достижении соглашения:

• Существующий код был в более не поддерживаемой цепочке инструментов (MicroPower Pascal), которая работала только на почти неподдерживаемой платформе разработки (PDP11-23).
• Поиск разработчиков, которые могли бы работать с инструментами и целями, становился практически невозможным.
• Целевое оборудование больше не было доступно, если требовались запасные части, а производитель все больше отказывался предоставлять услуги по ремонту.
• Проблемы в коде приводили к легко идентифицируемой неудовлетворенности клиентов и прямым затратам на обслуживание.
• Добавление новых функций или даже исправление ошибок становилось практически невозможным из-за ограничений целевого оборудования, что приводило к необходимости реорганизации других областей, чтобы освободить место при решении проблем.
• С 8-часовым временем сборки разработка и тестирование любых изменений были дорогостоящими.

В отчете подробно изложены проблемы с оценками текущих затрат и предложены 3 варианта:

1. Заморозить, где мы были, возможно, даже не исправлены ошибки в ближайшем будущем.
2. Оптимизируйте код только для пространства, безотносительно к удобству сопровождения, указывая, что любой, кто пытается сохранить оптимизированный код, должен быть умнее, чем тот, кто занимался оптимизацией.
3. Внедрите, с проверяемостью и ремонтопригодностью в качестве основных факторов, в широко распространенном отраслевом стандарте (ANSI C), на новом недорогом оборудовании COTS (PC-104), с несколькими поставщиками, имеющимися у себя дома. разработана интерфейсная карта, позволяющая ей работать с оставшимся существующим оборудованием. Добавление ограниченного набора новых функций в рамках разработки, таких как энергонезависимое хранилище, сторожевой таймер для автоматического перезапуска в случае сбоя, когда некоторые устройства выходили из строя несколько раз в день, и для сброса требовался сервисный вызов в размере 40 фунтов стерлингов , лучшая диагностика в процессе.

После получения третьего варианта мой 3-месячный контракт превратился в 3 года очень тяжелой работы, как для разработки нового программного, так и для аппаратного обеспечения, но с очень хорошим результатом.

Для случаев с менее значительным техническим долгом я склонен принять то, что я называю партизанским рефакторингом:

Когда есть проблема с определенным модулем:

1. Напишите набор тестов, которые демонстрируют проблему, которая также может быть неудачной без рефакторинга
2. Refactor как часть разработки указывает на то, что тесты по-прежнему не проходят.