В проектах редко случаются уникальные катастрофы.
Чаще всего это одни и те же сценарии, которые просто меняют маску.
Системное мышление называет их archetypes - типовые паттерны, по которым система сама себя загоняет в тупик.
Вот несколько, которые в IT встречаются чаще всего:
1. Лечение симптомов вместо причины.
Прод падает из-за архитектуры → команда заливает хотфиксы.
Качество кода падает → берут больше тестировщиков.
Сроки горят → кидают еще людей.
Симптом лечат, но корень остается, и проблема возвращается сильнее.
2. Эскалация конфликта.
Команда задержала релиз → заказчик усиливает контроль.
Контроль душит → команда скрывает проблемы.
Ситуация накручивается, пока все не выгорают.
3. Сдвиг бремени.
Вместо того чтобы чинить процесс, вводят костыли: еще один отчет, еще одну роль, еще один митинг.
Проблема маскируется, но система становится тяжелее и медленнее.
Как же это использовать PM-у:
- Узнавать паттерн. Важно уметь назвать сценарий: это дает язык, чтобы команда и заказчик перестали спорить «кто виноват» и начали обсуждать «как выйти».
- Задавать вопросы. «Мы лечим причину или симптом?», «Эта мера решает проблему или просто откладывает ее?»
- Встраивать в рутину. На ретро добавлять слой анализа: «В какой сценарий мы попали?». Это помогает не застревать в циклах.
- Объяснять наверх. Когда руководству сложно объяснить, что «еще 2 разработчика не спасут», архетип помогает показать схему повторяющегося провала.
Удивительное чувство, когда узнаёшь архетип:
ситуация кажется новой и сложной, а на самом деле это повтор старой истории.
И вот здесь ценность PM-а: не тушить пожар бесконечно, а сказать вслух - «мы в сценарии “сдвиг бремени”. Хотим продолжать или выходим из цикла?»
