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

27.07.18

Управление проектом - Agile

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

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

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

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

 

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-манифеста в работе, а когда, наоборот, всё шло наперекосяк из-за их игнорирования?

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

См. также.

Agile Бесплатно (free)

В статье рассмотрены практики, применяемые при разработке по методологии Agile.

13.05.2024    3326    0    Dimbayyyy    9    

10

Лидерство Личная эффективность Agile Анализ потребностей и поиск решений Бесплатно (free)

В семнадцатом выпуске второго сезона подкаста Радио “Аналитик“ обсудили, что из себя представляет модель Кеневин, чем и в каких ситуациях она может быть полезна тем, кто работает в сфере ИТ и не только.

19.04.2024    515    0    Radio_Analyst    0    

5

Agile Бесплатно (free)

Agile в ИТ встречается все чаще, и об адаптации гибких технологий под проекты 1С задумываются многие. Расскажем о ключевых инструментах и точках приложения усилий для успешного внедрения Scrum при разработке в 1С.

28.07.2023    2451    0    olegminkov    4    

7

Agile Руководитель проекта Россия Бесплатно (free)

Продукт команды №7, 6 поток (курс Марии Темчиной «Управление ИТ-проектами. Agile. Практический курс Agile-лидера»)

13.06.2023    1467    8    dimbasbear    1    

2

Agile Бесплатно (free)

На конференции Infostart Event 2021 Post-Apocalypse выступил директор практики БИТ:ERP компании Первый БИТ Глеб Стальной. В ходе доклада он рассмотрел трансформацию проектного подхода в продуктовый, рассказал про имплементацию «современных» практик DevOps и продемонстрировал инструменты для разработки, взаимодействия с бизнесом и клиентами, применяемые в его команде.

27.02.2023    2499    0    glebushka    2    

13

Agile Бизнес-аналитик Руководитель проекта Бесплатно (free)

Это один из вопросов, которые мне задают довольно часто. Ну да, Эджайл, Скрам, технологии, методологии,  красивые слова. Но где вы видели это в реальности в 1С внедрениях????

06.12.2021    4270    0    MariaTemchina    49    

13

Agile Бесплатно (free)

Есть сообщество в Facebook'е и Инстаграм, которое публикует жизненные комиксы про внедрение гибких технологий на практике - Comic Agile.

01.04.2021    3817    0    MariaTemchina    18    

16

Agile Руководитель проекта Бесплатно (free)

Коллеги, приглашаем поучаствовать в опросе - Agile в проектах внедрения 1С: реально работает или это миф? Интересен практический опыт!..

12.03.2021    8423    0    MariaTemchina    86    

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


Очень знакомо. И самый финиш когда мсо стороны заказчика принять стратегическое решение и продавливать его не кому))
Shmell; Трактор; MariaTemchina; +3 Ответить
2. MariaTemchina 1618 30.07.18 11:43 Сейчас в теме
(1) katenok86 - да, история знакомая. Вообще, очень часто запрос от клиента поступает на автоматизацию бизнес-процессов. А в действительности, при первом же взгляде на ситуацию аналитику становится понятно, что процессы-то прежде чем автоматизировать нужно банально выстроить, потому что они существуют в организации весьма условно. А, как выражаются менеджеры Сбербанка "автоматизированный хаос - это быстрый хаос!"... А выстроить бизнес-процессы у компании заказчика команда внедренцев ну никак не может...
3. Silenser 598 30.07.18 17:34 Сейчас в теме
(2)
автоматизированный хаос - это быстрый хаос!
Личный опыт говорит, что попытка автоматизации хаоса приводит к хаосу. Он не лучше и не хуже первоначального. Однако, в некоторых случаях визит представителя ИТ отдела в производственное подразделение приводит к тому, что люди понимают, что им нужен регламент работы, хотя бы его концепция, т.к. любой язык программирования достаточно формализован. Вот тогда ИТ может выступить в роли эксперта со стороны и помочь решить вопрос неопределенности. ИМХО.
MariaTemchina; +1 Ответить
4. MariaTemchina 1618 31.07.18 10:18 Сейчас в теме
(3) Silenser - вы привели удачный пример, спасибо. В моей практике тоже бывали случаи, когда система была готова к большей организованности, ей не хватало только удачного инструмента - и дальше ухватившись за необходимость прописать процедуру в ходе автоматизации, в дальнейшем ей начинали следовать и все были в выигрыше. Но, к сожалению, несколько чаще приходилось встречаться со случаями, когда организация вкладывает гигантские деньги во внедрение, допустим, MS Project'а, закупается ПО, пишутся регламенты, проводится обучение... И дальше все это кончается полным провалом, увольнением ответственных за внедрение и боьшим скандалом. Ибо менеджеры пишут в проджекте, что им в голову придет, планировать продолжают на коленке (или в чем они планировали). См. комикс в аттаче...
Прикрепленные файлы:
5. MariaTemchina 1618 31.07.18 10:21 Сейчас в теме
(4) Перевод комикса для тех, кто не владеет английским:

- Привет! Я из АйТи департамента и хочу спросить, насколько наша новая CRM-система упрощает вашу работу?
- Я рад, что ты спрашиваешь. Раньше, до того как появилась новая система, мне приходилось держать все мои контакты, письма, продажи и т. п. в куче разрозненных листов Excel. Но теперь, с тех пор как мы должны использовать новую CRM-систему...
... Мне приходится каждую неделю перебивать все записи из моих листов в новую систему, чтобы сделать вид, что я ею пользуюсь...
Shmell; myoker; AlenaR; Winstoncuk; PSKMOL; t.v.s.; Manoshkin; katenok86; Silenser; +9 Ответить
6. Silenser 598 31.07.18 15:05 Сейчас в теме
9. MariaTemchina 1618 31.07.18 19:00 Сейчас в теме
19. ovodkov 16.04.19 17:02 Сейчас в теме
К нам-автоматизаторам часто приходят так: "скажите как правильно" и начинается самое веселое. Я сейчас (апрель 19-го года) навнедрявшись и напроваливаливавшись проектов в том числе по гибким методологиям понимаю и пытаюсь в этом убеждать руководство и Заказчиков (работаю в консалтинге), что правильно работать по следующему алггоритму: если клиент новый - предлагаем внедрение Системы по Водопаду и, сделав что-нибудь маленькое, например, экспресс-диагностику за пару недели, понимаем специфику Заказчика, а поняв можно ли на этом Заказчике (Клиенте) использовать Agile или документы - наше все.
7. Neo0111 31.07.18 18:43 Сейчас в теме
Хм, мне показалось что "кейсы" выхватили лишь какие-то отдельные принципы Agile. Но суть Agile именно в применении всей совокупности принципов, а основная сложность внедрения - в изменении ценностей и способа мышления сотрудников. В противном случае, как пишут авторы книг по гибким технологиям, мы получаем "больше чем ничего".
8. MariaTemchina 1618 31.07.18 18:59 Сейчас в теме
(7) Да, firma111, вам совершенно правильно показалось. Даже авторы книг по гибким технологиям признают, что на практике имеет право на существование такая вещь как "гибридные методы".
10. Manoshkin 357 03.08.18 06:51 Сейчас в теме
Системы это хорошо. Но почему они работают, на какие тонкие струны души и тела они давят?
11. MariaTemchina 1618 03.08.18 10:00 Сейчас в теме
(10) Ах, Manoshkin... Это всегда непростой и немного философский вопрос - почему что-то работает так, как работает?.. Или наоборот, не работает так как должно?.. Недаром японцы считают управление проектами сочетанием науки и искусства...
12. yogaga 03.08.18 10:03 Сейчас в теме
(11) Японцы - вообще очень странный народ...
13. MariaTemchina 1618 03.08.18 10:33 Сейчас в теме
(12) Это точно. Но впахивать они умеют, этого у них не отнимешь...
18. RustIG 1688 01.11.18 10:16 Сейчас в теме
(10) системы выстреливают (то есть работают) благодаря профи, который их внедряет (использует).
14. capitan 2512 05.08.18 11:18 Сейчас в теме
Добавлю ложечку дегтя в эту статью меда.
Если вы читали статьи отцов-основателей Agile то наверняка обращали внимание - они прямо с порога говорят:
Главное в Agile (как и любой другой) - это команда
Без нее все манифесты - это просто набор бумаги

Так вот как раз японцы к командной работе готовы из коробки и для них все Agile манифесты это просто констатация факта
Как для нормального человека сказать что суп надо есть ложкой - он это и так знает с детства

А в наших реалиях как раз отсутствие команды и превращает Agile в набор красивых бумажек наклееных на доску
Winstoncuk; +1 Ответить
15. MariaTemchina 1618 06.08.18 14:49 Сейчас в теме
(14) Угу, capitan, не могу не согласиться.

Одно из ключевых ограничений Agile - он работает в команде замотивированных профессионалов. Нет команды замотивированных профессионалов - Agile не будет работать, увы.
Но это не повод не пытаться такую команду собрать и запустить. Ибо если получается - овчинка стоит выделки, еще как!..
16. Serg O. 270 05.09.18 06:57 Сейчас в теме
Внедрите нам новую систему, но чтобы всё было как в старой.
да и все 700 отчетов чтобы такие же были, они все "очень" нужны
Winstoncuk; MariaTemchina; +2 Ответить
17. MariaTemchina 1618 05.09.18 10:18 Сейчас в теме
(16) Да, Serg O. - очень знакомо. В этой ситуации заказчики, скорее всего, сами не задумываются, что же представляет для бизнеса ценность, а что нужно только "для галочки". Ну, и как результат, не могут конструктивно обсуждать это с командой внедрения...
20. 3soft 8 10.06.20 16:47 Сейчас в теме
Крупная компания внедряет SAP. В ходе проведения аналитики и сбора требований обнаруживается, что внедрение SAP затронет многие из регламентирующих документов, детально описывающие различные бизнес-процессы.... В общем, в итоге смогли принять и реализовать радикальное решение - все 63 регламента отменили, вместо них написали 2 по наиболее ключевым вопросам, внедрили SAP, бизнес-процессы работают через SAP без детализированного регламентирования


Не верится, что 63 регламента заменили 2-мя. Либо в SAP оказались заложены эти оставшиеся 61 регламент (т.е. доступен только вот такой workflow и ни шага вправо, ни влево; с SAP в этом плане не знаком), либо все осталось держаться на людях и их памяти/автоматизме. А людям свойственно уходить и приходить...
21. legrey 67 11.08.21 16:14 Сейчас в теме
"Итак, как же нам определиться - имеем ли мы дело с "продвинутыми гибкими методами" или с "разгильдяйством под прикрытием красивых слов"?"
Просто блестяще !
Мария, научите меня так красиво расстреливать идиотов.
Оставьте свое сообщение