​​🤼‍♀️ Разработчик →← Продакт

Общение продакта с разработчиком без участия проджекта может чревато отразиться на проекте. Если с этим ничего не делать. Когда у разработчика есть вопросы к продакту по фиче, кажется логичным сделать созвон и обсудить напрямую. В цепочке даже может не быть ПМа, так как коллеги в личке переписываются.

🛑Что может произойти на таком созвоне с невинной задумкой "да мне только прояснить":
1. Изменится scope. Например, решили что-то выкинуть из условий задачи или поняли, что хотим изменить описанную логику, чтобы улучшить эффект фичи.
2. Изменятся оценки. Изменение или прояснение scope не всегда, но часто влияет на трудозатраты в большую сторону.
3. Изменится бюджет. Где меняются оценки, там меняется и стоимость.

🤔Казалось бы, с продактом же общались, значит все ок - меняем. Но проджекту нужно поднимать попу и прояснять ожидания с другими заказчиками, если они есть. Нужно переделывать документацию, вносить изменения в договор, делать доп. соглашения. Встает вопрос, как это отражается на сроках проекта? Есть ли у нас на это бюджет? Если мы тратим меньше, то как осваиваем профицит? От компании и процессов зависит количество усилий, которое нужно теперь потратить, чтобы провести это изменение. И если проджект не знает об изменении, то в проекте появляется часовая бомба, чем дольше она лежит незамеченной, тем хуже от нее последствия. При этом у продакта и разработчика свой контекст, они живут в своих парадигмах. Разработчик же поговорил с продактом - значит делаем, продакт согласен. Продакт поговорил с разработчиком, разработчик ничего не сказал, значит все под контролем.

Сейчас может хотеться написать, что ПМ, который позволяет продакту и разработчику общаться напрямую - какой-то ненастоящий ПМ и злодей. Договоримся так: да, не всегда такое можно допускать и часто только в инхаус разработке. Но я вас умоляю, ПМ не должен бегать с палкой за каждой попыткой людей общаться, так и уволиться можно.

💊ПМ нивелирует риски не только за счет личного присутствия на обсуждении, для этого ему достаточно знать, что такая встреча будет и узнать результаты обсуждения. Зная результаты можно оценить масштаб влияния разговора на треугольник управления проектами и предпринять действия. Для этого полезно учить всех в команде вести договоренности. А со статистикой - чем такие обсуждения чаще всего заканчиваются, можно принимать решения - отпускать ли общаться продакта с разработчиками наедине со спокойной душой или самому подключаться на них.

#заказчик #манагерство