Стандарты для консерваторов

Стандарты для консерваторов

Интервью Евгения Пикулева корреспонденту  журналу IT-Manager Григорию Рудницкому.

Г.Р.:С чего начинался Ваш опыт управления ИТ-проектами?

Е.П.:Мой опыт в области управления проектами насчитывает примерно 13–14 лет. Все началось тогда, когда я работал технологом в Уральском коммерческом банке внешней торговли. Руководство этого банка в конце 90-х создало один из первых офисов управления проектами в региональных банках России. Этому способствовало то, что в банке помимо бизнес- и ИТ-подразделений возник отдельный слой специалистов, которые стали называться технологами. Собственно говоря, проектный офис и возник благодаря таким людям, поскольку количество уже тогда (это были 1998–2000 годы), число ИТ-проектов в банке было довольно значительным. А раз есть ИТ-проекты, необходимо грамотное управление ими.

Чем, на Ваш взгляд, ИТ-проекты отличаются от проектов в других областях бизнеса?

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

Есть ли особенности у российских компаний в области управления и выполнения ИТ-проектов?

Особенностью национального управления ИТ-проектами я бы, прежде всего, назвал отсутствие российской методологии. Есть западные стандарты управления ИТ-проектами, такие как, например PMBOK (Project Management Body of Knowledge), CobiT (Control Objectives for Information and Related Technology), и другие. В то же время большинство специалистов понимает, что нельзя в России управлять ИТ-проектами, руководствуясь западными методологиями, а нужно обязательно использовать национальные аспекты управления, причем мало кто знает, какие именно.
Вторая особенность заключается в том, что у нас в стране человеческий фактор имеет гораздо большее значение, нежели на Западе. Если руководитель ИТ-проекта обладает большим авторитетом среди сотрудников компании и имеет хорошие отношения с руководителями бизнес-подразделений, количество успешных проектов, как правило, велико. Нейтральное отношение встречается редко. Управление коммуникациями и управление заинтересованными сторонами приобретает в российских компаниях серьезный вес.
И наконец, еще одна российская национальная особенность. У нас очень не любят досрочно завершать неудачные проекты. Я периодически провожу тренинги, в которых стараюсь сравнить статистику успешных проектов на Западе и в России. Как правило, статистическая картина делится на три части: успешные, неуспешныее, а также проекты, которые завершили досрочно.. Так вот, количество досрочно завершенных ИТ-проектов в России минимально. У нас очень любят «тащить» проекты до конца, даже если бюджет и сроки проекта превышены на десятки процентов.. Главная национальная черта – если в проект вложена «копейка», то необходимо любой ценой проект завершить.,

Какие ИТ-проекты, реализованные Вами за все время деятельности в должности ИТ-директора, Вы считаете наиболее интересными или неординарными?

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

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

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

Как правильно составить бюджет ИТ-проекта и что необходимо учесть при его составлении?

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

Насколько важна мотивация для проектной команды?

Эффективная команда является ключевым фактором успеха практически любого ИТ-проекта. В строительной отрасли, например, ключевой фактор — это фактор времени. Для строителей сдать проект в срок гораздо важнее, чем удержаться в рамках бюджета. Если же рассматривать ИТ-проекты, то здесь на первом месте стоит отнюдь не соблюдение сроков или бюджета, а фактор хорошей сбалансированной команды, нацеленной на результат. Я слышал разные мнения по данному поводу, но больше половины ИТ-руководителей с этим согласна. Для ИТ-проектов характерна высокая степень уникальности, важность конечного результата, а также большое количество ожиданий заинтересованных сторон. Подчеркну: ожиданий, а не требований. А потому залогом успеха станет создание хорошей команды. Что такое «хорошая команда»? Это значит, что она должна быть, во-первых, компетентна, во-вторых, нацелена на успех, в-третьих, обладать командным духом. Это здоровая среда, в которой культивируется обмен мнениями и взаимовыручка и аккумулируются знания. Конечно, необходима мотивация. Но денежные механизмы мотивации стоят отнюдь не на первом месте, хотя, конечно, без денег ничего не бывает. Вы, как руководитель проекта, должны закрыть вопрос денежной мотивации определенными гарантиями и наличием соответствующей статьи в проектном бюджете. Но, повторяю, не менее важна и нематериальная мотивация — это и возможности профессионального роста, и поощрение командной работы. Я к нематериальной мотивации отношу и такие методы, как приобретение хорошего оборудования для сотрудников, например, хороших мониторов. И это, «выстреливает» иногда гораздо эффективней разового повышения зарплаты. Хотя, по большому счету, трудно назвать такие меры нематериальной мотивацией.

Насколько важны и полезны стандарты в области управления ИТ-проектами? Когда им нужно следовать в обязательном порядке?

Все мы знаем, что российский стандарт управления ИТ-проектами пока находится в стадии разработки. Да, некоторые ГОСТы уже опубликованы, некоторые остались с советских времен, но их еще трудно назвать стандартами в полном смысле слова. Необходимость соблюдения стандартов возникает в достаточно консервативной среде. В целом же российский рынок достаточно динамичная среда. С одной стороны, мы очень быстро догоняем Запад, копируем западные технологии, а с другой — успеваем отреагировать и на достаточно большое число мировых и национальных кризисов. Я, более чем за десять лет работы в банковской среде, насчитал довольно много кризисов, которые остро отражались и на ИТ-инфраструктуре, и на ИТ-проектах. Стандарты хороши тогда, когда обстановка более-менее спокойная и вы работаете в консервативной структуре, не любящей рисковать. Современные коммерческие банки уже трудно назвать такими организациями. В большинстве банков исповедуется стратегия «догнать и перегнать», т.е. стратегия прорыва. И это типично для российской банковской среды, которая совсем не консервативна.

На что же, в таком случае, следует ориентироваться руководителю ИТ-проекта?

Я бы сказал о трех китах. Назову их в порядке важности. Первый — это опыт, накопленный руководителем проекта. Второй — здравый смысл, а третий — стандарты. Но если нет первых двух, третий сам по себе ничем не поможет. Более того, вы даже можете запутаться. Какой стандарт выбрать? Их ведь довольно много, и скопировать зарубежный стандарт все равно не получится. Его нужно адаптировать к российской действительности.

Как оценить успешность ИТ-проекта? Очень часто возникают ситуации, когда проект завершен, задачи выполнены, заказчик доволен, однако либо сроки превышены, либо бюджет.

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

Прочитать интервью и остальные материалы ноябрьского номера IT-Manager можно по ссылке.

Рассказать друзьям: