3 ситуации, в которых вас спасет только Agile

В последние годы гибкая методика разработки медленно, но верно вытесняет классическую: с фиксированной ценой и сроками.

Уже разработаны миллионы, если не миллиарды сайтов, приложений, программ, баз данных. Какие-то из них благополучно завершают свой век навсегда, какие-то разрабатываются заново, если имеют успех. Но большая часть востребованного ПО развивается, модифицируется, приобретает новые свойства и функции.

В последнем случае в цикле жизни ресурса обычно участвуют несколько команд разработчиков, меняются программисты внутри команд. Стиль и качество кода внутри проекта могут сильно различаться.

Заказчики, привыкшие работать по старинке, с фиксированными сроками и ценами, опирающимися на договоры подряда, регулярно сталкиваются с тем, что исполнитель в какой-то момент уходит из проекта. Будь то компания или фрилансер. Озвучены могут быть разные причины: новый большой проект, нет разработчиков, состояние здоровья. Некоторые просто перестают выходить на связь. Причина в следующем: заказчик стремится снизить стоимость, продавливая бюджет в сторону уменьшения, разработчики идут на поводу. Некоторые в стоимость не закладывают даже минимальных рисков. В итоге они сталкиваются с тем, что реальный объем работ оказывается в разы больше оцененного, и принимают решение выйти из проекта, даже если это приведет к убыткам. Либо запросить пересмотр договора для фиксации реального бюджета. Но часто заказчики не готовы пересмотреть стоимость работ.

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

Гибкая схема, которая изначально не предполагает фиксирования цены и сроков, исключает такие ситуации. Работа оценивается приблизительно; в случае возникновения факторов, значительно увеличивающих объем работ, исполнитель уведомляет об этом заказчика. Вознаграждение всегда справедливое, согласованное заранее – стоимость часа.

IТ сфера развивается стремительно, сегодняшние требования к продуктам могут отличаться от прошлогодних так же как iPhone1 от iPhone 14 Pro Max (да-да, железяки развиваются и меняются медленнее, хотя и вносят свою лепту в скорость развития программного обеспечения).

Любая новая идея продукта еще на ранних стадиях его разработки может стать уже старой идеей продукта, внедренной с десяток раз у конкурентов.

Классическая схема с написанием огромного технического задания и несколькими месяцами его согласования и уточнения не подходит. Как не подходит и вариант точной оценки для требований из пары-тройки страниц. Особенно если проект немаленький.

Как же тогда получить новый продукт и вовремя, чтобы успеть захватить рынок или его часть?

В ситуации, когда новый продукт нужно вывести на рынок как можно быстрее, тоже удобна и незаменима гибкая схема разработки. Первым делом из набора идей и пожеланий стейкхолдеров выделяется самый нужный функционал, необходимый для проверки идеи проекта. Он-то и реализуется в MVP ─ минимально жизнеспособном продукте. И уже после запуска проекта он дорабатывается, исходя из сегодняшних требований рынка и моды, а не тех, которые были прописаны в огромном техническом задании год или два назад.

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

Зазевайся такая компания, остановись на месяц на согласовании ТЗ, и штат разработчиков, от 500 до нескольких тысяч человек, принесет убыток от 50 миллионов рублей.