Какую модель выбрать?

«Корпоративная технология проектного управления основывается на своде знаний по управлению проектами PMI PMBoK»

Сергей Трофимов, директор проектного офиса компании «ФОРС – Центр разработки» (ГК ФОРС)

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

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

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

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

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

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

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

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

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

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

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

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

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

Вячеслав Логушев, директор направления ИТ-сервиса иаутсорсинга компании X-Com

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

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

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

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

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

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

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

Александр Бутов, директор департамента управления проектами компании «Неофлекс»

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

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

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

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

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

«Для выбора эффективной модели проектного управления наша компания предлагает семь шагов»

Муртазали Дибиров, исполнительный директор, Swiss Leadership Akademie

1. Дизайн-мышление: главные цели и результаты, пакеты Scrum, Lean Startup.
2. Оценка рынка: развитие организации, цифровой SWOT-анализ, проверка.
3. Шаблон идеи: наброски, исследовательские интервью, личный профиль клиента, карты эмпатии.
4. Обратная связь и пользовательский опыт: сетка обратной связи, тестирование на основе гипотез, тестирование «исходной страницы».
5. Прототип, тестирование пользовательского опыта.
6. Бизнес-наблюдение: шаблон бизнес-модели, ценностного предложения и ценности платформы, суть короткой презентации.
7. Мышление по данным: «проблема-решение-соответствие», «механический турок», название продукта, минимальный действенный продукт (МДП).

Дизайн-мышление состоит из шести подпроектов:

1. Понять: каковы болевые точки клиента? Как он решает свои проблемы в настоящее время? Что облегчит ему жизнь? Чтобы понять проблему, проведите необходимые исследования.
2. Видеть: интервью с целевой аудиторией должны проводиться экспертами. Наблюдение осуществляется за повседневными операциями клиента, и результаты точно документируются. Цель состоит в генерации пользовательского опыта за счет деятельности экспертов в роли пользователя/клиента.
3. Собрать: полученные информация и наблюдения должны оцениваться с разных точек зрения. Попробуйте использовать исследование «360-градусов» целевой аудитории. Это позволтт использовать метод картирования.
4. Предложить идею: различные методы мозгового штурма с количественной и/или качественной оценкой обеспечивают сбор идей. На данном этапе излишняя критика может препятствовать реализации дизайнерского мышления в бизнес-идее.
5. Создать прототип: описание прототипа основывается на данных мозгового штурма и служит для апробации первых идей по поводу более позднего продукта, а также для ответа на конкретные вопросы, касающиеся его дальнейшего развития.
6. Тестировать: заключительный этап начинается с тестирования прототипа целевой аудиторией с целью обратной связи от пользователей и пошаговой оптимизации продукта.

Остальные шесть этапов представлены на рисунке.

«Кто не знает, как улучшить процессы управления проектами, надо стараться формулировать конкретную задачу по проекту на две недели и раз в две недели проверять, как она сделана»

Максим Захаренко, генеральный директор компании «Облакотека»

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

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

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

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

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

Безусловно, нам есть что оптимизировать, но даже по статистике в 2017 году мы сделали 86 задач, а в 2018-м – более 150. Я очень рекомендую всем, кто не знает, как улучшить процессы управления проектами, взять хотя бы эти два принципа: стараться формулировать конкретную задачу по проекту на две недели и обязательно раз в две недели проверять, как она сделана. Сначала будет трудно уложиться в две недели, но это не страшно. Команда или ускорится (как у нас), или вы научитесь отрезать меньше на эти две недели.

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

«Наша компания была пионером применения Agile и DevOps в проектах внедрения систем класcа ERP в крупных российских организациях»

Светлана Гацакова, директор департамента корпоративных информационных систем ALP Group

1. Наша компания внедряет ИТ-решения, от которых напрямую зависит основная деятельность крупных территориально распределенных организаций-заказчиков.

Это сложные проекты, захватывающие центральные офисы и регионы, зачастую связанные с изменением системы менеджмента. Например, с внедрением внутреннего или внешнего аутсорсинга и созданием ОЦО (Общие центры обслуживания), c переходом к менеджменту на основе данных (data-driven management, или ddm), c выстраиванием и непрерывной оптимизацией бизнес-процессов (process mining), а теперь с их роботизацией (robotic process automation, или RPA).

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

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

Новый подход, обеспечивающий эту гибкость, сегодня связан с применением различных методик Agile (обычно это SCRUM) и технологии частого накатывания новых версий на информационную систему, находящуюся в промышленной эксплуатации (DevOps). Наша компания была пионером применения Agile и DevOps в проектах внедрения систем класcа ERP в крупных российских организациях, и сегодня этот вариант управления проектами так же надежен и отработан, как и традиционные методики.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Алексей Воронцов, технический директор, консалтинг DIS Group

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

2. Мы используем наиболее полезные артефакты Agile и саму философию этого метода. В основе философии Agile – прозрачность, доверие к членам команды и ответственность перед ними, скромность. Можно уверенно сказать, что такой подход эффективен. У нас нет так называемых зомби-проектов, нет недовольных заказчиков.

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

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

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

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

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

«В своей работе я использую микс управленческих подходов: классическое планирование и адаптированные идеи бережливого производства»

Евгений Салтыков, руководитель проектов департамента корпоративных систем ЛАНИТ

1. В российских реалиях невозможно использовать классическую модель – будь то модель PMI, P2m или PRINCE2 – без адаптации к процессам разработки конкретного проекта. Это относится и к «быстрым» подходам управления, набирающим популярность в России.

В ходе многолетней работы над проектами я пришел к выводу, что наиболее правильным будет использование классического управления. Этот способ подходит для решения стратегических задач развития продуктов и обсуждения глобальных целей с клиентом. А «быстрые» и «гибкие» модели управления (Agile или Lean) стоит применять уже на локальном участке проекта в рамках быстрых поставок обновлений продукта клиенту.

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

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

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

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

5. Кто ищет, всегда найдет. Но найдя, не прекращайте совершенствовать свою модель. Мир слишком изменчив для того, чтобы стоять на месте.

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

Марина Доний, заместитель генерального директора по проектной работе компании «Аванпост»

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

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

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

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

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

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

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

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

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

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

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

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

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

Антон Чехонин, генеральный директор НОРБИТ (ГК ЛАНИТ)

1. Компания НОРБИТ реализует большое количество проектов, поэтому наши специалисты уделяют много внимания проектному управлению и выбору методики. В основном, мы выбираем между использованием водопадной методологии и гибкой Agile-методологии. Как правило, для небольших проектов больше подходит гибкая методология с быстрыми результатами и доделкой в процессе реализации. Классический водопад мы используем для серьезных проектов с большим количеством участников и сложными процессами.

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

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

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

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

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

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

Tel.: (499) 277-12-41  Fax: (499) 277-12-45  E-mail: sa@samag.ru

Copyright © Системный администратор