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

Вся моя работа состоит из консалтинг-проектов, будь то внедрение какой-то информационной системы или консультационная помощь. Любое сотрудничество я оформляю в виде проекта. Мое собственное знакомство с понятием «проект» началось с изучения книги Project Management Body of Knowledge (Руководство к своду знаний по управлению проектами, PMBoK). Из этого учебника я и возьму определение проекта:

Проект — это временное предприятие, предназначенное для создания продуктов, услуг или результата.

Соответственно, управление проектом — это управление созданием продуктов, услуг или любых других заранее определенных результатов.

Так как я постоянно работаю с внедрением IT-систем и автоматизацией процессов, неудивительно, что для себя я также использую различные системы автоматизации. Если какое-то действие мне приходится выполнять более 1—2 раз, я обязательно ищу возможность в будущем облегчить свой труд. А потому системы управления проектами я начал изучать, в первую очередь, для себя.

В процессе выбора наилучшего решения я проанализировал такие системы:

— Zoho Projects

— Microsoft Project 2007, 2010,2016

— Мегаплан

— Управление проектным офисом 1С

— Basecamp

— ActiveCollab и др.

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

Что такое проект: подробнее

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

Основные составляющие любого проекта:

— Проект всегда имеет начало и конец.

— Проект делится на определенные этапы.

— На каждом этапе выполняются определенные виды работ.

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

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

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

1. Описываем проект в целом.

Т.е. по сути, определяем исходные данные (что у нас имеется в наличии) и ставим общую цель (что мы хотим получить в результате).

2. Определяем основные вехи.

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

3. Списки задач.

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

4. Задачи и подзадачи.

Детализация каждого списка задач. Степень детализации определяете вы сами. Пример такой детализации я привел в предыдущем пункте. Здесь главное — вовремя остановиться. Детализация не должна выходить за рамки здравого смысла.

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

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

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

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

Критический путь проекта

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

Допустим, в рамках проекта имеется задача, на выполнение которой требуется 10 дней, и задача, на которую хватит 3 дней. Соответственно, одновременно с задачей, рассчитанной на 10 дней, выполнить вторую мы сможем (конечно, если они могут выполняться параллельно). А вот наоборот успеть — точно невозможно.

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

Зачем нужен критический путь:

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

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

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

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

Шаблоны проектов

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

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

Шаблон проекта — это набор основных этапов и задач, благодаря которым проект выбранного типа может состояться.

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

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

Представление задач и отчетность

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

— Список;

— Канбан;

— Диаграмма Ганта.

Список — самый простой вид отчетов. Вы просто выводите перечень задач в виде общего списка и видите, что выполнено, что — в процессе, а что еще и не начинали делать. Возможно, вы уже пользовались, так называемыми, Таск менеджерами. Это самый простой вариант управления проектами, где задачи обычно сразу отображаются в виде отчета-списка. При этом такой вид отображения — наиболее информативен, так как в списке обычно отображаются все важные параметры задач.

Канбан — это вид представления, при котором все задачи делятся графически по какому-либо атрибуту: статус задач, исполнитель, сроки выполнения и т. д. И тогда все задачи будут сортироваться с учетом выбранного параметра. Этот вид отображения чуть менее информативен, чем списки. Здесь карточки графические, информации в них видно меньше, чтобы изучить подробности, придется зайти в задачу. Зато их очень удобно сортировать и «перетаскивать» по экрану. Этот вид отображения не самый популярный, но и он имеет своих ценителей.

Диаграмма Ганта — самый популярный вариант отчетности в системах управления проектами. Здесь все задачи представляются в виде горизонтально-столбовой диаграммы, где начало и конец — это «границы» выполнения задачи. Также здесь видны наглядно все связи и взаимодействия между задачами. В диаграмме вы сможете наглядно увидеть процесс выполнения каждой задачи, степень загруженности сотрудников, «тонкие» места, т.е. задачи, которые не выполняются своевременно, что может повредить всему проекту. Также здесь легко управлять задачами — перетаскивать их по полю, переназначать исполнителей, менять сроки и т. д.

Исполнители

В системах управления проектов есть еще одно важное понятие — Исполнитель. С точки зрения управления они могут быть трех типов:

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

— Исполнитель — один человек (специалист, пользователь IT системы, разработчик). Обычно указывают ФИО.

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

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

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

Основное отличие этих систем друг от друга:

— Таск менеджер применяют, в первую очередь, для управления задачами в рамках одного, обычно, небольшого проекта. Основное преимущество этого решения — простота. Здесь можно быстро создать проект с любыми задачами, быстро изменить или удалить его. В принципе, изначально таск менеджеры предполагались в качестве альтернативы органайзеров, т.е. как помощники в работе одного человека. А потому здесь не фиксируются многие нюансы: кто создал задачу, кто ее удалил или изменил, т.е. это просто помощник в организации труда одного человека или небольшой команды.

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

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

При выборе системы управления проектами вы можете руководствоваться своими приоритетами, каждая из них имеет свои плюсы и минусы. Здесь я хочу заметить одно: standalone-решений для систем управления проектами в наше время практически не осталось. Все сервисы облачные, т. е. SAAS. Основная причина — в предназначении этих систем: они дают возможность работать, в том числе, с удаленными сотрудниками. Это преимущество в наше время стало настолько популярно, что от коробочных решений отказались практически все ведущие разработчики.

Частые вопросы и ответы

Что такое PMBoK и зачем он нужен?

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

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

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

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

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

Чем отличается проект от процесса?

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

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