В разработке почти всегда приходится выбирать между быстрым решением и технически идеальным. И почти всегда правильный ответ находится где-то между крайностями.
За последние годы я видел два почти зеркальных примера.
Первый сервис буквально дышит на ладан. Операционка съедает больше половины времени команды, релизы заставляют нервничать, а часть конструкции держится на подпорках и знаниях нескольких старожилов.
Но сервис коммерчески успешен. Он нашёл аудиторию, приносит деньги и продолжает расти.
В соседнем мире команда построила решение, которое можно ставить в музей. Красивые контракты, современный стек, продуманная архитектура и почти физическое удовольствие от того, насколько всё правильно устроено.
Только стоимость разработки оказалась в разы выше потенциальной прибыли — и сервис закрыли.
Прощаться со вторым проектом бывает даже тяжелее, чем с первым. В него вложено столько сил, что хочется продолжать уже не ради продукта, а чтобы оправдать предыдущие инвестиции.
Эти два случая хорошо показывают неприятную вещь: коммерческий успех не доказывает качество технического решения. Но и техническое совершенство ничего не говорит о ценности продукта.
Технический долг — не моральная категория
О техдолге часто говорят так, будто однажды разработчики поленились сделать нормально, а теперь просят несколько месяцев, чтобы всё переписать.
Иногда так и было. Но чаще плохое техническое решение появилось не из-за лени. Оно помогло вовремя запуститься, выполнить обязательство перед клиентом или проверить гипотезу до того, как на неё потратили год.
Компания получила ценность раньше и согласилась заплатить за это позже. Это и есть долг.
Мартин Фаулер разделяет техдолг как минимум по двум осям: осознанный или случайный, разумный или безрассудный. Такое разделение полезнее, чем попытка назвать долгом любой некрасивый код.
Разумный долг выглядит примерно так:
— мы понимаем, какое ограничение принимаем
— знаем, что покупаем этим компромиссом
— представляем, где начнут появляться проценты
— сохраняем возможность изменить решение
— договариваемся, когда вернёмся к вопросу.
«Сделаем быстро, а потом разберёмся» без ответа на эти вопросы — уже не стратегия. Это надежда, что счёт придёт кому-нибудь другому.
Когда быстрый MVP действительно оправдан
Когда-то наставник сказал мне: Если тебе нравится продукт на старте, значит, ты опоздал с его запуском на несколько недель. А может, и месяцев.
Фраза нарочито резкая, но её смысл мне близок.
На старте мы редко до конца понимаем, что именно строим. Меняются пользовательские сценарии, продуктовые границы, контракты, API и даже сама модель бизнеса. Идеальная архитектура для неверной гипотезы остаётся неверной архитектурой.
Быстрое решение особенно оправданно, если:
— спрос ещё не подтверждён
— срок жизни эксперимента неизвестен
— решение можно относительно дёшево заменить
— нагрузка и число интеграций пока невелики
— ошибка не создаёт неприемлемого риска для пользователей и бизнеса
Но MVP — это не разрешение отключить инженерное мышление.
Даже в эксперименте нельзя экономить на том, без чего сам эксперимент потеряет смысл: корректной аналитике, сохранности данных, базовой безопасности и возможности понять, что происходит с системой.
Быстро — это осознанно упростить конструкцию. Тяп-ляп — это не знать, что именно мы упростили и чем рискуем.
Как появляются музейные проекты
У противоположной крайности обычно хорошие намерения.
Команда хочет не повторять прошлых ошибок, выбирает современный стек, проектирует универсальные контракты и сразу готовится к большому масштабу. По отдельности каждое решение выглядит разумно.
Проблема появляется, когда техническая программа начинает жить отдельно от продукта.
Обычно это можно заметить по нескольким признакам:
— архитектура рассчитана на объём, которого ещё нет даже в оптимистичном бизнес-плане
— платформа строится сразу для множества сценариев, хотя подтверждён только один
— месяцами нельзя показать пользователю промежуточную ценность
— технологические требования подробно описаны, а экономика продукта — приблизительно
— ответом на вопрос о сроке запуска становится рассказ о фундаменте, который сначала необходимо закончить.
Именно поэтому мне нравится идея Дэна Маккинли. Новая технология может быть лучшим инструментом для конкретной задачи, но вместе с ней компания покупает обучение, эксплуатацию, наблюдаемость, найм и новые способы поломки.
Иногда этот счёт оправдан. Но платить его нужно там, где технология создаёт преимущество продукта, а не просто делает работу интереснее для разработчиков.
Когда сарайчик пора перестать латать
Запустить MVP недостаточно. Нужно ещё заметить момент, когда он перестал быть экспериментом.
Продукт уже доказал ценность, пользователи пришли, нагрузка растёт — но внутри всё ещё живут решения, рассчитанные на несколько недель. Команда продолжает добавлять этажи, хотя фундамент проектировали под дачный домик.
Одного универсального порога здесь нет. Но я начинаю беспокоиться, когда вижу несколько сигналов одновременно:
— операционка стабильно отнимает значительную часть ёмкости команды
— каждая продуктовая доработка требует трогать несвязанные части системы
— скорость разработки падает при росте команды
— знания о критических местах сосредоточены у двух-трёх человек
— архитектурные ограничения уже определяют продуктовый бэклог
— новые клиенты или объёмы требуют всё более дорогих подпорок
— стоимость и последствия инцидентов перестают быть приемлемыми
Главный признак — проценты по долгу начали расти быстрее, чем ценность, которую мы получаем от сохранения старого решения.
Именно здесь требуется самое неприятное решение. Продолжать латать систему ещё какое-то время почти всегда дешевле и спокойнее. Перестройка требует людей, которых придётся забрать у продуктовых задач, а её результат редко можно красиво показать пользователю.
Но чем дольше ждать, тем сложнее будет миграция.
Это не обязательно означает «остановить всё и переписать с нуля». Чаще разумнее выделить критические границы, постепенно заменить самые дорогие участки и оставить работающие части в покое. Цель — не получить идеальную систему, а вернуть команде возможность развивать продукт с приемлемой скоростью и риском.
CPO и CTO находятся по одну сторону стола
Техдолг часто становится следствием продуктового решения, а не виной разработки.
Но эта формулировка легко превращается в новое перекладывание ответственности: продукт якобы заставил торопиться, разработка предупреждала, а теперь пусть бизнес выделяет время на исправление.
Так не работает.
CPO и CTO — одна команда. Быстрый запуск, музейный провал и счёт за компромиссы у них общие.
Задача продукта — объяснить, какую гипотезу мы проверяем, сколько стоит задержка и какой результат оправдает дальнейшие инвестиции.
Задача технологии — объяснить не то, что решение «некрасивое», а его цену: как оно повлияет на скорость следующих изменений, надёжность, масштабирование и операционные затраты.
Совместное решение должно отвечать хотя бы на шесть вопросов:
1. Что именно мы хотим проверить этим запуском?
2. На какой срок рассчитано временное решение?
3. Что мы упрощаем осознанно?
4. На чём экономить нельзя даже в MVP?
5. По каким сигналам мы поймём, что эксперимент стал продуктом?
6. Где возьмём ресурс на укрепление фундамента, если гипотеза выстрелит?
Полезно заранее определить точки пересмотра: достижение определённой нагрузки, появление внешнего SLA, подключение следующей команды или рост доли операционки. Необязательно сразу назначать дату большого переписывания. Важно договориться, при каких условиях старое решение перестанет считаться достаточным.
Инженерная стратегия не существует отдельно от продуктовой и бизнес-стратегии. Если продукт планирует часто проверять гипотезы, техническая среда должна делать эксперименты дешёвыми. Если бизнес уже сделал ставку на долгоживущий высоконагруженный сервис, нельзя продолжать относиться к нему как к временному прототипу.
Не выбирать между качеством и бизнесом
Вопрос не в том, что важнее: хороший код или быстрый выход на рынок.
Нужно выбирать уровень технических инвестиций, соответствующий зрелости продукта, неопределённости и цене ошибки.
На старте обычно важнее сохранить скорость и возможность передумать. После подтверждения гипотезы — вовремя начать платить за фундамент. В зрелом продукте — не превращать качество в религию и продолжать считать экономику каждого улучшения.
Плох не сам технический долг. Плохо брать его, не понимая, что мы покупаем, сколько платим процентов и когда собираемся возвращать.
Музейный экспонат может быть безупречен, но в нём никто не живёт. Сарайчик может оказаться удивительно прибыльным и полезным.
Задача технического руководителя — не запретить строить сарайчики.
Задача — вовремя заметить, что команда уже надстраивает один из них до небоскрёба.
Я веду под псевдонимом Telegram-канал «будни неСТО» — об инженерном управлении, продуктах и корпоративной реальности без карьерных сказок.
ссылка на оригинал статьи https://habr.com/ru/articles/1078738/