Мы автоматизируем дистрибуцию и мобильную торговлю в национальных и транснациональных компаниях секторов FMCG, DYI, телекома и нефтехимии, в том числе консолидируем данные по вторичным продажам и создаем автоматизированные рабочие места для удаленных и офисных сотрудников.
Нам необходимо в срок, с должным уровнем качества и за приемлемую цену удовлетворить потребности заказчиков. Эти факторы и являются решающими при выборе методологии.
В рамках внешних проектов внедрения мы используем собственную методологию, основанную на PMI PMBоK. Опыт работы PMI PMBоK я определенно могу назвать положительным.
Особый упор мы делаем на формализацию и совершенствование процессов оценки проектов и подготовки бюджета доходов и расходов; разработку устава проекта; постановку, отслеживание и оценку качества выполнения проектных задач. Мы предлагаем клиентам итерационное развитие проекта: в первую очередь запустить базовый функционал, чтобы получить начальную бизнес-выгоду и обратную связь. Если бизнес заказчика еще не готов к внедрению сложного функционала, такой подход позволяет скорректировать требования и принять бизнес-решения, опираясь на реальный опыт эксплуатации системы. Затем по скорректированным требованиям проводятся следующие этапы внедрения.
Когда наша система автоматизации не покрывает потребности заказчиков, мы включаем реализацию требуемого функционала в план серийной или индивидуальной разработки. Для индивидуальной разработки мы используем Agile и другие гибкие методологии, позволяющие создать в оптимальные сроки и с минимальными затратами, особенно если заказчик готов погружаться в процесс и качественно давать обратную связь.
В нашей компании действует матричная модель. Сотрудники ресурсных отделов с сильной матрицей поступают в распоряжение руководителя проекта и подотчетны ему. В ресурсных отделах со слабой матрицей за результаты работ отвечают функциональные руководители. Для обеспечения высокого уровня качества мы предпочитаем использовать и развивать своих сотрудников.
Команду для проекта формируем из внутреннего пула сотрудников, так как быстро собрать профессиональную и слаженную команду под проект, набрав новых людей, практически невозможно.
Каждый новый сотрудник ресурсного отдела обязательно проходит подготовку в центре обучения компании, результат контролируется тестированием. Для начального обучения мы используем Learning Management System (LMS). В дальнейшем специалисты постоянно проходят тестирования средствами LMS для поддержания уровня знаний. При вводе сотрудника в новый проект проводим собеседование и ситуационные тренинги с руководителем проекта.
Работа в проекте – это командная работа, при которой результаты труда одного сотрудника становятся вводными для его коллеги. Поэтому мы внесли в систему мотивации оценку работы, которую один сотрудник передает другому. Оценка обязательно модерируется руководителем проекта и влияет на KPI.
Руководитель проекта должен хорошо разбираться в предметной области, быть готовым вникнуть в суть и мельчайшие детали любой из задач проекта самостоятельно или при помощи эксперта.
Любую специфику, известную заранее, необходимо учитывать. Например, в нашей методологии есть четкое разделение на подключение площадок на базе 1С и на базе других учетных систем. В России большинство дистрибуторов используют решения от 1С, под которые у нас накоплена большая коллекция наработок кода. Это позволяет упростить и ускорить процессы интеграции.
Управление проектами – это наука, но наука не самая точная. В данной области нет универсальных решений, подходящих для всех проектов, даже если рассматривать портфель только одного руководителя.
Почти каждый раз руководителю требуется адаптировать стандартную методологию к особенностям данного проекта. Корпоративная методология базируется на своде знаний по управлению PMI PMBoK и дополняется, адаптируется нужным образом.
Необходимо различать процесс управления проектом и проектные технологии для получения результата. В качестве основной проектной технологии в компании используется гибкий итеративно-инкрементальный подход к управлению проектами, ориентированный на динамическое формирование требований и обеспечение их реализации в процессе постоянного взаимодействия с заказчиком. Этот подход позволяет в ходе внедрения уточнять у него требования к итоговому результату и получать обратную связь по промежуточным результатам: постановке задач, макетам, прототипам и всего сделанного на ранних этапах проекта.
Если говорить о негативном опыте, то он связан с серьезным расширением границ проекта в процессе такого динамического формирования требований.
Еще более серьезной проблемой может стать то, что заказчик невнимательно работает с проектной документацией на этапе анализа и проектирования решения – тогда, когда внести изменения в поставленные задачи достаточно просто. Гораздо труднее исправить программный код, когда он уже написан. И совсем плохо, если требуется переработка всей архитектуры решения.
Издержки на такие «переделки», которых можно было бы избежать, могут достигать 50% от всех проектных затрат.
Одна из ключевых задач при планировании проекта – разработка иерархической структуры работ (ИСР, WBS), что позволяет «разбить» их на более мелкие, легкоуправляемые элементы. Создавая и анализируя ИСР, руководитель проекта определяет, какие работы целесообразно отдать на аутсорсинг по контракту с фиксированной стоимостью, для выполнения каких привлечь аутсорсеров в режиме почасовой оплаты, а какие реализовать собственными силами.
В компании ФОРС все три подхода используются в равной мере. Главное преимущество аутсорсинга – перенос рисков на исполнителя и более низкая стоимость работ по сравнению с уровнем оплаты труда собственных специалистов. Их труд целесообразнее использовать для выполнения критичных работ – там, где требуются специальные компетенции, экспертиза или наличие прав доступа к конфиденциальной информации.
Да, обучение необходимо как минимум по следующим направлениям:
Если используется какая-то специализированная технология, то обязательно требуется обучение этой технологии.
В проектной деятельности имеется много технологий, предназначенных для повышения производительности. Одна из них – мотивация. Сбалансированная мотивация направлена на обеспечение и качественных, и количественных показателей.
В качестве самого простого примера можно привести мотивационную схему в проекте, предусматривающем работы по сопровождению программного обеспечения. Схема учитывала, с одной стороны, количественные показатели обработки заявок сотрудниками, с другой стороны, учитывались сложность заявки, своевременность ее исполнения (соответствие SLA), качество предоставленного решения.
При внедрении системы материальной мотивации целесообразно провести дифференциацию сотрудников по категориям. У нас существует три категории сотрудников: члены проектной команды, руководители проектов и руководители отделов, управляющих ресурсами.
Каждой категории сотрудников устанавливаются определенные показатели, в том числе учитывающие коллективные достижения, которые служат основанием для выплаты премии.
Помимо инструментов материальной мотивации, так же или даже более важны инструменты не материальные, они выбираются для сотрудника индивидуально:
Для руководителя проекта в нашей компании как минимум необходимо владение сводом знаний по управлению проектами PMI PMBoK. Сертификация руководителей проектов на степень PMP (Project Management Professional) входит в стратегию компании по развитию проектного управления.
Также руководителю необходимо знать внутренние процессы и технологии реализации проектов. Если выделить три ключевые компетенции, которые наиболее важны для руководителя проекта, то это умение налаживать работу с заинтересованными лицами и организовывать сбор требований к проекту; навыки планирования и оценки трудоемкости работ; опыт в управлении изменениями.
ФОРС работает на российском рынке и для российских заказчиков, поэтому используемые нами методологии управления обязательно учитывают российскую специфику. Наверное, основные отечественные «этнокультурные» особенности, которые влияют на проектное управление, это:
Эти факторы влияют в наибольшей степени на ход и сроки исполнения проекта, на качество полученного результата. Поэтому знания из области управления сроками, управления качеством и, что очень важно, управления коммуникациями проекта следует дополнять различными методами и инструментами, чтобы нивелировать влияние наших национальных особенностей.
Обязательным условием выбора методологии управления проектом являются первичные цели проекта, его ограничения (границы) и возможные сроки реализации. При этом мы также оцениваем такие аспекты, как:
Три основных методологии, которые нам приходится использовать: Scrum, каскадная и итеративные модели. При этом не могу сказать, что на 100% мы следуем всем подходам, этапам, рекомендациям, принятым в каждой из методологий. Более того, мы периодически применяем некий симбиоз методологий в рамках одного проекта, так как у каждой есть свои плюсы и минусы, и стараемся найти наиболее подходящий «рецепт» для каждого конкретного проекта.
Самая большая ошибка начинающих руководителей – на мой взгляд, это уверенность в том, что если вы все спланировали, учли риски, раздали задачи участникам проекта, то можно дальше расслабиться и ждать, когда к тебе «постучится» команда и предоставит результат деятельности, и обязательно положительный. Это не так. Необходимо на ежедневной основе работать с командой, с изменениями в требованиях, управлять доступными ресурсами, анализировать изменения в законодательстве и т.д. и т.п.
Команда проекта набирается исходя из специфики и сложности задач. Также нужно понимать, что многое зависит и от потенциального масштаба проекта. В случае если текущих компетенций сотрудников не хватает или все ресурсы задействованы на других задачах, то изначально принимается решение о возможности и/или необходимости привлечения внешних ресурсов (аутсорс, внештатные консультанты, технологические партнеры), расширения собственного штата. Также рассматривается возможность перераспределения сотрудников внутри компании. После выработанного решения начинается планомерная работа по ее реализации: поиск, переговоры, прием на работу. Оговорюсь, что данный процесс не заканчивается на всем протяжении реализации проекта, так как все мы знаем, что такое риски и необходимость управления ими.
Однозначного ответа на вопрос, кто лучше или кого мы предпочитаем, аутсорс или свой штат сотрудников, не существует. Все зависит от специфики проекта. На каких-то проектах можно 80% всех трудозатрат отдать на аутсорс и получить приемлемый результат. В каких-то мы просто не готовы привлекать аутсорсеров, к примеру по причине конфиденциальности.
Обязательно. Если команда не понимает, что от нее хотят, то отрицательный результат не заставит себя долго ждать. Именно поэтому наша компания приветствует обучение сотрудников и не только в рамках текущих выполняемых ими обязанностей.
Для меня нет такого понятия, как «мотивация» персонала. Я считаю, что его давно нужно заменить на понятие «стимуляция», как бы грубо это не звучало. Итак:
Как минимум руководитель должен знать, а лучше понимать, что успешность любого проекта зависит от людей, которые будут принимать в нем участие. В данном случае главное – это знать, каким образом, а также кому можно и нужно делегировать полномочия решения конкретных либо общих задач по проекту. Ну и, конечно же, иметь как минимум общие представления о предметной области, чтобы не «плавать» в терминологии и понимать, какие компетенции требуются от команды в целом.
Здесь более корректно сказать, что методология должна выбираться исходя не из специфики на уровне государства в целом, а исходя из области применения результата проекта и самого проекта в частности.
Бизнес-цель проекта и его ограничения являются для нас решающими факторами. Методика реализации проекта должна соответствовать требованиям контракта, уровню зрелости команды, условиям заказчика, а также корпоративной структуре.
Сначала мы определяем, по какой методологии делаем проект. И уже под нее проектируем «идеальную» команду, которая бы наилучшим образом соответствовала потребностям и учитывала особенности работы с заказчиком. Разумеется, в большинстве случаев идеал труднодостижим, поэтому мы находим компромисс, учитывающий доступность специалистов, их личную мотивацию, возможность найти ресурсы вне КРОК (у подрядчика или аутсорсеров).
Использовать аутсорсинг или нет – вопрос не только экономический, но и стратегический. КРОК уделяет особое внимание развитию собственной экспертизы, удержанию лучших специалистов, вложению в молодые дарования. К аутсорсингу мы прибегаем исключительно в тех случаях, когда необходимой компетенции для реализации проекта нет, и мы не видим потребности в ее развитии в своей команде.
Все новички изучают проектные методологии, использующиеся в компании КРОК, а также ГОСТ34, поскольку без этого сложно работать с государственными заказчиками. В некоторых случаях мы даже проводим специальное обучение команд особенностям работы в конкретном проекте. В том числе привлекаем внешних экспертов для этой цели.
По нашему опыту наиболее эффективно работа складывается, когда цели проекта «гармонизированы» с целями команды.
Самое главное – понимать, что руководитель работает с ЛЮДЬМИ, а не с «ресурсами». Поэтому в первую очередь он должен не управлять или контролировать, а создавать условия, при которых достижение личных целей человека совпадает с целями проекта, а также оперативно реагировать на отклонения.
У нас был очень интересный совместный опыт с международной компанией GBMC, в чьем портфолио был проект трансформации Airbus в процессе перехода на проектный способ строительства самолетов. Конечно же, нам было интересно, в чем заключается в данном случае российская специфика и как ее учитывать в проектах. Ответ был очень простой – нет национальной специфики, есть конкретные люди, их привычки, их культурный «код». Менеджер должен учитывать именно эти факторы, если команда интернациональная. Например, на первой встрече может быть «фиаско» разного рода: немцы придут за 10 минут, французы опоздают на 15, испанцы вообще не придут. Но непосредственная работа с людьми решает быстро все проблемы.
Вводная: занимаюсь проектами по автоматизации учета на 1С (в основном).
Проект по созданию продукта для выпуска на рынок как коробочного решения или проект по автоматизации учета на предприятии.
Agile при создании коробочного продукта и различные вариации классического PMBоK в случае проектов для конкретного заказчика. Негативный (и позитивный) опыт заключается как раз в применении неправильной (или правильной) вариации классического PMBоK.
Команда собирается из сотрудников предприятия в зависимости от компетенций. Аутсорс привлекается во вторую очередь и на второстепенные задачи.
Нет, не требуется.
Надо набирать персонал из сотрудников, нацеленных на результат. Денежная мотивация (проектная премия только после завершения всего проекта), неденежная мотивация (индивидуально с каждым сотрудником).
Зачем он это делает? Что принесет ему данный проект, желательно в деньгах, – так проще сравнивать эффект и затраты.
Один из основных критериев, влияющих на выбор методологии проектного управления, – это скорость достижения результатов, соответствующих ожиданиям наших клиентов. С точки зрения внутренних регламентов мы используем классическую методологию управления проектами, основанную на стандарте PMI.
В 2016 году нашей компанией был успешно пройден внешний аудит на соответствие требованиям стандарта ГОСТ Р 54869-2011 «Проектный менеджмент. Требования к управлению проектом». В ряде случаев для достижения необходимого результата руководителями проектов применяются итерационные подходы предоставления результатов заказчикам.
Мой основной опыт связан с «водопадной» (waterfall) моделью управления, но также имеется опыт применения фреймворка SCRUM (методология гибкой разработки ПО). Приведу пример, когда наглядно ощутил отличия гибкой методологии от классической, – это проект, при старте которого ничто не предвещало больших проблем: хорошо знакомый клиент, с которым уже был опыт работы, отлично составленное техническое задание (ТЗ), заинтересованность в проекте исполнителей со стороны клиента, достаточный запас по срокам.
Из Манифеста гибкой разработки программного обеспечения (Agile Manifesto): «Сотрудничество с заказчиком важнее контрактных обязательств». В рамках проекта заказчик должен был выделить сервер для установки программного обеспечения (ПО) в течение нескольких дней с даты подписания контракта. Выделение сервера по независящим от нас причинам затянулось больше, чем на два месяца. Чтобы завершить проект в срок, мы доставили на площадку клиента собственный сервер, установили на сервер ПО, приступили к выполнению работ. После того как клиент выделил собственный сервер, все наработки были перенесены на него. В результате нам удалось значительно сократить время на реализацию проекта и повысить престиж нашей компании в глазах клиента.
Опять же Agile Manifesto говорит: «Реакция на изменения важнее следования плану», а также: «Люди и взаимодействие важнее, чем процессы и инструменты».
В рамках того же проекта выяснилось, что практическая ценность от реализации проекта строго в рамках ТЗ не соответствует реальным бизнес-потребностям конечного пользователя. Были достигнуты договоренности с клиентом об отступлении от буквы ТЗ и итерационном внедрении компонентов системы с промежуточной приемкой результатов работ. В итоге мы не выбились из бюджета, так как вовремя отреагировали на необходимость изменения ТЗ, а также сохранили хорошие отношения с заказчиком, так как реализовали систему, на практике отвечающую его бизнес-потребностям.
У нас в компании используется матричная структура с тремя вертикалями: Отдел продаж, Проектный офис и Технический департамент. Основным поставщиком исполнителей является Технический департамент, и ему отдается предпочтение. По отдельным видам работ привлекаем аутсорсеров, при этом в компании выстроен серьезный процесс отбора претендентов на привлечение.
С учетом того, что основной методологией у нас все-таки является классический waterfall, специальное обучение для исполнителей не требуется. Руководителей проектов обучаем по мере необходимости, для технических специалистов силами Проектного офиса проводятся семинары, презентации по основам проектного управления и по отдельным процессам управления проектами.
С одной стороны, широко используются методы материальной мотивации, размер которой зависит от эффективного участия сотрудников в проектной деятельности. С другой стороны, в компании Angara Technologies Group реализуется подход, что успешный проект – это вклад каждого сотрудника в общую цель компании. Сотрудники во многом руководствуются своей внутренней мотивацией, а компания создает условия для ее поощрения. Считаю наиболее эффективной ту мотивацию, которая наиболее последовательно связана с достигаемым результатом.
Руководителям для успешной реализации новых проектов необходим большой набор знаний, но главное – важно понимать основную бизнес-цель, которую необходимо достичь в результате выполнения проекта. Остальные компоненты во многом укладываются в известный треугольник «Качество – Сроки – Деньги».
Конечно! Руководитель проекта должен учитывать национальную специфику и особенности области, в которой он работает, будь то информационные технологии, информационная безопасность, разработка ПО или иная сфера.
Сам проект и условия, в которых он должен проходить, всегда разнообразны, и именно от этого зависит выбор методологии. В сложных, длительных и комплексных проектах применяются так называемые тяжелые методологии, такие как PMBoK, Prince2. В более простых проектах, где мы понимаем, что реализация будет быстрой и что у нас имеется достаточно отработанных компетенции для реализации, можно применять Scrum и Kanban.
Мой положительный опыт совмещен с негативным. В одном из сложных проектов была использована тяжелая методология. Когда основные задачи проекта были успешно решены, мы столкнулись с тем, что выбранная методология оказалась слишком громоздкой для решения задач попроще. Это создавало дискомфорт для всей проектной команды. По этой причине была выбрана легкая методология Kanban, которая позволила быстро и эффективно завершить проект в срок и с высокими результатами. Так что если выбранная методология становится проблемой самого проекта – смело ее меняйте.
Для любого руководителя наличие сильной команды очень важно. Разница лишь в том, что у руководителя проекта на каждом проекте она может быть новой. Это вызов – одновременно работать с разными людьми, делая из них сильную команду.
Очевидно, что с сотрудниками компании работать проще. У нас единая корпоративная культура, единое видение на управление, единые формализованные документы. С командами, которые состоят из сотрудников Softline, мы прошли уже не один проект. С такой командой сложности в мотивации и в коммуникациях минимальны или вовсе отсутствуют.
С аутсорсерами и подрядчиками дело обстоит иначе. Люди, приходящие на проект «со стороны», очень часто сталкиваются с требованиями принимать те правила игры, к которым они не привыкли. Руководитель проекта должен приложить максимум усилий для интеграции сотрудников в рамки принятых норм и уровня качества, который приемлем для нас.
У нас в компании уже много лет используется простая и понятная методология управления проектами. Обычно на установочной встрече с командой обсуждаются основные управленческие вещи – что мне нужно от команды проекта и что нужно команде проекта. Необходимое обучение требуется лишь в специальном случае, когда у сотрудника совсем нет опыта проектной работы.
Одни приходят на проект, чтобы повысить свой профессионализм, другие – получить премию, а третьи – за повышением статуса. Чтобы проектная команда работала отлично, руководителю проекта необходимо держать в голове все многообразие целей и ценностей участников команды, заботиться о создании здоровой атмосферы в команде, дав коллегам чувство надежности и товарищества.
Руководитель проектов еще до старта изучает большое количество информации о самом проекте и о заказчике и формализует их в уставных документах проекта. Обязательно следует проверить все расчеты, имеющие отношение к проекту, если они были сделаны до того, как информация попала в руки проектного менеджера. Затем необходимо набрать проектную команду, обсудить с ней все тонкости реализации. Затем тонкости реализации имеет смысл обсудить с заказчиком. И можно начинать работать.
Можно многое понимать под фразой «российская специфика», но так как мы живем в России и работаем в ней, для нас это не специфика, а данность, к которой мы все привыкли.
Мы не выбираем методологию от проекта к проекту, а используем свою методику проектного управления. Когда проектный офис в Xerox только создавался, мы проанализировали существующие методологии и приняли решение использовать стандарты PMI (Project Management Institute). Кроме того, в нашей компании существует культура использования методологии Lean Six Sigma, из которой мы заимствовали ряд элементов, например оценку качества проекта, выраженного в количестве дефектов. В результате у нас появилась собственная методика проектного управления, которая, на наш взгляд, в полной мере отвечает специфике наших проектов.
Основная задача любого проекта – достичь поставленной цели в срок и в соответствии с согласованным бюджетом. Это и является ключевым критерием, по которому оценивается эффективность управления проектом.
Мы используем подход PMI с элементами Lean Six Sigma. Методология хорошо зарекомендовала себя, поскольку позволяет гарантировать достижение запланированного результата.
Из минусов можно отметить, что зачастую у клиента отсутствуют соответствующие компетенции или он не понимает важности выполнения тех или иных действий в проекте, особенно касающиеся проектной документации и процесса планирования.
Поскольку ИТ-проекты, которые мы реализуем для заказчиков, достаточно краткосрочные, имеют определенную специфику и реализуются на регулярной основе, в нашей компании организован собственный проектный офис. Наши проектные руководители часто являются «играющими тренерами», в отличие от классического понимания роли руководителя проектов.
Обучение команды обязательно. Наш опыт показывает, что даже люди с дипломом или сертификатом руководителя проектов не имеют практики и зачастую слабо разбираются в реальном управлении проектами. Кроме того, в силу специфики того или иного проекта команде могут требоваться дополнительные знания помимо общего понимания проектных технологий.
Любой проект должен иметь согласованные критерии успешности. Достигнутые показатели по этим критериям и являются показателями производительности и эффективности работы проектного персонала.
Прежде всего руководителю необходимо разбираться в решении, которое разработано архитектором для конкретного клиента. И, конечно, важно понимать методику управления проектами. Это позволяет не терять время на поиск нужных контактов, механизмов, шаблонов и т.д. непосредственно на проекте.
Любой проект реализуется в первую очередь для клиента, а российский клиент сильно отличается от западного, поэтому учитывать российскую специфику крайне важно. Например, иногда проект приходится значительно упрощать с точки зрения проектного управления, так как единственное, что волнует клиента, – получение результата в срок (причем сильно сжатый), и он не хочет сильно погружаться в процесс его достижения.
При выборе методологии мы опираемся на прошлый опыт и знания наших руководителей. К примеру, я сертифицированный SCRUM-мастер, работал в этой должности в концерне «Ауди» и хорошо знаю, что российский клиент сильно отличается от западного, поэтому учитывать российскую специфику крайне важно и в теории, и на практике. Поэтому сейчас свои проекты мы чаще всего разрабатываем по методике SCRUM.
Jira и Confluence от Atlassian – отличная прога для управления проектами, ее главный плюс в том, что она заточена под проектную деятельность, а мелкие детали (которых может не хватать) можно легко сделать самому. Open Project используем для прозрачности, чтобы наши клиенты видели прогресс проекта и могли планировать его запуск и внедрение.
Обычно мы работаем со своими сотрудниками, стараемся не отдавать дополнительные проекты на аутсорс из-за того, что их сложнее контролировать. Если быстро найти опытного специалиста невозможно, то мы берем стажера и прикрепляем его к опытному программисту.
Чаще всего да, но не всегда мы обучаем всю команду проектной технологии. Чаще всего мы отправляем на обучение одного-двух специалистов (это дешевле), чтобы они потом транслировали знания в виде лекций и презентаций, а также курировали проекты, которые используют новую методологию. Например, совсем недавно наш программист обучался в Швейцарии в центре Magnolia CMS, после этого он совместно с нашими разработчиками реализовал несколько проектов на базе этой CMS.
Первая и главная мотивация у нас – это реализованный проект. Свои проекты мы отбираем тщательно, и поэтому каждая команда любит свой проект и старается для его реализации. Немаловажным инструментом являются спринты (у нас один спринт длится две недели) и scrum-доска, на которой мы отслеживаем прогресс, а также проведение scrum-митингов, где каждый участник команды рассказывает, что он делал, что планирует делать и с какими проблемами он столкнулся.
В первую очередь руководителю требуется знать методологии оценки проектов, чтобы грамотно рассчитать время и количество сотрудников для проекта. А также основные показатели эффективности для оценки результатов (в нашем случае я отслеживаю результаты и эффективность команды по фактуре – часы, затраченные на задачу/проект – и scrum-доске, где виден общий график выполнения задач).
Скорее нет, чем да. В нашей команде работают российские ребята, и они часто работают в выделенных немецких командах. И у нас никогда не разнились методы работы тут и там. Пожалуй, самое важное – выстроить эту систему, потратить на нее время и силы. Это актуально для любой страны и компании.
1. Решающие факторы при выборе той или иной методологии – наличие и строгость ограничений проекта. При наличии жестких сроков, ограниченном бюджете, хорошем понимании результата и критериев качества мы используем классический «водопад», предполагающий последовательную реализацию четко обозначенных этапов проекта.
При отсутствии жестких ограничений на сроки и бюджет, а главное, четкого понимания результата используются гибкие методологии. Кроме того, в компании разработана технология, которая позволяет совмещать гибкие методологии и классический «водопадный» подход.
При решении типологизированных задач в компании традиционно используется методология ANSI PMBоK, среди преимуществ которой можно выделить: наличие инструментов управления и контроля результатов проделанных работ. К недостаткам такой технологии относятся: невозможность применения для реализации научных и/или рискованных проектов, а также низкая вариативность реализации, сложность внесения корректив по ходу проекта.
Поскольку одним из направлений деятельности компании является реализация нестандартных IT-проектов, разработка не имеющих аналогов программных решений, зачастую в работе используется методология Scrum. Среди ее плюсов: применение в условиях рискованных проектов с неясным результатом, возможность внесения корректив, а также отсутствие требования высокого уровня культуры управления. Минусы такой методологии: дороговизна разработки решения, необходимость постоянного вовлечения заказчика.
Основной вид деятельности компании – разработка ИТ-решений в сфере анализа Больших данных и алгоритмов искусственного интеллекта – представляет собой наукоемкое производство. По факту специалистов с достаточной квалификацией на рынке труда – единицы. В силу исторических связей нашей компании с академическим сообществом сотрудниками зачастую становятся учащиеся и выпускники ведущих технологических российских вузов и подразделений РАН.
Любая методология требует обучения проектной команды. Также никто не отменял таких понятий, как слаженность в работе и согласованность в командных действиях. В гибких методологиях уровень вовлечения команды значительно выше по сравнению с классическими методологиями. В таких случаях требуется применение методов мозгового штурма, постоянного обсуждения достигнутых результатов и поиска путей устранения возникающих в ходе работы ошибок. Однако даже после обучения могут потребоваться несколько итераций боевого проекта для разбора узких мест в использовании методологии.
В компании используются следующие инструменты: расширение сферы ответственности сотрудников, рост компетенций в рамках проекта, доступ к интересным, амбициозным задачам. Также всячески поощряется повышение квалификации сотрудников посредством посещения различных курсов и семинаров, предоставляется возможность написания квалификационных работ и научных публикаций в соавторстве с учеными – представителями ИТ-отделов научно-исследовательских центров РАН. Безусловно, в компании практикуется и наиболее традиционный метод мотивации персонала – денежные премии и бонусы за выполнение проектов.
Руководитель, во-первых, должен понимать суть методологии управления проектом, варьировать методы в соответствии с решаемыми задачами. Во-вторых, хорошо знать команду, улавливать нюансы поведения своей команды, уметь выстраивать коммуникации с каждым сотрудником.
Опыт и понимание отраслевой специфики, отдельные детали решения задачи, взаимоотношения с заказчиком, ограничения и прочие нюансы проекта зачастую выявляются уже в рамках проекта, на этапе инициации. И, конечно же, далеко не последнюю роль играет сам человек, руководитель, его внутренняя организация и темперамент, предрасположенность к коммуникации и организованность, заложенные природой и воспитанием.
В России особую популярность приобрели гибкие методологии управления проектом. Во многом это обусловлено их управляемостью в изменяемой внешней среде, что весьма свойственно для нашей страны. При этом заказчики по-прежнему ставят порой весьма жесткие сроки реализации проектов, предъявляют высокие требования к качеству, а также осуществляют контроль над бюджетом проекта. Поэтому не стоит каждый раз слепо выбирать гибкие методологии, когда есть ограничения, нужно обращать внимание и на классический водопад. Мое мнение – в России необходимо применять двухуровневую систему управления, совмещающую «водопадную» и гибкую методологии. Особенно хорошо такой симбиоз показал себя в государственных контрактах.
Универсальной методологии, как и лекарства от всех болезней, не существует.
При выборе той или иной методики приходится учитывать много факторов, и это всегда индивидуально для каждого проекта. Среди наиболее важных (лично для меня) – тип проекта, специфика заказчика и имеющиеся ограничения.
Если предстоит работать в проекте с четко формализованными требованиями и четким пониманием заказчика о конечном результате, наиболее подходящей будет классическая (каскадная) модель управления. Она предполагает незначительные изменения требований в процессе выполнения работ, а также строгую очередность реализации этапов проекта, в которой переход к последующему этапу происходит только после окончания и приемки заказчиком предыдущего. Это позволяет еще на старте проекта задать все необходимые потребительские и функциональные свойства продукта и подготовить понятную «дорожную карту» на весь проект. Однако у данного подхода есть один существенный минус – высокая степень формализации, что не дает достаточной гибкости к внесению изменений и может существенно сказаться на сроках реализации. Ведь «осязаемый» результат заказчик видит, как правило, только ближе к окончанию проекта, не имея возможности оперативно вносить необходимые корректировки, если требования были определены неверно.
Вышеописанная методика хорошо подходит для реализации инженерно-строительных и инфраструктурных проектов, но совершенно не подходит для разработки ПО и решения других сервисно-ориентированных задач, где на старте проекта не всегда известно, каким будет финальный продукт, а скорость вывода его на рынок является определяющим фактором и существенным конкурентным преимуществом. В таких случаях мы используем гибкие методики управления проектами – Agile, Scrum и т.д., которые набирают все большую популярность в среде разработчиков и заказчиков. Так, например, самый большой банк страны – Сбербанк – в 2016 году объявил о переходе на работу всех своих программистов в Agile-формате. Методология предполагает разбиение проекта на короткие итерации (спринты), в конце которых появляется часть законченного функционала. Это позволяет разработчикам оперативно получать обратную связь от заказчика/потребителей и гибко реагировать на меняющиеся требования и приоритеты в реализации продукта.
Проектную команду мы набираем индивидуально под каждый проект после тщательного анализа и изучения. «Костяк» проектной команды мы всегда формируем из собственных сотрудников, поскольку именно они отвечают перед заказчиком за достижение целей проекта, а это большая ответственность. В эту группу входят руководитель проекта, архитектор (их может быть несколько), ГИП (главный инженер проекта), консультанты, ключевые проектировщики. Если проект большой по масштабам, территориально распределен или с крайне сжатыми сроками реализации, в команду могут быть привлечены сторонние специалисты.
Важно, чтобы каждый сотрудник знал и понимал свою роль и место в команде, свои функции, ответственность, те принципы, по которым строится и работает команда. Необходимо добиться, чтобы большой коллектив функционировал как единый организм. Когда я говорю про команду, я имею в виду в том числе и заказчика, как непосредственного участника процесса реализации.
В проектном сообществе ничто не вызывает такой резонанс, как споры о мотивации проектных команд и эффективности использования тех или иных инструментов. Все ищут «тайный Грааль», но опыт подсказывает, что его нет – все сугубо индивидуально. В своей организации мы уделяем много времени этому вопросу, и опыт показывает, что использование отдельного мотивационного драйвера или их ограниченной выборки дает ограниченный результат. Мотивация сотрудников – величина комплексная, и подход должен быть соответствующим. Я не буду оригинален, если скажу, что, помимо прочего, у нас есть финансовая мотивация за успешную реализацию проектов. Но, как показывает практика, она носит исключительно временный эффект и быстро проходит. Поэтому особое внимание мы уделяем нефинансовой мотивации сотрудников через чувство значимости личного вклада в общий успех, удовлетворение от достигнутого результата, получения нового уникального опыта, корпоративное обучение и многое другое.
Как уже было сказано ранее, проектное сообщество предлагает большое количество различных методологий, обобщающих лучшие мировые практики. Тем не менее в чистом виде они, как правило, не могут быть применимы к нашей российской действительности. Это прежде всего обусловлено нашим менталитетом, зрелостью бизнес-процессов организаций и готовностью членов проектных команд к использованию той или иной методологии.
Сейчас существует множество методологий управления – от абсолютно жестких (waterfall, инкрементальная) до гибких (Scrum, спиральная).
Основное отличие заключается в том, насколько заказчик ПО вовлечен в сам процесс разработки.
Если у клиента мало времени или он не хочет вдаваться в детали, делается проект по жесткой методологии, подписывается, и все, кто в нем участвуют напрямую, завязываются на сроки.
Если клиент хочет что-то свое эмоциональное, создается scrum-команда, он становится в ней полноправным членом (stakeholder) и проходит через все боли и радости проекта.
Сам я очень люблю Kanban (это когда есть только доска и карточки-задачи). Он не обязывает, как Scrum, к ежедневным зарегламентированным совещаниям. Не просит распланировать весь проект на начальной стадии или сообщить идеально точные сроки. При этом дает отличную наглядность о ходе проекта на дашборде.
Начинал я с waterfall. Конечно, если не считать экстремального программирования (философия которого – в отсутствии методологии).
Но у меня самого никогда не получается точно сказать, какими инструментами я воспользуюсь по ходу проекта, пока его не выполню.
Меня всегда удивляло – с точностью до дня (а иногда до часа) расписывать все задачи проекта на диаграмме Ганта в Project, а после накидывать еще 200% времени «на попадос».
И более того, я очень хорошо видел, как работают разработчики. Если им называешь срок по одной и той же задаче – день и неделю, они его просрочивают всегда на один день. Срок зависит не от плана, а от мотивации.
Поэтому начал работать с Kanban. Набираешь команду, расклеиваешь карточки в Trello, мотивируешь людей, и вперед. Люди, желающие работать, никогда не сорвут проект. Проверено сотни раз.
Самое важное – найти одного единомышленника, человека который очень хочет завершить проект. Далее команда сама будет фильтровать всех, кто в нее попадает. Аутсорсеры, безусловно, нужны. Они дают резкое увеличение ресурсов, когда это необходимо. Основную часть проекта, конечно, предпочтительнее делать штатными сотрудниками.
Любая методология требует обучения проектной команды. Также никто не отменял таких понятий, как слаженность в работе и согласованность в командных действиях. В гибких методологиях уровень вовлечения команды значительно выше по сравнению с классическими методологиями. В таких случаях требуется применение методов мозгового штурма, постоянного обсуждения достигнутых результатов и поиска путей устранения возникающих в ходе работы ошибок. Однако даже после обучения могут потребоваться несколько итераций боевого проекта для разбора узких мест в использовании методологии.
Достойная зарплата должна быть обязательно, без этого никуда.
Много значит престиж бренда компании и комфорт офиса. А далее мотивации много не бывает, при этом она, по сути, бесплатна: свободный график, внимание руководства, возможность обучения, похвалы и так далее.
Основной показатель: у сотрудника должны «гореть глаза», когда он видит работу.
Надо знать проблемы клиента. Большая часть проектов проваливается, потому что не решает основных болей заказчика. Бывает заказчик просит сделать автоматизацию, а при этом не налажен даже учет. В этом случае стоит не браться за проект, а помочь клиенту подготовиться к нему.
Бывает, между собственниками нет согласия в проекте. В «семейные» разборки лучше вообще не влезать. Поэтому не нужно смотреть на проектную документацию, нужно приехать в офис и поговорить со всеми. Причем как с собственниками, так и с сотрудниками.
Нужно. В России очень низкая производительность труда.
Слишком много свободы дает расслабленность, поэтому любую гибкую методологию нужно очень жестко контролировать.
У нас сложилась собственная система, направленная не на методологию, а на конкретных личностей и их особенности, под проект формируется слаженная команда, которая за счет синергии справляется с управлением сама.
Пытались использовать те или иные элементы методологии Agile, но в нашей ситуации конкретные формальные элементы больше мешали, чем помогали. И мы пришли к «настоящему» Agile, когда главное – люди, а не процессы. Если здравого смысла и уровня коммуникации хватает, чтобы сделать качественный продукт, значит, больше ничего не надо.
Мы не привлекаем сторонних специалистов для работы в проектах – у нас всегда свой штат, главное достоинство которого – сработавшиеся, отлично дополняющие друг друга профессионалы.
Проектная методология – это универсальный способ организовать эффективную совместную работу людей, еще не работавших вместе или вообще не знакомых до проекта. В этих условиях (особенно если речь об Agile) знание методологии всеми участниками – обязательное условие для того, чтобы она работала. У всех участников должен быть общий бэкграунд (например, в виде методологии), и его нужно как-то в головы сотрудников поместить – это и есть обучение. В нашем случае общим бэкграундом являются личная вовлеченность членов команды, гибкое планирование и ориентирование на результат.
У нас в ITSumma это прежде всего личностный рост как профессионала, обмен знаниями между членами команды и коллектива в целом, работа над интересными (как с технологической, так и с продуктовой точки зрения) проектами, осознание личного вклада в общее дело.
Чтобы руководителю быть готовым к новому проекту, в первую очередь нужно иметь несколько разнообразных проектов в багаже (не обязательно успешных, все приносят опыт). Если говорить о том, что нужно знать в фазе инициации проекта, чтобы принять решение, браться за него или нет, тут важны опыт и экспертные оценки как руководителя, так и ключевых членов команды. Хорошо, если уже в самом начале мы представляем в общих чертах, какие будут использованы технологии, какие у команды есть компетенции и каких нет, правильно оценим доступные ресурсы и риски.
Для нас нет понятия «российской специфики» в проектной работе – главное значение имеют люди, которые работают в команде.
В начале нулевых мы в группе компаний «ИМПУЛЬС-ИВЦ» проводили полноценное исследование по выбору методологии управления проектами и остановились на системе IPMA (СОВНЕТ). Для нас тогда были важны наличие адаптации к местным условиям, подходы в подготовке и сертификации сотрудников и, главное, конечно, само содержание и совпадение представлений о правильном управлении. Предметная область не стоит на месте, и приятно, что в последние годы все большую адаптацию проходят методы Agile, Scrum.
Для ИТ и организационных проектов мы обычно используем MS Project, а для объектов, связанных с монтажом инженерных систем, – нашу собственную разработку «1С:Подрядчик строительства. Управление строительным производством». В обоих случаях важна подготовка персонала, прежде всего руководителей проектов, по методологии и технологии, а также дисциплина ведения проекта.
Ведь порой, разработав устав (концепцию) проекта, составив календарные планы и сетевые графики, назначив ресурсы, менеджмент забывает о системном руководстве, отслеживании результатов, вех, отставаний, постепенно погружая проект в хаос и в итоге проваливая его. То есть цикл управления останавливается на стадии планирования, забывая про учет, контроль и оперативное регулирование.
Так как одно из направлений нашей группы – информационно-коммуникационные технологии, большинство ИТ-проектов мы выполняем собственными силами, создаем временные группы или расширяем штат. Набор внешних подрядчиков производится только для узкоспециальных работ, где не хватает нашей компетенции и/или сертификации. Используя собственных сотрудников, заказчик несет все риски самостоятельно. Нанимая внешнего подрядчика, значительную часть рисков первый переносит на второго. Маржа подрядчика и есть плата за риск.
Да, конечно. Особенно это касается состава проектного офиса, руководителей, спонсоров проектов, людей, отвечающих за выделенные этапы и задачи проектов. Важна не только подготовка сотрудников (самообучение, внутреннее, внешнее обучение), но и валидная сертификация, такая, за которой стоит реальное подтверждение знаний и навыков, а не только красивый документ.
Каждый человек уникален, и проектные коллективы всегда разные, как сами проекты, поэтому желательно, чтобы в распоряжении спонсоров, руководителей проектов был целый арсенал материальных и нематериальных мотиваторов. В таком случае менеджмент сможет выбирать нужные инструменты для конкретной ситуации и людей.
По своим знаниям руководитель проекта должен быть, например, в состоянии выступить основным автором устава (концепции) проект, даже если по факту он не будет разрабатывать его самостоятельно.
Одна из важных характеристик любого проекта – это география, менталитет участников проекта, культурные особенности страны и региона. Выбирайте правильных подрядчиков и проектные команды и не забывайте создавать резервы во всем (сроки, деньги, ресурсы).
Решающим фактором при определении методологии всегда являются цели заказчика. Если цели и сроки четко обозначены, то наилучшим выбором будет классическая методология. Она позволяет лучше планировать ресурсную загрузку компании и оптимизировать расходы, именно поэтому в наших проектах мы стремимся к этому варианту.
Исходя из задач наших клиентов мы применяем различные методологии управления. Например, для реализации инфраструктурных проектов хорошо подходит классический вариант на основе PMBoK. Но, если у заказчика сложная оргструктура с большим количеством заинтересованных лиц или в ходе оперативного планирования постоянно возникают новые задачи, или руководство компании ищет новые подходы к реализации стратегических целей, не обойтись без Agile. Эта методология позволяет нам оперативно получать обратную связь от заказчика и за короткий интервал времени реализовывать только то, что наиболее важно на данный момент. Из минусов такого подхода –сложность в планировании ресурсов компании.
Наша компания максимально задействует собственный штат специалистов, крайне редко прибегая к услугам сторонних организаций. Такой подход дает инструменты для точечной мотивации каждого участника проекта и соответственно повышает качество реализуемых проектов.
Когда возникает необходимость отойти от устоявшейся в компании технологии, отдельное внимание мы уделяем обучению команды новой методике работы.
Инструментов может быть много в зависимости от самого исполнителя, но основные из них практически не меняются. Как ни странно, но в первую очередь это эмоциональная поддержка и признание коллективом успешности сотрудника. И только потом финансовая мотивация, как в виде дополнительных премий, так и в виде штрафов за некачественно выполненную работу.
Прежде всего цели и обязательства проекта. Все остальное грамотный руководитель решит.
Я считаю, что отличия в менталитете России и стран Запада в настоящее время не влияют на выбор методологии в такой степени, чтобы говорить об этом серьезно.
Учитываются используемые технологии, инструменты, наш опыт и практики, которые применяет клиент. На основе этого выбирается методология, которая приведет к запланированному результату с минимальными затратами ресурсов, времени и нервов задействованных лиц.
Мы практикуем управление с помощью «водопадного» метода, основанного на PMBoK, и Agile. «Водопад» часто используется при проектировании и внедрении программно-аппаратных комплексов или построении центров обработки данных. Agile – при разработке и доработке прикладных систем.
Провал наступает, когда происходит подмена метода ведения проекта. Был свидетелем, когда команда задекларировала Agile, но уже к третьей итерации забросила stand up, а scrum-мастер рисовал диаграммы Ганта, которые никто не соблюдал. Другой кейс пострадал из-за рассогласованности действий и несоблюдения правил управления изменениями. Перед самым тестированием системы резервного копирования технические специалисты клиента, не уведомив команду, добавили новые политики. Мы вместе с клиентом потратили несколько дней, чтобы разобраться, почему время резервного копирования отличается от заданного.
Девять из десяти проектов мы реализуем собственными силами. Внешних подрядчиков привлекаем для выполнения работ, по которым держать в штате своих сотрудников нецелесообразно (строительно-монтажные работы, транспортные услуги и т.д.).
Для наших менеджеров проектов обучение обязательно, многие из них уже сертифицированы PMI. Методы управления waterfall и Agile у нас детально описаны и регламентированы. Они шлифуются и совершенствуются годами – у ключевого бизнес-процесса в этом году юбилей – 10 лет. Регламентами руководствуются все участники проекта с нашей стороны. На клиента мы транслируем краткий свод правил в виде устава. Так реализация становится прозрачной с точки зрения информационного поля и технической стороны.
Мы учим сотрудников за деревьями видеть лес. У нас максимально прозрачный вклад каждого участника в результат проекта. Люди понимают, на что они влияют, к чему нужно стремиться и почему нельзя подвести команду. И мы получаем удовольствие от того, что сделали мир еще чуть-чуть лучше и технологичнее.
Знать, что он демиург мира-проекта. Теперь от него зависит создание этого мира, качества жизни в нем, смысла существования и конечного результата. Он должен понимать, какой цели хочет достичь, сколько у него есть на это времени, денег и чем готов рискнуть, когда что-то пойдет не так.
Существует даже отдельная область знаний по национальной специфике. Российская раньше сильно проявлялась в игре: «Вы пошли навстречу по цене, поэтому мы не будем строго спрашивать за срыв сроков». Без знаний правил, достичь целей нельзя. Иначе вы рискуете играть в шахматы, а партнер – в нарды. Мы стараемся учитывать не только национальные, но и культурные, географические и отраслевые особенности.
На выбор методологии проекта оказывают влияние несколько факторов. Главные критерии − это ожидания заказчика и цели проекта. Немаловажными моментами являются также сроки и состав команды. Так, при решении конкретных задач с жестко определенным бюджетом и сроками лучше использовать классические модели. Если же заказчик готов решать существующую проблему, но при этом понимает, что четкой методики решения нет, то итерационные гибкие модели подойдут здесь лучше.
К примеру, у нас был проект, согласно которому требовалось автоматизировать свыше 10 бизнес-процессов. Задача была поставлена достаточно размыто, так как из-за непрозрачности текущих работ по процессам и сложности их контроля руководство не всегда понимало, что происходит по процессу в конкретный период времени. При этом конечный результат заказчик четко назвать не мог. Тут требовалась большая аналитическая работа по оптимизации процессов.
В данном случае мы применили гибкую методику: внедрение происходило итерационно и в нем отсутствовали присущие каскадной модели этапы долгого исследования и проектирования. На каждой итерации, размер которых не превышал двух недель, ставились локальные задачи, чаще всего на основе макетов, решение которых оценивалось заказчиком. И на следующей итерации новые задачи ставились уже с учетом оценки заказчика.
При такой работе мы автоматизировали 4 из 13 процессов, добавили необходимую отчетность. А так как остальные процессы были сильно завязаны на первых, то их автоматизация даже не потребовалась. Задача заказчика была решена.
Чаще всего мы работаем, используя классическую waterfall-модель управления, или, как ее еще называют, каскадную. Данная модель предполагает последовательный процесс реализации ИТ-проектов, который включает в себя такие шаги, как анализ потребностей заказчика, проектирование, реализацию, тестирование, запуск проекта в эксплуатацию и его сопровождение.
Это обоснованно тем, что такие проекты проще планировать как по работам, так и по бюджетам. И у заказчика, и у нас есть четкое представление, когда, какие специалисты понадобятся. К тому же в нашей компании есть четко прописанная технология ведения таких проектов, что упрощает процесс.
Для более локальных проектов мы применяем различные agile-методологии. Стоит понимать, что agile-методологии требуют наличия сплоченной команды, которой руководит опытный руководитель, способный эффективно перераспределять ресурсы и задачи в ходе проекта, не теряя при этом конечную цель и учитывая все ограничения.
Команды на проект мы набираем из своих сотрудников. Принцип набора достаточно прост: сначала определяется руководитель проекта, затем формируется команда из сотрудников с необходимым уровнем компетенций и сработанностью друг с другом. Одна из целей обучения и развития наших сотрудников − это обеспечение возможности и умения работать любому члену команды на любом проекте.
Есть опыт работы и с аутсорсерами. Но здесь стоит отметить, что для привлечения аутсорсеров должны быть веские причины. Внешними сотрудниками сложнее управлять и предсказывать их поведение, к тому же в командах со смешанным составом могут быть недопонимания и необоснованные конфликты, вызванные различием в культуре ведения проектов.
Реальность жизни меняется настолько быстро, что наиболее эффективным способом обучения является практика. Общий алгоритм получения знаний по той или иной методике следующий: изучение основных терминов и понятий методологии (чтение словарей или глоссариев), изучение опыта работы команды на каком-либо проекте с использованием методологии (в форме семинаров или индивидуальных бесед) и далее участие в проекте с назначенным наставником или куратором. Конечно же, работе помогает дополнительное изучение практик и тренинги по отдельным элементам: управление рисками, ведение переговоров, работа с возражениями и прочие.
На мой взгляд, самым ценным на сегодня являются знания. Эту мысль мы ежедневно доносим до своего коллектива. Любой проект и достижение результатов в рамках него несут дополнительные навыки и опыт. Для наших наиболее амбициозных членов команды работа на проектах − это возможность расширить свой круг общения, а отлично завершенный проект − хороший бонус в его пользу.
Кроме общих знаний и навыков управления проектами, руководителю проекта необходимо понимание и знание бизнес-процессов, которые потребуется оптимизировать и автоматизировать, так же как и смежных процессов. Желательно знание информационных систем, используемых в компании, понимание их принципов работы и круга решаемых задач.
На мой взгляд, выбор самой методологии в большей мере зависит от задач заказчика, а не от географии его деятельности. Конечно, в этом вопросе срабатывают особенности российского менталитета. Например, у нас не привыкли работать с договорами с открытой суммой, как следствие, сложности в применении agile-технологий. Или все решения в рамках проекта принимаются с привлечением высшего руководства, что требует дополнительного планирования и учета в рисках.
Специфика и тип проекта, возможность и желание заказчика работать по той или иной методологии. Также важна команда, которая будет работать над проектом, насколько она готова работать, например по Scrum.
В работе использовали (и в той или иной степени продолжаем использовать) waterfall, Kanban и Scrum. Основной негативный опыт связан не с самой методологией разработки, а с некорректным выбором методологии для проекта либо попыткой поставить методологию разработки основной целью проекта. В итоге был отрицательный опыт попытки внедрения Scrum в крупный госпроект, которая привела к замедлению разработки за счет появления «ритуалов», которые не смогла принять команда. В контексте положительного опыта можно оценивать большинство проектов, где выбранная методология подходила под требования проекта.
При выборе команды мы ориентируемся на необходимые для проекта компетенции. В случае проектов со сложной предметной областью стараемся выбрать сотрудников, у которых был опыт разработки ПО в данном сегменте (часто это важнее, чем технические навыки в конкретном языке программирования, фреймворке и т.д.). Кроме того, мы отдаем предпочтение командам, которые уже сработались на предыдущих проектах. Команду формируем исключительно из своих сотрудников.
Если требуется всю команду перевести на работу по новой методологии разработки, то обучение является обязательным (часто его можно провести без отрыва от проекта). Особенно это актуально при переводе всей команды с «водопадной» модели на Agile. В основном обучение затрагивает используемые при гибких методологиях инструменты и «ритуалы».
Как показывает опыт, основным мотивирующим фактором для команды является заинтересованность в использовании того или иного технологического стека и желание получить какой-либо новый опыт, нежели какая-то материальная составляющая. Поэтому основной упор мы делаем на инструменты, используемые при формировании команды, а различного рода материальные стимулы заменяет высокий, по меркам отрасли и региона, оклад. Также значительную роль при мотивации и эффективности команды играет осведомленность каждого участника команды о целях и бизнес-задачах проекта. Поэтому на этапах планирования и анализа большое внимание уделяется внутренним митингам, на которых руководители проектов и аналитики доносят до команды информацию о том, для чего внедряется тот или иной функционал и почему, например, заказчик хочет именно такой вариант реализации, а не любой другой. В дальнейшем сотрудник должен быть вовлечен в процесс развития продукта, обладать информацией по плану развития проекта и получать обратную связь об успехах и неудачах.
С учетом особенностей того или иного проекта на роль руководителя могут быть назначены разные руководители, с учетом текущей загруженности и наличия опыта в аналогичных проектах. Если отталкиваться о наборе требований к руководителю проектов в целом, то можно выделить следующие способности и навыки:
Далее руководитель проекта, чтобы быть готовым к проекту, должен собрать вводную информацию по проекту, такую как:
На наш взгляд, при выборе методологии особой российской специфики нет, и мы применяем одинаковый подход для российских и зарубежных заказчиков, но, разумеется, есть ряд «привычек» у заказчиков разных стран, например, по выбору используемых в проекте технологий и инструментов коммуникации.
Главное − разговаривать с заказчиком на одном языке. Подавляющее большинство наших заказчиков находятся в Европе, и им ближе методология PRINCE2. Ее мы и используем.
Комбинация слов «проектные технологии» в основном используется в образовании. В управлении проектами обычно говорят о «проектных методологиях». Мы используем и PRINCE2 и PMI PMBoK. В проектах, связанных с разработкой ПО, чаще всего используем Scrum.
В основном проектная команда формируется из своих сотрудников, но иногда привлекаем аутсорсеров, когда своих ресурсов не хватает.
Проектных менеджеров и админи-страторов, которые выполняют ИТ-инфраструктурные проекты, мы в обязательном порядке обучаем методологии PRINCE2. Менеджеры, которые руководят проектами разработки программного обеспечения, изучают Scrum. Для остальных членов команды обязательного обучения проектной методологии не требуется.
Мы используем в качестве основного показателя деятельности проектной команды индекс удовлетворенности заказчика. По завершении каждого проекта просим заказчика заполнить небольшую анкету, в которой он отмечает как общую удовлетворенность ходом и результатами проекта, так и удовлетворенность отдельными аспектами проекта, такими, например, как частота и качество коммуникации, умение выявлять и подсвечивать риски проекта и т.п.
Наши менеджеры проектов всегда готовы к любым проектам. А вот чтобы выполнить проект, надо знать, чего хотят заинтересованные стороны проекта.
Одна из основных компетенций менеджеров проектов – способность выявлять заинтересованные стороны (стейкхолдеров) проекта, их интересы и возможности влияния на проект и налаживать эффективные коммуникации с ними.
Специфика скорее связана не со страной, а с предпочтениями конкретного заказчика. Если заказчик уже работал с гибкими методологиями, то исполнителю, безусловно, надо учитывать этот факт и предлагать ему исполнение проекта на основе гибкой методологии. В целом в России более популярны PMI PMBok и Scrum.
При выборе методологии мы традиционно учитываем несколько факторов. Решающими для нас являются:
При реализации проектов в сфере ИТ и бизнес-консалтинга уже очень активно применяются современные гибкие методы управления проектами (Agile и Scrum). В наших проектах по внедрению ERP-систем мы активно комбинируем данные методологии с классической «водопадной» моделью. Это приносит положительный эффект, так как позволяет сохранять глобальный контроль над проектом, но при этом обеспечивать его оперативную гибкость. Негативный опыт может быть связан со случаями, когда заказчик декларирует использование гибких методов проектного управления, но в реальности не выстраивает никаких процессов для этого и не наделяет соответствующими полномочиями руководителя проекта со своей стороны.
Основной костяк команды проекта набирается исходя из функциональных потребностей проекта (логистика, финансы, бухгалтерский учет и т.п.) и необходимого ролевого состава (ведущий консультант, ведущий разработчик, консультант и т.п.) с точки зрения запланированных к выполнению работ. Грубо говоря, это некоторый «паззл», который я складываю в начале каждого проекта. Основная задача – избежать белых пятен.
По моему опыту, да. Часто я выступаю в роли тренера либо коуча, что, кстати, рекомендуется стандартами управления проектами от PMI и других вендоров.
По сути, в данном вопросе уже содержится и ответ на него. Это все инструменты, которые привязаны к конкретному результату, необходимому для проекта. Это может быть детальный план работ, привязанный к конкретным документам, диаграммам, программному коду и т.п., либо проектный портал, либо среда коллективной работы. Важно, чтобы команда понимала результат и его декомпозицию, а работа в этих инструментах была прозрачной и публичной (в рамках команды проекта).
Основное – это знание различных методик и инструментов проектного управления, понимание, когда и как их лучше применить; владение предметной областью проекта; знание экономики, основ бизнес-моделирования и методологий управления бизнесом; умение работать в команде. Отмечу также, что очень важно быть готовым меняться самому в рамках подготовки нового проекта, а не накладывать на него свои жесткие шаблоны и рамки.
Проекты, которые мы реализуем в России, часто сопровождаются большим количеством изменений, происходящих в бизнесе параллельно с нашей работой. Это нельзя назвать особенностью одной России. Мне кажется, что это специфика так называемых развивающихся стран.
Если говорить о проектах внедрения, то мы придерживаемся традиционной методологии управления. Это дает нам возможность на каждом этапе быть уверенным, что все работает правильно. С другой стороны, у нас уже накоплен большой опыт внедрения на различных объектах (транспортные узлы, автомагистрали и перекрестки, стадионы и пр.), поэтому этапы планирования и проектирования мы выполняем достаточно быстро.
При реализации проектов мы работаем как через партнеров, так и самостоятельно, силами собственной проектной команды. Достаточно часто, даже если большая часть проекта реализуется партнером, наши сотрудники присутствуют на месте и оказывают помощь и консультируют.
Да, если используются нетрадиционные подходы к управлению, может потребоваться специальная подготовка не только руководителей, но и рядовых членов проектной команды.
Мотивация базируется на понимании каждым членом команды своей зоны ответственности. Без этого ни «количественные» (материальные), ни качественные (признание роли члена команды в успехе или неудаче) инструменты не будут выполнять свою мотивирующую функцию.
Чтобы команда работала эффективно в рамках традиционного проекта, проектный менеджер должен четко представлять себе роль каждого члена команды и максимально четко ставить задачи исполнителям и понимать, каким образом будут организованы обратная связь с заказчиком, проверка качества реализации на каждой стадии, и, конечно, грамотно прописать все граничные условия.
Я думаю, что речь здесь может идти не столько о «страновой» специфике, сколько об особенностях того или иного объекта (организации, предприятия), где происходит внедрение проекта. В нашем случае мы должны учитывать, например, различные режимные ограничения, правила работы с информацией, требования внешних и внутренних пользователей и пр. Например, работая с системами распознавания лиц для решения различных задач безопасности, мы должны понимать, каким образом будет организовано взаимодействие различных служб, которые станут работать с системой, что должно быть заложено на этапе проектирования для дальнейшего развития и расширения системы.
Критерий прост: если методология позволяет сократить трудозатраты, требуемые для решения задачи, – значит, ее стоит внедрить. В противном случае методология для нас бесполезна. Мы же обращаемся только к тому, что действительно работает.
В разное время мы использовали каскадную модель (waterfall model), Kanban (Kanban Development), Scrum. Выбор той или иной методологии всегда определялся в соответствии с актуальными на тот момент целями компании, степенью ее зрелости и уровнем компетенции разработчиков. Методологии сменяли друг друга эволюционным путем, после выявления проблемных аспектов, а также благодаря пониманию того, как можно улучшить существующие подходы.
Изначально мы использовали каскадную модель как наиболее подходящую для создания сложных информационных систем для крупных государственных заказчиков. Она отлично учитывала особенности конкурсных технических заданий и позволяла организовывать проектное управление в привычных для сторон условиях. Кроме того, эта методология без проблем согласуется с ГОСТ34, который используют многие заказчики.
По мере усложнения создаваемых нами ИТ-решений и увеличения сроков реализации проектов ввиду их сложности мы все больше ощущали на практике ограничения текущей модели разработки. Заказчики изначально планировали разработку в несколько этапов, цели проекта уточнялись и даже менялись по ходу реализации проекта. Нам явно требовался переход к гибкой методологии разработки (Agile), способной обеспечить итеративность и динамическое формирование требований.
Основными приоритетами стали возможность реализовывать текущие требования проекта, полная прозрачность процесса для всех участников, включая заказчика, и равномерное распределение нагрузки между исполнителями. После проведения серии экспериментов с другими методологиями мы выбрали Kanban. Его применение позволило сохранить текущие процессы разработки, постепенно улучшая их.
По мере трансформации отдельных проектов в комплексные отраслевые решения в командах естественным образом стали выделяться роли, характерные для Scrum (например, Product Owners и Stakeholders). Стало понятно, что мы готовы переходить к этой методологии, которую и используем успешно в настоящее время. Из ее преимуществ для «Нетрики» можем выделить скорость реализации проектов, уровень удовлетворенности заказчиков.
Негативный опыт был, пожалуй, только при использовании каскадной модели в длительных проектах, когда на последних этапах внезапно менялись, например, требования законодательства. Но благодаря высокой квалификации проектной команды даже такие непредвиденные изменения не вызывали серьезных проблем.
Для достойного качества разрабатываемых решений мы стараемся привлекать свои команды. К аутсорсерам обращаемся редко и в любом случае оставляем за собой координирование проекта, постановку задач и контроль итогового результата.
Команду для проекта формируем из внутреннего пула сотрудников, так как быстро собрать профессиональную и слаженную команду под проект, набрав новых людей, практически невозможно.
Разумеется, важно обучить команду новой технологии. Хотя в принципе различий между теорией и практикой нет, в работе они всегда видны. Между знанием методологии и способностью эффективно применять ее на практике огромная пропасть. И специальное обучение команды – лишь один из способов преодоления этой пропасти.
Распространенное мнение о том, что один из самых эффективных мотиваторов – это деньги, на практике не подтверждается. Кроме материального вознаграждения, важно видеть ценность проекта, над которым работаешь, его практическую пользу, использовать современные технические решения. Вызовы вроде высокой сложности проекта тоже отлично стимулируют профессионалов. Несомненно, имеют значение и отношения в команде, наличие общей культуры и ценностей.
Необходимо знать, что скрытые возможности человеческого разума практически безграничны. Кроме этого, желательно осознавать, что, когда и как нужно делать для успешной реализации нового проекта. Понимать задачи, а также сильные и слабые стороны команды, уметь максимально эффективно применить первые и нивелировать вторые.
Зависит от заказчика, но скорее нужно, чем нет.
Например, многие госзаказчики после выхода Постановления Правительства от 15 октября 2016 года № 1050 «Об организации проектной деятельности в Правительстве России» активно внедряют у себя проектное управление и организуют проектные офисы. Нужно учитывать используемые ими подходы для организации совместной работы.
По нашим наблюдениям, на российском рынке обычно либо вообще мало что знают о проектном управлении и действуют скорее интуитивно, либо глубоко изучили вопрос и обладают серьезной экспертизой. Иначе говоря, мы зачастую сталкиваемся с крайностями в понимании проблемы, когда прийти к золотой середине бывает не так просто.
Компания «Аванпост» является вендором, занимающимся разработкой и продвижением собственных информационных систем. Вся наша основная деятельность может быть упрощенно разделена на два больших блока работ:
Управление разработкой − это свой сложный мир, живущий по своим законам и методологиям. А гораздо большая проектная составляющая существует в части внедрения наших систем у заказчиков, т.к. тут во всей красе присутствуют все признаки проектной деятельности: создание уникального результата в четко заданное время в условиях ограниченных ресурсов. Причем проектная деятельность осложняется еще и тем, что внедрение всегда ведется с привлечением партнера (системного интегратора). То есть в процессе выполнения проекта участвуют минимум три организации со своими процессами, подходами и целями.
Поскольку управление подобными крупными проектами − задача очень непростая, а уровень ответственности очень высок, то в нашей компании разработана собственная методология ведения проектов. В ее основе находится международный стандарт по управлению проектами PMI PMBоK. Но его положения сильно переработаны и адаптированы к специфике нашей деятельности. Так что теперь вопрос выбора методологии перед нами не стоит.
Мой жизненный опыт в прошлом был очень тесно связан с проектным менеджментом. Дело в том, что с 2003 по 2008 год я был исполнительным директором компании PM Expert, одного из признанных лидеров в сфере консалтинга и обучения вопросам проектного менеджмента в России. С тех по и по сей день продолжаю внимательно следить за развитием всех основных стандартов в сфере проектного менеджмента и с интересом наблюдаю за развитием рынка информационных систем по управлению проектами. Но в своей нынешней компании мы выбрали наиболее классические и проверенные инструменты, на основании которых и построили собственную методологию проектного управления. Методологической основой для нас стал упомянутый выше PMI PMBоK, а в качестве средства автоматизации мы используем MS Project.
Команда при выполнении наших проектов выглядит достаточно предсказуемо. От нас в проекте всегда участвуют архитектор (отвечает за техническое проектирование решения) и менеджер проекта (отвечает за общую координацию работ). Инженеры по внедрению могут быть как от интегратора (наиболее частый вариант), так и от «Аванпоста», а иногда даже от заказчика. Поскольку мы внедряем сложные системы, требующие аналитической проработки бизнес-процессов заказчика, то еще в проекте есть роли аналитика или консультанта. Аутсорсеров на свои проекты мы не привлекаем.
Команду для проекта формируем из внутреннего пула сотрудников, так как быстро собрать профессиональную и слаженную команду под проект, набрав новых людей, практически невозможно.
Все наши сотрудники детально изучают нашу методологию проектного менеджмента. Для этого у нас разработан подробный мануал с детальным описанием ролей, зон ответственности, порядка взаимодействия и выполнения всех основных процессов в ходе проекта. А также все вновь принимаемые на работу сотрудники проходят внутреннее обучение по методологии и сдают небольшой экзамен на проверку знаний в виде теста и собеседования.
За годы работы я видел очень много различных и иногда очень витиеватых систем мотивации для проектных команд. Но у себя в компании я остановился на наиболее простом, понятном и очевидном подходе. Мы говорим о финансовой премии, которая рассчитывается и начисляется следующим образом. На каждый запускаемый нами проект определяется фонд премирования, в котором есть определенная доля для каждого из сотрудников, и ее размер сотрудник узнает сразу в начале проекта. При этом его премия делится на две равные части. Первая часть «За личные результаты», вторая «За успех всего проекта». Если сотрудник выполнял все свои задачи качественно и вовремя, то он гарантированно получит премию «За личные результаты», даже если проект в целом будет не совсем удачен. Но если проект будет сдан в срок, с высоким качеством и хорошей оценкой заказчика, то сотрудник получит и вторую часть премии «За успех проекта». Именно эта часть способствует тому, что члены проектной команды ориентированы на совместную работу и единый результат, что предотвращает внутренние противоречия и разногласия. Но есть еще одно правило: если к работе сотрудника были нарекания и он был лишен личной премии, то даже при успешном завершении проекта он не получит и премию за успех проекта.
Мне не совсем нравится термин «выбор» методологии. Я абсолютно уверен, что любая организация при серьезном подходе к своей проектной деятельности будет сама разрабатывать свою внутреннюю методологию, учитывающую вид их бизнеса, отраслевые особенности и, конечно, требования законодательства и регуляторов. Так что учет российской и отраслевой специфики в этом случае произойдет автоматически.
Основных факторов, влияющих на выбор, три: вид проекта, объем проекта и возможность вовлечения в проект специалистов Заказчика.
Мы используем как классические, так и гибкие методы проектного управления. Наибольшую пользу удается извлечь из их разумного сочетания: это позволяет гибко управлять объемом и ресурсами проекта, не выходя за сроки и обеспечивая высокое качество выполненных работ.
Ресурсный менеджер предлагает специалистов в проектную команду исходя из квалификационных требований и их текущей занятости на других проектах. Внешние исполнители привлекаются в периоды пиковой загрузки и в случае недостаточности технической или функциональной экспертизы для выполнения отдельных проектных работ.
Команда, которая постоянно учится, чаще достигает успеха в проекте. Важно использовать свои знания, опыт коллег и конкурентов на пользу дела. Курсы дают возможность обновить и углубить знания, обменяться опытом, перенять полезные практические навыки и методы решения сложных проектных задач.
Наиболее эффективным инструментом являются проектные премии, выплачиваемые при достижении командой запланированных результатов проекта. Из нематериальных факторов выделю возможность изучения новой современной технологии в рамках проекта, а также взаимосвязь успешного выполнения проекта с индивидуальными планами развития участников команды.
Самый ценный и незаменимый ресурс руководителя проекта – его практический управленческий опыт. Знание методов управления, специфики проекта и возможностей проектной команды позволит ему подойти к новому проекту во всеоружии.
Российская специфика сама по себе не является определяющим фактором, но корпоративная культура компании Заказчика, отчасти формирующаяся под влиянием российской специфики, должна учитываться при выборе методологии управления проектом.
