Лонгрид, будет полезен руководителям проектов и руководителям разного уровня, принимающим решения о организации проектной деятельности в компании.
Agile - веяние нового времени, которое с подачи некоторых “евангелистов” продается как самый лучший и инновационный способ делать проекты. Гибкие методики вошли в обиход не так давно, с середины 90х в западных компаниях, разрабатывающих софт, и прижились в России примерно с середины 2000х. Большую роль в этом сыграл Сбербанк со своим Сберджайлом. Теперь же Agile лепят по чем зря в разных сферах: от разработки автомобилей, до госуправления. Но так ли он хорош как о нем говорят и нужен ли он вам? Давайте разбираться.
Суть Agile - это создание гибкости при адаптации проекта к изменениям. Классические методологии, базирующиеся на календарно-плановом подходе, которые обобщенно называют Waterfall, сталкиваются с фундаментальной неустойчивостью перед изменениями. Это связано с тем, что проект в такой философии развивается последовательно, вначале определяются требования к продукту и проекту, затем на основании этих требований организуется команда, готовится план и бюджет проекта. Проект развивается по плану, то есть показатели эффективности команды сводятся к выполнению плана и бюджета. В случае, когда в проект нужно внести изменения, например добавить в продукт дополнительный функционал или поменять требования к качеству, - план вынужден меняться. Что сделать сложно, поскольку оптимальная реализация не сможет быть достигнута, на это понадобится дополнительное время и задел будет утерян. По сути - это шаг назад для проекта, возврат на этап планирования.
Agile, который подразумевает итерационный подход к реализации содержания продукта в этом плане выглядит более выигрышно, поскольку не требует жесткого соблюдения первоначального плана.
Но это преимущество является в свою очередь и серьезным недостатком, который по какой-то причине часто вычеркивают из контекста.
Гибкий подход не позволяет встроить в проекта длинноцикловые работы и работы по реализации мандаторных требований, например сертификацонных, поскольку такие работы сложно разделить на инкременты и сложно приоритизировать и арбитрировать такие требования, они просто должны быть реализованы.
Проще говоря, если вам надо сертифицировать продукт, хотите вы этого или нет, вам придется закладывать соответствующие нефункциональные требования в скоуп с самого начала, вам придется делать валидацию продукта для проверки выполнения этих требований и вам придется проходить сертификацию. Регуляторы очень не любят когда им дают на проверку продукты, не соответствующие стандартам. И Agile определенно не поможет сократить количество ресурсов необходимых на эти работы или сократить сроки их выполнения, при этом он может привести к тому, что важный функционал потеряется в бэклоге и заблокирует весь проект на последних стадиях.
То же самое касается отраслей, в которых реализация проекта по определению последовательная, например строительство. Если вы возводите каркас здания, то вам всегда нужно сначала связать арматуру, потом поставить опалубку и только потом лить бетон. Поменять последовательность этих работ в бэклоге не получится. Инача будет как в той советской шутке про несогласованность: “Даешь перевыполнение плана по замесу бетона”.
Проблемы с Agile также возникают в проектах, в которых требуется координация множества разрозненных команд. Например при создании новых летательных аппаратов, где продукт состоит из тысяч компонентов и систем, требует подготовки производства, создания оснастки, подготовки инфраструктуры для эксплуатации нового типа воздушного судна.
Синхронизация подрядчиков и соисполнителей - это не только максимизация темпа проекта, но и торможение, в случае когда какой-то из элементов проекта не успевает к сроку. В SCRUMе (популярный agile фреймворк) слаженно работающая команда проекта - это завод по выпуску нового функционала продукта, тактом производства которого является спринт, и такой завод очень неустойчив когда его нужно затормозить. Классическая организация куда лучше справляется с ситуациями задержек фаз, она просто не станет делать следующий этап работ, пока предыдущий не был завершен. Люди работающие в таких проектах привычны к таким поворотам событий и, при нормальных условиях, тратят простои на развитие, на формализацию опыта и документацию выученных уроков.
SCRUM же накапливает активы проекта (методологические изменения, шаблоны, выученные уроки) в рамках плановых ретроспектив, завершающих очередной спринт. И если вынужденный простой в проекте (не по вине команды) после отгрузки очередного инкремента занимает больше чем несколько дней - темп и мотивация команды в перспективе существенно падает, происходит эффект “обнуления” в головах исполнителей.
Следующий фактор, который накладывает ограничения на работу по гибким методологиям - это удаленность разработчика от клиента в контексте организации. Под этим понимается то, насколько часто и близко исполнители могут общаться с финальным клиентом, как много передаточных звеньев по пути от “запроса клиента” до списка задач исполнителя.
Agile подразумевает очень короткую дистанцию, при которой исполнители могут прямо общаться с клиентом, или наличие максимум одного передатчика информации в лице Владельца продукта.
Представим себе автомобильный продукт, планирование которого содержит в себе:
- Опросы клиентов
- Анализ рынка, в части аватара клиента, его поведения, особенностей эксплуатации, конкурентов
- Анализ регуляторных требований
- Анализ локальных нормативных актов
- Анализ технологических возможностей завода-изготовителя, на котором планируется развернуть производство
- Анализ потребительских свойств, технического и технологического исполнения продуктов конкурентов
И множество других активностей, на реализацию которых автопроизводители тратят годы и ресурс команд экспертов в различных областях.
Явно, что инженеру, разрабатывающему, допустим, раму сиденья, разобраться с таким объемом материала практически невозможно. Именно поэтому инженеру нужно ТЗ в котором будет описано что именно ему нужно сделать, а субъективное восприятие клиента, не прошедшее переработку в ТЗ, скорее уведет инженера от хорошего результата, чем поможет в этом.
Следующий немаловажный фактор, это менталитет и восприятие реальности исполнителями. Представьте что ваш исполнитель ходил в среднестатистический детский сад, в котором его приучали с малых лет делать то что говорит воспитатель, потом он пошел в школу, где его оценки зависели в основном от дисциплины и выполнения образовательного плана и лишь отчасти от его творческих возможностей, потом в институт, где успех зависел от явки на лекции и семинары, а потом он ещё отслужил в армии, где его насиловали, чтобы добиться послушания.
Agile подразумевает что команда исполнителей самоорганизуется, что возможно только при высоком уровне профессионализма, развитых творческих способностях, и хороших коммуникативных навыках исполнителей. К сожалению, таких людей в принципе мало, и платить им нужно выше рынка, что является существенной преградой для формирования эффективных agile-команд.
Таким образом, Agile ограниченно применим или не применим вовсе в проектах и организациях, в которых:
- К продукту применяются нефункциональные требования, не подлежащие арбитрированию, например сертификационные требования,
- Цикл создания продукта достаточно долгий, например год и более,
- Проект имеет большой масштаб и требует работы со смежникам, синхронизации внутри проекта с различными подразделениями, например как в авиастроении,
- Проект реализуется в сфере, подразумевающей последовательную (линейную) реализацию проекта, например строительство,
- Клиент удален от непосредственного исполнителя работ более чем на одно промежуточное звено в коммуникации, например проекты с гос. участием и финансированием,
- В проекте работают исполнители со слабо простроенной мотивацией, заурядными способностями и не развитыми коммуникационными навыками.
Таким образом, если ваша организация или проект характеризуется одним из приведенных выше тезисов, автор советует рассмотреть альтернативные методы организации проекта и оставить Agile тем, кому это действительно нужно.
