Долг, инфляция и банкротство: что скрывает изнанка IT-продуктов

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

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

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

За внешним благополучием нередко скрывается бомба замедленного действия: в Work Solutions не раз приходили проекты, которые не могли двигаться вперед из-за нестабильной кодовой базы. Далее рассмотрим, из чего складывается внутреннее качество, на что оно влияет, и как его обеспечить.

Единой методики оценки качества информационных систем нет. В первую очередь смотрят на надежность работы и сложность внедрения изменений. Эти показатели складываются из следующих характеристик:

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

Для описания этого явления в разработке ПО есть емкое понятие — технический долг. Это когда выбор в пользу быстрого, но неоптимального решения в моменте экономит время, но в долгосрочной перспективе приводит к увеличению стоимости доработок. За каждое такое решение проекту начисляется «пеня».

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

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

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

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

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

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

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

На сопровождение любого ПО нужны деньги. Даже продукт эталонного качества постепенно модифицируется и становится сложным и дорогим в обслуживании. Поэтому техдолг — мера субъективная, не всегда понятно, какая доля усилий идет на погашение «процентов», и что считать оптимальной стоимостью сопровождения и внедрения нового функционала. У каждой информационной системы она своя.

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

Измерить пользу рефакторинга сложно — разработчики редко погружены в бизнес настолько, чтобы приводить аргументы в привязке к продуктовым метрикам. Единицы специалистов могут дать объяснение в формате: «если мы инвестируем в переработку компонента X, то быстрее внедрим функцию Y и таким образом привлечем на Z клиентов больше». В итоге предсказать ROI невозможно, из-за чего рефакторинг постоянно откладывается.

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

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

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

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

Теперь, когда мы определили важность качества кода, следует дать рекомендации о том, как это качество обеспечить.

Если проект создается с нуля, и коммуникация с командой разработки выстроена хорошо, то вы понимаете условия кредитования. Как отметили выше — умышленный техдолг поддается контролю. Если долг перешел по наследству, то сперва восстановите полную картину — пригласите экспертов для аудита.

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

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

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

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

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

Если измерять производительность только по количеству добавленных функций и исправленных дефектов, то команда сосредоточится на этих показателях, поэтому численные KPI вводить не рекомендуется. Лучше установить команде четкие критерии готовности, включающие в себя метрики внутреннего качества. Не принимайте задачи, которые не соответствуют заданному DoD.

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

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

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