Управление ИТ-проектами: как выбирают методологию 23 руководителя ИТ-компаний

57 минут на чтение —

Управление ИТ-проектами — это всегда поиск баланса между сроками, бюджетом, качеством результата и ожиданиями заказчика. Одни компании годами шлифуют собственную методологию на базе PMI PMBoK, другие переходят на Scrum и Kanban, третьи сознательно комбинируют «водопад» с гибкими подходами. Универсального рецепта нет — и это первое, в чем сходятся почти все участники опроса.

Журнал «БИТ» задал семь вопросов о том, как устроено управление ИТ-проектами изнутри, руководителям проектных офисов, департаментов разработки и внедрения 23 российских ИТ-компаний. Что становится решающим при выборе методологии. Какие проектные технологии работают, а какие приводят к срыву сроков. Из кого собирать команду и когда есть смысл привлекать аутсорсеров. Нужно ли обучать команду методологии. Чем мотивировать людей на результат. Что должен знать руководитель до старта проекта. И влияет ли на выбор российская специфика.

7 вопросов, на которые ответили эксперты

На вопросы «БИТа» отвечают эксперты ведущих компаний:

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

Итерационное внедрение и матричная команда

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

Адаптация PMI PMBoK под конкретный проект

Симбиоз нескольких методологий в одном проекте

Сначала методология, потом «идеальная» команда

Классика PMI и итерации там, где важна скорость результата

Тяжелые методологии для сложных проектов, Kanban — для простых

Cобственная методика на базе PMI и Lean Six Sigma

SCRUM, спринты и прозрачность для заказчика

Как совместить «водопад» и гибкие методологии

Каскад для инфраструктуры, Agile для разработки

Kanban и мотивация вместо детального плана

«Настоящий» Agile — люди важнее процессов

Методология IPMA (СОВНЕТ) и дисциплина ведения проекта

Классика при четких целях, Agile при меняющихся задачах

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

Waterfall для крупных проектов, agile для локальных

Как подобрать методологию под тип проекта и команду

PRINCE2 и индекс удовлетворенности заказчика

Комбинация Agile и «водопада» во внедрении ERP

Традиционная методология в проектах внедрения

Эволюция от каскада через Kanban к Scrum

Многие госзаказчики после выхода Постановления Правительства от 15 октября 2016 года № 1050 «Об организации проектной деятельности в Правительстве России» активно внедряют у себя проектное управление и организуют проектные офисы. Нужно учитывать используемые ими подходы для организации совместной работы.

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

Собственная методология на базе PMI PMBoK

Андрей Конусов генеральный директор компании «Аванпост»

“Мы выбрали наиболее классические и проверенные инструменты, на основании которых и построили собственную методологию.”

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

  1. Процессы ИТ-разработки.
  2. Проекты по внедрению наших продуктов у заказчиков.

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

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

Поскольку управление подобными крупными проектами − задача очень непростая, а уровень ответственности очень высок, то в нашей компании разработана собственная методология ведения проектов. В ее основе находится международный стандарт по управлению проектами PMI PMBоK. Но его положения сильно переработаны и адаптированы к специфике нашей деятельности. Так что теперь вопрос выбора методологии перед нами не стоит.

Мой жизненный опыт в прошлом был очень тесно связан с проектным менеджментом. Дело в том, что с 2003 по 2008 год я был исполнительным директором компании PM Expert, одного из признанных лидеров в сфере консалтинга и обучения вопросам проектного менеджмента в России. С тех по и по сей день продолжаю внимательно следить за развитием всех основных стандартов в сфере проектного менеджмента и с интересом наблюдаю за развитием рынка информационных систем по управлению проектами.

В своей нынешней компании мы выбрали наиболее классические и проверенные инструменты, на основании которых и построили собственную методологию проектного управления. Методологической основой для нас стал упомянутый выше PMI PMBоK, а в качестве средства автоматизации мы используем MS Project.

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

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

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

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

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

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

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

Разумное сочетание классических и гибких методов

Коротко о главном

Что объединяет ответы 23 экспертов об управлении ИТ-проектами:

  • Методологию выбирают не «по моде», а под тип проекта: жесткие сроки, бюджет и понятный результат — классический «водопад» или PMBoK; неясные требования и вовлеченный заказчик — Agile, Scrum, Kanban.
  • Большинство компаний используют не чистую методологию, а собственную адаптацию под свою отрасль, процессы и уровень зрелости команды.
  • Костяк проектной команды почти всегда собирают из своих сотрудников; аутсорс подключают на пиковых нагрузках, второстепенных или узкоспециальных работах.
  • Обучение нужно не столько «сертификату», сколько общему языку внутри команды — особенно при переходе с каскадной модели на гибкую.
  • Деньги работают как мотиватор ограниченно: устойчивый результат дают понимание цели проекта, прозрачный вклад каждого участника и профессиональный рост.
  • Российская специфика важна не сама по себе, а через корпоративную культуру и привычки конкретного заказчика — их и стоит учитывать при выборе методологии.