Четыре цены одной фичи

Консультируя компании, я периодически сталкиваюсь с позицией: "Мы работаем быстро. Нам не нужны сложные процессы. За счет этого мы летим вперед."
Если делать быстро, просто кодить, не уделять время проработке гипотезы, написанию RFC, то на выходе получаем скорость. Кажется, что за счет этого компания обгоняет конкурентов.

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

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

Школа мысли

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

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

Build - цена создания. С ней мы уже познакомились. Она показывает, сколько стоит дотащить фичу до прода в первый раз. Эту цену считают практически все, потому что её спрашивают на старте. И вот, фича на проде, вроде бы оно заработало. Но это только начало.

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

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

Change - цена изменений. Через неделю после запуска к тебе прийдёт бизнес и скажет: "Мы тут поработали и поняли, что надо сделать маленькую правку". Маленькая она в глазах бизнеса. А если проект написан в один огромный кусок кода с горой if-ов, маленькая правка превращается в кучу времени на изменение этой хрупкой системы. И вот та самая скорость на старте формирует высокую стоимость именно здесь.

Я консультировал компанию, в которой считали: "Автотесты - пустая трата. Надо сразу писать код хорошо". При этом около 70% релизов разкурочивали систему.

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

Зрелое решение оценивает все четыре цены до старта. Конечно же, здесь не нужны точные цифры. Достаточно порядка величин. Они помогают осознать стоимость компромиссов.
Делаем на старте монолит? Это нормально. Но как сделать так, чтобы его можно было поддерживать и развивать?

Подытожим

Build - сколько стоит довести до прода? Платим на старте ресурсов команды разработки.
Run - сколько стоит эксплуатация и поддержка? Платим всю жизнь продукта ресурсами дежурных и оплатой инфраструктуры.
Change - сколько стоит внесение изменений? Платим каждый раз, когда хотим добавить новую кнопочку ресурсами команды разработки.
Exit - сколько стоит заменить подсистему? Платим редко, но много, если построили хрупко ресурсами всей команды.

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

#процессы #разработка