Проектный треугольник

Поговорим о такой базовой штуке как проектный треугольник. С неё буквально начинается обучение управлению проектами.

В чём суть? Проектные ограничения складываются из трёх базовых вещей: сроков, денег, содержания. Из них складывается треугольник (тройственное ограничение), площадью которого становится качество. Если одна сторона изменится без изменения двух других, качество «протечёт».

Теперь детали.

Тройственное ограничение

Сроки

Временной компонент треугольника складывается из проектного расписания. Сколько часов вам нужно суммарно потратить на работы. Есть и вторая чиселка — итоговый дедлайн проекта или его фазы.

Важный момент. «Сделаю за два часа в течение недели». Иными словами, если сотрудник сказал, что ему нужно сорок часов на задачу¹, это не означает, что задача будет готова через неделю. Прочтите, пожалуйста, статью про утилизацию ресурсов.

Деньги

В айти деньги тесно связаны с временем, так как большая часть проектной сметы — зарплаты исполнителей. Мы мало утилизируем материалы, большинство библиотек и фрейморков бесплатны. Иногда требуются лицензии на специфические инструменты, но их доля невелика.

Ознакомьтесь с расходной частью P&L реального проекта:

Содержание

В содержание айти проекта входит результирующий продукт, состоящий из фич. Прочтите, пожалуйста, статью про ИСР.

Один из главных проектных рисков — расползание содержания. Заказчик может вас заверять на старте проекта — мы перечислили и заложили в ИСР точно всё. Новых фич не прилетит. Но новые фичи прилетят. Возможно, сразу после первого демо. Так устроено мышление заказчика, одно дело — представлять продукт в виде галлюцинации и совсем другое — увидеть его воочию.

Методика управления треугольником

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

• выбор гибкого ограничения;
• приоритизация фич;
• создание плана управления рисками;
• создание плана управления изменениями;
• сопоставление методологии управления с приоритетным ограничением.

Разберём их все:

Выбор гибкого ограничения

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

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

Приоритизация фич

Прочтите, пожалуйста, статью о MOSKOW. В продуктовой разработке приоритеты даст продакт. В заказной придётся ориентироваться на мнение заказчика. Некоторые фичи для него могут быть очень важны, другие — в меньшей степени. И этот список приоритетов нужно с заказчика получить. Даже если он будет говорить, что все фичи имеют высший приоритет, все они нужны и всё такое.

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

Создание плана управления рисками

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

Создание плана управления изменениями

От заказчика прилетает фича. Или имеющаяся фича кардинально меняется. Это должно быть зафиксировано, бюджет должен быть перевёрстан, изменение утверждено. Это база.

Теперь по плану управления изменениями:

Ограничения. Запишите ограничения, которые можно более гибко корректировать, чтобы реагировать на изменения.

Уточните процедуру выполнения запроса на изменение.

Параметры временных рамок запроса на изменение. Здесь прописываем, в какие сроки команда обрабатывает запрос на изменение.

Изменение процесса общения. Процедура, при помощи которой заказчик будет сообщать об изменении.

Инструменты управления изменениями. Какие инструменты будут использоваться для изменений. Первейший — экселька с реестром изменений.

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

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

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

Проектный треугольник в гибких методологиях

В скраме нет глобального плана проекта. Есть бэклог с приоритетами и бэклог спринта с фичами на итерацию.

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

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

---

1. Также нельзя забывать, что при восьмичасовом рабочем дне, сотрудник никогда не работает все восемь часов. При офисном варианте у сеньора получается четыре-шесть часов продуктивной работы. Удалёнщики более эффективны — у них меньше «отвлекалочек». ↩︎
2. Ладно, ладно. За сто с лишним лет существования олимпийского движения, Игры переносили шесть раз, из них пять раз в связи с войнами и один — из организационных соображений. Но вы прекрасно поняли мысль. ↩︎
3. Риск не всегда несёт увеличение бюджета. Бывают позитивные риски, которые бюджет уменьшают. Редкий, но встречающийся на проектах зверь. ↩︎