Неопытные IT-бизнесмены пытаются сделать универсальное решение, которое подойдет для решения разных задач и проблем. Т.е. мы сначала делаем, а потом думаем какие проблемы и задачи при продаже это будет решать. Наши решения основаны на видении продукта, которое будет меняться на ходу. Такой подход они называют аджайлом, и для этого нанимают скрам мастера/владельца продукта.

Это нормально, если мы готовы ответственно подходить к этому процессу. А именно, когда в процессе продаж (особенно бизнес на крупный b2b этим грешит) мы вдруг принимаем решение менять продукт, то это автоматически означает вовлечение разработчиков в принятие решения (в каком виде это будет), рефакторинг и прогнозирование поставки на основе их оценок.

Однако чаще всего разработчиков никто не спрашивает и решение принимается без них. Максимум - тимлида (proxy po) спросят. А это означает, что мы спускаем разработчикам дедлайн, и следовательно выходим в проектную историю, когда мы загоняем их в треугольник cost-scope-time и надо в него попасть. Качество падает, получается носорог. Бизнес недоумевает - а чего это цена story point-а стала такой высокой (обычно выражается в том, что даже самые маленькие доработки оказываются слишком трудоемкими)? Наверное разработчики обленились и работать не хотят.

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

Нам нужен JTBD-фреймворк, когда в принятии решений мы ориентируемся на реальные данные (или гипотезы) о задаче, которую решает клиент. Этот подход разрушает неэффективный подход к управлению продуктом. И основная трудность тут - убедить бизнес в том, чтобы перейти от рандомного потребления бюджетов b2b клиента к продуктовому портфелю из задач (юзер кейсов).

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