Переделки в разработке часто оказываются не провалом процесса, а способом быстрее добраться до реальности: пользователей, багов, ограничений и нормальных требований. В материале Reksoft, опубликованном в блоге «Карьера в IT-индустрии», Habr / Карьера разбирает знакомую IT-ситуацию: один разработчик долго проектирует почти идеальную систему, второй выпускает кривоватую, но рабочую версию и улучшает ее по живой обратной связи.
Повод выглядит почти как очередная притча против перфекционизма, но смысл тоньше. Автор не утверждает, что «делать плохо» полезно само по себе. В истории выигрывает не тот, кто наспех набросал продукт и забыл о качестве, а тот, кто превратил переделки в часть работы: выпустил минимальную версию, увидел реальные проблемы, получил пользователей и начал менять продукт уже не по догадкам, а по фактам.
Это болезненно узнаваемый сценарий для разработки, дизайна, текстов и внутренних процессов. Команда берет задачу, делает первую рабочую версию и почти всегда подразумевает: потом улучшим. Иногда это честный прототип. Иногда временное решение, которое живет годами, обрастает зависимостями и внезапно становится «так у нас исторически сложилось». В этом месте романтика быстрого запуска заканчивается, начинается бухгалтерия технического долга.
Главная причина, по версии автора, в неопределенности. На старте задачи редко понятно, какие сценарии действительно важны, где появится нагрузка, какие интеграции начнут ломаться первыми и что пользователи сочтут неудобным. Даже подробные требования не закрывают все пробелы. Поэтому попытка «сразу сделать хорошо» часто превращается в угадайку с дорогой архитектурой, долгими обсуждениями и спором о будущем, которое еще никто не видел.
Черновая версия работает иначе. Она дает команде объект, который можно критиковать, измерять и чинить. Пока задачи существуют только в описании, каждое решение ветвится: можно так, можно иначе, а можно еще полдня спорить о правильном названии сущности. После первого релиза появляется конкретика: вот пользовательский сценарий, вот неудобный экран, вот место, где код не выдержал нагрузки, вот фича, которая никому не нужна. Улучшать плохое, но работающее решение психологически и организационно проще, чем строить идеальное в пустоте.
Есть и человеческий слой. Быстро закрытая задача дает ощущение движения: коммит есть, билд собрался, пользователь что-то нажал. Долгое проектирование такого удовольствия не дает. Со стороны оно может выглядеть как отсутствие прогресса, хотя именно там иногда экономятся недели будущих исправлений. В командах это подкрепляется культурой наград: срочно починил продакшн — герой, не допустил проблемы заранее — ну, наверное, просто повезло.
Отсюда появляется перекос. Переделки в разработке становятся не осознанным этапом, а побочным эффектом спешки. Никто не планирует стоимость возврата к коду, не фиксирует, какие компромиссы временные, не договаривается, когда прототип должен умереть или превратиться в нормальный продуктовый модуль. Потом выясняется, что «быстро накидать» было дешево только в первый день, а дальше команда платит процентами: багами, сложностью онбординга, страхом менять старые участки.
Для разработчиков практический вывод простой: не все переделки одинаково вредны. Одно дело — выпустить MVP, чтобы проверить гипотезу и выбросить половину после проверки. Другое — под видом MVP протащить в продакшн неустойчивую основу, на которую завтра придут реальные клиенты, SLA и отчеты для руководства. В первом случае команда покупает знание. Во втором берет кредит, не глядя на ставку.
Для бизнеса вывод еще неприятнее, но полезнее. Скорость выхода на рынок сама по себе не заменяет продуктового мышления. Быстрый запуск оправдан, когда есть понятный механизм обратной связи и готовность менять решение. Если же после релиза команда переключается на следующий пожар, черновик перестает быть инструментом обучения и становится постоянной архитектурой компании. Потом это называют legacy, хотя вчера оно называлось «давайте пока так».
Самая здравая позиция находится между двумя крайностями. Не нужно строить собор там, где достаточно проверить спрос. Но и не стоит притворяться, что любой черновик автоматически приведет к хорошему продукту. Рабочий вопрос для команды звучит не «делать сразу идеально или быстро», а честнее: что именно мы сейчас выпускаем, сколько стоит ошибка, кто и когда вернется к этому месту, если гипотеза подтвердится?
Похоже, зрелость инженерной культуры измеряется не отсутствием переделок, а отношением к ним. Если команда заранее понимает, где она экспериментирует, где строит фундамент, а где просто устала и закрывает задачу на автопилоте, переделки в разработке перестают быть хаосом. Они становятся дорогим, но управляемым способом учиться на реальности, а не на фантазиях из стартового техзадания.