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

Сергей Трофимов, директор проектного офиса компании «ФОРС – Центр разработки» (ГК ФОРС)

1. Управление проектами – это наука, но наука не самая точная. В данной области нет универсальных решений, подходящих для всех проектов, даже если рассматривать портфель только одного руководителя.

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

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

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

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

Издержки на такие «переделки», которых можно было бы избежать, могут достигать 50% от всех проектных затрат.

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

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

4. Да, обучение необходимо как минимум по следующим направлениям:

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

Если используется какая-то специализированная технология, то обязательно требуется обучение этой технологии.

5. В проектной деятельности имеется много технологий, предназначенных для повышения производительности. Одна из них – мотивация. Сбалансированная мотивация направлена на обеспечение и качественных, и количественных показателей.

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

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

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

Помимо инструментов материальной мотивации, так же или даже более важны инструменты не материальные, они выбираются для сотрудника индивидуально:

• Профессиональный рост (получение компетенций)
• Карьерный рост
• Образование
• Признание заслуг
• Наличие свободного времени

6. Для руководителя проекта в нашей компании как минимум необходимо владение сводом знаний по управлению проектами PMI PMBoK. Сертификация руководителей проектов на степень PMP (Project Management Professional) входит в стратегию компании по развитию проектного управления.

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

7. ФОРС работает на российском рынке и для российских заказчиков, поэтому используемые нами методологии управления обязательно учитывают российскую специфику. Наверное, основные отечественные «этнокультурные» особенности, которые влияют на проектное управление, это:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

«Аутсорс привлекается во вторую очередь и на второстепенные задачи»

Иван Аюпов, руководитель направления НФО компании «Хомнет консалтинг»

Вводная: занимаюсь проектами по автоматизации учета на 1С (в основном).

1. Проект по созданию продукта для выпуска на рынок как коробочного решения или проект по автоматизации учета на предприятии.

2. Agile при создании коробочного продукта и различные вариации классического PMBоK в случае проектов для конкретного заказчика. Негативный (и позитивный) опыт заключается как раз в применении неправильной (или правильной) вариации классического PMBоK.

3. Команда собирается из сотрудников предприятия в зависимости от компетенций. Аутсорс привлекается во вторую очередь и на второстепенные задачи.

4. Нет, не требуется.

5. Надо набирать персонал из сотрудников, нацеленных на результат. Денежная мотивация (проектная премия только после завершения всего проекта), неденежная мотивация (индивидуально с каждым сотрудником).

6. Зачем он это делает? Что принесет ему данный проект, желательно в деньгах, – так проще сравнивать эффект и затраты.

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

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

Антон Байтала, директор Проектного офиса, компания ANGARA

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

В 2016 году нашей компанией был успешно пройден внешний аудит на соответствие требованиям стандарта ГОСТ Р 54869-2011 «Проектный менеджмент. Требования к управлению проектом». В ряде случаев для достижения необходимого результата руководителями проектов применяются итерационные подходы предоставления результатов заказчикам.

2. Мой основной опыт связан с «водопадной» (waterfall) моделью управления, но также имеется опыт применения фреймворка SCRUM (методология гибкой разработки ПО). Приведу пример, когда наглядно ощутил отличия гибкой методологии от классической, – это проект, при старте которого ничто не предвещало больших проблем: хорошо знакомый клиент, с которым уже был опыт работы, отлично составленное техническое задание (ТЗ), заинтересованность в проекте исполнителей со стороны клиента, достаточный запас по срокам.

Из Манифеста гибкой разработки программного обеспечения (Agile Manifesto): «Сотрудничество с заказчиком важнее контрактных обязательств». В рамках проекта заказчик должен был выделить сервер для установки программного обеспечения (ПО) в течение нескольких дней с даты подписания контракта. Выделение сервера по независящим от нас причинам затянулось больше, чем на два месяца. Чтобы завершить проект в срок, мы доставили на площадку клиента собственный сервер, установили на сервер ПО, приступили к выполнению работ. После того как клиент выделил собственный сервер, все наработки были перенесены на него. В результате нам удалось значительно сократить время на реализацию проекта и повысить престиж нашей компании в глазах клиента.

Опять же Agile Manifesto говорит: «Реакция на изменения важнее следования плану», а также: «Люди и взаимодействие важнее, чем процессы и инструменты».

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

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

4. С учетом того, что основной методологией у нас все-таки является классический waterfall, специальное обучение для исполнителей не требуется. Руководителей проектов обучаем по мере необходимости, для технических специалистов силами Проектного офиса проводятся семинары, презентации по основам проектного управления и по отдельным процессам управления проектами.

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

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

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

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

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

«Сейчас свои проекты мы чаще всего разрабатываем по методике SCRUM»

Йоханн Воронин, генеральный директор «Корбит»

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

2. Jira и Confluence от Atlassian – отличная прога для управления проектами, ее главный плюс в том, что она заточена под проектную деятельность, а мелкие детали (которых может не хватать) можно легко сделать самому. Open Project используем для прозрачности, чтобы наши клиенты видели прогресс проекта и могли планировать его запуск и внедрение.

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

4. Чаще всего да, но не всегда мы обучаем всю команду проектной технологии. Чаще всего мы отправляем на обучение одного-двух специалистов (это дешевле), чтобы они потом транслировали знания в виде лекций и презентаций, а также курировали проекты, которые используют новую методологию. Например, совсем недавно наш программист обучался в Швейцарии в центре Magnolia CMS, после этого он совместно с нашими разработчиками реализовал несколько проектов на базе этой CMS.

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

6. В первую очередь руководителю требуется знать методологии оценки проектов, чтобы грамотно рассчитать время и количество сотрудников для проекта. А также основные показатели эффективности для оценки результатов (в нашем случае я отслеживаю результаты и эффективность команды по фактуре – часы, затраченные на задачу/проект – и scrum-доске, где виден общий график выполнения задач).

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

«В компании разработана технология, которая позволяет совмещать гибкие методологии и классический “водопадный” подход»

Даниил Каширин, генеральный директор «Форексис» (интегратор технологий анализа Больших данных)

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

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

2. При решении типологизированных задач в компании традиционно используется методология ANSI PMBоK, среди преимуществ которой можно выделить: наличие инструментов управления и контроля результатов проделанных работ. К недостаткам такой технологии относятся: невозможность применения для реализации научных и/или рискованных проектов, а также низкая вариативность реализации, сложность внесения корректив по ходу проекта.

Поскольку одним из направлений деятельности компании является реализация нестандартных IT-проектов, разработка не имеющих аналогов программных решений, зачастую в работе используется методология Scrum. Среди ее плюсов: применение в условиях рискованных проектов с неясным результатом, возможность внесения корректив, а также отсутствие требования высокого уровня культуры управления. Минусы такой методологии: дороговизна разработки решения, необходимость постоянного вовлечения заказчика.

3. Основной вид деятельности компании – разработка ИТ-решений в сфере анализа Больших данных и алгоритмов искусственного интеллекта – представляет собой наукоемкое производство. По факту специалистов с достаточной квалификацией на рынке труда – единицы. В силу исторических связей нашей компании с академическим сообществом сотрудниками зачастую становятся учащиеся и выпускники ведущих технологических российских вузов и подразделений РАН.

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

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

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

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

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

«В проектном сообществе ничто не вызывает такой резонанс, как споры о мотивации проектных команд»

Юрий Корчуков, заместитель директора центра инженерных компетенций компании «Техносерв»

1. Универсальной методологии, как и лекарства от всех болезней, не существует.

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

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

Вышеописанная методика хорошо подходит для реализации инженерно-строительных и инфраструктурных проектов, но совершенно не подходит для разработки ПО и решения других сервисно-ориентированных задач, где на старте проекта не всегда известно, каким будет финальный продукт, а скорость вывода его на рынок является определяющим фактором и существенным конкурентным преимуществом. В таких случаях мы используем гибкие методики управления проектами – Agile, Scrum и т.д., которые набирают все большую популярность в среде разработчиков и заказчиков. Так, например, самый большой банк страны – Сбербанк – в 2016 году объявил о переходе на работу всех своих программистов в Agile-формате. Методология предполагает разбиение проекта на короткие итерации (спринты), в конце которых появляется часть законченного функционала. Это позволяет разработчикам оперативно получать обратную связь от заказчика/потребителей и гибко реагировать на меняющиеся требования и приоритеты в реализации продукта.

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

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

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

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

«У меня никогда не получается точно сказать, какими инструментами я воспользуюсь по ходу проекта, пока его не выполню»

Сергей Львов, руководитель департамента разработки компании ALLSUN

1. Сейчас существует множество методологий управления – от абсолютно жестких (waterfall, инкрементальная) до гибких (Scrum, спиральная).

Основное отличие заключается в том, насколько заказчик ПО вовлечен в сам процесс разработки.

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

Если клиент хочет что-то свое эмоциональное, создается scrum-команда, он становится в ней полноправным членом (stakeholder) и проходит через все боли и радости проекта.

Сам я очень люблю Kanban (это когда есть только доска и карточки-задачи). Он не обязывает, как Scrum, к ежедневным зарегламентированным совещаниям. Не просит распланировать весь проект на начальной стадии или сообщить идеально точные сроки. При этом дает отличную наглядность о ходе проекта на дашборде.

2. Начинал я с waterfall. Конечно, если не считать экстремального программирования (философия которого – в отсутствии методологии).

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

Меня всегда удивляло – с точностью до дня (а иногда до часа) расписывать все задачи проекта на диаграмме Ганта в Project, а после накидывать еще 200% времени «на попадос».

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

Поэтому начал работать с Kanban. Набираешь команду, расклеиваешь карточки в Trello, мотивируешь людей, и вперед. Люди, желающие работать, никогда не сорвут проект. Проверено сотни раз.

3. Самое важное – найти одного единомышленника, человека который очень хочет завершить проект. Далее команда сама будет фильтровать всех, кто в нее попадает. Аутсорсеры, безусловно, нужны. Они дают резкое увеличение ресурсов, когда это необходимо. Основную часть проекта, конечно, предпочтительнее делать штатными сотрудниками.

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

5. Достойная зарплата должна быть обязательно, без этого никуда.

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

Основной показатель: у сотрудника должны «гореть глаза», когда он видит работу.

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

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

7. Нужно. В России очень низкая производительность труда.

Слишком много свободы дает расслабленность, поэтому любую гибкую методологию нужно очень жестко контролировать.

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

Александр Маликов, технический директор ITSumma

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

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

3. Мы не привлекаем сторонних специалистов для работы в проектах – у нас всегда свой штат, главное достоинство которого – сработавшиеся, отлично дополняющие друг друга профессионалы.

4. Проектная методология – это универсальный способ организовать эффективную совместную работу людей, еще не работавших вместе или вообще не знакомых до проекта. В этих условиях (особенно если речь об Agile) знание методологии всеми участниками – обязательное условие для того, чтобы она работала. У всех участников должен быть общий бэкграунд (например, в виде методологии), и его нужно как-то в головы сотрудников поместить – это и есть обучение. В нашем случае общим бэкграундом являются личная вовлеченность членов команды, гибкое планирование и ориентирование на результат.

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

6. Чтобы руководителю быть готовым к новому проекту, в первую очередь нужно иметь несколько разнообразных проектов в багаже (не обязательно успешных, все приносят опыт). Если говорить о том, что нужно знать в фазе инициации проекта, чтобы принять решение, браться за него или нет, тут важны опыт и экспертные оценки как руководителя, так и ключевых членов команды. Хорошо, если уже в самом начале мы представляем в общих чертах, какие будут использованы технологии, какие у команды есть компетенции и каких нет, правильно оценим доступные ресурсы и риски.

7. Для нас нет понятия «российской специфики» в проектной работе – главное значение имеют люди, которые работают в команде.

«Желательно, чтобы в распоряжении руководителей был целый арсенал материальных и нематериальных мотиваторов»

Евгений Новак, председатель совета директоров, ГК «ИМПУЛЬС-ИВЦ»

1. В начале нулевых мы в группе компаний «ИМПУЛЬС-ИВЦ» проводили полноценное исследование по выбору методологии управления проектами и остановились на системе IPMA (СОВНЕТ). Для нас тогда были важны наличие адаптации к местным условиям, подходы в подготовке и сертификации сотрудников и, главное, конечно, само содержание и совпадение представлений о правильном управлении. Предметная область не стоит на месте, и приятно, что в последние годы все большую адаптацию проходят методы Agile, Scrum.

2. Для ИТ и организационных проектов мы обычно используем MS Project, а для объектов, связанных с монтажом инженерных систем, – нашу собственную разработку «1С:Подрядчик строительства. Управление строительным производством». В обоих случаях важна подготовка персонала, прежде всего руководителей проектов, по методологии и технологии, а также дисциплина ведения проекта.

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

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

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

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

6. По своим знаниям руководитель проекта должен быть, например, в состоянии выступить основным автором устава (концепции) проект, даже если по факту он не будет разрабатывать его самостоятельно.

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

«Если цели и сроки четко обозначены, то наилучшим выбором будет классическая методология»

Денис Прищепа, начальник отдела управления проектами, компания «Инфосистемы Джет»

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

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

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

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

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

6. Прежде всего цели и обязательства проекта. Все остальное грамотный руководитель решит.

7. Я считаю, что отличия в менталитете России и стран Запада в настоящее время не влияют на выбор методологии в такой степени, чтобы говорить об этом серьезно.

«Провал наступает, когда происходит подмена метода ведения проекта»

Денис Прозоров, технический директор Группы компаний ХОСТ

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

2. Мы практикуем управление с помощью «водопадного» метода, основанного на PMBoK, и Agile. «Водопад» часто используется при проектировании и внедрении программно-аппаратных комплексов или построении центров обработки данных. Agile – при разработке и доработке прикладных систем.

Провал наступает, когда происходит подмена метода ведения проекта. Был свидетелем, когда команда задекларировала Agile, но уже к третьей итерации забросила stand up, а scrum-мастер рисовал диаграммы Ганта, которые никто не соблюдал. Другой кейс пострадал из-за рассогласованности действий и несоблюдения правил управления изменениями. Перед самым тестированием системы резервного копирования технические специалисты клиента, не уведомив команду, добавили новые политики. Мы вместе с клиентом потратили несколько дней, чтобы разобраться, почему время резервного копирования отличается от заданного.

3. Девять из десяти проектов мы реализуем собственными силами. Внешних подрядчиков привлекаем для выполнения работ, по которым держать в штате своих сотрудников нецелесообразно (строительно-монтажные работы, транспортные услуги и т.д.).

4. Для наших менеджеров проектов обучение обязательно, многие из них уже сертифицированы PMI. Методы управления waterfall и Agile у нас детально описаны и регламентированы. Они шлифуются и совершенствуются годами – у ключевого бизнес-процесса в этом году юбилей – 10 лет. Регламентами руководствуются все участники проекта с нашей стороны. На клиента мы транслируем краткий свод правил в виде устава. Так реализация становится прозрачной с точки зрения информационного поля и технической стороны.

5. Мы учим сотрудников за деревьями видеть лес. У нас максимально прозрачный вклад каждого участника в результат проекта. Люди понимают, на что они влияют, к чему нужно стремиться и почему нельзя подвести команду. И мы получаем удовольствие от того, что сделали мир еще чуть-чуть лучше и технологичнее.

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

7. Существует даже отдельная область знаний по национальной специфике. Российская раньше сильно проявлялась в игре: «Вы пошли навстречу по цене, поэтому мы не будем строго спрашивать за срыв сроков». Без знаний правил, достичь целей нельзя. Иначе вы рискуете играть в шахматы, а партнер – в нарды. Мы стараемся учитывать не только национальные, но и культурные, географические и отраслевые особенности.

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

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

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

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

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

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

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

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

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

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

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

4. Реальность жизни меняется настолько быстро, что наиболее эффективным способом обучения является практика. Общий алгоритм получения знаний по той или