Почему Agile превращается в Тяп-ляп. Кто виноват и что делать?

В комментариях к моей прошлой статье, где я описывала разные подходы к проектному управлению, мне задали очень хороший вопрос - а как понять, чем отличается Agile (гибкие методы управления проектами) и Do & Fix (или, попросту говоря, "Тяп-ляп")?.. Пожалуй, разверну мой ответ из комментариев в отдельную статью. Сразу оговорюсь: в отличие от, к примеру, Джеффа Свазерленда, автора книги "SCRUM: Революционный метод управления проектами", я ни секунды никого не уверяю, что всеми проектами обязательно надо управлять именно по гибким методологиям. Все проекты разные, все ситуации разные. Как я уже писала, стоит проанализировать большое число факторов, и дальше уже определиться с методами. Типовые внедрения, чаще всего, удобнее делать по водопаду, а различные доработки с размытым ТЗ, либо инновационные проекты - как раз по Agile. На практике разные подходы в "чистом виде" встречаются несколько реже, чем в умных книжках, большая часть практикуют так называемые "гибридные" модели. Но по моему опыту от применения (с умом!) в проектном управлении принципов Agile выигрывают практически любые проекты.

Итак, как же нам определиться - имеем ли мы дело с "продвинутыми гибкими методами" или с "разгильдяйством под прикрытием красивых слов"? Иными словами - как отличить Agile от подхода Do & Fix (оно же Тяп-ляп)? Попробую рассказать на конкретных примерах. Героев называть по понятным причинам не буду. 

Давайте начнем с того, что почитаем и поосмысляем Agile манифест:

И особенно внимательно его нижние строчки. Потому что, если мы правую часть откидываем в принципе, мы как раз и получаем Do&Fix.  Таким образом, мы можем взять манифест в качестве своеобразного чеклиста, и пройтись по всем его четырем пунктам: 

1. Люди и взаимодействие важнее процессов и инструментов

Проверяем себя:
- Главным фокусом внимания для нас являются люди и взаимодействие? 
- На этом фоне уделяем ли мы внимание процессам и инструментам? 

Кейс № 1. Пример фокуса внимания на людей и взаимодействие (Agile)

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

Кейс № 2. Пример фокуса внимания на процессы и инструменты (Классический подход)

Согласно регламентам поставщик обязан выполнить поставку в течение месяца. Данный срок для клиента не приемлем, и он пытается договориться с руководителем проекта, чтобы ему пошли навстречу и сделали отгрузку раньше.  Команда проекта идет к отделу закупок и объясняет ситуацию: на складе есть нужная продукция, зарезервированная для другого клиента. Но тому она понадобится не раньше, чем через полтора месяца (к какому моменту ее сто раз успеют доставить еще раз), а другому клиенту нужна сейчас. Начальник отдела закупок в ответ делает лицо кирпичом, и сообщает, что не может нарушить регламент, и предлагает сделать заказ установленным порядком в течение месяца. Услышав ответ от команды проекта, клиент закономерно уходит к другому поставщику. Вместо ситуации "win-win" (выиграл-выиграл) получаем потерю клиента.  

Кейс № 3. Игнорируем процессы и инструменты в принципе (Do&Fix) 

За счет государственных заказов организация выросла из научной лаборатории в довольно крупное опытное производственное предприятие (около 200 сотрудников). А бизнес-процессы - не выросли, и так и остались построены по принципу "как получается, так и работаем"...  Когда было принято решение автоматизировать бизнес-процессы, решили их не описывать/не выстраивать, а просто идти от имеющихся людей и взаимодействий. Что получилось? "Автоматизация хаоса приводит к автоматизированному хаосу" («Реинжиниринг корпорации: Манифест революции в бизнесе» Майкл Хаммер и Джеймс Чампи). Вы уже поняли - бардак получился. Если структура бизнес-процессов не выстроена, если нет понимания, какова цепочка создания ценностей - то попытка внедрения "Agile" приводит только к усилению бардака. 

2. Работающий продукт важнее исчерпывающей документации

Проверяем себя:
- Мы стремимся в первую очередь производить работающий продукт? 
- При этом, заполняем ли мы необходимую документацию? 

Кейс № 4. "У нас Эджайл, мы работаем без документации" (Do&Fix)

Дано: ИТ подразделение банка, перешедшее на Agile. Руководителю удалось убедить заказчика и спонсора, что из принципа "работающий продукт важнее исчерпывающей документации" следует, что можно выпускать продукты вообще без документации. Главное, работающий продукт - не правда ли? И таки умудрились каким-то образом передать в эксплуатацию недокументированный функционал. Все было хорошо, пока не произошел реальный сбой - и в результате работа АБС банка чуть не остановилась. Коллеги, это не Agile, это разгильдяйство. 

Кейс № 5. Продукт на первом месте, документация - на втором (Agile)  

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

Кейс № 6. Документация на первом месте, продукт - на втором (распространенный подход)  

В этом месте можно описать все ситуации, когда команда увлекается написанием и подготовкой документации, и до собственно работающего продукта дело доходит не сразу (или не доходит вовсе). При этом при определенном везении команде могут довольно длительное время подготовительный процесс оплачивать - люди же работают, документации сколько (в одной компании мне предложили даже измерять продуктивность работы РП количеством подготовленных документов)!.. Получается в итоге как в анекдоте: "Были когда-то такие птицы, птеродактили. Летать они, правда, не летали, зато планиииировали!!!" 

3. Сотрудничество с заказчиком важнее согласования условий контракта 

Проверяем себя: 
- Готовы ли мы к сотрудничеству с заказчиком (вместо приглашения юриста для объяснения, что мы ничего не обязаны)? 
- На этом фоне, относимся ли мы уважительно к контрактным обязательствам? 

Кейс № 7.  Эффективное сотрудничество (Agile)

Представляем на минутку такую картину:

- Заказчик доверяет исполнителю, исполнитель доверяет заказчику (уже знакомы, уже сотрудничали, понимают, что репутация дороже, чем моментальный выигрыш)

- Исполнитель настроен максимально вложиться, чтобы заказчика оставить довольным

- Заказчик готов справедливо оплатить работу исполнителя и не заинтересован максимально раскручивать того на деньги.

Представили? (Не очень сложно было?) Вот если нам удается выстроить такую среду - Agile имеет шансы работать полноценно. Да, конечно, контракт есть - и он предполагает какой-то объем работ. Но каждая из сторон готова в разумных пределах пойти навстречу. Например, если заказчик просит что-то  сверх контракта - то команда разумно договаривается на обоюдовыгодных условиях - например, давайте мы вот эту функцию в бэклог добавим, а вот эту из нее, наоборот, уберем - как стало понятно по ходу работы, она не такая уж принципиальная... Кстати сказать, в моей практике подобного типа договоренности встречались и в самых водопадах-водопадах. Допустим, ТЗ на разработку банковского приложения составлено в деталях уже не первом этапе, требования согласованы на самом верху и изменению не подлежат, а посреди проекта бизнес-подразделение слезно просит добавить еще некоторый функционал, потому что к середине проекта уже стало ясно, что без него - никак. Окей, отвечают разработчики - что ж мы, звери, что ли? Добавим. Только чур, тогда мы не будем делать упомянутые в ТЗ "для галочки" 10 никому не нужных отчетов... Так что и в водопаде вполне смена правил игры случается, но - в данном случае она полулегальна, и отдел сопровождения, когда ему передадут приложение, в котором часть заявленного функционала не разработана, а часть наоборот - добавлена, но не задокументирована - будет, мягко выражаясь, не очень довольна (а правилами безопасности банка команда разработки не имеет право заниматься сопровождением рабочей эксплуатации).  

 Еще раз повторюсь, при условии доверия, ценности репутации, большого горизонта планирования у обеих сторон и самодисциплины исполнителя - такая схема вполне может работать со многими заказчиками (не со всеми), проверено. В моей практике чаще всего хорошо работает  взаимодействие в формате "джентельменских соглашений" на уровне доп.соглашений, сверх основного пакета работ.  -  А если что-то идет не так -  см. следующий кейс:

Кейс № 8. Сотрудничество не сложилось

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

Либо другой вариант несложившегося сотрудничества. Взаимодействие заказчика с командой  происходит в основном до подписания контракта и составления ТЗ. На демонстрации к команде представители заказчика не являются (или присылают кого-то не имеющего отношения к принятию решений). Переданные прототипы никто не смотрит, промежуточные версии рабочего продукта никто не проверяет на местах. На этом месте мы теряем ту самую гибкость и обучаемость Agile - и возвращаемся к Do & Fix. 

4. Готовность к изменениям важнее следования первоначальному плану 

Проверяем себя:
- Готовы ли мы к изменениям? 
- Есть ли у нас первоначальный план, и отталкиваемся ли мы от него при изменениях? 

Кейс № 9. Первоначальный план превыше всего (водопад)

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

Кейс № 10. Реагируйте на изменения, а о планах вам знать необязательно (Do&Fix)

Мне приходилось участвовать в проекте внедрения ERP-системы в организации на фоне отсутствия у руководства картины, как должны быть выглядеть бизнес-процессы после ее внедрения. "Передача заказа на производство - только после готовности и оформления всех комплектующих. Иначе - только через мой труп!" - объясняет начальник производства. "В ситуации задержки по срокам мы не можем ждать полной комплектации, и тем более готовности бухгалтерских документов, запускаем как только есть возможность, можем фиксировать это во второй базе 1С. Иначе - только через мой труп!" - отвечает исполнительный директор. "Никаких двух баз 1С, все должно быть максимально прозрачно и в одной базе, иначе - только через мой труп" - машет главный бухгалтер. На этом месте у аналитика при сборе требований возникает вопрос, куда девать столько трупов - как можно определить в таких условиях направления движения?...  Пришлось сначала инициировать стратегическую сессию, понимать виденье организации производства, и только потом стало возможным внедрение ERP-системы.

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

Итак, мы с вами прошлись по всем принципам Agile манифеста. Если мы на все вопросы ответили "Да" - то можно говорить, что у нас гибкие методы управления проектами. Если каждый применяет какие попало инструменты, документация не соответствует продукции, контракт "для галочки", сроки точно сорваны под предлогом изменений - простите, но это Do & Fix. 
В общих словах - примерно так. Коллеги, поделитесь вашим опытом? Когда на вашей памяти, удавалось успешно применить принципы Agile-манифеста в работе, а когда, наоборот, всё шло наперекосяк из-за их игнорирования?

Подробнее об управлении ИТ-проектами вы можете узнать на моих онлайн-курсах