3 типа технического долга и способы управления им
Подобно тому, как умный финансовый долг может помочь вам быстрее достичь основных жизненных целей, не все технические долговые обязательства вредны, а управление техническим долгом может дать огромные выгоды для вашей компании. Это особенно актуально для быстрорастущих компаний, которым крайне необходимо своевременно поставлять продукцию, чтобы определить соответствие продукта рынку, удовлетворить потребности клиентов и использовать новые возможности. Но точно так же, как с финансовым долгом, вы должны быть мудрыми по поводу технической задолженности. В долгосрочной перспективе накопленный долг может замедлить скорость вашей доставки, вызвать проблемы с моральным духом разработчиков или даже полностью потопить ваш бизнес.
Даг Лиодден управляет техническим долгом более 14 лет - совсем недавно в качестве соучредителя и технического директора AdTech-компании Tapad, которую он помог привести к продаже за $ 360 млн. Несмотря на то, что нет единого универсального решения, Даг обнаружил, что классификация долга по категориям помогает во взаимодействии и решении проблем с долговыми обязательствами в разных группах. Он поделился тремя основными типами технического долга и своей стратегией решения каждой проблем.
1. Умышленный технический долг
Часто инженеры выделяют два способа что-то сделать: быстрый и правильный, говорит Даг. Во многих случаях быстрый способ - это правильный путь (когда нужно избежать чрезмерной инженерии), но иногда команда намеренно делает что-то «неправильное», потому что им нужно быстро доставлять продукт на рынок.
«Мы иногда сознательно набираем технический долг, чтобы сократить время выхода на рынок».
При выборе этого пути учитывайте не только то, сколько времени вы сэкономите на запуске функции, но и то, что потребуется, чтобы погасить явно возникшую задолженность. Убедитесь, что заинтересованные стороны знают, что в последствии это неизбежно замедлит запуск других функций.
Как решить эту проблему: использование гибкой методологии в работе вашей команды может расходиться с таким подходом, но но Даг обнаружил, что обычно имеет смысл отслеживать этот тип технического долга в отставании, когда умышленно откладывается работа, которая должна быть завершена. Если он не отслеживается должным образом, он вряд ли будет погашен и с течением времени превратится в случайный долг проектированию. Владельцы продукта и заинтересованные стороны должны нести ответственность за начисление такого долга, как это принято в результате принятия бизнес-решений.
2. Случайный / устаревший технический долг
При разработке программных систем команда Дага пытается уравновесить прагматическое мышление и перспективность своих проектов с простотой и быстрой доставкой. Это сложный баланс, предупреждает Даг, и он не всегда достигается. По мере развития систем и изменения требований вы можете осознать, что ваша разработка дала трещину или что новые функции стали трудными и медленными в реализации. Хороший оригинальный дизайн часто будет проще рефакторировать поэтапно, но иногда вам, возможно, придется стиснуть зубы и сделать более значительный рефакторинг.
Как решить эту проблему: как значительно реорганизовать систему - огромная тема сама по себе, но совершенно естественно, что это должно происходить с определенной периодичностью (через год или около того, когда система находится в «устойчивом» состоянии). В противном случае вы можете перестроить систему в первую очередь и понести лишние замедления. Командные или технологические лидеры и владельцы продуктов должны нести ответственность за то, что нет времени для решения этого типа технического долга, поскольку оно подвержено проектными решениями и часто меняющимися требованиями.
3. Технический долг Bit Rot
Такой долг может возникнуть со временем. Компонент или система медленно переходит в ненужную сложность посредством множества дополнительных изменений, часто усугубляемых при работе нескольких людей, которые не могут до конца понять исходный дизайн. К симптомам относятся, среди прочего, копирование и ритуальное балластное программирование.
Как решить эту проблему: это, пожалуй, единственный тип технического долга, который вы должны стараться избегать последовательно, говорит Даг, путем непрерывного рефакторинга. Сильные команды найдут время, чтобы понять дизайн системы, над которой они работают (даже если они не разрабатывали ее первоначально), постепенно улучшить дизайн и очистить плохой код Команда разработчиков должна быть ответственна за то, чтобы избежать долга Bit Rot, как и отдельные разработчики, навлекшие его.
Хотя категоризация технического долга не превратит его в легкий в обращении, она может обеспечить более продуктивные разговоры о нем и сделать свою команду сильнее. Технический долг будет и должен всегда существовать в системах. Очень важно, чтобы вы попытались понять, как долг замедляет вашу команду, и сбалансировать усилия по предоставлению функций в краткосрочной перспективе с увеличением общей производительности в среднесрочной и долгосрочной перспективе.