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