Задачка для продуктового IT-менеджера

Представим себе, есть некий B2B продукт, который разрабатывает компания. К этому продукту подключаются крупные корпорации. Для успешной интеграции нужно доделывать ряд фич, индивидуальных для каждой корпорации.

Особенностью корпоративного рынка являются длительные разрывы между платежами и большими суммами, обычно раз в квартал. Когда влетает оплата — заказчик «наваливает» новых фич, которые ему нужны были «на вчера».

Сейчас процесс разработки устроен так: есть 3 отдела со своими командам, каждый из которых направлен на следующие цели:

1. Core Division — обязательные задачи по ядру продукта, без которых все упадет.
2. Support Division — поддержка фич, которые не вписываются в ядро и обеспечивают интеграции с заказчиками.
3. R&D Division — изучение и наработка новых фич.

Финансирование Core Division идет из остатков общего счета, куда принимают оплату от корпораций за сопровождения продукта.
Финансирование отделов 2 и 3 формируется отдельными контрактами корпорациями на разработку новых фич. Каждая фича — уникальна для конкретного заказчика. Те, которые удается унифицировать — идут в Core.

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

Для работы над проектами есть три роли, с которыми вам непосредственно, как продуктовому IT-менеджеру, придется иметь дело:

1. Бизнес аналитик. Он выслушивает хотелки корпоративных заказчиков, проводит примерный анализ на время выполнения и превращает хотелки в эпики.
2. Системный аналитик. Он декомпозирует эпики в сторисы, которые надо собственно закодировать.
3. PM. Декомпозирует с лидами сторисы в таски, на основе которых три вышестоящих отдела разрабатывает фичи, которые так страстно ждет заказчик. Тестирование и деливери выполняются автоматически при помощи фреймворка, который взят на аутсорс и проблем не создает.

А вот и те, кто создает проблемы в продуктовой компании:
1. Бизнес аналитик постоянно сетует на то, что надо перекраивать бизнес-логику фич и очень неохотно берут новые фичи. Качество их работы, эпики — оставляет желать лучшего.
2. Системный аналитик постоянно занят и отказывается декомпозировать, ссылаясь на плохое качество эпика.
3. PM — почти то же самое. Так как из-за особенностей оплаты корпораций — требования по фичам, изменения и отмены — влетают раз в квартал, то PM занимается обсуждением блокеров, переносами в беклог и прочими вещами с разработчиками.

Дополнительные условия задачи: каждый квартал приходят запросы на фичи, которые надо «на вчера», часть фич за прошлый квартал требуют правок и еще часть — оказываются ненужными.

Раз в квартал число фич в очереди очень большое. Корпорации требуют очень быстрых результатов. Не все фичи оказываются нужными. Но 10% тех самых фич, которые стали нужными — обеспечивают финансовую жизнь продуктовой компании.

Также, в Core Division — все стабильно, беклог на пять лет вперед и никаких нервов. Support и R&D — беклог максимум на квартал, шквал техдолга и фрустрация от бесполезности 90% написанного кода. Но именно они и дают те 10% фич. Какие именно 10% — неизвестно! Разработчик выдерживает 2 года и уходит, унося ценную экспертизу.

Собственно — ваша задача, это внести изменения и объяснить, почему они будут полезными для данной продуктовой компании. Напомню что вам делегированы полномочия на три команды и три роли. Менять типы заказчиков или нанимать стрессоустойчивых разработчиков — вы не можете.