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

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

1. Битрикс24

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

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

2. Jira

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

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

3. Asana

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

Отдельно стоит упомянуть, что функциональность продукта расширяется с помощью подключения сторонних сервисов: от Dropbox и Google Drive до Zapier и Bitbucket.

4. ActiveCollab

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

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

5. Slack

Сегодня это фактически стандарт для корпоративной переписки. Огромный плюс мессенджера - большое число интеграций со сторонними сервисами. Главный недостаток - ограниченное хранение истории чатов на бесплатной версии (поиск по последним10 000 сообщениям,10 интеграций и 5 Гб серверного места на команду).

И, конечно, в Slack доступны боты в больших количествах. Мессенджер попытался взять лучшее от своих прародителей вроде IRC и Jabber.

6. Wrike

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

Отдельно указывается, что есть функция создания отчетов для экономии времени. Дополнение к Outlook и Apple Mail помогает создавать задачи напрямую из писем.

7. MS Project

Старожил рынка, не так давно получивший и онлайн-версию. Очень популярен у западных пользователей и едва ли не синоним диаграммы Ганта. Позволяет планировать проекты, управлять ресурсами, планировать сценарии вида «что, если» и следить за дедлайнами и прогрессом. Плотно интегрируется с Microsoft Office последних версий, SharePoint.

Требует очень много времени на освоение. Его внедрение - целая история для компании.

8. Evernote

Один из флагманов сервисов «новой волны» (в эпоху после Microsoft и Web 2.0, конечно же) для сбора данных в командах и зачаточная система управления, которая только-только появляется в продукте. Среди функций для команд - недавно прямо в интерфейсе системы появился таск-менеджер, система рабочих проектов Spaces, а также возможность создания корпоративной базы знаний.

Сам проект идеально подходит именно для последней задачи.

9. Trello

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

Главный плюс проекта - возможность быстро и просто увидеть проект «с высоты птичьего полета» и визуально оценить степень готовности.

10. Basecamp

Один из первопроходцев систем управления проектами «новой волны», запущен в 2004 году. Среди возможностей: ведение списков, просмотр расписания сотрудников и команд, хранение файлов и групповой чат. При помощи API можно подключать сторонние приложения. За14 лет проект сохранил свою главную черту: функциональную простоту.

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

Выводы

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

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

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

Ниже мы расскажем о следующих методах:

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

Наиболее популярным среди таковых является уже рассмотренная нами диаграмма Гантта, где указаны основные задачи и сроки начала и завершения их решения. Но если она подходит для проектов с жесткими сроками и ресурсными ограничениями, то для проектов, требующих большего уровня контроля самого процесса реализации, лучше всего использовать гибкие методы проектного управления, такие как Agile, и взаимосвязанные с ним Kanban, Lean и прочие, а также такие, которые позволяют управлять сразу несколькими составляющими, например, ресурсами, временем и работой, - это Scrum и Six Sigma. Но не будем забегать вперед, а расскажем обо всем по порядку.

Agile

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

Упрощенная схема работы по Agile выглядит так:

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

Преимущества Agile:

• Адаптивность и гибкость (его можно подстраивать под разные процессы и условия)
• Быстрое и относительно безболезненное реагирование на изменения
• Прекрасно подходит для разработки инновационных продуктов с высоким уровнем неопределенности и низкой информативности

Недостатки Agıle:

• Не является методом
• Необходимость каждый раз составлять новую систему управления на основе принципов подхода Agıle
• Применение подхода сопряжено с изменениями процедур реализации проекта и базовых ценностей
• Требует знаний, упорства, больших затрат и административных ресурсов (для облегчения применения подхода принято использовать методы Scrum, Kanban и другие)

Scrum

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

Наиболее важные части первыми отбираются для выполнения в спринте (спринты в Scrum - это итерации продолжительностью от 2 до 4 недель). По итогам спринта заказчик получает рабочий инкремент продукта, т.е. готовые к использованию части. Как только один спринт закончен, проектная команда начинает следующий спринт. Продолжительность спринтов всегда одинакова, но команда всегда сама устанавливает ее, оценивая свою производительность и особенности проекта.

Упрощенная схема работы по Scrum такова:

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

Вся процессуальная структура метода вращается вокруг пяти основных встреч:

• Упорядочивание беклога. Встреча напоминает планирование, рассмотренное нами в первом уроке. Проводить ее нужно в первый день нового спринта. На встрече обсуждается то, что уже удалось сделать по проекту и что еще нужно сделать, и определяются дальнейшие шаги. Инициатор ставит задачи, соответствующие новому этапу. Упорядочивание беклога определяет результативность нового спринта.
• Планирование спринта. После расстановки приоритетов и определения задач инициатором команда принимает решение о своих действиях на протяжении наступающей итерации и ищет способы достижения поставленной цели. Для этого могут использоваться самые разные инструменты планирования и оценки (важно, чтобы они соответствовали принципам метода). Планировать спринт нужно в самом начале итерации, но по окончании встречи по упорядочиванию беклога.
• Летучки. Летучки - это ежедневные встречи, проводящиеся в одно и то же время (на них тратиться, как правило, до 15 минут). Члены команды делятся информацией о статусе своей работы и состоянии проекта, однако никакие решения не принимаются и проблемы не обсуждаются (для этого выделяется отдельное время, и устраиваются дополнительные встречи). Летучки нужны лишь для обмена сведениями.
• Подведение итогов спринта. На этом этапе исследуется и адаптируется созданный продукт. Члены команды делятся своими результатами со всеми заинтересованными лицами. Главной задачей здесь является удостовериться в том, что продукт спринта соответствует целям проекта и ожиданиям участников проекта.
• Ретроспектива спринта. Этап, проводящийся сразу же после предыдущего, но до того как начнет планироваться новый спринт. Команда определяет степень четкости и слаженности пройденного этапа, исследует появившиеся проблемы в методологии, работе и взаимодействии. Благодаря ретроспективе команда может сделать выводы и повысить эффективность следующего спринта.

Преимущества Scrum:

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

Недостатки Scrum:

• Высокая требовательность к проектной команде (нужно, чтобы в команде было от 5 до 9 человек, и все члены команды должны обладать сразу несколькими компетенциями, необходимыми для реализации проекта, благодаря чему сотрудники могут дополнять и заменять друг друга, а работа никогда не будет стоять на месте)
• Все сотрудники должны уметь и хотеть работать в команде, быть способны к и активно брать на себя ответственность
• Подходит не для всех организаций и команд, т.к. схема работы по методу подходит для разработки далеко не каждого продукта (например, построить здание или создать промышленный станок по методу Scrum будет невозможно)

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

Lean

Согласно Agile, проект должен быть разбит на небольшие подпроекты и пакеты работ, но вот как разрабатывать эти подпроекты и пакеты работ - непонятно. Метод «Лин» дополняет принципы Agile своей схемой потока операций для качественного выполнения каждой отдельной итерации.

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

Ниже представлена упрощенная схема работы по Lean:

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

Преимущества Lean:

• Подходит для проектов, требующих четкого исполнения и ровного качества, т.к. обладает всем соответствующим инструментарием
• Сочетает в себе структурированность и гибкость

Недостатки Lean:

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

Подобно Agile, Lean представляет собой не столько метод, сколько образ мышления и концепцию, при помощи которой можно самостоятельно сформировать такую систему управления проектами, которая будет удовлетворять всем вашим требованиям.

Kanban

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

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

Упрощенная схема работы по Kanban выглядит так:

Отличие этого метода от того же Scrum состоит в меньшей строгости: нет ограниченных по времени спринтов и регламентированных встреч, отсутствуют роли членов команды и участников (кроме инициатора проекта). Также в Kanban один член команды может заниматься выполнением нескольких задач в одно и то же время.

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

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

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

Преимущества Kanban:

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

Недостатки Kanban:

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

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

Six Sigma

Метод Six Sigma или, проще говоря, «6 сигм» представляет собой более структурированную версию Lean, причем даже более структурированную, чем Kanban. Она отличается еще большим планированием, что позволяет экономить ресурсы, повышать качество продукта и минимизировать объем потерь и брака.

Цель любого проекта заключается в удовлетворении заказчика качественным продуктом. Качества можно добиться благодаря непрерывному процессу улучшения всех составляющих проекта, основанному на доскональном анализе его показателей. «6 сигм» в самой подробной форме разбирает методы устранения сопутствующих проекту проблем. Основной этого подхода служит алгоритм DMEDI, состоящий из 5 шагов:

• Define (Определение): этап аналогичен ранним этапам других систем управления проектами. Его цель - это определение содержания проекта, сбор информации о его предпосылках и .
• Measure (Измерение): метод позволяет собирать и анализировать количественные данные о проекте, и второй этап нужен для определения показателей, обуславливающих успех проекта, а также для определения требуемых данных, их сбора и анализа.
• Explore (Исследование): на этом этапе руководитель проекта принимает решение о методах, посредством которых команда сможет достичь поставленных целей в соответствии с требованиями по срокам и бюджету. Здесь огромную роль играет нестандартное мышление для решения возникающих проблем.
• Develop (Разработка): четвертый этап - это этап реализации решений и планов, разработанных на предыдущих этапах. Необходимо понимать, что на этом этапе нужно иметь подробный план с описанием всех действий, требующихся для решения поставленных задач. Ко всему прочему на этом этапе обследуется прогресс хода проекта.
• Improve (Улучшение) или Контроль (Control): данный этап является ключевым, и ставит перед собой задачу по долгосрочному улучшению процессов реализации проекта. Для эффективного прохождения этого этапа необходимо тщательно документировать извлеченные уроки, анализировать собранные данные и применять полученные знания и по отношению к проекту, и по отношению к деятельности всей организации.

Преимущества Six Sigma:

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

Недостатки Six Sigma:

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

Метод «6 сигм» напоминает «Канбан», но устанавливает конкретные этапы реализации задач - планирование, постановку целей и тестирование качества. Также Six Sigma требует более частых встреч команды, но сам процесс осуществления проекта будет более понятен, а команда всегда сможет придерживаться намеченного плана.

PRINCE2

От прочих методов проектного управления PRINCE2 (от англ. PRojects IN Controlled Environments version 2) отличатся отсутствием итеративного подхода. По сути, это гибрид классического проектного управления с концентрацией на качестве, как это делается в Six Sigma.

Схематично процессы работы по PRINCE2 выглядят так:

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

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

• Бизнес-аспект: выгоден ли проект?
• Потребительский аспект: какой нужно создать продукт?
• Ресурсный аспект: есть ли возможности и ресурсы для достижения цели?

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

Сами же процессы можно охарактеризовать так:

• Старт проекта. В ходе первого процесса назначается руководитель, и устанавливаются общие требования к характеристикам конечного результата. Проект-менеджер должен уделять особое внимание деталям и давать отчет Управляющему комитету проекта, отвечающему за общее руководство проектом и успех его реализации.
• Инициация проекта. В ходе второго процесса руководителем составляется «Документация по инициации проекта», содержащая в себе разбитый на стадии план проекта. Стадии всегда следуют одна за другой, но по продолжительности вполне могут различаться.
• Руководство проектом. Третий процесс основан на том, что дает Управляющему комитету возможность нести общую ответственность за успех реализации задумки без погружения в детали, находящиеся в области полномочий проект-менеджера.
• Контроль стадии. Даже если проект осуществляется в идеальных условиях, в него будут вноситься какие-то поправки. Четвертый процесс необходим для реализации одного из принципов PRINCE2 - принципа управления по исключениям. Руководитель проекта должен выявлять отклонения от заданных параметров проекта (сроки, качество, бюджет и т.д.) в ходе выполнения стадии. В случае, когда отклонения превышают полномочия (допуски) руководителя, он должен поставить об этом в известность Управляющий комитет и предложить варианты решения возникших проблем.
• Управление созданием продукта. Пятый процесс - это взаимодействие руководителя и его команды, направленное на создание одного из проектных продуктов. К числу обязанностей руководителя добавляется делегирование соответствующих полномочий менеджеру команды и приемка готового продукта.
• Управление границами стадии. В ходе шестого процесса руководитель снабжает Управляющий комитет всей информацией, позволяющей оценить результаты завершенной стадии и принять решение о переходе к следующей стадии.
• Завершение проекта. Процесс завершения проекта является частью финальной стадии создания продукта. Его цель состоит в подтверждении или факта принятия продукта, или факта того, что проект не принесет больше ничего стоящего.

Преимущества PRINCE2:

• Легко адаптируется к особенностям организации
• Имеет четкое описание ролей и распределения ответственности
• Концентрируется на продукте проекта и экономической целесообразности
• Имеет конкретные уровни управления
• Позволяет последовательно выстроить проектную работу
• Фиксирует опыт и позволяет постоянно совершенствоваться

Недостатки PRINCE2:

• Отсутствуют отраслевые практики
• Отсутствуют конкретные инструменты для проектной работы

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

Управление проектами - это, пусть и не совсем точная, но серьезная наука. Конечно, в ней вряд ли удастся отыскать универсальные решения и основы, однако если вы сможете найти такой метод проектного управления, который подойдет вашему проекту по большинству параметров, вы можете быть уверены, что достичь успеха - в ваших силах. Главное - это применять метод, в котором есть хоть какая-то структура, а также использовать в своей проектной деятельности вспомогательные инструменты, такие как системы управления проектами, например, MS Project, Asana, Wrike, Basecamp и другие. И о самых популярных системах вы узнаете из заключительного урока, после чего в вашем распоряжении будет вся основная информация по управлению проектами.

Проверьте свои знания

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

Экспертные оценки - это оценка (экспертиза) проблемы проекта профессионалом, используется в управлении любыми процессами и областями проекта и применяется в отношении любых технических и управленческих деталей. СЛ 10

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

Этими лицами могут быть:

Представители других подразделений организации;

Внешние или внутренние консультанты;

Заинтересованные стороны проекта, в том числе заказчики или спонсоры;

Профессиональные и технические ассоциации;

Отраслевые объединения;

Эксперты по отдельным вопросам и т. п.

В проектном управлении применяется и экспертное оценивание.

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

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

ABC-анализ - метод, позволяющий классифицировать ресурсы по степени их важности. В его основе лежит принцип Парето - 20 % всех действий дают 80 % результатов. По отношению к ABC-анализу правило Парето может прозвучать так: надежный контроль 20 % действий позволяет на 80 % контролировать систему.

ABC-анализ - анализ действий (решений) путем деления на три категории:

А - наиболее ценные, 20 % - 80 % - результатов;

В - промежуточные, 30 % - 15 % - результатов;

С - наименее ценные, 50 % - 5 % - результатов.

В зависимости от целей анализа может быть выделено произвольное количество групп. Чаще всего выделяют 3, реже 4-5 групп.

По сути, ABC-анализ - это ранжирование действий (решений) по разным параметрам. Ранжировать таким образом можно все, что имеет достаточное количество статистических данных. Результатом АВС анализа является группировка объектов по степени влияния на общий результат.

АВС-анализ основывается на принципе дисбаланса, при проведении которого строится график зависимости совокупного эффекта от количества элементов. Такой график называется кривой Парето, кривой Лоренца или ABC-кривой.

Пример кривой Парето показан на СЛ11б

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

Порядок проведения АВС-анализа:

1. Определяем цель анализа (а зачем собственно нужен вам этот анализ?).
2. Определяем действия по итогам анализа (что будем делать с полученными результатами?).
3. Выбираем объект анализа (что будем анализировать?) и параметр анализа (по какому признаку будем анализировать?).
4. Составляем рейтинговый список объектов по убыванию значения параметра.
5. Рассчитываем долю параметра от общей суммы параметров с накопительным итогом. Доля с накопительным итогом высчитывается путем прибавления параметра к сумме предыдущих параметров.
6. Выделяем группы А, В и С: присваиваем значения групп выбранным объектам.

Методов выделения групп существует порядка десяти, наиболее применимы из них: эмпирический метод, метод суммы и метод касательных. В эмпирическом методе разделение происходит в классической пропорции 80/15/5. В методе суммы складывается доля объектов и их совокупная доля в результате - таким образом значение суммы находится в диапазоне от 0 до 200 %. Группы выделяют так: группа А - 100 %, В - 45 %, С - остальное. Достоинства метода - большая гибкость. Самым гибким методом является метод касательных, в котором к кривой АВС проводится касательная, отделяя сначала группу А, а затем С.

Вероятности возникновения спроса на материальные ресурсы А, В и С подчинены различным законам.

Установлено, что в большинстве промышленных и торговых фирм примерно 75 % стоимости объема продаж составляют всего около 10 % наименований номенклатуры (группа А), 20 % стоимости - 25 % наименований (группа В), 5 % стоимости - 65 % наименований (группа С). Существует множество способов выделения групп в ABC-анализе.

Метод АВС используется при планировании и формировании принципов управления конкретным проектом.

SWOT - метод анализа в стратегическом планировании, заключающийся в разделении факторов и явлений на четыре категории: strengths (сильные стороны), weaknesses (слабые стороны), opportunities (возможности) и threats (угрозы).СЛ 12

Сочетание факторов и явлений наглядно передается таблицей внизу.

Комментарии к таблице:

1. Внутренние факторы, имеющие позитивное влияние на проект, - это его сильные стороны. Например, положительное решение вопроса о финансировании проекта - это его сильная сторона.

2. Внутренние факторы, имеющие негативное влияние на проект, - это слабые стороны проекта. Например, отсутствие профессиональной команды управления проектом - это его слабость.

3. Внешние факторы, оказывающие позитивное влияние на проект, расширяют возможности для реализации проекта. К примеру, если продукт проекта отвечает ожиданиям населения, то этот факт значительно повышает поддержку проекта.

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

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

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

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

"БРИТВА ОККАМА" - принцип, согласно которому более простым теориям следует отдавать предпочтение перед сложными, если и те и другие в равной степени согласуются с эмпирическими, опытными данными. СЛ 13

"Бритва Оккама" – методологический принцип, получивший название по имени английского монаха-францисканца, философа-номиналиста Уильяма Оккама (1285 – 1349), в упрощенном виде гласящий: «Не следует множить сущее без необходимости» (либо «Не следует привлекать новые сущности без самой крайней на то необходимости»).

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

Для примера: при принятии решения по аспекту проекта следует учитывать только те факторы и возможные следствия, которые имеют отношение к рассматриваемому аспекту проекта. В частности, не следует привлекать сюда надуманные корпоративные правила.

АНАЛИЗ ПРИОРИТЕТОВ ПО ЭЙЗЕНХАУЭРУ СЛ 14

Срочные дела, как правило, не самые важные, а важные - не самые срочные. (Дуайт Эйзенхауэр.)

Работа руководителя проекта такова, что приходится все время «крутиться». Поэтому у него всегда множество дел, которые надо сделать срочно. Как же с этим справиться?

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

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

По принципу Эйзенхауэра приоритеты устанавливаются по таким критериям, как срочность и важность дела. В зависимости от степени срочности и важности задачи раз­личаются 4 возможности их оценки и (в итоге) выполнения:

· срочные/важные дела . За них следует приниматься немедленно и самому их выполнять;

· срочные/менее важные дела . Здесь существует опасность попасть под «тиранию» спешности и в результате целиком отдаться решению конкретной задачи, потому что она срочная. Если же она, однако, является не столь важной, то должна быть в любом случае делегирована, поскольку для ее выполнения не требуется каких-либо особых качеств;

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

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

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

Управление командой начинается с планирования и проектирования. Существуют десятки, если не сотни, методологий управления проектами: от “Разработки по ReadMe” до громоздкого, зато на все случаи жизни PMBOK . Как программисты, бывает, изобретают велосипеды, так и проект-менеджеры могут этим грешить. Если с методологией мы могли позволить себе некоторые вольности, то инструмент подбирался уже без “велосипедостроения”…

Что такое “pivot” стартапа

Pivot (от англ. - вертеться, поворачиваться вокруг своей оси) в контексте стартапа - это отказ от текущей бизнес-модели, программного продукта и перезапуск всех работ по новой концепции. Объяснение, почему так происходит, почему так произошло у нас, выходит за рамки статьи. Поясню лишь то, что в нашем случае обозначал “pivot”:

• ограниченные ресурсы - 4 человека на все работы;
• жестко определенные сроки - 30 календарных дней;
• необходимость выполнить поставленную задачу: “получить первый доход с продукта”.

Подробнее об исходной точке

• Проект начинается не с “0” - программный продукт-предок был версии 2.3, имел хорошую архитектуру после рефакторинга, с отловленными и исправленными багами;
• Задача по разработке: из продукта-предка v2.3 сделать продукт-потомок v0.1 alpha-1. Основные изменения касаются переработки архитектуры под многопроектность, добавления новых типов конечных документов, удаления ненужных функций, редизайна в соответствии со вкусами новой ЦА, создания “демо-режима” работы;
• Финансово-маркетинговая задача: в кратчайшие сроки выпустить продукт и привлечь к нему аудиторию, проанализировав реакцию на него. По анализу составить план дальнейшего развития. С полученных дополнительных финансов ускорить разработку нового функционала;
• Проектирование началось с создания маркетингового концепт-документа , в котором были сформулированы основные идеи и тезисы: какие работы нужно провести, чтобы реализовать поставленные задачи;
• Состав команды и обязанности, которые они выполняют:
  “Программист” - фронтенд\бэкенд разработка, системное администрирование;
  “Тестер” - тестирование ПО, написание баг-репортов, SMM- и контент- менеджмент, анализ и обработка фидбэка;
  “Дизайнер” - разработка внешнего вида и механики GUI, создание и подготовка медиа-контента;
  “Проект менеджер” - аналитика, проектирование, планирование, управление (проектное, маркетинговое, финансовое и т.д.), разработка технической документации, текстового контента, SEO.
• Ограничение-требование от наших менторов-инвесторов: за 30 дней переделать продукт, подготовить материалы и работы по продвижению.

Инструменты управления проектами

У нашей команды есть опыт работы с тремя “связками” инструментов по управлению проектами:

“Связка первая”

Мегаплан - трекинг задач, не связанных с разработкой кода;
Redmine + GIT - баги и задачи, связанные с разработкой кода + контроль версий;
Kayako - сервис для сбора фидбэка, баг-репортинга;

Такая связка хороша, когда в разработке несколько проектов, несколько заказчиков и т.д. (Redmine), много сотрудников и задач, не связанных с работой над кодом (Мегаплан), много пользователей, а соответственно много: саппорта, фидбэка, баг-репортов (Kayako).

“Связка вторая”
Google Docs - электронный документооборот и облачный редактор документов;
Мегаплан - трекинг задач, не связанных с разработкой кода + CRM-система;
BitBucket вместо Redmine + GIT;

“Вторая связка” подходит, когда проект один, и он относительно простой (BitBucket); при этом работы, не связанной с кодом (Мегаплан), много, а фидбэка-саппорта пока мало, так что хватает настроенного веб-интерфейса от почты (Yandex.pdd).

“Связка третья”
Google Docs - как облачный редактор;
TrackStudio + GIT - трекер задач, как по коду, так и прочих + электронный документооборот;
Яндекс.Почта для домена - для сбора фидбэка, баг-репортинга.

Эта связка - самая правильная, она позволяет в одной системе вести работу над задачами как по коду, так и по всему остальному. К сожалению, основной инструмент в этой связке требует много ресурсов на настройку-допиливание (TrackStudio); по фидбэку-сапорту, как и во “второй связке”, хватает Yandex.pdd,

Эти связки были подобраны под разные условия работы. Google Docs используется всегда: мы просто его любим - это приятный, быстрый и удобный облачный редактор документов.

Под наши условия: один проект, работать надо как над кодом, так и над продвижением, пользователей пока вообще нет, много саппорта-фидбэка не предвидится, предполагали выбор второй или третьей “связки”. “Третья связка” (основанная на TrackStudio) после коротких размышлений отпала - не было ни времени, ни ресурсов, чтобы настроить-довести этот инструмент под новый проект. Решили использовать “Вторую связку” с инструментами, которые работали из коробки (BitBucket, Мегаплан).

Вариант попробовать что-то новое не рассматривался по той же причине, по какой отказались от использования “Третьей связки”. Не было времени на эксперименты, нужно было начинать работать. Учитывая отсутствие возможности попробовать новое, положились на опыт проект-менеджера по общению с парой десятков прочих систем управления проектами (СУП) как специализированных для разработки ПО, так и широкой области применения: от Teamer’а до BugZill’ы.

Планирование

Почему мы начали с выбора инструментов, а не с планирования?

Потому что “вторая связка” состоит из двух негибких сервисов: BitBacket’а и Мегаплана. Они не имеют возможности настраивать их под любые процессы, поэтому приходится выстраивать методологию управления проектом в терминах и ограничениях этих инструментов. Выбрав инструменты, и зная их ограничения, можно приступать к следующему этапу - планированию.

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

Общие задачи ставятся в Мегаплане, будем использовать его терминологию. Отправная точка в иерархии таск-менеджера Мегаплана - “Вехи”. Веха - срез проекта на определенном сроке, её еще можно описать, как набор целей, которые нужно достичь к конкретному времени. Планирование сводится к созданию вех. Рассмотрим их на примере нашей ситуации (переделываем один проект в другой, подготавливаем его продвижение, на всё 30 дней, с 5 сентября по 5 октября).

Веха #1. “Подготовительный этап”, закончено к 10 сентября:
- Выбраны и настроены инструменты, локальные сервера;
- Спланирован ход работ;
- Поставлены и распределены задачи;
- Составлены ТЗ по всем задачам.

Веха #2. “Базовые работы”, закончено к 15 сентября:
- Произведен рефакторинг кода проекта (ускорит реализацию будущих задач);
- Подготовлены серверы и учетные записи, домены для продакшна;
- Разработан и собран ключевой контент для продвижения (по правилу «Бритвы Оккама»: 20% “ключевого” контента дадут 80% трафика);

Веха #3. “Первый наглядный результат”, закончено к 20 сентября:
- Рефакторинг редактора (перенесен в iframe, что позволит быстро реализовать “демо-режим”);
- Произведен редизайн GUI;
- “Запущены” блог проекта, сообщества в социальных сетях.

Веха #4. “Первый публичный результат”, закончено к 25 сентября:
- Добавлена форма приема платежей;
- Реализован демо-режим;
- На демо-режиме запущен промо-сайт с 90-100% запланированного контента;
- Версия 0.0.11 задеплойдена в продакшн;
- Сообщества в соц. сетях и блог на сайте наполнены первыми постами.

Веха #5. “Подготовлено продвижение проекта”, закончено к 30 сентября:
- Заведен блог на Хабрахабре;
- Реализованы мелкие фичи и доработки;
- Пройдена модерация и подключена система биллинга;
- Версия 0.0.17 задеплойдена в продакшн;
- Согласно плану публикаций продолжается постинг в соц. сети и в блог на сайте.

Финальная Веха #6. “Первое продвижение проекта”, закончено к 10 октября:
- Реализован весь задуманный на альфа-версию функционал;
- Релиз версии R0.1 Alpha-1 задеплойден в продакшн;
- Первая статья опубликована в блоге на Хабрахабре;

Запланированные Вехи #7-Х. “Создание комьюнити проекта”, закончено к 30 октября:
- Опубликованы 3-5 статей в блог на Хабрахабре;
- Подготавливаются и публикуются посты в блог на сайте, в сообщества соц. сетей;
- Идет сбор и анализ фидбэка, общая переписка с заинтересовавшимися в проекте пользователями;
- Планируются и проводятся работы по прочему продвижению согласно маркетинговому концепту;
- Производятся хот-фиксы;
- Анализируются суммы собранных средств, соотносятся с возможностями по дальнейшему развитию проектов.

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

Напомню: первые Вехи планировались, опираясь на “маркетинговый концепт” . Наша команда состоит из 4-х человек, несколько лет работающих вместе над разными проектами. Схожие с теми, что поставлены в Вехах для Alpha-версии Ahoba (; задачи, мы уже реализовывали в других проектах. Поэтому, составляя Вехи, проект-менеджер уже представлял кто и как будет решать поставленные задачи. Этот процесс происходил неформально, опираясь на прошлый опыт, эмпирическую оценку и аналитическое прогнозирование.

Можно написать книгу о этих неформальных мыслительных процессах, о истории их возникновения, проб вариантов, обучение на ошибках и т.д. Получится этакий “PMBOK Lite for Brain”. Однако, на данный момент нет не то что книги, но и оформленной на бумаге концепции: все на 70% - в голове ПМ’а, и лишь оставшиеся 30% - в его личных шпаргалках-тезисах. Возможно когда-нибудь и из этих наработок получится, пускай и не книга, но достойная статья для Хабрахабра точно. Сейчас же мы просто отметим, что было сделано, не вдаваясь в вопрос “Как?”.

Проработка структуры проекта

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

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

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

0. Проектирование
1. Разработка проекта
2. Продвижение проекта
2.1. Сайт и блог Ahoba (;
2.2. Продвижение в соц. сетях
2.3. Продвижение на Хабрахабре
3. Разработка дизайна и медиа-контента

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

Постановка задач

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

Общий принцип-последовательность, через который проходит большинство задач в наших проектах, можно описать так:

Краткая концепция задачи → Разработка подробного ТЗ → Создание тестового\демо контента → Создание макетов GUI по ТЗ → Постановка формальной задачи на реализацию в таск-трекер (ТЗ + Макет) → Реализация → Тестирование → Багфикс (если нужно) → Закрытие задачи.

Над задачей на разных этапах работают разные люди с разными ролями: ПМ разрабатывает концепцию задачи; бизнес-аналитик, технический писатель составляют ТЗ; дизайнер рисует макет; ПМ передает ТЗ и Макет программисту; программист реализует задачу, передает её на тестирование; тестер проверяет реализацию и, если всё в порядке, соответствует ТЗ и Макету, то уже как QA-специалист закрывает задачу.

И это самый простой вариант… Бывают ситуации, когда нельзя определить, как именно реализовать задачу. Тогда программист может подключаться к задаче уже на этапе проектирования (например: могут быть реализованы несколько прототипов интерфейсов, чтобы юзабилити-эксперт оценил каждый вариант и внес конечный в цепочку реализации).

В итоге имеем около 5-ти типовых моделей жизненных циклов задач и еще пару десятков “атипичных”.

Гибкие инструменты для трекинга задач, такие, как TrackStudio, хороши тем, что позволяют формально настроить менеджмент по любой модели жизненного цикла задачи. Это и их достоинство, и их недостаток. Как уже говорилось выше, когда нет ресурсов на первоначальную настройку, использовать эту систему не получится. Взяв коробочные Мегаплан и BitBucket, мы понимали, что формально настроить их для наших жизненных циклов реализации задач не выйдет. Поэтому, дальнейший рассказ а-ля “много-много костылей” о неформальном использование этих сервисов.

Как в связке “Мегаплан + BitBucket” реализовать нашу модель жизненного цикла задачи? Во-первых, конкретные фичи, связанные с кодом (п.1. “Разработка” из иерархической структуры, определенной ранее), заносятся в BitBucket, а задачи по подготовке материалов для реализации фич (ТЗ + Макет + Тестовые\Демо данные) - в трекер Мегаплана.

Алгоритм примерно такой:
Ставим в Мегаплан задачу для бизнес-аналитика: “Разработать ТЗ ” - со ссылкой-примечанием “Готовое ТЗ выложить в задачу Х для дизайнера ”. Дизайнеру, также в Мегаплан, ставим задачу “Разработать Макет по ТЗ ” с теми же ссылками-примечаниями: “Позже ТЗ в задачу выложит бизнес-аналитик, готовый Макет выложить в задачу Y в BitBucket ”. Программист и тестер работают только в BitBucket’e, оперируя сменой статусов у задач.

В интерфейсе этих СУП’ов объединения этапов работы над задачами нет. При неумелом проект-менеджменте это может привести к негативным последствиям. Из личного опыта: если вручную не согласовывать распределение работ (а автоматизировано инструменты этого не делают), может возникнуть ситуация, когда, например, программист простаивает неделями в ожидании формальных описаний для фич. Такое я наблюдал на прошлом месте работы. В итоге ведущий разработчик уволился, аргументируя своё увольнение монологом в духе: “Мне скучно, так как нет работы, а я код писать хочу”. Это показательный пример того, как неподходящие инструменты или их неформальное использование, могут деморализовать членов команды. Всем, решившим, как и мы, использовать “Вторую связку”, нужно понимать и учитывать эти риски при работе в таких системах управления проектами.

Наша команда - 4 человека. Каждый занимается несколькими проектными работами. Мне, как проект-менеджеру, нужно было поскорее закончить с этим самым проект-менеджментом и приступать к работе бизнес-аналитика\технического писателя, SEO-специалиста, маркетолога и копирайтера. К работе ПМ’а возвращаться не хотелось, да и не было возможности.

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

Таблица: “Работы по реализации и продвижению проекта Ahoba (; ver. Alpha-1”


И т.д., всего около 50 задач.

По целям из Вех получилось сформулировать конкретные задачи. Некоторые цели описаны одной задачей, другие разделены на несколько. Сроки из Вех позволили расставить дедлайны, ориентируясь на логическую последовательность выполнения работ. По заранее установленным проектным ролям, были назначены исполнители, ответственные за те или иные задачи. Сами задачи, естественно, не состоят из одних лишь заголовков, указанных в таблице. Большинство из них были дополнены описаниями, пояснениями, ссылками на проектную документацию в Google Docs, чек-листами с этапами или алгоритмами выполнения…

Отдельно стоит отметить распараллеливание на раннем этапе. Пока ПМ прорабатывает задачи, команде нечем заняться. Чтобы избежать простоя, работа ПМ’а начинается с постановки задач, не требующих детального ТЗ или аналитики: Программист начинает с удаления ненужного функционала; Дизайнер рисует лого проекта; SMM-менеджер подбирает контент для постов по тематике, определенной еще в концепте. Все при деле, а проект-менеджер спокойно работает над полусотней задач, распланировав деятельность команды на следующие 30 дней.

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

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

Задачи сформулированы и поставлены, сроки и исполнители определены, но, чтобы достичь поставленных целей без сучка и задоринки, необходимо соблюдать ряд формальных правил:

• Любая идея, предложение, пожелание и т.д. проходят через ПМ’а, т.к. он отвечает за общую работу и жизненные циклы отдельных задач, определяя и внося всё новое согласно текущей ситуации;
• Все задачи фиксируются в системах управления проектом. Связанные с кодом - в BitBecket’е, все прочие - в Мегаплане;
• Для каждой задачи должен быть назначен ответственный и определен дедлайн;
• Задача должна иметь полное, формальное, однозначное описание. Если исполнитель не уверен в смысле задачи, он обязан перед её выполнением уточнить его у постановщика задачи. Постановщик, если необходимо, дополняет описание;
• Порядок выполнения задач - согласно их дедлайнам. Если задачи имеют одинаковый дедлайн, исполнитель сам выбирает, в какой последовательности их реализовывать;
• Статусы при работе над задачами (выставляются автоматически и вручную) и реакция на них в Мегаплане:
  1. “Новая задача” - необходимо ознакомится с сутью и условиями задачи, согласовать порядок выполнения прочих своих задач и новой.
  2. “Принята к исполнению” - ответственный за задачу знает о ней, если свободен, работает над её реализацией.
  3. “Условно завершена” - статус устанавливается вручную, после того, как исполнитель закончил работу над задачей, выполнил все условия описанные в ней. (Например, по условию: выложил готовый Макет в связанную задачу по разработке GUI).
  4. “Завершена” - устанавливается вручную, после того как поставщик задачи проверил качество её исполнения;
• Статусы при работе над задачами, служебная информация в заголовках (задаются только вручную) и реакция на них при работе в BitBucket’e:
  1. Задаче должен быть указан тип. Тип “task” - задается для задач, связанных с добавлением нового или изменением текущего функционала; тип “bug” - для задач по исправлению ошибок, недочетов.
  2. Т.к. в BitBucket’е нет сущности “версия” или “релиз”, для каждой задачи, в начале её заголовка добавляется служебная информация типа “RX”, где “R” - метка обозначающая релиз, а “X” - номер релиза. Пример метки - “R0.1”. Перенос задач из релиза в релиз осуществляется изменением служебной метки в заголовке задачи.
  3. Задача добавляется без статуса, если в ней отсутствуют какие-то данные (например, макет нового GUI), при этом в описании должно быть примечание (например: “Позже дизайнер выложит макет, подробности в задаче - ссылка_на_задачу_по_разработке_макета ”).
  4. Задаче ставится статус “new”, что означает, что все описания по ней готовы, и программист может приступать к работе над ней;
  5. Задаче ставится статус “resolved”, когда программист заканчивает работу над задачей и деплойдит изменения на тестовый сервер. Данный статус означает, что тестер может приступить к тестированию задачи.
  6. Если в выполненной задаче найдены ошибки, и их можно исправить в рамках текущей задачи, тестер ставит статус “invalid”. Это означает, что программисту необходимо исправить найденные недочеты. После правки программист опять ставит статус “resolved”.
  7. После того как текущая задача реализована без ошибок, или ошибки вынесены в отдельную задачу с типом “bug”, задаче присваивается статус “closed”.
  8. Каждой задаче автоматически присваивается уникальный ID. Он необходим для двух вещей: а) для привязки коммитов в git-репозиторий к определенной задаче; б) для получения номера версии текущего релиза.

На этих правилах, инструментах и методологии было реализовано управление проектом при создании и продвижении стартапа Ahoba (; на этапе “Alpha-1”. Цели и условия, которые у нас были, диктовали именно их.

Кирилл,
руководитель проекта

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

Внешнее окружение:

политика, экономика, общество, законы и право, наука и техника, культура, природа, экология, инфраструктура;

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

Внутреннее окружение. Наиболее существенными факторами "внутреннего" окружения являются:

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

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

участники проекта. Они реализуют различные интересы в процессе осуществления проекта, формируют свои требования в соответствии с целями и мотивацией и оказывают влияние на проект в соответствии со своими интересами, компетенцией и степенью "вовлеченности" в проект;

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

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

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

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

организация, система документации проекта .

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

PMI PMBOK 2015 Guide 4d Edition (оценка проектов на основании британской методики) состоит из двух частей:

Часть 1 - это структура знаний управления проектами, которая обеспечивает базовую структуру для понимания управления проектами, и его методологию, это введение, которое определяет ключевые термины и обеспечивает обзор остальной части документа;

Часть 2 - описывает основное содержание стандарта - это 39 основных процессов и их взаимодействие при управлении проектами. Это 9 областей знаний управления проектами (таблица. 1.2.). Область знаний - это специфическая сфера компетенции менеджера проекта, которую ему необходимо знать, для того, чтобы успешно осуществить проект.

Таблица 1.2.

9-областей знаний по управления проектами

	Процессы
1. Управление Интеграцией	1. Процессы, обеспечивающие координацию между элементами проекта.
2. Управление Замыслом	2. Процессы, обеспечивающие замысел и выполнение всех требуемых и только тре-буемых работ.
3. Управление Временем	3. Процессы, обеспечивающие завершение работ в заданное время.
4. Управление Стоимостью	4. Процессы, обеспечивающие завершение работ в заданном бюджете.
5. Управление Качеством	5. Процессы, обеспечивающие выполнение требований и ожиданий заказчика.
6. Управление Ресурсами	6. Процессы, обеспечивающие наиболее эффективное использование ресурсов, участ-вующих в проекте.
7. Управление Коммуникацией	7. Процессы, обеспечивающие создание, хранение и своевременное распределение информации о проекте.
8. Управление Риском	8. Процессы, связанные с определением, анализом и реакцией на возможный риск, связанные с проектом.
9. Управление Поставками	9. Процессы, необходимые для заказа товаров и услуг у других организаций.

Примечание: источник .

Как правило, для удобства управления, проекты разбиваются на несколько фаз. Все фазы вместе называются жизненным циклом проекта (Project Life Cicle). Внутри каждой фазы и в целом по проекту процессы организованы в пять групп (табл. 1.3).

Таблица 1.3

Процессы внутри фазы по проекту

Примечание: источник .

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

международная организация по стандартизации ISO опубликовала стандарт ISO 10006 «Системы менеджмента качества. Руководящие указания по менеджменту качества проектов». В настоящее время выполняется разработка стандарта ISO 21500 «Руководство по менеджменту проектов». Однако официально данный стандарт будет утвержден только в 2012 году;

международная ассоциация проектного менеджмента (International Project Management Association - IPMA) объединяет 45 национальных ассоциаций и является авторитетной профессиональной организацией в области управления проектами. Россию в IPMA представляет национальная ассоциация управления проектами СОВНЕТ. Основным стандартом, разработанным IPMA, является ICB (IPMA Competence Baseline, 3-я версия выпущена в 2015 году), определяющая требования к квалификации специалистов в области управления проектами и являющаяся основой для международной сертификации. В соответствии с правилами и требованиями IPMA в России разработаны национальные требования к компетенции менеджера проекта и программа сертификации специалистов по управлению проектами. Специалисты, прошедшие сертификацию по этой системе, получают сертификаты международного образца, которые признаются во всем мире;

институт управления проектами США (Project Management Institute - PMI) сегодня «де факто» также можно назвать международной профессиональной организацией. Членами PMI являются специалисты в области управления проектами со всего мира, в различных странах функционируют отделения института. PMI ведет активную разработку стандартов в области управления проектами. В настоящее время опубликовано 3 основных стандарта, регламентирующих процессы управления на уровне проекта, программы, портфеля проектов и более 10 дополнительных стандартов. Дополнительные стандарты определяют как требования к отдельным методикам управления проектами (разработка иерархической структуры работ, разработка календарного плана, управление рисками и другие), так и к применению проектного менеджмента для определенных типов проектов (управление строительными проектами, управление государственными проектами и другие) .

По областям применения стандарты могут быть разделены на следующие группы:

применимые к отдельным объектам управления (проект, программа, портфель проектов) и регламентирующие соответствующие процессы управления;

применимые к субъектам управления (менеджеры проектов, участники команд управления проектами) и определяющие требования к знаниям и квалификации соответствующих специалистов и процессу оценки квалификации;

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

Некоторые Окончание табл. 1. наиболее известные стандарты международного и национального уровня представлены в следующей таблице 1.4. .

Таблица 1.4.

Наиболее известные стандарты международного и национального уровня

Классификация стандартов
Международные стандарты, определяющие общие требования к процессам управления проектом.	ISO 10006 «Системы менеджмента качества. Руководящие указания по менеджменту качества проектов»	ГОСТ Р ИСО 10006-2013 «Системы менеджмента качества. Руководство по менеджменту качества при проектировании», 2015.На практике применяется достаточно редко, поскольку носит общий характер.
Национальные стандарты, определяющие общие требования к процессам управления проектом.	A Guide to the Project Management Body of Knowledge (PMBOK Guide). Руководство к своду знаний по управлению проектами. Четвертое издание. PMI. 2015 PRINCE2 (PRojects IN Controlled Environments). OGC UK, 2001 и другие национальные стандарты	Руководство к своду знаний по управлению проектами. Четвертое издание. PMI. 2015 Русская версия. Не является стандартом в России. Однако PMBOK широко применяется на международном уровне и является стандартом «де факто». В России также применяется достаточно широко.
ЕСУП (Евразийский Стандарт Управления Инновационными Проектами)	Не известны иностранные версии стандарта	Евразийский Стандарт Управления Проектами разрабатывается на основе лучших мировых достижений проектного менеджмента с учётом задач и особенностей Евразийской цивилизации. Основная идея стандарта воплощена в корпоративном прототипе ЕСУП.
Стандарты, определяющие общие требования к процессам управления программой и портфелем проектов.	The Standard for Program Management, Second Edition, PMI 2015. The Standard for Portfolio Management, Second Edition, PMI 2015 Managing Successful Programmes, OGC UK, 2014 P2M. Program and Project Management for Innovation of Enterprises, PMCC, 2002
Стандарты, определяющие требования к последовательности и методикам выполнения отдельных процессов.	Practice Standard for Work Breakdown Structure, 2nd Edition, PMI, 2015 Practice Standard for Earned Value Management, PMI, 2013 Practice Standard for Scheduling, PMI, 2014 Practice Standard for Configuration Management, PMI, 2014	ГОСТ Р 52806-2014 Менеджмент рисков проектов. Общие положения.
Стандарты, определяющие требования к квалификации специалистов в области управления проектами.	ICB IPMA Competence Baseline, Version 3.0, IPMA 2015 PMCDF Project Management Competence Development Framework, PMI, 2013	Основы Профессиональных Знаний и Национальные Требования к Компетентности (НТК 3.0) Специалистов по Управлению Проектами, СОВНЕТ, 2013. Не является официальным стандартом в России, но зарегистрирован в Росстандарте России. Используется для сертификации специалистов в соответствии с требованиями IPMA. ГОСТ Р 52807-2014 Руководство по оценке компетентности менеджеров проектов.
Стандарты, определяющие требования к корпоративной системе управления проектами.	OPM3 Organizational Project Management Maturity Model, PMI, 2015	Нет русскоязычных версий стандартов.

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

В рамках организационно - деятельностей (“менеджерской”) модели (ICB IPMA) проект как понятие определяется через предприятие, усилие и деятельность.

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

те, которые можно описать в виде процессов, объектов, методов;

те, которые не описываемы в принципе или трудно описываемы в виде процессов, объектов, методов.

Современные подходы к стандартизации в области РМ основаны на следующем:

для международных и национальных стандартов по РМ в качестве объектов выбираются, как правило, глоссарии, процессы и методы;

для тех областей РМ, описание которых в виде объектов для стандартизации нецелесообразно или невозможно, используются профессиональные квалификационные стандарты (требования) к деятельности специалистов по РМ (Project Management Professional) и менеджеров проектов (Project Manager).

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

Вывод по первой главе

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

В систему управления проектами можно включить: разработку миссии организации, стратегии организации, портфеля программ, программы портфеля проектов. Также необходимо применять разнообразные программно-целевые методы управления (особенно планирования), предусматривающие формирование и организацию выполнения целевых комплексных программ и проектов (ЦКП). Эти задачи представляют собой комплекс взаимосвязанных мероприятий, направленных на достижение конкретных социально-экономических целей. Глобальных систем международных стандартов по РМ не существует. Это связано как с принципиальной невозможностью комплексной стандартизации управления социотехническими системами, какими являются современные проекты, так и с нецелесообразностью разработки стандартов по большому кругу вопросов современного РМ.