Долг, инфляция и банкротство: что скрывает изнанка IT-продуктов
Кто имел дело с разработкой ПО, обязательно сталкивался с ситуацией, когда внешне система работает исправно, но при попытке что-то в ней изменить программисты жалуются на «костыли» и «лапшекод», завышают оценки и настаивают на переписывании с нуля. Почему так происходит, и как избежать неприятной ситуации, читайте в этом материале.
В конкурентной гонке за создание лучших цифровых продуктов приходится работать с ограниченными бюджетами и жесткими дедлайнами. И когда при фиксированных сроках и объемах срабатывают проектные риски, исполнитель жертвует качеством.
Классический треугольник «быстро-качественно-дешево» в IT усложнен из-за разделения качества на внешнее и внутреннее. И если первое проверяют QA-специалисты и видят конечные пользователи, то последнее часто скрыто даже от глаз стейкхолдеров.
За внешним благополучием нередко скрывается бомба замедленного действия: в Work Solutions не раз приходили проекты, которые не могли двигаться вперед из-за нестабильной кодовой базы. Далее рассмотрим, из чего складывается внутреннее качество, на что оно влияет, и как его обеспечить.
Что считается высоким внутренним качеством IT-продукта?
Единой методики оценки качества информационных систем нет. В первую очередь смотрят на надежность работы и сложность внедрения изменений. Эти показатели складываются из следующих характеристик:
- Консистентность и читаемость кода
Написанный код должен быть понятен не только машине, но и людям. Чтение кода займет в разы больше времени, если отсутствует понятная структура, отступы, деление на абзацы, согласованность в наименовании функций и переменных и т.д; - Соблюдение лучших практик
Для каждого стиля программирования есть неофициальные наборы правил, которых нужно придерживаться при проектной работе. Код должен выглядеть так, будто его писал один человек; - Наличие документации
Что будет, если тимлида внезапно собьет автобус? Чтобы проект не зависел от конкретных людей, нужен регламентированный процесс фиксирования и передачи проектных знаний между участниками; - Производительность
Даже если человеческому глазу работа системы кажется быстрой, то в реальности ответы от сервера могут приходить с задержкой, а сайт низко ранжироваться из-за медленной отрисовки интерфейса. - Отсутствие дефектов
В хорошем ПО заранее предусмотрено нестандартное поведение системы, понятным языком описаны ошибки, а также настроен мониторинг и логирование сбоев; - Прохождение метрик и тестов
Помимо ручного тестирования, которое помогает определить корректность работы пользовательских сценариев, код должен быть покрыт автоматическими тестами.
Что будет, если эти критерии игнорировать?
Хотя качество кода — важнейший параметр в разработке, им часто жертвуют в угоду скорости. Проблемы из-за плохого кода часто проявляются не сразу, а только после запуска: внедрение нового функционала непредсказуемо ломает старый, постоянно всплывают новые ограничения, растягиваются сроки.
Для описания этого явления в разработке ПО есть емкое понятие — технический долг. Это когда выбор в пользу быстрого, но неоптимального решения в моменте экономит время, но в долгосрочной перспективе приводит к увеличению стоимости доработок. За каждое такое решение проекту начисляется «пеня».
Выплачивается долг переписыванием кода или рефакторингом. Затраченное на это время уходит в счет погашения процентов. Очевидно, что чем дольше существует долг, тем выше цена, которую придется заплатить в итоге.
Верно и обратное — качественный код со временем повышает рентабельность. Таким образом, создание надежной кодовой базы похоже на вклад. Когда отдаете предпочтение быстрому, но ограниченному решению — вы занимаете средства, которые придется возвращать с процентами, но если тратите немного больше — впоследствии получаете дивиденды в виде сокращения расходов на разработку.
Заем также может служить развитию. Быстрее представив новый функционал и запустив продукт на рынок, бизнес получает конкурентное преимущество. Владелец продукта сам оценивает потенциальные риски и выгоды и решает, насколько сильно готов кредитоваться — выделять дополнительное время разработчику или срезать очередной угол, чтобы скорее проверить гипотезу.
Когда выбор в пользу менее оптимального решения делается осознанно, и все заинтересованные стороны в курсе, то образуется умышленный техдолг. Ответственность за него часто падает на владельца продукта, который должен выработать стратегию по его устранению. Так, например, нормально сокращать TTM за счет снижения качества, но в случае коммерческого успеха лучше сразу планировать ресурсы на переписывание MVP.
Если стратегии по выплате долга нет, и все проблемы постоянно заметаются под ковер, то проект ждет техническое банкротство, когда стоимость изменений приобретает отрицательную ценность и все усилия уходят только на поддержание работоспособности.
Когда выбора нет, или техдолг переходит по наследству
Иногда о проблемах внутри проекта никто не догадывается, пока они сами не дадут о себе знать. В таком случае, перед вами неумышленный техдолг. Представьте, что нужно подписать договор на получение ссуды без возможности ознакомиться с условиями. Незавидное положение.
Причины неумышленного техдолга бывают разные: неверно выбранные технологии, низкая квалификация программистов, слабый менеджмент, несоблюдение методологий разработки. Погашать его сложно.
На сопровождение любого ПО нужны деньги. Даже продукт эталонного качества постепенно модифицируется и становится сложным и дорогим в обслуживании. Поэтому техдолг — мера субъективная, не всегда понятно, какая доля усилий идет на погашение «процентов», и что считать оптимальной стоимостью сопровождения и внедрения нового функционала. У каждой информационной системы она своя.
По мере того, как усложняется внедрение нового функционала, возникает необходимость в рефакторинге — оптимизации кода для повышения эффективности обслуживания. Рефакторинг как правило не устраняет ошибки, а помогает предотвращать их возникновение в будущем — а это ключ к снижению затрат.
Измерить пользу рефакторинга сложно — разработчики редко погружены в бизнес настолько, чтобы приводить аргументы в привязке к продуктовым метрикам. Единицы специалистов могут дать объяснение в формате: «если мы инвестируем в переработку компонента X, то быстрее внедрим функцию Y и таким образом привлечем на Z клиентов больше». В итоге предсказать ROI невозможно, из-за чего рефакторинг постоянно откладывается.
При высоком уровне корпоративной культуры и вертикальном устройстве команды, когда есть архитекторы, тимлиды и старшие специалисты, разработчики на проекте обязательно должны наладить процесс обеспечения качества и непрерывный рефакторинг.
А что, если над проектом работает несколько команд, каждая из которых вносит свой вклад, не имея четкого представления о первоначальном замысле? Добавьте к этому свойственную IT-рынку высокую текучесть кадров и сменяемость состава разработчиков и получите ситуацию, когда каждый новый привлеченный исполнитель критикует предшественника.
Если вы доверяете своим разработчикам, попросите их составить список всего, что кажется неоптимальным, а затем оценить сроки устранения выявленных узких горлышек. Если же уровень доверия низкий, то обратитесь к независимым экспертам, которые проведут тщательный технический аудит и подготовят исчерпывающую отчетную документацию со списком рекомендаций.
Обычно любой проект можно привести в порядок. Проводить рефакторинг кода функция за функцией, разделить монолитную архитектуру на отдельные микросервисы и т.д. Но в отдельных редких случаях речь может идти уже не о долге, а технической инфляции, когда текущий уровень технологий превосходит уровень основы вашего продукта до такой степени, что перестает быть совместим с актуальными технологиями. Тогда может потребоваться полная переделка с нуля.
Как обеспечить высокое внутреннее качество продукта?
Теперь, когда мы определили важность качества кода, следует дать рекомендации о том, как это качество обеспечить.
Выявление и отслеживание
Если проект создается с нуля, и коммуникация с командой разработки выстроена хорошо, то вы понимаете условия кредитования. Как отметили выше — умышленный техдолг поддается контролю. Если долг перешел по наследству, то сперва восстановите полную картину — пригласите экспертов для аудита.
Как и в случае с займом, убедитесь, что есть план по выплате — отслеживайте каждое такое решение, ведите учет несогласованных оценок. В будущем они послужат ориентиром, сколько времени в конечном итоге потребуется, чтобы привести все в порядок.
Оценка рисков и приоритезация
Общий техдолг состоит из ряда микрозаймов с разными процентными ставками. Получив представление об их размере, определите, что реально угрожает проекту, а с чем можно жить.
Подойдет классическая методика оценки рисков на основе их потенциального влияния. Если проблема проявляется часто и затрагивает много пользователей — устраняйте безотлагательно, в противном случае — понижайте приоритет.
Планирование и распределение нагрузки
Разом избавиться от техдолга целиком невозможно, поэтому как и с банковской ссудой здесь возможны регулярные взносы по спланированному графику платежей. Так вы распределите нагрузку и сохраните баланс между разработкой новых функций и улучшением текущего кода. По данным исследований в крупных технологических компаниях, управление техдолгом в среднем занимает 25% от всего времени разработки.
Мотивация команды
Необходимо создать условия, мотивирующие сотрудников поддерживать внутреннее качество. К сожалению, четких метрик, чтобы определить готовность продукта к масштабированию, нет.
Если измерять производительность только по количеству добавленных функций и исправленных дефектов, то команда сосредоточится на этих показателях, поэтому численные KPI вводить не рекомендуется. Лучше установить команде четкие критерии готовности, включающие в себя метрики внутреннего качества. Не принимайте задачи, которые не соответствуют заданному DoD.
Разработка IT-продукта — это вложения, которые должны окупаться в виде прямых доходов или снижения затрат. Вывод новых продуктов на рынок приносит прибыль, а качественный код позволяет делать это с минимальными издержками, поэтому для финансовой эффективности нужно балансировать этими показателями.
Соблазн отступить от стандартов качества возникает при необходимости соблюдать жесткие сроки. Низкое внутреннее качество увеличивает энтропию, и по мере расширения кодовой базы усложняется обслуживание, и подрывается командный дух.
Чтобы выработать стратегию обслуживания технического долга, наладьте диалог с командой разработки, вместе составьте список задач с привязкой к бизнес-метрикам. Какие показатели поможет улучшить рефакторинг? Какие проблемы возникнут, если ничего не делать? Только через общение вы сможете лучше друг друга понимать и добиваться желаемых результатов.