pmi что это в проектах
Качаем навык управления проектами или еще раз про PMI PMBOK
Структура статьи
Друзья, всем привет. Сегодня я расскажу про управление проектами, про методологию или свод правил по управлению проектами PMI PMBOK (Project Management Institute Project Management Body Of Knowledge). Выпустил эту методологию и регулярно ее обновляет авторитетный институт по управлению проектами, расположенный в Пенсильвании, США. Несмотря на то, что в мире есть и другие методологии, например британский стандарт PRINCE2 или японский P2M, в России наиболее популярна именно эта, на ее основе приняты ГОСТы по проектному менеджменту.
В целом я попробую лаконично, но возможности интересно рассказать о тех знаниях и опыте в области управления проектами, которые получил на данный момент. Также я являюсь сертифицированным экспертом по управлению проектами – PME.
Методика управления проектами универсальна, правила одни и те же. Сами же проекты всегда разные, они имеют начало и конец в отличие от операционной деятельности, которая, как бы происходит постоянно, рутинно. Мы с вами являемся участниками множества проектов и на работе и дома. Проектом может быть исследование рынка, разработка программного обеспечения, строительство нового здания. Проектом может быть и переезд на новое место жительства или создание семьи.
PMI PMBOK – методология использующая современный процессный подход, согласно которого все работы по управлению проектом осуществляются в виде отдельных взаимосвязанных между собой процессов. Каждый процесс начинается с исходного состояния и завершается неким результатом или ценностью, которая затем используется в других процессах или является конечным продуктом. Всего методология содержит 49 процессов из 10 областей зданий. Процессы можно сгруппировать не только по областям знаний, но и по фазам жизненного цикла проекта: инициация, планирование, исполнение, мониторинг и контроль, завершение. Таким PMBOK есть сеть взаимосвязанных процессов по управлению проектами, выполнение которых приведет вас к успеху (статистика показывает, что вероятность успеха выше там, где используется осознанное профессиональное управление проектом). Свод правил как раз и описывает каким образом нужно производить каждый их этих процессов через определенные порядок, методики и инструменты.
Проект считается успешным, если не превышены запланированные для него бюджет и график, а также заказчик и конечные пользователи остались довольны его результатами.
Если вы профессиональный руководитель проектов или его помощник, то пройти курсы по управлению проектами и получить сертификат просто обязаны. Если вы являетесь регулярным участником различных проектов у себя в компании, то можно и самостоятельно изучить принципы проектного управления через открытые источники.
Я решил привести информацию в структурированной форме, с учетом существования 10 областей знаний. Надеюсь, мои заключения будут интересны и полезны как тем людям которые только слышали про PMBOK, так и профессионалам. По каждой из областей знаний я опишу следующее:
Управление проектами по PmBok
Руководство PMI PMBoK® – это стандарт для управления проектами. Данный стандарт описывает процессы управления проектами, инструменты и методы, используемые для управления проектом в целях достижения успешного результата.
PMI PMBOK был разработан и поддерживается Институтом управления проектами (PMI®, Project Management Institute) — это ведущая международная некоммерческая ассоциация профессионалов в управлении проектами, объединяющая более 200 000 членов в 125 странах. Получить степень PMP можно здесь.
Разберем свод правил по этой книге с помощью методологии Ивана Селиховкина.
ЧАСТЬ 1.СТРУКТУРА PMBOK
10 областей знаний:
Области знаний разбиты на группы и состоят из 47 процессов управления проектом, объединенных в 5 групп:
Процесс — это задача, к примеру, создать расписание.
Пример: область знаний «управление сроками» на этапах «ПЛАНИРОВАНИЕ» и «МОНИТОРИНГ»:
Исключение: процессы из областей знания «интеграция» и «управление HR»:
Примечание. Область знаний «Управление интеграцией» — в книге эта глава первая, но никогда не стоит начинать чтение книги с этой главы, потому что она абстрактна и не даем применимых знаний.
ЧАСТЬ 2.
ПРИНЦИПЫ ПРОЕКТНОГО УПРАВЛЕНИЯ
Фундаментальные принципы PMI :
Разберем каждый принцип подробнее.
1. Принцип яйца
«Скорлупа яйца» — Устав проекта, который пишется в начале проекта
«Внутреннее содержимое яйца»:
2. Принцип удава
Жизненный цикл проекта:
Начало проекта — «инициация» > Середина проекта — «цикл Деминга» > Конец проекта — «закрытие»
Если представить этапы в виде удава, то получается следующая картинка (этого в книге нет, это разработал И.Селиховкин):
3. Принцип командности и проактивности
ЧАСТЬ 3. ОБЛАСТИ ЗНАНИЙ
1. УПРАВЛЕНИЕ ИНТЕГРАЦИЕЙ ПРОЕКТА
ROI-return of investment — (возврат инвестиций)
internal rate of return — (внутренняя ставка возврата)
discounted cash flow — (дисконтированный денежный поток)
net present value — (чистый дисконтированный доход)
4.1. Разработка устава проекта
Устав фиксирует цели и ограничения проекта
Должен быть неизменным
4.2. Разработка плана управления проектом
Как будем измерять выполнение планов, как закрывать проект.
4.3. Мониторинг и контроль работ проекта
Проверка хода проекта относительно всех планов: нужно сверить «план» и «факт» (укладываем в сроки?, укладываемся в бюджет? и т.п.)
4.4. Интегрированный контроль изменений
4.5. Руководство и управление работами проекта
Это координация команды, действия по планам, работа с отчета и т.п.
4.6. Закрытие фазы или проекта
Все проекты и фазы должны быть закрыты все зависимости завершился он триумфом или провалом.
2. УПРАВЛЕНИЕ СОДЕРЖАНИЕМ ПРОЕКТА
Определить, какие работы необходимы, а потом что только они выполняются. 
5.1. Планирование управлением содержанием
Связать все планы воедино
5.2. Сбор требований
Сбор требований происходит посредством опроса заинтересонных лиц — интервью, анкеты и т.п.
5.3. Определение содержания
Делаем концепцию (техническое задание): детальное описание продукта и проекта
Определяем: что делаем и чего НЕ делаем в ходе проекта
5.4. Создание иерархической структуры работ
Разделяй и властвуй!
Перед тем как представить иерархическую структуру работ желательно представить иерархическую структуру продукта
Иерархическая структура продукта (PBS — Product Breakdown Structure):
Иерархическая структура работ (WBS — Work Breakdown Structure):
Существенным является не способ представления, а иерархичность: декомпозиция любого результата на его составляющие.
От сложного – к простому.
5.5. Контроль содержания
Если понимаем, что не учли какой-то элемент, то вносим изменения в планы
5.6. Подтверждение содержания
3. УПРАВЛЕНИЕ ВРЕМЕНЕМ (СРОКАМИ) ПРОЕКТА
Вот как это выглядит на «Карте процессов»: 
6.1. Управление расписанием
Как создать расписание и сопоставление содержания с расписанием
6.2. Определение операций
Декомпозиция технического задания в ДЕЙСТВИЯ!
Берем иерархическую структуру работ и переводим ее в «глаголы» — как добьем результата обозначенного в ИСР.
6.3. Определение последовательности операций
Перестраиваем ИСР в Сетевую диаграмму (PDM — Precedence Diagramming Method, Метод «операции в узлах» (метод предшествования).
Сетевая диаграмма проекта показывает набор операций и логику их последовательностей – кто за кем. Заметьте, что в этой диаграмме нет никаких характеристик самих операций, например, сроков или длительностей – только логика: что и в какой последовательности должно делаться в проекте. Эта диаграмма является важнейшим промежуточным шагом на пути к значимой цели – расписание проекта
6.4. Оценка ресурсов операций
Ресурсы делятся на:
6.5. Оценка длительности операций
Способ оценки по аналогии с предыдущей похожей деятельностью.
Пример такой оценки: мы уже исполняли подобные работы и по опыту знаем, что на исполнение требуется 5 дней. Или не исполняли подобного, но погуглили или опросили экспертов.
Среди аналоговых методов оценки есть один метод, который люди используют чаще всего – оценка из своего опыта. Это предполагает простой алгоритм:
опытный человек чешет затылок и сообщает: — ну, я это не раз делал, понадобится столько-то деньков.
Такой оценки имеет существенную особенность – оценки получаются заниженными, то есть оптимистичными.
Это оценка такого типа:
я не знаю, сколько понадобится времени на эту операцию, но могу сказать, что если все пойдет хорошо, то уложимся в 5 дней (оптимистичная оценка), в худшем варианте понадобится 10 дней (пессимистичная оценка), а скорее всего, потребуется 7 дней (наиболее вероятная оценка).
В результате нужно усреднить способом «оценка PERT» (PERT – Program Evaluation and Review Technique):
Ожидаемая оценка = (Оптимистичная + 4 * Наиболее вероятная + Пессимистичная) / 6
Обращаю внимание, что делим на 6 потому, что взяли 4 наиболее вероятных оценок и по одной оптимистичной и пессимистичной – всего шесть оценок.
Пример: Оценка по трем точкам.
Некоторая работа исполнялась 10 раз. Статистика длительностей:
Посчитаем разные средние значения:
Средняя (арифм) = (4 * 2 + 5 * 7 + 9 * 1) / 10 = 5,2 дней
Ожидаемая (PERT) = (4 + 4 * 5 + 9) / 6 = 5,5 дней
6.6. Разработка расписания
Используйте программное обеспечение — диаграммы Ганта и т.п.
Метод критического пути для составления расписания
Метод критического пути является основным способом расчета расписания проекта.
Операции могут иметь резервы, вызванные наличием параллельных цепочек:
Резерв (Float, Total Float, Slack) – время, на которое операция может быть задержана, без увеличения длительности проекта:
Свободный резерв (Free Float) – время, на которое операция может быть задержана, не влияя на раннее начало любой последующей операции
В прямом проходе, от начала к концу проекта, рассчитываются ранние даты операций. А в обратном проходе, от конца проекта к началу, все наоборот – рассчитываются поздние даты каждой операции.
Результатом расчета является таблица с ранними датами и резевами каждой операции:. 
Операции без резервов являются основным фокусом внимания менеджера и команды проекта:
Критический путь — все работы, у которых нет резервов. Критический путь определяет длительность проекта.
6.7. Контроль расписания
Делаем прогнозы отклонений и отслеживаем укладываемся ли в в график.
4. УПРАВЛЕНИЕ СТОИМОСТЬЮ ПРОЕКТА
7.1. Планирование управлением стоимостью
Как будем держать под контролем наш план
7.2. Оценка стоимости
Считаем себестоимость на основе временных зарат.
Стоимость проекта = стоимость всех работ проекта
Стоимость работы = стоимость израсходованных ресурсов.
Стоимость проекта = Сумма стоимостей израсходованных ресурсов.
7.3. Определение бюджета
Бюджет проекта – это распределение стоимости проекта по времени.
Базовый план стоимости (cost baseline)= себестоимость работ + резервы работ + резервы пакетов работ
Бюджет проекта (project budget) = Базовый план стоимости + управленческие резервы
Управленческие резервы — это деньги, который спонсор проекта отложил на «всякий случай»
«План по стоимости» — это бюджет проекта.
Стоимости делят на две важные группы:
«Резерв управления» – это превышение бюджета, вызванное выявленными рисками.
7.4. Контроль стоимости
Собираем все вместе и контролируем календарный план проекта (MS Project):
7. УПРАВЛЕНИЕ КОММУНИКАЦИЯМИ
Заинтересованные стороны проекта – это лица и организации, например заказчики, спонсоры, исполняющая организация и общественность, которые активно участвуют в проекте, или интересы которых могут быть затронуты как положительно, так и отрицательно в ходе исполнения или в результате завершения проекта. Они также могут оказывать влияние на проект или на его результаты. Заинтересованные стороны проекта могут находиться на различных уровнях внутри организации и иметь разные уровни полномочий либо могут являться внешними по отношению к исполняющей организации проекта.
В процессе планирования коммуникаций определяются информация и взаимодействия, необходимые заинтересованным сторонам проекта, например: каким лицам какая информация нужна, когда она им понадобится, кто и каким образом должен им эту информацию предоставить.
Это процесс предоставления необходимой информации заинтересованным сторонам проекта в соответствии с планом.
Это процесс общения и работы с заинтересованными сторонами проекта для удовлетворения их потребностей и решения возникающих проблем.
Это процесс сбора и распространения информации об исполнении, включая отчеты о состоянии, результаты измерения исполнения и прогнозы. Процесс подготовки отчетов об исполнении включает периодический сбор фактических данных и их сопоставление с базовым планом для оценки продвижения проекта и его исполнения, передачи данной информации, а также прогнозирования результатов проекта.
Pmi что это в проектах
This top reference is available in English, Spanish, French, Brazilian Portuguese, Italian, German, Russian, Arabic, Simplified Chinese and Korean.
Join Your Local Chapter
Build your professional network and gain insider connections within local companies in your area. Learn how the benefits of belonging to a PMI chapter can help you.
Resource Hub
We’ve compiled a variety of free online resources, virtual events and even a sneak peek of new digital offerings to help you connect with the global community, build skills, and prepare to advance in a post-COVID-19 world. Explore and share these resources, and check back often for updates.
Membership
Join PMI, the world’s leading project management organization with over 600,000 Global Members and over 300 Local Chapters Internationally.
What is PMI Membership?
In a word, dedication. PMI membership signifies that you’re serious about your project management career and your professional development. It highlights this dedication to employers, colleagues and stakeholders, giving you an edge in the job market. It also provides you with access to valuable knowledge, networks and resources.
Networking
Find a mentor, friend, or new contact. Connect with over 1 million global project management peers and experts through live events, learning seminars and online community. Build a network of peers that you can rely on for guidance, support and idea sharing. Converse with peers locally, in other countries, in and outside your industry that share the same core passion for project management.
Tools & Templates
As a PMI member, you’ll gain exclusive access to PMI publications and global standards. In addition, leverage thousands of tools, templates, articles, guides and other resources to keep you informed and remain efficient.
Chapters
Expand your network by attending PMI local Chapter events. Events offer a variety of topical sessions to informal meetups. Collaborate with like-minded individuals locally to create and share consumable content, tools and resources.
Certifications
You, certified. The recognition you deserve; the credibility you need. PMI certification is a mark of excellence — in any location, in any industry.
Take the CAPM Exam Online
Studying for the CAPM exam? You now have the option of taking it from your favorite computer at home or in the office.
*According to data collected since January 2021 comparing exam pass rates of those that completed training through an Authorized Training Partner versus those that did not.
Learning
Grow your knowledge and your opportunities with thought leadership, training and tools.
Build Your Project Management Skills Online, Anytime
Want to learn and earn PDUs or CEUs on your schedule — anytime, anywhere? Or, pick up a new skill quickly like, project team leadership or agile? Browse our most popular online courses.
Events
Sign up for a PMI event to build your skills, develop lasting relationships and engage with experts. Share best practices and gain practical insights.
SeminarsWorld® Virtual
Supercharge your skills, work smarter with SeminarsWorld ® Virtual. Registration is open for training through November. Choose from 1 to 4-day classes or try our new hour-long classes. Learn more.
Community
There is a place where conversation and content intersect, where you can maintain your credentials, get answers to your questions, share your expertise – anytime, anywhere. That place is ProjectManagement.com, PMI’s home for online community. We’ll see you there…
Virtual Experience Series
New World. New Challenges. New Solutions.
Recovery is just underway, and while we are navigating a world defined by challenge and change, we can embrace the opportunity to Make Reality in new and exciting ways. Register for on demand access through 31 January 2022.
Менеджмент знаний в международных стандартах: ISO, PMI
Всем привет. После KnowledgeConf 2019 прошло уже полгода, за это время я успел выступить еще на двух конференциях и провести лекции на тему управления знаниями в двух крупных ИТ-компаниях. Общаясь с коллегами, я понял, что в ИТ пока можно говорить об управлении знаниями на уровне «новичок», а точнее, просто осознать, что управление знаниями нужно любому подразделению любой компании. Сегодня будет минимум моего собственного опыта – я бы хотел рассмотреть существующие международные стандарты в области менеджмента знаний.
Начнем, наверное, с самого популярного бренда в области стандартизации – ISO. Представьте себе, существует целый отдельный стандарт, посвященный системам управления знаниями (ISO 30401:2018). Но сегодня я бы на нем останавливаться не стал. Прежде чем разбираться «как» должна выглядеть и работать система управления знаниями, нужно договориться, что она, в принципе, нужна.
Возьмем, например, ISO 9001:2015 (Quality management systems). Как следует из названия, это стандарт, посвященный системе менеджмента качества. Чтобы сертифицироваться по этому стандарту, организация должна обеспечивать прозрачность и бесперебойность рабочих процессов и производимых продуктов и/или услуг. Иными словами, сертификат означает, что в вашей компании все работает четко, слаженно, вы понимаете, какие риски несет текущая организация процессов, знаете, как контролировать эти риски, и стремитесь их минимизировать.
При чем здесь управление знаниями? А вот при чем:
7.1.6 Знания организации
Организация должна определить знания, необходимые для функционирования ее процессов и для достижения соответствия продукции и услуг.
Знания должны поддерживаться и быть доступными в необходимом объеме.
При рассмотрении изменяющихся нужд и тенденций организация должна принимать во внимание имеющиеся у нее знания и определять, каким образом получить или обеспечить доступ к дополнительным знаниям и их актуализации.
ПРИМЕЧАНИЕ 1. Знания организации — это знания, специфичные для организации; в основном полученные на основе опыта.
Знания – это информация, которая используется и которой обмениваются для достижения целей организации.
ПРИМЕЧАНИЕ 2. Основой знаний организации могут быть:
a) внутренние источники (например, интеллектуальная собственность; знания, полученные из опыта; выводы, извлеченные из неудачных или успешных проектов; сбор и обмен недокументированными знаниями и опытом; результаты улучшений процессов, продукции и услуг);
b) внешние источники (например, стандарты, научное сообщество, конференции, знания, полученные от потребителей и внешних поставщиков).
И ниже, в приложениях:
Требования, относящиеся к знаниям организации, были введены с целью:
a) защиты организации от потери знаний, например, из-за:
b) стимулирования организации к приобретению знаний, например, на основе:
Итак, стандарт ISO в области менеджмента качества утверждает, что для обеспечения качества своей деятельности предприятие должно заниматься менеджментом знаний. Именно так, безальтернативно – «должно». Иначе nonconformity, и до свидания. Уже один этот факт как бы намекает, что это не факультативный аспект в организации, как к управлению знаниями в ИТ часто относятся, а обязательная составляющая бизнес-процессов.
Более того, стандарт рассказывает, какие риски менеджмент знаний призван устранять. На самом деле, они вполне очевидны.
Давайте представим… нет не так – вспомните, пожалуйста, ситуацию из своей карьеры, когда вам очень нужна была по работе какая-то информация, а ее единственный носитель был в этот момент в отпуске/командировке, вообще уволился из компании или просто болел. Вспомнили? Я думаю, практически любому из нас приходилось с этим сталкиваться. Что вы в этот момент чувствовали?
Если через какое-то время руководство подразделения будет разбирать срыв сроков проекта, оно, конечно же, найдет виноватого и на этом успокоится. Но вам лично в тот момент, когда знания были нужны, никак не помогло понимание, что «виноват РМ, который уехал на Бали и не оставил никаких инструкций на случай вопросов». Безусловно, он виноват. Но вашу задачу это решить не поможет.
Если же знания задокументированы в системе, доступной людям, которым они могут понадобиться, то описанная «курортная» история становится практически невозможной. Таким образом, обеспечивается непрерывность бизнес-процессов, а значит, отпуска, уходы сотрудников и тот самый пресловутый bus factor предприятию не страшны – качество продукта/сервиса останется на своем обычном уровне.
Если в компании есть площадка для обмена и хранения информации и опыта, а также сформирована культура (привычка) пользования этой площадкой, то сотрудникам не приходится ждать по несколько дней ответа от коллеги (или вообще несколько дней искать этого коллегу) и ставить из-за этого на hold свои задачи.
Почему говорю о привычке? Потому что мало сделать базу знаний, чтобы ей начали пользоваться. Мы все привыкли искать ответы на свои вопросы в гугле, а интранет чаще всего у нас ассоциируется с заявлениями на отпуск и доской объявлений. У нас нет привычки «поискать информацию о фреймворках Agile» (например) на интранете. Поэтому, даже если у нас в одну секунду появится крутейшая база знаний, пользоваться ей на следующую секунду (и даже на следующий месяц) никто не начнет – нет привычки. Менять свои привычки больно и долго. Не все к этому готовы. Особенно если 15 лет «и так же работали». Но без этого инициативу по работе со знаниями в компании ждет провал. Именно поэтому мастера в области УЗ неразрывно связывают управление знаниями с управлением изменениями (change management).
Еще стоит обратить внимание на то, что «При рассмотрении изменяющихся нужд и тенденций организация должна принимать во внимание имеющиеся у нее знания…», т.е. выработать культуру обращения к предыдущему опыту при принятии решений в условиях изменяющегося мира. И заметьте, снова «должна».
Кстати, в этом небольшом пункте стандарта очень много говорится про опыт. Обычно, когда речь заходит про управление знаниями, стереотипы начинают подсовывать картинку базы знаний с сотнями документов, размещенных в виде файлов (регламентов, требований). Но ISO говорит об опыте. Знания, полученные на основе прошлого опыта компании и каждого ее сотрудника, и есть то самое, что позволяет избежать риска повторного совершения ошибок, сразу принимать более выгодные решения и даже создавать новый продукт. В наиболее зрелых в сфере управления знаний компаниях (в том числе и российских, кстати), управление знаниями рассматривается как средство повышения капитализации компании, создания новых продуктов, разработки новых идей и оптимизации процессов. Это не база знаний, это механизм для инноваций. Разобраться в этом подробнее нам помогает Руководство PMBOK организации PMI.
PMBOK – это руководство к своду знаний по управлению проектами, настольная книга PMа. В шестом издании (2016) этого руководства появился раздел, посвященный управлению интеграцией проекта, в который, в свою очередь, включен подраздел об управлении знаниями проекта. Этот пункт был создан «на основе комментариев пользователей руководства», т.е. стал продуктом опыта по использованию предыдущих версий гайда в реальных условиях. И реальность потребовала управления знаниями!
Основным выходом нового пункта является «Реестр извлеченных уроков» (в описанном выше стандарте ISO, кстати, он тоже упоминается). Причем, согласно руководству, составление этого реестра должно производиться на всем протяжении реализации проекта, а не по его завершении, когда приходит время анализировать результат. На мой взгляд это очень перекликается с ретроспективами в agile, но об этом я напишу отдельный пост. Дословно текст в PMBOK звучит так:
Управление знаниями проекта – это процесс использования существующих знаний и создания новых знаний для достижения целей проекта и содействия обучению в организации
Область знаний «управление интеграцией проекта» требует объединения результатов, полученных во всех других областях знаний.
Развивающиеся тенденции в процессах интеграции включают в себя, среди прочего:
• Управление знаниями проекта
Все более мобильный и сменяемый характер рабочей силы требует и более строгого процесса определения знаний на всем протяжении жизненного цикла проекта и их передачи целевым аудиториям так, чтобы исключить утрату знаний
Ключевые выгоды данного процесса состоят в том, что ранее приобретенные знания организации используются в целях получения или улучшения результатов проекта, а знания, полученные при реализации текущего проекта, остаются доступными для обеспечения операционной деятельности организации и будущих проектов или их фаз. Этот процесс осуществляется на протяжении всего проекта.
Не буду копипастить сюда весь большой раздел руководства. С ним можно ознакомиться самостоятельно и сделать соответствующие выводы. Представленных выше цитат, на мой взгляд, вполне достаточно. Мне кажется, наличие подобной детализации задачи РМа по управлению знаниями проекта уже говорит о важности этого аспекта при работе над проектами. Кстати, часто слышу тезис: «Кому нужны наши знания в других отделах?» То есть, кому нужны вот эти извлеченные уроки?
На самом деле, часто можно видеть, что подразделение рассматривает себя, как «юнит в вакууме». Вот есть мы с нашей библиотечкой, а вот есть вся остальная компания, и знания о нашей библиотечке ей никак не пригодятся. О библиотечке – возможно. А о сопутствующих процессах?
Банальный пример: в ходе работы над проектом происходило взаимодействие с подрядчиком. Например, с дизайнером. Подрядчик оказался так себе, срывал сроки, отказывался дорабатывать без дополнительной оплаты. РМ зафиксировал в реестре извлеченных уроков, что не стоит работать с этим ненадежным подрядчиком. В это же время где-нибудь в маркетинге тоже искали дизайнера и натолкнулись на того же подрядчика. И в этот момент есть два варианта:
а) если в компании хорошо налажена культура переиспользования опыта, коллега из маркетинга поищет в реестре извлеченных уроков, не связывался ли кто-то уже с этим подрядчиком, увидит негативный фидбек от нашего РМа и не потеряет времени и денег, общаясь с этим ненадежным подрядчиком.
б) если в компании нет такой культуры, маркетолог обратится к тому же ненадежному подрядчику, потеряет деньги компании, время и может сорвать важную и срочную промо кампанию, например.
Какой вариант кажется более успешным? И заметьте, полезной оказалась не информация о разрабатываемом продукте, а о сопутствующих разработке процессах. И полезной она оказалась не другому РМу, а сотруднику совершенно другого направления. Отсюда вывод: нельзя рассматривать разработку отдельно от продаж, техподдержку от бизнес-аналитики, а ИТ – от АХУ. У всех в компании есть опыт работы, который окажется полезным кому-то еще в компании. И вовсе не обязательно это будут представители смежных направлений.
Впрочем, и техническая сторона проекта может пригодиться. Попробуйте провести аудит проектов в вашей компании за последние несколько лет. Вы удивитесь, сколько велосипедов было изобретено при решении схожих задач. Почему? Потому что не налажены процессы обмена знаниями.
Итак, управление знаниями, согласно руководству PMI, это одна из задач РМа. Как видим, две известных организации, которые проводят платные сертификации по своим стандартам, включают менеджмент знаний в списки мастхэв инструментов контроля качества и работы над проектами. Почему же менеджеры в ИТ-компаниях до сих пор считают, что управление знаниями – это документирование? Почему центрами обмена знаниями остаются кулер и курилка? Все дело в понимании и привычках. Надеюсь, постепенно понимания сферы управления знаниями и у айтишных менеджеров будет становиться все больше, и устная традиция перестанет служить инструментом сохранения знаний в компании. Изучайте стандарты своей работы – в них много чего интересного!