4×4.proPROJEKT

Текущий пост будет посвящен управлению проектами.

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

Формат остаётся традиционным 4х4.proPROJECT. Четверка вопросов (тем) подлежащих рассмотрению: методологии управления проектами, определение и ключевые признаки проекта, результаты проекта, документы проекта.

Четверка методологий управления проектами, о которых немного расскажу: PMBOK, PRINCE2, SCRUM, P2M.

Думаю, аббревиатуру PMBOK слышал каждый хоть как то интересовался вопросами управления проектами в широком значении этого термина (значительно шире, чем разработка программного обеспечения, что сейчас очень на слуху). Образована аббревиатура от первых букв Project Management Body of Knowledge , что в переводе означает Свод знаний по управлению проектами, а документ, в котором об этом всё написано, называется «Руководство к своду знаний по управлению проектами». Этот свод знаний разработан и развивается американским Project Management Institute (PMI). Свод знаний является глубоко проработанным, методологически выверенным, хорошо задокументированным подходом к управлению проектами, вокруг которого создана целая экосистема: обучение, документы, сертификация специалистов и т.д. Свод выглядит, да и является очень сложным и громоздким, но зато он готов ответить на большинство вопросов по всем процессам в управлении проектами их взаимосвязям, задает принципы, следуя которым можно управлять проектами практически любой сложности.

Хочется отметить, что указанный свод не застыл как некая догма, а постоянно развивается. Так в  пятой редакции РМВOК появилась новая  область знаний — «Управление заинтересованными сторонами (часто и в русскоязычной литературе используется заимствованное слово – стейкхолдеры) проекта». Я для себя определяю основные четыре принципа PMBOK: управление (менеджмент), дисциплина, планирование, документирование. Если эти слова вызывают у Вас отторжение – Вам с PMBOK не по пути, да и с менеджментом вообще, по-моему, не очень. Считаю, что управлять проектами по PMBOK рентабельно только на очень больших проектах, а вот использование принципов, отдельных приемов и документов возможно и полезно при управлении любыми проектами, да и не только проектами. Кстати, международная организация по стандартизации выпустила ISO 21500 – это международный стандарт по управлению проектами, который является «немножко облегченной» версией PMBOK.

PRojects IN Controlled Environments 2 (PRINCE2)  — это разработанная в Великобритании методология управления проектами. Создавалась она в конце 1980-ых для управления проектами в сфере информационных технологий, но позже расширила свои границы, и в настоящее время является стандартом де-факто в Великобритании по управлению проектами в различных сферах. Методология, по-моему, очень близка к американской PMBOK, но попроще, потому что многие процессы, рассматриваемые в PMBOK, PRINCE2 вывела за пределы стандарта. Четыре принципа, которые я определил для себя по отношению к PMBOK, вполне распространимы и на PRINCE2.

Второй ключевой посыл этой методологии – это акцент на создание в рамках проекта инновации. Несколько лет назад, до последнего «увлечения» «американским» подходом Agile, президент Сбербанка России Герман Греф писал: «Принципиальным подходом, который составляет ядро нашей стратегии, является ценностный подход, который составляет фундамент японской системы знаний по управлению инновационными проектами и программами Р2М. Ориентация на создание ценностей заложена в основу нашего инновационного продукта «Производственной Системы Сбербанка». Именно от глубины понимания миссии инновационного развития и ценностей заинтересованных сторон, их гармонизации и ориентации на успех, зависит эффективность нашей деятельности, которую мы непрерывно контролируем и совершенствуем с использованием лучшей японской и мировой практики».

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

Уважаемая Википедия об этом пишет:

«Agile — семейство процессов разработки, а не единственный подход в разработке программного обеспечения, и определяется Agile Manifesto[2]. Agile не включает практик, а определяет ценности и принципы, которыми руководствуются успешные команды.

Agile Manifesto разработан и принят 11—13 февраля 2001 года на лыжном курорте The Lodge at Snowbird в горах Юты. Agile Manifesto содержит 4 основные идеи и 12 принципов. Примечательно, что Agile Manifesto не содержит практических советов.

Основные идеи:

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

«…Существует несколько методик, относящихся к классу гибких методологий разработки, в частности экстремальное программирование, DSDM, Scrum, FDD»

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

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

Расскажу коротко и «своими словами». Цель метода: короткими (2-4 недели) циклами разработки (Sprint) добавить конкретную функциональность программному продукту и передать эту функциональность в виде работающей программы Заказчику. В начале каждого спринта из  журнала пожеланий проекта (список функциональности) выбирается функциональность для текущего спринта, которая переносится в журнал пожеланий спринта и не меняется уже до его окончания (мне кажется, это противоречит одному из принципов манифеста). По ходу спринта ежедневно команда «ритуально» (в одно и тоже время, в одном и том же месте, стоя, в течение 15-ти минут) «обсуждает» ход выполнения и «планирует» задачи на следующий день.

Есть среди участников «свиньи» и «куры» с разными правами по возможности «подать голос». Есть свой Мастер — не руководитель проекта, не проект-менеджер, скорее администратор-организатор и ещё некоторые роли. Спринт должен закончиться хорошо, но метод допускает всё-таки и возможность его остановки, например если команда решила, что результат не может быть достигнут.

Знаю, что методы Agile работают в программировании,  краем уха слышал, что их пытаются внедрять значительно шире. Моё личное отношение – всему своё место. На примере программирования, например: разработка мобильных приложений для «развлекательно-вспомогательных» сервисов, где скорость выхода на рынок важнее безопасности, потенциальных проблем при эксплуатации, невысоком уровне ответственности – «ЗА», разработка автоматизированной системы управления технологическими процессами атомной электростанции или самолета и т.д. – «ПРОТИВ».

Кстати, этим летом на встрече «ПроБизнес» вице-президент и сертифицированный консультант международной консалтинговой компании «Институт Адизеса» Павел Голенченко говорил о том, что в США «мода» на Agile «сходит на нет».

«Каждый, право, имеет право…» — это я об отношении и мнении каждого менеджера к методологиям управления проектами.

Что же такое проект? Ниже приведены определения из описанных выше методологий.

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

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

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

Определение проекта в SCRUM\Agile я не нашёл L .

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

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

Вторым ключевым признаком проекта является уникальность созданного в нём продукта или услуги. Создание новой модели автомобиля – проект, серийный выпуск этих автомобилей это уже, скорее процесс, но не проект, точно. Интересно взглянуть на уникальность ещё с одной стороны. Как Вы думаете, строительство торгового центра по типовому проекту в новом городе, это проект или нет? Я считаю, что да. Во-первых, проект даже типовой надо привязать к местности, местным коммуникациям и т.д. – это уже  уникальность. С большой долей вероятности часть материалов, оборудования и т.д. будут наверняка «местными», даже если небольшая часть команды проекта и будет та же, что строила другие такие же типовые магазины, большая часть подрядчиков и других членов команды будут новыми. А внедрение на предприятии стандартной системы менеджмента качества или системы управления проектами в соответствие с PMBOK, CRM-системы (что бы автоматизировать клиенториентированность :), помните proMARKETING) или другого программного продукта – это, тоже проекты, и здесь надо помнить о первом ключевом признаке – временное предприятие, важно что бы этот проект не превратился в процесс  🙁 .

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

Я считаю ключевыми четыре документа: сетевой график (здесь немного лукавства, так как что бы сделать сетевой график надо сначала сделать иерархическую структуру работ, т.е. по-честному ключевых документов к меня пять J ), устав проекта, реестр рисков и реестр заинтересованных сторон. Я рекомендую делать эти документы при управленческом планировании не только при управлении проектами. Например, Вы можете определить для себя, что решение некоторой задачи Вы рассматриваете как Ваш «личный» проект, т.е. Вы используете при её решении проектный подход у управлению, который выразится в том, что Вы сделаете для этого проекта ключевые документы управления проектом. Первые разы будет тяжеловато, но результат, скорее всего, не заставит себя долго ждать и Вам понравится. Планирование экономит время на выполнение, мы об этом говорили неоднократно. Помните, я уже писал о разнице между  «планировать и строить планы» от Александра Фридмана?! План должен быть на носителе (бумага, память компьютера…) – а это уже документ, почему бы не взять форму документа из проверенной методологии. Шаблоны документов можно найти в интернете. Например есть образцы документов в приложении к книге «Управление ИТ-проектом «с нуля» в любой организации» (2010 год), Иван Селиховкин – рекомендую, в этой книге Вы найдете очень много полезного по управлению проектами. Эту книгу бесплатно J можно найти по ссылке http://pmlead.ru/?page_id=453

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

Об иерархической структуре работ и сетевом графике мы уже говорили, обсуждая четыре базисных компетенции менеджера-руководителя http://promanagement.by/2016/06/21/competence1/

Устав проекта – важнейший документ проекта. Я категорически рекомендую его делать, даже если Ваши Спонсор и Заказчик не готовы его подписывать. Качественно написанный устав является для менеджера проекта супер-КИВИ на старте, он помогает понять глубинные требования заказчика, осознать истинную ценность создаваемого проектом продукта (даже если Вы и не используете Р2М), настроиться  на реалии, в которых Вам придется и творить и «пахать». Помните я ещё в начале блога писал о том что и Питер Друкер и Ицхак Адизес обращали внимание на важность «НЕ»?! Устав проекта тоже имеет аналогичный раздел, который называется «Требованиями к продукту НЕ являются (продукт НЕ включает)».

Реестр рисков – первый шаг от прогнозирования к планированию управления рисками. А отличается прогнозирование от планирования тем, что прогнозирование – это «представление» будущих событий, на которые Вы влиять не можете, а планирование – это «представление» будущих событий на которые Вы можете и будете влиять! Когда Вы начинаете идентифицировать («представлять» возможные) риски, помните, Риски бывают со знаком «+», а не только «-». Управление Рисками позволяет планировать и обосновывать создание резервов проекта. Управление Рисками позволяет освобождать ресурсы Проекта, когда риск сработал или «ушел». И как почти везде есть своя четверка, 4 области рисков: содержание, расписание, стоимость, качество.  Есть целая «отрасль» в менеджменте , не только проектном – риск-менеджмент. Я не призываю погрузиться в неё, я предлагаю взять шаблон реестра рисков и попытаться его заполнить для своего ближайшего проекта, что бы почувствовать и понять насколько это полезная штука. Обсудите этот документ с членами команды, более опытными коллегами, наверняка они смогут Вам помочь как в идентификации рисков так и в оценке их вероятности и влияния.

Реестр заинтересованных сторон – это документ «материализующий» новую для PMBOK, появившуюся в 5-ой редакции, область знаний – Управление заинтересованными сторонами (стейкхолдерами). Форму опять же можно взять у того же Ивана Селиховкина. Это самый «секретный» документ проект-менеджера, потому что он содержит Вашу личную оценку главных ожиданий, требований и интересов всех заинтересованных лиц, включая представителей Заказчика и даже членов команды. Когда Вы закончите этот документ, вернитесь к реестру рисков – уверен, Вам будет что туда дописать. В отличие от других проектных документов, этот не надо обсуждать даже с членами команды. Например Ваша (недо)оценка влияния  на проект кого-то из стейкхолдеров, может его обидеть и Вы получите скрытый неучтенный риск со знаком минус.

Вот и всё, что я хотел сказать об управлении проектами в этом посте, с учётом его «запланированного» объёма. Если кого-то заинтересовала эта тема, и возникло желание погрузиться в тему поглубже, рекомендую начать с книги Ивана Селиховкина, из которой мы собирались брать шаблоны документов. У него же есть обучающие он-лайн продукты по проектному менеджменту (я заканчивал его авторский курс у «Стартоплана») и конкретно по PMBOK, в том числе бесплатные.

На следующей неделе, надеюсь, выйдет последний в текущем цикле 44х4.proMANAGEMENT пост. Я пока не решил о чём он будет, есть варианты, как говорится.

До встречи через неделю!