До какой степени нужно детализировать задачи?

Планирование проекта

Уточнение содержания и состава работ

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

Иерархическая структура работ (ИСР) (Work Breakdown Structure, WBS) - ориентированная на результат иерархическая декомпозиция работ, выполняемых командой проекта для достижения целей проекта и необходимых результатов. С ее помощью структурируется и определяется все содержание проекта. Каждый следующий уровень иерархии отражает более детальное определение элементов проекта.

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

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

Выполнять декомпозицию работ проекта можно по-разному. Например, ГОСТ 19.102-77 предусматривает каскадный подход и определяет следующие стадии разработки программной системы:

1. Техническое задание

2. Эскизный проект

3. Технический проект

4. Рабочий проект

5. Внедрение

Если следовать этому стандарту, то на первом уровне ИСР должны находиться именно эти проектные продукты. Если бы пришлось разрабатывать АСУ для управления ядерным реактором или пилотируемым космическим аппаратом, то именно так и следовало поступать. Однако в коммерческой разработке ПО такой подход не эффективен. Как мы уже говорили, современный процесс разработки коммерческого ПО должен быть инкрементальным. Это означает, что на верхнем уровне декомпозиции нашего проекта должны находиться продукты проекта, а на следующем уровне - компоненты, из которых эти продукты состоят. Компоненты далее могут быть декомпозированы на «фичи» - функции, которые они должны реализовывать.

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

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

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

Например

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

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

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

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

• Никаких пропусков. Это означает, что все действия по выполнению вашей главной задачи (написание отчета) включают три описанные подзадачи. Если вы полагаете, что необходимо выполнить еще какую-либо работу, определите ее как четвертую подзадачу в общей схеме.

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

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

Соблюдайте иерархию

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

Уровни детализации общей задачи выглядят так:

• уровень 1 — общая задача;

• уровень 2 — отдельные задачи;

• уровень 3 — подзадачи;

• уровень 4 — подзадачи более низкого уровня.

До какой степени нужно детализировать задачи?

Определить степень детализации — не такая уж простая задача. Даже опытные проектные менеджеры не всегда могут уловить момент, когда следует остановиться. Одна моя клиентка рассказывала, что шеф поручил ей спланировать личный фронт работ на 12 месяцев с интервалом в 20 минут. Это задание вызвало у нее легкий шок.

Выделить существенные детали общего комплекса работ, не распыляясь на мелкие операции, помогут три вопроса.

Три ключевых вопроса

1• Можете ли вы точно оценить необходимые ресурсы для выполнения данной работы? Ресурсы — это персонал, оборудование, сырье и материалы, финансы, вспомогательные средства, информация и т. д.

2• Можете ли вы точно рассчитать время для данной работы?

3• Если вы хотите поручить выполнение этой работы кому-либо еще, сможете ли вы объяснить, что конкретно нужно сделать?

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

Планирование задач с неопределенным сроком завершения

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

Планирование долгосрочных проектов

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

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

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

• Оставшуюся часть работ по проекту разделите на этапы длительностью от одного до двух месяцев.

• Через три месяца просмотрите первоначальный план и так же детально спланируйте работы на следующие три месяца.

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

• Продолжайте действовать таким же образом до завершения проекта.

Идентификатор работы

На рис. показан рекомендуемый формат идентификации отдельной работы в структурной схеме работ.

• Первый номер соответствует некой общей задаче.

• Второй номер определяет задачу нижнего уровня в рамках обшей задачи.

• Следующие номера относятся к подзадачам более низких уровней; последний означает конкретную работу.

пример синий

Разработка структурной схемы работ

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

• Разработка сверху вниз. Проводите декомпозицию последовательно, начиная с верхнего уровня задач и заканчивая нижними — работами.

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

1. Определите все основные задачи проекта.

2. Определите все задачи второго уровня.

3. При необходимости продолжите декомпозицию задач.

4. Продолжайте, пока не достигнете нижнего уровня — конкретных работ.

• Метод мозгового штурма. Продумайте все задачи, которые, по вашему мнению, должны быть выполнены в проекте, и затем систематизируйте их.

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

1. На отдельном листе запишите все возможные задачи по вашему проекту.

• На данном этапе не заботьтесь о накладках или уровне детализации задач.

• Не отвлекайтесь на мелочи и редактирование формулировок.

• Не обсуждайте целесообразность каждого вида работ.

• Просто все запишите!

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

Это будут задачи верхнего уровня.

3. При необходимости разбейте отдельные задачи на подзадачи.

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

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

Организационная блок-схема

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

Рис. 3.4. Организационный формат структурной схемы работ

Структурированный документ

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

Для больших проектов целесообразно использовать оба формата структурной схемы работ.

Рис. 3.5. Формат структурированного документа

Организационный формат в нестрогом виде

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

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

• От центрального кружка идут линии к кружкам, означающим основные задачи.

• От основных задач ответвляются задачи следующих уровней детализации.