Waterfall или Agile: как лучше управлять проектами
Выбор методологии для управления проектом влияет на весь ход работы. Чем отличаются Agile и Waterfall? Алексей Лихацкий, CEO IT-компании AppEvent, сравнил оба подхода и поделился историей применения Agile в своей работе.
Водопад и проворство: о чем речь?
Под словом «проект» можно понимать любое начинание, задумку, которая должна привести к определенному результату. Сдача экзамена в вузе, покупка дома или ведение собственного бизнеса. Именно о последнем я буду говорить в своей статье.
Если есть проект, есть и способы им управлять. Две самые популярные методологии Waterfall, в переводе с английского «водопад», и Agile, в переводе с английского «проворный», «ловкий». Кратко рассмотрим принципы каждого подхода.
Waterfall. Традиционный подход к управлению проектами. Проект реализуется последовательно в несколько стадий. Разом работать над двумя стадиями мы не можем. На каждом этапе ведется документация, фиксирующая прогресс. Вся работа сопровождается четкими требованиями. Они детально проработаны и зафиксированы еще в начале работы. Поэтому изменения в проект «находу» вносятся с трудом. За бюджетом и сроками выполнения проекта ведется жесткий контроль. Это позволяет точно прогнозировать расходы и дедлайны.
Agile. Гибкий подход к управлению проектами. Вся работа делится на короткие циклы — спринты или итерации. После каждого спринта продукт корректируется с опорой на анализ проделанной работы. Методология адаптирована под внесение изменений на любом этапе разработки. Из-за этого ведение документации уходит на второй план, важно качество продукта. Присутствует постоянная коммуникация как внутри команды, так и между командой и клиентом.
Сравнение методологий
Как мы убедились, в каждой методологии есть свои плюсы и минусы. Сравним их по тем критериям, которые я, как CEO IT-компании, считаю важными для построения успешного бизнеса.
Гибкость и изменения. Agile лучше адаптирован под внесение изменений из-за системы итераций. После анализа промежуточного результата можно внести изменения и адаптироваться под рынок. Изменения в среде играют большую роль в успешной реализации бизнеса. Изменения в законодательстве, способ потребления — все переменные могут сделать продукт неактуальным.
Планирование и прогнозирование. В этом аспекте побеждает Waterfall. Методология позволяет четко планировать сроки и бюджет. Agile в этом отношении менее предсказуем.
Возможность ускорения процесса. В этом аспекте лучше справляется Agile. Сроки гибче, а длительность спринта можно поменять, если этого требует заказчик. В Waterfall все сроки зафиксированы, а процессы берутся в работу линейно. Ускорить их выполнение сложно.
Взаимодействие с клиентом. Назвать однозначного победителя здесь сложно. Все зависит от характера клиента и его желания быть вовлеченным в работу над проектом. Если клиент готов постоянно работать с командой, методология Agile с тесным контактом между исполнителем и заказчиком подойдет идеально. Если же у клиента нет времени или желания на постоянные зум-коллы, лучше выбрать Waterfall. При использовании методологии основное взаимодействие происходит при формировании начальных требований.
Полезность выпускаемого продукта. Балл получает Agile за тесное общение с клиентом, следовательно точечное знание его запросов. Если мы знаем клиента и его потребности досконально, мы сможем создать более полезный продукт. Помимо этого Agile повышает актуальность продукта возможностью вносить правки и адаптироваться под новые условия рынка. Waterfall тяжело принимает изменения, следовательно снижает адаптивность, а в перспективе и полезность продукта для ЦА.
Ведение документации. Waterfall требует обширной документации на каждом этапе. В будущем она может служить полноценной инструкцией для создания подобного проекта. В Agile акцент сделан на промежуточные результаты и работающий продукт. Конечный результат важнее исчерпывающей документации. Из-за этого при использовании методологии документация может не вестись тщательно.
Самоорганизованность команды. Взаимодействие отделов и слаженность работы каждого сотрудника — это про Agile. Когда все этапы создания проекта запущены разом, отделам необходимо поддерживать внутреннюю связь. При работе по Waterfall мы не приступаем к дизайну, пока полностью не отпишем техническую часть проекта. Команды и специалисты сменяют друг друга. Самоорганизованность и корпоративная культура уходят на второй план.
Скорость получения первого результата. Здесь первенство забирает Agile с его распараллеленными процессами. После каждой итерации виден промежуточный результат. Бывает, что благодаря такому подходу запуск продукта отменяют уже на половине его создания. Потому что понимают, что результат не будет востребован. При работе с Waterfall первый результат мы увидим только в конце проекта. Из-за этого возникает риск позднего вскрытия проблем. Если ошибки допущены уже на стадии проектирования, последствия осознаем только после запуска.
Нет хорошей и плохой
Опирайтесь на специфику своего проекта при выборе методологии. Где-то однозначно подойдет Waterfall. К примеру, мы знаем, как класть асфальт или строить дом. Такие регламенты существуют. По ним и идем, перетекая из одного этапа в другой. Запараллелить работу паспортного стола и отказаться от Waterfall — до сих пор сложная задача.
В AppEvent мы выбрали Agile за гибкость, ежедневные митапы и гарантированную актуальность продукта на рынке. Однако мы помним, что эта методология может и навредить продукту. С Agile важно не «переработать» над проектом. Мы хотим идеал или то, что работает и закрывает боли аудитории? Это как уборка: помыли полы, хочется протереть пыль и помыть окна. Пока протирали пыль, полы уже не такие чистые. Снова начинаем мыть полы. Уборка никогда не закончится. Так может случиться и с проектом. Важно прийти к первой рабочей версии продукта. Выкатить ее, дать ЦА или клиенту изучить проект, а после вносить правки и стремиться к идеалу.
Какая методология ближе вам и почему?