Читать книгу Bridge Framework - Группа авторов - Страница 3

Один проект, две реальности

Возьмем простую задачу: «Добавить фильтр по категориям».

В плане проекта это всего одна строка: пять story points, два дня – готово.

Проджект-менеджер видит deliverables. Milestone. Обещание стейкхолдерам.

Разработчик видит четыре сервиса, которые нужно затронуть. Legacy query builder, который никогда не проектировался для комбинированных фильтров. Миграцию схемы базы данных. Риск падения производительности на 100 000+ записей. И несколько неизвестных, которые проявятся только в середине реализации.

Ни одна из этих перспектив не ошибочна.

Но каждая из них – неполна.

И именно в разрыве между ними чаще всего и возникают проблемы в спринтах.

Аспект

Проджект-менеджер

Разработчик

Основная валюта

Timeline, scope, бюджет

Зависимости, техдолг, сложность

Временной горизонт

Milestones, спринты

Спринты + устойчивость на 1-3 года

Определение успеха

Сдали по плану

Система стабильна, нет сюрпризов

Карта реальности

План проекта

Техническая архитектура

Пять проявлений разрыва

#

Проблема

Видит PM

Видит разработчик

Следствие

1

PM недооценивает сложность

«Одна задача»

Граф зависимостей + миграции

Нереалистичные сроки

2

Разработчик не понимает контекст

«Зачем углубляться?»

«Не знаю, насколько жесткий дедлайн»

Перфекционизм или хак

3

Scope creep без пересмотра сроков

«Это же мелочь»

Неделя невидимой работы

Систематическая недооценка

4

Скрытые зависимости

«Почему вдруг блокер?»

«Это было очевидно»

Паралич в середине спринта

5

Невидимый техдолг

«Почему упала velocity?»

«Долг накапливался месяцами»

Постепенное замедление

Почему совет «просто больше общайтесь» не работает

Команды слышат этот совет постоянно. Но на практике он редко помогает – по трем структурным причинам.

Разные словари создают иллюзию понимания.

Обе стороны кивают, но вкладывают в одни и те же слова разный смысл.

Нет безопасного и структурированного способа сообщать плохие новости заранее.

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

Информация течёт в одну сторону.

Разработчик отчитывается перед проджект-менеджером, но стратегический контекст и причины решений редко возвращаются обратно к команде.

Проблема не в том, что команды недостаточно разговаривают.

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

Два реальных кейса

Кейс 1 – FinTech SaaS, 2024

Задача: «Фильтр по категориям». PM оценил в 5 story points. Разработчики выявили 4 сервиса, миграцию и риск производительности на 100k+ записей. Зависимость от ML-команды осталась неназванной. Результат: деградация производительности 40%, спринт сорван на 60%, потеряно $80 000.

Кейс 2 – Enterprise SaaS, 2025

Рефакторинг god-классов не был виден в плане проекта. Velocity начала снижаться. Проджект-менеджер интерпретировал это как падение производительности команды.

Результат – 18 часов простоя, два месяца вынужденного рефакторинга и потеря более $400 000 ARR.

Проблема в таких ситуациях – не в людях.

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