В сфере разработки программного обеспечения одна из основных проблем, с которой сталкиваются команды, — это попытки создать масштабный продукт сразу и идеально с первого раза. Истории о провалах при полном переписывании кода стали практически народным опытом среди специалистов в области IT. Попытка реализовать масштабные проекты «с нуля» под грифом «сделать все правильно» зачастую приводит к затягиванию сроков, огромному стрессу для команды и в конечном итоге — к тому, что продукт так и остается недоделанным. Отсюда и родилась старая истина, которую многие уже поняли на собственном опыте: либо запускать обновления и функции постепенно, шаг за шагом, либо рисковать провалом. В терминах современного рынка разработки озвучивается девиз — ship incrementally or die trying (запускай поэтапно или умри, пытаясь).
Почему же столь сложно отказаться от перфекционизма и большущих проектов в пользу поэтапного подхода? Каковы скрытые опасности долгих переписок и почему стоит изменить менталитет в пользу быстрых, маленьких релизов? Попробуем подробно разобраться. Многие из нас знакомы с мучительным опытом работы над проектами, которые изначально кажутся идеальными. Сначала в голове рисуется блестящая архитектура, затем начинается методичная перепись всего функционала. Представьте структуру, где каждая кнопка, каждое анимированное движение должны быть безупречны. Казалось бы, такой подход должен привести к качественному и современному продукту.
Результат же — долгая пауза без выхода ни одной версии для пользователей, постоянное увеличение объема работы и нарастание давления внутри команды. Подобные этапы можно сравнить с оставшейся в холодильнике китайской едой: чем дольше проект лежит полуфабрикатом, тем меньше у всех желания приступить к его окончанию и тем сильнее накапливается внутренняя усталость и разочарование. Среди хронических проблем, мешающих вовремя вывести продукт на рынок, выделяются четыре основные причины. Перфекционизм — когда разработчики и менеджеры не позволяют себе сделать релиз, если что-то не соответствует высокой, порой слишком высокой, внутренней планке качества. Это когда даже мелкие детали, например анимация кнопок, должны быть безупречны перед запуском.
Вторая причина — это расширение объема задач, когда простой на первый взгляд продукт превращается в нечто огромное, напоминающее сложнейшие корпоративные системы, где уже тяжело уследить за всеми компонентами и взаимосвязями. Третья проблема — так называемое «заболевание функции», когда к проекту постоянно добавляют новые и новые возможности, которые часто не имеют прямого отношения к основным целям бизнеса и существенно усложняют разработку и поддержку. Наконец, профессиональная гордость, когда команда не хочет показывать пользователям недоработанную или частично реализованную версию, боясь критики. Эти четыре причины часто идут рука об руку и создают идеальный шторм для провала масштабного переписывания. Рассмотрим на примере — миграция с Angular на React в одной компании.
Изначально команда планировала полностью переписать весь фронтенд приложения, представив его как идеальный продукт. Первая попытка — попытка сделать все сразу — провалилась. Проект стал слишком масштабным и сложным. Затем объем задач вырос настолько, что превратился в нечто, похожее на соцсеть гигантского масштаба. При этом добавлялись дополнения по типу машинного обучения, которые хоть и выглядели круто, но никак не влияли на основной доход компании.
Еще хуже, проект не показывался пользователям, потому что «не готов». В итоге релиза не было вообще. И этот сценарий повторился несколько раз, даже в новых версиях другого продукта и редизайне сайта. Научиться на своих ошибках удалось не сразу, но опыт научил, что существует одна крайне важная вещь, о которой редко говорят открыто — реальная цена затяжных проектов не во времени, а в ментальной нагрузке. Каждый день, когда продукт не выходит на рынок, добавляется куча нового кода, который нужно тестировать, поддерживать и прорабатывать.
Появляются все новые и новые сценарии для проверки. Работа становится похожа на постоянное ношение тяжелого рюкзака с камнями — рано или поздно вы просто ломаете спину. Решение кажется парадоксально простым — выпускать продукт постепенно, иногда называемый инкрементальным запуском. Даже если релиз «кривой» и далек от идеала, именно такой подход приносит реальные выгоды. Например, когда команда впервые сделала миграцию на React небольшими частями, пользователи уже начали получать улучшения и давать обратную связь.
Баги фиксировались сразу и быстро, не копились накапливаясь лавиной. В итоге продукт стал гораздо лучше, а душевное состояние команды улучшилось. Следующий шаг — внедрение принципа двухнедельного цикла разработки. Выбирается конкретная небольшая задача или улучшение с четким ограничением по времени в две недели. По истечении этих двух недель задача должна либо выйти в релиз, либо быть пересмотрена с уменьшением объема.
Если цель слишком масштабная, она делится на более мелкие части, чтобы гарантированно получить его рабочий результат за короткий срок. Именно такой подход помогает снизить стресс и сделать процесс создания продукта предсказуемым и управляемым. Не все готовы признать простую истину — маленькие релизы означают меньше ошибок. Чем больше новых строк кода вы добавляете за раз, тем выше вероятность появления сложных багов. Ошибки «расползаются» по системе, вызывают цепочки новых ошибок, замедляют разработку и усложняют поддержку.
Реальность такова, что нельзя написать полностью идеальный код, способный сразу безупречно работать. Частота ошибок пропорциональна количеству кода, а иногда даже растет быстрее. Все это пленяет наглядно простой пример: при выпуске 100 строк кода, если появилась ошибка, ее легче быстро исправить, чем при выпуске 10 000 строк, где баги возникают как домино. Главный итог, к которому приходит каждый, кто попробовал инкрементальный подход — перестать относиться к релизам, как к магистерской диссертации. Не нужно ждать абсолютного совершенства и бояться показывать проект на ранних стадиях.
Пользователи гораздо больше ценят продукт, который работает хоть и с недостатками, но уже сегодня, чем затянутые проекты с обещаниями идеала в отдаленном будущем. Все эти уроки приходят через боль и ошибки — многократное повторение попыток запустить переписку «по-старому» и столкновение с одними и теми же проблемами. Только отпуская стремление к идеалу и принимая философию постепенных релизов, можно добиться стабильности, высокого качества и удовлетворения клиентов. Нельзя не отметить, что подобные принципы актуальны не только для технической части разработки, но и для принципов управления командами, разработки бизнес-моделей и стратегического планирования. В конечном итоге, учиться запускать быстро и поэтапно — значит принимать реальности рынка, пользователей и человеческой психологии.
Чем раньше мы услышим этот урок, тем больше шансов на успех в мире, где изменения происходят молниеносно, а конкуренция не дремлет. Перестаньте бояться несовершенства. Начинайте запускать сегодня. Маленькие шаги обернутся большими победами в будущем.
