Справедливость в работе с командой проекта: каскад vs скрам
Waterfall: команда как армия.
При каскадной модели команда формируется полностью на фазе инициации. Состав жёстко привязан к WBS (Work Breakdown Structure): аналитик, архитектор, разработчики, тестировщики, внедренцы. Каждой роли назначается процент занятости — часто волнообразный. В первом месяце аналитик загружен на 100%, разработчик — 0%, тестировщик — 0%. На третьем месяце аналитик — 20%, разработчик — 100%, тестировщик всё ещё курит. К пятому месяцу все бегут с криком «горим».
Распределение обязанностей формально описывается матрицей RACI (Responsible — Accountable — Consulted — Informed). На практике же Accountable всегда один (руководитель проекта), а Consulted — все, кто успел высказаться на последнем совещании. Вопрос «почему я должен исправлять чужую ошибку в требованиях?» — маркер зрелой Waterfall-команды.
Справедливость в каскаде достигается только двумя способами: публичная таблица нагрузки в человеко-часах по каждому исполнителю (обновляемая по факту) и регулярный пересмотр процентов занятости на стыках фаз. Без этого Waterfall превращается в систему, где самый ответственный сотрудник работает за троих, а самый дипломатичный — имитирует бурную деятельность.
Scrum: самоорганизация с элементами анархии.
В Scrum команда — кросс-функциональное ядро из 7±2 человек. Ролей три: Product Owner (владелец бэклога), Scrum Master (фасилитатор, не менеджер) и Development Team. Команда формируется один раз на старте и работает полным составом на каждом спринте.
Распределение задач происходит на Sprint Planning: команда сама выбирает задачи из Product Backlog, оценивая их в Story Points (относительная сложность). Никто не назначает задачи сверху. Это порождает главную проблему справедливости: «серые кардиналы» регулярно выбирают лёгкие истории, оставляя сложные новичкам.
Коллективная ответственность за Sprint Goal частично решает проблему. Если спринт провален — виновата вся команда, а не один «лентяй». Дополнительно используются два механизма: открытая доска задач, где видно у кого сколько активных историй, и Sprint Retrospective — ретроспектива, на которой команда обязана назвать тех, кто не дотягивал, и тех, кто перерабатывал.
Velocity (скорость команды) позволяет объективно сравнивать спринты. Если кто-то систематически берёт задачи на 2 Story Points, когда коллеги берут на 5 — это становится очевидным после двух спринтов.
Три ключевых отличия в подходе.
— При формировании команды Waterfall набирает всех до старта, создавая зияющие дыры в загрузке, тогда как Scrum ограничивается минимальным ядром и донабирает людей по мере необходимости.
— При распределении задач Waterfall использует директивное назначение через RACI и WBS — сверху вниз, а Scrum опирается на самоорганизацию снизу вверх через Sprint Planning.
— При оценке эффективности в Waterfall смотрят на процент фактической занятости к плановой, в Scrum — на Velocity и количество сложных Story Points на человека.
Ни Waterfall, ни Scrum не делают распределение обязанностей объективно справедливым. Waterfall честен в юридическом смысле: зоны ответственности прописаны, спрос строгий. Но он неизбежно порождает пиковые перегрузки и простои. Scrum создаёт иллюзию равенства, но требует от команды взрослости и готовности говорить друг другу неприятные вещи на ретроспективе.
Единственный известный способ приблизиться к справедливости — тотальная прозрачность. Открытые дашборды нагрузки, публичные оценки сложности и регулярные калибровки. Всё остальное — методологический театр.
#проектное_управление #Waterfall #Scrum #команда_проекта #RACI #WBS #StoryPoints #SprintRetrospective #методологии_управления #ваш_проектный_офис