Как мы уже писали выше, Ажайл предполагает:
Это действительно классные принципы. Они позволяют гибко реагировать на текущую ситуацию, актуальные тренды и реальные нужды клиентов. Постоянные релизы дают возможность мгновенно проверять и корректировать свежие идеи. Фокус на наиболее важных фичах позволяет эффективнее распоряжаться имеющимеся ресурсами и оперативно предоставлять самый актуальный сервис и самый востребованный функционал.
Такой подход черзвычайно успешен и эффективен практически в любых отраслях и особенно в IT!
Это все звучит прекрасно, но давайте взглянем на этот процесс с точки зрения бюджетов и сроков. Ведь менеджерам и владельцам бизнесса необходимо понимать кем, когда и за сколько будет реализован тот или иной функционал. Это необходимо, чтобы правильно расставлять приоритеты. Необходимо для планирования релизов. Необходимо для принятия стратегических решений по развитию компании и управлению ресурсами.
Например, вот типичные вопросы, ответы на которые черезвычайно важны при принятия управленческих решений:
Однако с ответами на эти вопросы у ажайла и начинаются проблемы... Поскольку дать прогнозы или оценку предстоящей работы в мире гибких разработок очень затруднительно: в ажайле нету детальных и четких планов, спецификаций и сроков. Более того, даже, если, приблизительная оценка будет дана, обеспечить ее выполнимость в течении цикла разрабоки очень сложно: наш изначально запланированный скоуп будет постоянно изменяться и корректироваться после каждой итерации. Будут появляться классные и свежие идеи, различные исправления, рекомендации, которые надо обязательно зарелизить в первую очередь. Да, да именно так и работает ажайл.
В данном месте адепты ажайла могут возразить – зачем нам сроки и бюджеты? ведь ажайл предполагает беспрерывную поставку наиболее приоритетных фич! После каждой итерации мы будем релизать новый функционал, который будет сразу начинать работать, приносить прибыль и давать возможность собирать фидбэк от реального использования!
Однако мы смеем не согласится с этим мнением.
Беспрерывно релизать новые наработки на live environment после каждой итерации – не всегда правильный подход! Очень часто, фича или продукт не является привлекательным для клиента, пока не реализован минимальный набор функционала. Будете ли вы пользоваться продуктом которые имеет только страницу приветсвия и логина? Зайдете ли вы повторно в интернет магазин который не дает возможности заказать покупки после токо как вы потратили время на просмотр и выбор товара?
А как быть без планирования сроков поставки фич? Ведь, как правило, перед запуском продукта или какого либо нового функционала - проводятся различные медийные и маркетинговые мероприятия, которые необходимо заранее запланровать и организовать. Или, новый функционал требует коррекций в различных областях вашего приложении, которые будут выполняться другими отделами или командами и эту активность необходимо синхронизировать.
Отсутствие же согласованного бюжета, вообще очень опасный подход при реализации проектов. Ведь определенные ожидания по размеру бюджета в любом случае присутствуют у всех участников. И в этом случае, неизбежное расхождение реального бюджета и ожидаемого будет порождать массу проблем: будет расти недоверие и напряженность между участниками проекта, будет вводится доплнительный контроль в процессы, там где котроль особо не нужен. А в некоторых случаях превышение бюджета может приводить к остановке разработки продукта, или увольнению части команды, что конечно же очень печально.
Все это выглядит и звучит так, что ажайл хорош только в “идеальных” проектах: когда у нас есть уже успешно работающий продукт, бездонные бюджеты, полностью лояльные клиенты и отсутсвие запутанных управленческих ситуаций
В более же реальных проектах: когда наши бюджеты и ресурсы имеют разумное ограничение, точные сроки реализации нового функционала должны быть определены и соблюдены с минимальной погрешность, когда наш продукт еще не стал лидером в своем сегменте и последствие от внедрения неудачных или неполных фич могут оказаться очень болезненными - следует пользоваться более консервативными методологиями, дающими больше предсказуемости и контроля
Но на самом деле это не так! Ажайл прекрасно подходит для любых компаний, команд и проектов! Однако, если в вашей копании или проекте вопросы планирования играют важную роль, вам стоит использовать так называемый гибридный подход – ажайл который включает в себя ряд лучших практик из проектного управления. На данный момент гибридных подход это луший выбор для организаций которые только начинают внедрять ажайл у себя!
Давайте тогда рассмотрим какие же элементы проектного управления следует включать в чистый ажайл, чтобы сделать его подходящим абсолютно любой компании, максимально уменьшить риск потенциальный проблем и максимально увеличть вероятность успешного завершения проета
Здесь нет необходимости оченивать проект максимально точно, хвати лишь высокоуровневой, приблизительной оценки. Также, если проект ожидается длительным, давать оценку на весь проект не нужно, достаточно оценить скоуп одной или нескольких ближайших фаз.
Такая оценка очень важна, поскольку:
При этом мы должны либо сохранить существующий road map без изменений либо аккуратного его перестроить в соответсвии с новыми глобальнцми целями! При этом перестройка роад мапа и последствие этих изменений должны быть совершенно прозрачны и понятны всем участниками
Это пожайлуй самый важный пункт! Как мы уже поторяли много раз, изменение приоритетов и скоупа ожидаемо и преветсвуется в гибких разработках, и как правило когда мы говорим об изменение скоупа, мы имеем ввиду его расширение. В этом случае, основная задача проектной команды - корректно перестраивать так называемый проектный треугольник, состоящий скоупа, сроков и ресурсов. Увеличение скоупа можно корректировать через добавление ресурсов или изменение даты финального релиза, но чаще всего корректировка происходит через ревайз скоупа: После каждого изменения в приоритетах или добавление нового функционал, проектная команда должна проанализировать все задачи запланированные на ближайший гранд релиз и сформировать новый скоуп и роад мап. Успешность реализации проекта практические полностью зависит от того на сколько правильно и прозрачно будут происходить эти коррекции!
Так как кореректировки в приоритетах и скоупе будут происходит достаточно часто, то постоянный ревайз скоупа превратисят в трудоемкой и проблематичной процесс для проектной команды и стекхолдеров. Ведь необходимо будет учесть зависимости между задачами, их важность, сложность и принять решение что и как может быть сдвинуто. Также не забудем про то что у нас может меняться размер команды: команда может увеличиваться или уменьшаться, люди будут будут брать отгулы, болеть и уходить в отпуска... и все эти изменения также необходимо учесть в обновленном road map.
Поэтому черезвычайно важно, использовать современные приложения для управления проектами (такие как TBB, Jira, Azure DevOps или другие). Это позволит сэкономить кучу времени при обработке изменений, позволит сделать процесс ревайза скопа прозрачным и понятным для всех участников, позволит не забыть и не упустить ни одного важного нюанса или задачи.
И вы будете приятно удивлены на сколько мощным, гибким и быстрым является ажайл!
Более подробно ознакомиться с одним из перечисленных инструментов по управлению проектами и другими нашими статьями вы можете здесь.
В следующей статье мы планируем рассмотреть вопросы использования ажайла в распределенных командах, находящихся в разных географических локациях и лучшие практики по построению самомотивирущихся команд
Продолжение следует...
