Управление ИТ-проектами: методологии, инструменты, специфика

Журнал «БИТ» поинтересовался у Softline, КРОК, Xerox Россия, Актив, МайТэк и других компаний, какую методологию ИТ-проектов они используют в работе.

«Опросник» был таким:

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

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

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

Три основных методологии, которые нам приходится использовать: Scrum, каскадная и итеративные модели. При этом не могу сказать, что на 100% мы следуем всем подходам, этапам, рекомендациям, принятым в каждой из методологий ИТ-проектов. Более того, мы периодически применяем некий симбиоз подходов в рамках одного проекта, так как у каждого есть свои плюсы и минусы, и стараемся найти наиболее подходящий «рецепт» для каждого конкретного проекта.

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

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

Однозначного ответа на вопрос, кто лучше или кого мы предпочитаем, аутсорс или свой штат сотрудников, не существует. Всё зависит от специфики проекта. На каких-то проектах можно 80% всех трудозатрат отдать на аутсорс и получить приемлемый результат. В каких-то мы просто не готовы привлекать аутсорсеров, к примеру, из-за конфиденциальности.

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

Для меня нет такого понятия, как «мотивация» персонала. Я считаю, что его давно нужно заменить на понятие «стимуляция», как бы грубо это ни звучало. Итак:

• цель самого проекта или деятельности. Команде необходимо «видеть» конечный результат своей деятельности, даже если мы работаем по Scrum. Если команда не понимает, что у них на горизонте, то всё превратится в работу на процесс, а не результат. Также необходимо видеть среднесрочные и краткосрочные цели с обязательным их достижением и получением обратной связи от заказчика, даже если заказчик внутренний;
• заинтересованность в результате. К примеру:
•  кому-то нужно повышение благосостояния – можно стимулировать премиальной составляющей;
• кто-то хочет отправиться в путешествие, и стандартных двух недель отпуска не хватает. Можно пойти человеку навстречу и обговорить отдельные условия;
• проговаривается отдельный распорядок рабочего дня, вплоть до возможности работы удаленно;
• кому-то хватает обычного доброго слова, поддержки и признания в коллективе его достижений.

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

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

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

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

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

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

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

Самое главное – понимать, что руководитель работает с ЛЮДЬМИ, а не с «ресурсами». Поэтому в первую очередь он должен не управлять или контролировать, а создавать условия, при которых достижение личных целей человека совпадает с целями проекта, а также оперативно реагировать на отклонения.

У нас был очень интересный совместный опыт с международной компанией GBMC, в чьем портфолио был проект трансформации Airbus в процессе перехода на проектный способ строительства самолетов. Конечно же, нам было интересно, в чем заключается в данном случае российская специфика и как ее учитывать. Ответ был очень простой – нет национальной специфики, есть конкретные люди, их привычки, их культурный «код». Менеджер должен учитывать именно эти факторы, если команда интернациональная. Например, на первой встрече может быть «фиаско» разного рода: немцы придут за 10 минут, французы опоздают на 15, испанцы вообще не придут. Но непосредственная работа с людьми решает быстро все проблемы.

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

Мой положительный опыт совмещен с негативным. В одном из сложных проектов была использована тяжелая методология. Когда основные задачи проекта были успешно решены, мы столкнулись с тем, что он оказалась слишком громоздкой для решения задач попроще. Это создавало дискомфорт для всей команды. По этой причине была выбрана легкая методология ИТ-проектов Kanban, которая позволила быстро и эффективно завершить задачи в срок и с высокими результатами. Так что если выбранная методология становится проблемой самого проекта – смело её меняйте.

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

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

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

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

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

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

Можно многое понимать под фразой «российская специфика», но так как мы живём в России и работаем в ней, для нас это не «специфика», а данность, к которой мы все привыкли.

– Мы не выбираем варианты от проекта к проекту, а используем свою методику управления ИТ-проектами. Когда проектный офис в Xerox только создавался, мы проанализировали существующие методологии и приняли решение использовать стандарты PMI (Project Management Institute). Кроме того, в нашей компании существует культура применения Lean Six Sigma, из которой мы заимствовали ряд элементов, например, оценку качества проекта, выраженного в количестве дефектов. В результате у нас появилась собственная методология ИТ-проектов, которая, на наш взгляд, в полной мере отвечает специфике наших проектов.

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

Мы используем подход PMI с элементами Lean Six Sigma. Методология хорошо зарекомендовала себя, поскольку позволяет гарантировать достижение запланированного результата.

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

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

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

Любой проект должен иметь согласованные критерии успешности. Достигнутые показатели по этим критериям и являются показателями производительности и эффективности работы проектного персонала.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Источник: Полная версия опроса в Журнале "БИТ"