Модель Кеневин (Cynefin framework) и теория запутанности.
В предыдущем обсуждении, среди регулярных вопросов на конференциях и в проектах звучит одно и тоже мнение - нам надо спланировать весь проект от начала и до конца. Чем сложнее и длительнее проект, тем план должен быть точнее и тщательнее проработан.
Пример. В одной большой промышленной организации планируется проект по переходу с одной версии ПО (система документооборота и BPM) на другую. Активных пользователей системы порядка 600. В проекте предполагается сохранение всего старого функционала и перенос архивных данных. Участники проекта: Заказчик – директор по ИТ, вендор – поставщик ПО и генеральный подрядчик (в другом городе), Исполнитель – местный интегратор.
Что требует Заказчик:
- Строгий подробный план до конца проекта
- Коммуникации ограничены
- Фиксированный бюджет
- Фиксированный срок
- Изменения в старой версии проводить по требованию (нет гарантии заморозки)
Что делает хороший руководитель проекта? Бегает в мыле, готовит план, нарушает план, пинает команду и проклинает тот день, когда он взялся за проект. И так каждый раз.
Можно ли жить по другому?
Прежде чем продолжить обсуждение, я хотел бы вспомнить про Теорию запутанности (complexity theory) и Cynefin framework (подробнее можно почитать здесь). Теория запутанности довольно новая отрасль науки и используется в философии, биологии, кибернетике, менеджменте. Согласно этой теории мы живем в окружении различных по типу систем (если мы говорим о системе, то мы подразумеваем некую согласованность: делаю Х, получаю результат Y):
- Системы упорядоченные простые: Х=Y. Мы делаем X и однозначно (линейно) получаем Y. Пример: производство табуреток.
- Системы упорядоченные сложные: Х===Y. Мы делаем X и получаем Y, но между ними есть различные стадии процесса. Пример: полет A380. При наборе высоты пилот изменяет положение руля, самолет идет на взлет, но между действием и результатом происходит цепочка событий.
- Системы хаотичные: X ~ Y?. Связь между Х и Y очень сложно определить (если она вообще есть). Пример: "хороший" пример - пожар в здании. События и процессы меняются настолько быстро и непредсказуемо, что результат невозможно предугадать.
- Системы запутанные: XY. X и Y связаны между собой. Если делаем X, то получаем Y, что вновь повлияет на X и т.д. Пример: представьте себе любой живой организм или организацию.
Вернемся к ИТ-проектам. ИТ-проекты отличаются друг от друга спецификой и реализуются в разных по типу системах. Поэтому и наши действия по проектам будут отличаться. В простых системах мы будем придерживаться четких инструкций (установка ОС), в упорядоченных сложных нам нужны эксперты для достижения результата. Именно в упорядоченных сложных работают практики по проектному управлению (PMI, Prince2 и им подобные). Если же у нас проект развивается в запутанных системах (разработка ПО в подавляющем количестве случаев), где много неопределенного, изменений, то нам нужны эмпирические и адаптивные практики. Именно здесь хорошо работают гибкие фреймворки, позволяющие ставить эксперименты, менять направление движения и пр. И, заметьте, при правильном выборе никакого противостояния «Классика» vs Agile нет.
Теперь давайте посмотрим на тот кейс, который был описан в начале. Возможно ли менеджеру проекта пойти по другому пути?
