Один мой коллега проджект-менеджер столкнулся с типичной проблемой. Четыре ключевых архитектурных компонента находились за пределами его команды. Из-за этого постоянно возникали зависимости и лишние согласования.
Он и раньше понимал эту проблему. Но она была размазана по десяткам ситуаций: тут ждем одну команду, там нужен чужой компонент, здесь снова зависимость. Все это было известно, но общей картины не было.
Он собрал с командой HeatMap в моем программном обеспечении для диагностики организации. И тут случился хороший aha-момент.
Оказалось, что команда самостоятельно выполняет 58% работы. Вроде немало. Но из 11 элементов беклога самостоятельно доводит до конца 0. То есть команда много чего могла делать сама, но закончить самостоятельно хотя бы один элемент не могла вообще.
Карта показала и причину: почти каждый элемент в какой-то момент упирался во внешний компонент или организационную функцию. И вот тут разговор про оргструктуру резко стал предметным.
«Мы за 2 недели на изи поменяли структуру департамента и втянули 3 компонента внутрь юнита, максимально легко и без сопротивления команд или менеджмента».
По словам участника, менеджмент понял ситуацию с первого раза, и end-to-end команда появилась за один спринт. Особенно зашел автоматический вывод по матрице: «юнит может начать работу, но не может закончить». Очень простая фраза, но она сразу отрезвляет.
Мне нравятся такие инструменты потому, что они делают видимым то, что до этого существовало только кусками в головах людей.
HeatMap — один из модулей моего ПО для диагностики и проектирования организаций. Там есть и другие модули, матрицы и способы посмотреть на организацию с разных сторон.
Мы используем этот инструментарий в двух программах — DAO «Дизайн адаптивных организаций» (ссылка) и DAO Практикум «Проектирование вашей организации» (ссылка).
На Практикуме участники работают со своей реальной организацией: собирают данные, визуализируют устройство системы и проектируют изменения.
Бывало: работаем много, закончить не можем?