Эту страницу открывают, когда PM и разработка вроде бы работают над одним проектом, но регулярно расходятся в темпе, приоритетах, трактовке рисков и оценке реалистичности решений.
Работа с разработкой для PM — это не про контроль технических деталей вместо команды, а про создание понятного, уважительного и управляемого контура взаимодействия вокруг сроков, качества, ограничений и решений.
Что это за компетенция
Это умение выстраивать рабочий стык между delivery-логикой PM и инженерной логикой разработки. Сильный PM не залезает в техническое лидерство, но и не снимает с себя ответственность за перевод технических сигналов в управленческие решения. Здесь особенно важна связка с требованиями, планированием и change management.
Зачем нужна
Она нужна, чтобы:
- собирать реалистичные сроки и обязательства;
- не терять технические риски между обсуждениями и статусами;
- переводить инженерные ограничения в понятный язык для стейкхолдеров;
- удерживать уважительный, но требовательный рабочий контур с командой разработки.
Как выглядит слабый уровень
- PM либо спорит с разработкой без понимания инженерной цены решения, либо полностью отдаёт управление течению событий;
- технические сигналы воспринимаются слишком поздно;
- разговоры о сроках быстро превращаются в спор о правоте людей;
- команда не верит, что PM действительно понимает цену технических ограничений.
Как выглядит сильный уровень
- PM рано вытаскивает инженерные риски и зависимости в управленческий контур;
- умеет задавать вопросы, которые помогают разработке раскрыть реальную картину, а не просто защищаться;
- не обещает наверх то, что не собрано снизу;
- удерживает одновременно уважение к экспертизе и требование к прозрачности, срокам и договорённостям.
Что ломается без неё
- PM либо давит на разработку без понимания цены решений, либо уходит в полную пассивность;
- технические риски поднимаются поздно;
- сроки и обещания обсуждаются без реальной инженерной базы;
- взаимное недоверие быстро съедает скорость работы.
Что делать пошагово
1. Отделяйте управленческую задачу от желания рулить технической реализацией. 2. Задавайте вопросы, которые вытаскивают риски, зависимости и цену решения. 3. Не обещайте сроки и объём без опоры на инженерную реальность. 4. Переводите технические сигналы в язык проектных последствий для стейкхолдеров. 5. Удерживайте уважение к экспертизе разработки, не снимая при этом требования к предсказуемости и прозрачности.
Типовые ошибки
- интерпретировать инженерную осторожность как саботаж;
- спорить с оценкой, не поняв её драйверы;
- не вытаскивать технические риски в управленческий контур;
- обещать наверх то, что не подтверждено снизу.
Как качать навык
- учитесь отличать техническую дискуссию от управленческого решения и не смешивать их в одном слое разговора;
- разбирайте прошлые конфликты через вопрос: где не был проговорён trade-off между реалистичностью, сроком и качеством;
- усиливайте связку с объяснением компромиссов и конфликтом с разработчиком.