Войти
Мастер-класс
«Про бизнес.» 7 сентября 2015

Как при планировании проекта не упустить из виду все задачи

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

Фото с сайта degraupublicidade.com.brФото с сайта degraupublicidade.com.brФото с сайта degraupublicidade.com.br
Фото с сайта degraupublicidade.com.br

– Упущенные работы приведут к тому, что их все равно надо будет реализовывать. Но ранее выделенных бюджета и сроков проекта уже не хватит.

Чтобы представлять рамки проекта, снизить вероятность того, что некоторые работы будут упущены – в некоторых методологиях управления проектами (например, в PMBOK) предлагают использовать Иерархическую структуру работ (ИСР). Англоязычное название – Work Breakdown Structure (WBS).

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

Обычно при создании ИСР возникает 2 ключевых вопроса:

1. По какому принципу делить проект на задачи?

2. На сколько уровней декомпозировать проект и когда остановиться?

Подходы к декомпозиции проекта

Разобьем эти подходы – на примере внедрения СRM в компании.

1. По результатам проекта. Все 4 результата проекта являются необходимыми для достижения конечной цели – CRM в компании должна приносить эффект для бизнеса.

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

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


3. По функциям (специализации труда). Этот подход подразумевает, что мы выделяем пакеты работ по принципу специализации труда. У меня получилась следующая картина:

В этом случае задействованы вот эти специалисты:

  • Сбором и анализом требований занимаются бизнес-аналитики
  • Разработку архитектуры и технического проекта выполняет обычно системный архитектор
  • Доработкой программного продукта занимаются программисты
  • Внедрением – консультанты (внедренцы)
  • Управлением проектом – руководитель проекта

Все эти специальности существуют в индустрии разработки программного обеспечения (ПО).

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

Вы спросите, а куда он «пропал» в варианте с декомпозиции по функциям? Отдельной профессии под этот вид работ в ИТ не предусмотрено. Но, исходя из моего опыта, эту задачу поручат, вероятнее всего, руководителю проекта. Значит, эта работа появится при декомпозиции пакета работ «Управление проектом» как дочерняя.

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

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

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

Принципы построения ИСР

Фото с сайта foto.basov.com.ua
Фото с сайта foto.basov.com.ua

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

2. У каждой дочерней работы может быть только одна родительская работа.

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

4. Дочерние работы, декомпозирующие родительскую работу, должны быть равнозначны. В качестве критерия равнозначности может выступать объем работ (трудозатраты) или длительность.

5. При построении иерархической структуры работ на различных уровнях можно применять разные критерии декомпозиции. Это наталкивает нас на мысль, что ИСР будет строиться на разных критериях:

  • На первом уровне иерархии мы можем использовать подход по результатам
  • На втором уровне – по жизненному циклу и т.д.

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

Это значит, что если при внедрении CRM вы будете использовать итерационную модель жизненного цикла проекта – структура работ по этапам проекта вам не очень подойдет. Если вы помните, при итерационном подходе сбор и анализ требований, разработка архитектуры, программирование и тестирование выполняются в каждой итерации. В этом случае, лучше на верхнем уровне ИСР прописать названия итераций, а при их декомпозиции – указать, какие требования войдут для реализации в каждую итерацию.

Глубина декомпозиции работ

Фото с сайта 1gai.ru
Фото с сайта 1gai.ru

Считается, что декомпозицию ИСР можно прекращать, когда работы нижнего уровня удовлетворяют условиям:

  • Требования к результату ясны и понятны руководителю проекта
  • За одной работой можно закрепить одного исполнителя
  • Трудоемкость (либо срок) работы не превышает определенного уровня

Для определения трудоемкости нужно вывести количественные значения. Условие может быть таким: трудоемкость работы не должна превышать 8 человеко-часов. К примеру, в проекте CRM руководитель проекта может контролировать подчиненных через ежедневные отчеты о потраченном времени.

Потенциально задача в 8 человеко-часов может быть завершена за один рабочий день – и это значит, период контроля и трудоемкость задач синхронизированы. И такая степень детализации является для проекта достаточной.

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

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

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

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


 

Комментарии

Войдите, чтобы оставить комментарий

Сейчас на главной

Новости компаний

Платный контент