Пост о том, как мы в компании настраивали процесс коммуникации проектного офиса с командой разработки, которая у нас одна на несколько проектов.

Почему же мы решили что-то поменять? Случился обычный кейс растущей компании: руководитель проекта на словах изменил приоритет задачи (собравшись с тимлидом бэкенда). Через два дня другой РП попросил тимлида заняться другим — про первую договорённость он не знал. Задача, обещанная клиенту к концу спринта, выпала из плана. Что было потом на планёрке у CEO, думаю, представляете) Вообще, слабая коммуникация — одна из главных причин превышения бюджета и сроков проекта, наравне с ошибками в требованиях и нехваткой ресурсов.

Начиная строить процесс, покопался в теории, в релевантных кейсах. Модели коммуникации, которые выделил для себя: — Прямые встречи РП с исполнителями; — Дейли-стендапы — короткая синхронизация по статусу без длинных совещаний; — Регламентированная отчётность — фиксированные точки: списки задач на входе и выходе из спринта, статус-отчёты; — Эскалация через комитеты — решения по срокам и бюджету поднимаются на уровень руководства.

Вид методологии управления проектом во многом задаёт формат: как часто встречаемся, кто получает какие отчёты, как решаем споры. Отдельный вопрос — роли: тут пригодилась логика RACI — по каждой задаче явно понятно, кто её делает и отвечает за результат, кого нужно спросить перед стартом, а кого достаточно просто держать в курсе.

В компании мы начинали с прямых встреч РП и разработчиков. При команде в несколько человек это работало отлично: договорились — разошлись, минимум лишней документации. Проблемы начались с ростом числа параллельных проектов и их масштабов. Одни и те же вопросы обсуждали по кругу с разными людьми. Приоритеты, согласованные на одной встрече, терялись и не учитывались на следующей. Разработчики иногда получали противоречивые указания от разных РП, которые не видели общей картины загрузки друг друга. Встречи затягивались, при этом вопросы на встрече задавались поотдельно, а другие отделы вынуждены были ждать своей очереди. Со временем, методом проб и ошибок, PMO перешел на регламент вокруг спринта: список задач на входе — приоритизированный бэклог с явным владельцем и критерием готовности по каждой задаче уровня Epic (по сути, наш Definition of Done — без него "сделано" каждый понимал по-своему); список на выходе — что сделано, что нет и почему, какие блокеры возникли; финальная отчётность — сводка для проектного офиса. Таким образом приоритизация следующего спринта происходит уже по факту, а не по предположениям месячной давности (да, таски в жире обновляли далеко не все). Сама отчётность по спринту стала основой для статусов, которые я готовлю для руководства: данные уже зафиксированы, их не нужно собирать заново.

Нужно понимать, что формализация не универсальна, а регламент не стоит воспринимать как самоцель. Если список задач на входе и выходе спринта превращается в ритуал — с полями, которые никто не читает, и отчётами для галочки — команда воспринимает процесс как помеху.

Для срочных вопросов формальные точки не подходят: если в проде авария, никто не должен ждать «до следующего чек-пойнта». Мы оставили короткий прямой канал — рабочий чат, куда можно написать напрямую разработчику или РП в обход цепочки согласований (переместить бы его еще в рабочее пространство...). По сути, это наш SLA по реагированию на критические обращения: с учетом специфики ПО, счёт идёт на секунды. Переход от устных договорённостей к письменной фиксации иногда читается как недоверие, но здесь важно объяснить цель открыто: не контроль ради контроля, а общая память команды, которая экономит время всем.

Надо сказать, что даже сейчас мы этот процесс время от времени пересматриваем — когда снимать срез по задачам, как управлять ожиданиями заказчиков. И всё это работает, и планирование стало намного прозрачнее. Передать бы наш опыт на ступень выше... Но это уже совсем другая история)

Как у вас построена коммуникация между руководителями проекта и разработкой — на личных договорённостях или в явном фиксированном процессе?