Читать книгу: «Bridge Framework»

Name: Bridge Framework
Rating: 5.0 (4 reviews)

Сервин Османов, Асие Абдуллаева

Шрифт:

Предисловие: Почему мы написали эту книгу

Этот фреймворк родился не из теории.

Он вырос из повторяющихся сбоев, которые происходят в командах снова и снова.

Разработчики получают задачи в духе: «сделай как в WhatsApp». Объем работы растет, но сроки остаются прежними. Архитектурные решения начинают обсуждать люди, которые никогда не писали код, а бэклог оказывается размытым или неполным.

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

Разрыв между проджект-менеджером и разработчиком – это не личная проблема.

Это архитектурная дыра в системе работы.

BRIDGE – фреймворк, созданный для того, чтобы закрыть этот разрыв.

Он не заменяет Scrum или Kanban. Он добавляет то, чего им часто не хватает на практике: структуру взаимодействия между управлением и разработкой.

Фреймворк состоит из шести слоев, которые создают общий язык, общую видимость процессов и совместную ответственность за то, что на самом деле происходит внутри спринта.

Для разработчиков – это способ вернуть инженерную экспертизу в процесс принятия решений.

Для проджект-менеджеров – инструмент, позволяющий заранее видеть риски и управлять проектами без неожиданных срывов.

Любая организация, создающая систему, неизбежно воспроизводит в структуре этой системы структуру собственной коммуникации. – Мелвин Конвей, 1968

Закон Конвея неумолим: разрывы в коммуникации внутри команды отражаются на самом продукте. BRIDGE устраняет оба.

Глава 1. Два мира, один разрыв

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

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

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

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

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

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

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

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

Аспект

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

Разработчик

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

Timeline, scope, бюджет

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

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

Milestones, спринты

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