Борис Вольфсон - Гибкое управление проектами и продуктами

Time-bound – цели со сроком

При обсуждении сроков выполнения задач или достижения целей нельзя не вспомнить еще один эмпирический закон – закон Паркинсона: «Любая работа увеличивается в объеме, чтобы заполнить все отпущенное на нее время». Из личного опыта скажу, что, когда у задачи нет срока, она вытесняется срочными делами и шанс, что до нее когда-нибудь дойдут руки, падает, поэтому при постановке любой задачи необходимо устанавливать срок исполнения.

Срочность целей тесно связана с достижимостью: чем меньше срок исполнения задачи, тем более она труднодостижимая, что надо учитывать при постановке задач (табл. 3.7).

Таблица 3.7.

Срочность задач

Концепция ограничения по срокам встроена в Scrum: итерации всегда фиксированного размера и команда четко знает, когда будет проводиться демонстрация результатов спринта.

SMART

Лишняя функциональность

Может показаться, что большое количество функций является конкурентным преимуществом, но почти всегда это не так. Более того, таким продуктом обычно сложно пользоваться, сложно его разрабатывать, да еще его очень сложно поддерживать.

Насколько дорогой окажется поддержка, сильно зависит от длительности проекта. Проиллюстрирую это следующим графиком, на котором по горизонтальной оси отложена длительность проекта, а по вертикальной – стоимость. Если стоимость разработки новой «фишки» фактически не зависит от длительности проекта, то стоимость поддержки в длительных проектах вырастает. В некоторой точке эти графики пересекутся.

На практике понять, где находится эта точка (и соответствующая длительность проекта), очень сложно, так как ее расположение будет зависеть от многих факторов. С другой стороны, ясно, что для проектов, которые достаточно коротки, выгодной стратегией будет создание «фишек» без оглядки на стоимость поддержки в противовес проектам с длинным жизненным циклом.

Зависимость стоимости разработки и поддержки от длительности проекта

Если со стартапами все понятно, то для анализа проектов с жизненным циклом, длительность которых измеряется годами, можно рассмотреть следующую формулу стоимости разработки и поддержки «фишки»:

FC = StoryPoints × StoryPointCost + SupportCost

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

Зависимость стоимости разработки и поддержки от времени жизни проекта

Из этого можно сделать следующие выводы:

• в бесконечном проекте важна только стоимость поддержки;

• чем длительнее проект, тем важней стоимость поддержки;

• в долгосрочных проектах нужно оценивать стоимость поддержки, а не разработки;

• чем длительнее проект, тем выгодней вырезать ненужные «фишки».

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

Глава 4. Управление командой

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

Гибкие методологии опираются на людей и взаимодействие между ними, поэтому грамотное управление людьми выходит на первый план. В этой главе мы выясним, как мотивировать команду, оценивать и развивать ее в сторону гибкости.

Что такое команда

Определений команды существует несколько десятков. Будем придерживаться следующего, которое дал Майкл Армстронг.

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

Этапы командообразования

Чтобы группа людей превратилась в сплоченную команду, она должна пройти несколько этапов. Наиболее распространенной моделью командообразования является модель Такмана.

Этапы командообразования

В своем развитии команды проходят несколько этапов.

1. Формирование.

На данном этапе происходит создание команды и постановка целей, распределение и закрепление ролей (в том числе социальных). Отдельные члены команды еще не очень понимают цель и задачи, которые перед ними поставлены.

Отсутствие направленности к цели у членов команды

2. Бурление.

На этом этапе участники осознают свои цели и определяют вектор движения. Обратите внимание, что векторы разнонаправлены между собой и с направлением, которое необходимо для достижения цели.

Разнонаправленность членов команды

Цель также стала более четкой и понимаемой для команды.

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

3. Нормализация.

Следующим этапом идет такой, когда члены команды притираются друг к другу и начинают двигаться сонаправленно.

Сонаправленность членов команды

Основной задачей скрам-мастера является помощь команде для перехода на следующий этап.

4. Функционирование.

На данном этапе команда становится самоуправляемой и способной оптимизировать свою производительность, поэтому векторы, направленные к цели, удлиняются.

Сильная сонаправленность членов команды

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

5. Расформирование.

Когда цели, поставленные перед командой, достигнуты, наступает этап расформирования и направление «движения» участников снова рассинхронизируется.

Рассинхронизация членов команды на этапе расформирования

Командообразование в Scrum. Как было описано выше, чтобы работать эффективно, команда должна находиться на этапе функционирования. Соответственно, главной задачей команды (и, в частности, скрам-мастера) является максимально быстрый переход между этапами (табл. 4.1).

Таблица 4.1.

Приблизительное время для различных этапов командообразования

Спринты предполагаются двухнедельными. Самый лучший вариант в таблице выше не описан: можно просто взять сыгранную команду.

Самоорганизация в командах

Давайте сначала четко определим, что не является самоорганизующейся командой и что не входит в ее полномочия.

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

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

Что же может команда, если цель ей ставится сверху? Она может выбрать максимально эффективный способ, которым будет достигать этой цели. Эффективность в данном случае можно измерить сроком, составом и ценой работ. При этом команде приходится адаптироваться к ограничениям, которые заданы в проекте, и условиям окружающей среды, потому что, как правило, механизмов влияния на них у команды нет.

Децентрализация и умение адаптироваться свойственны не только командам разработчиков. Посмотрите на колонию муравьев, как они строят муравейник и выполняют повседневную работу. Такая же параллельная работа ведется и в гибких командах: контроль и «власть» децентрализованы и распределены между членами команды. Соответственно, решения, из которых складывается конечный результат, принимаются каждым членом команды, разделяя ответственность, но не размывая ее между всеми.

Стили управления

В зависимости от этапа командообразования необходимы различные стили лидерства. Попробуем использовать для этого модель ситуативного лидерства, которую разработали Херси и Бленчард, и объединим ее с моделью Такмана.