Журнал о системах электронного документооборота (СЭД)
Внедрение электронного документооборота

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

  0 комментариев Добавить в закладки

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

●   Что для вас является решающим при выборе методологии управления проектом?

●   С какими видами проектных технологий вам доводилось работать? Расскажите о положительном и, возможно, негативном опыте.

●   Как вы набираете команду для проекта? Привлекаете ли аутсорсеров или предпочитаете своих сотрудников?

●   Требуется ли для использования той или иной проектной технологии специальное обучение команды?

●   Какие инструменты, мотивирующие проектный коллектив на результат, вы считаете эффективными?

●   Что нужно знать руководителю, чтобы быть готовым к новому проекту?

●   Нужно ли учитывать при выборе методологии управления проектом российскую специфику?

 

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

Николай Монахов, заместитель руководителя ИТ-отдела компании «Актив»

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

●    возможность или невозможность итерационности развития конечного решения, для реализации которого создается проект;

●    начальные условия (наличие персонала, степени проработанности задачи);

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

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

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

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

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

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

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

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

●   заинтересованность в результате. К примеру:

●   кому-то нужно повышение благосостояния – можно стимулировать премиальной составляющей;

●   кто-то хочет отправиться в путешествие, и стандартных двух недель отпуска не хватает. Можно пойти человеку навстречу и обговорить отдельные условия;

●   проговаривается отдельный распорядок рабочего дня, вплоть до возможности работы удаленно;

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

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

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

Максим Андреев«Самое главное – понимать, что руководитель работает с ЛЮДЬМИ, а не с “ресурсами”»

Максим Андреев, заместитель директора департамента информационных технологий, директор по бизнес-приложениям компании КРОК

 

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

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

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

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

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

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

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

 

Елена Гречихина«Если выбранная методология становится проблемой самого проекта – смело ее меняйте»

Елена Гречихина, руководитель проектов департамента сервисов и технической поддержки группы компаний Softline

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

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

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

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

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

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

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

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

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

 

Наталья Елисеева«Наши проектные руководители часто являются “играющими тренерами”»

Наталья Елисеева, руководитель отдела инфраструктурной поддержки компании Xerox Россия

 

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

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

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

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

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

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

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

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

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

Айдар Сарваров«Реальность жизни меняется настолько быстро, что наиболее эффективным способом обучения является практика»

Айдар Сарваров, директор департамента проектов ООО «МайТэк»

 

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

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

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

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

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

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

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

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

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

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

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

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

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

 

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

Похожие записи
Комментарии (0)
Сейчас обсуждают
Больше комментариев