Всем привет! Меня зовут Валерия Балтабаева, я выполняю роль руководителя проектов в ГК КОРУС Консалтинг.
Более 15 лет наша команда – Департамент корпоративных сервисов – занимается проектами автоматизации HR процессов, в частности разработкой корпоративных порталов. За нашими плечами сложные крупные проекты в таких компаниях как ПГК, Банк Санкт-Петербург, Газпром, РЖД и другие. Несколько лет назад, собрав весь наш многолетний опыт в области HR tech в более чем 100 крупных компаниях, мы создали продукт K-team HRM – готовое решение, которое создает единое инфопространство в компании и охватывает все этапы взаимодействия с персоналом: от приема на работу и адаптации до мотивации и управления талантами. Продукт быстро стал популярным и вошел в топ HRM-систем, обеспечив нашей команде поток проектов.
Казалось бы, одни плюсы, но в чем подвох?
Вызовы типовых проектов
Дело в том, что команда высококвалифицированных специалистов, которая участвовала в больших проектах внедрения и накапливала экспертизу годами, теперь вынуждена перестроиться под текущий тренд на рынке – Заказчикам нужны короткие проекты и готовая функциональность с минимальной кастомизацияей. Это означает что задачи становятся похожи друг на друга, проекты становятся короче, сотрудники начинают скучать, выгорать, не имея возможности реализовать весь свой креативный потенциал. При этом внедрение «коробочного» решения — лишь первый этап долгосрочного сотрудничества с Заказчиком, который осознанно выбирает концепцию MVP, планирует развитие системы и получает быструю победу, а также реальную обратную связь от сотрудников, работающих с системой. В моей практике много таких кейсов, поэтому я уверена, что от команды базового внедрения зависит в том числе продолжение сотрудничества с Клиентом.
Моя твердая позиция, даже идеология: нельзя обеспечить качественный результат для Заказчика, если у команды нет внутренних ресурсов. Невозможно сделать других счастливыми, если сам несчастен.
Поэтому передо мной, как Руководителем Проекта (Далее РП), встает вопрос – как помочь команде быть вовлеченными в работу и по-настоящему хотеть получить результат даже на типовых проектах с низкой неопределённостью, без очевидного вызова.
Рынок стандартизации: данные исследований
Исследования подтверждают — рынок движется к стандартизации:
72% компаний уже используют типовые решения для оптимизации расходов,
в IT-индустрии доля шаблонных проектов за три года увеличилась с 45% до 68% (McKinsey, 2023),
68% компаний выбирают типовые решения для ускорения выхода на рынок (Forrester, 2022),
Рынок low-code платформ вырастет на 28% к 2025 г. (Gartner, 2024),
65% новых бизнес-приложений будут создаваться на базе типовых решений (против 35% в 2020). (Gartner, 2024),
Согласно исследованию Deloitte (2023) автоматизация рутинных процессов экономит до 30% бюджета проектов.
Личный опыт: от сложных проектов к базовым внедрениям
Что же делать?
После одного большого и очень нервного проекта меня переключили на типовое внедрение – технология обкатана, задачи понятны, за короткий срок и фиксированную стоимость Заказчик получает готовую HR-систему, интегрированную с 1С ЗУП и Active Directory. В это же время от коллег внутри команды я начала слышать первые звоночки, что работать на подобных проектах нравится далеко не всем – но что делать, не всегда возможно предложить альтернативу.
Я собрала обратную связь от команды и других РП в нашей компании (у нас есть свой Клуб РП), и поняла, что корень проблемы чаще всего лежит в коммуникациях и соблюдении гигиенических правил в организации работы команды. И вот такие правила я сформулировала для себя и предлагаю вам попробовать их приложить на своих проектах.
Бонусный фонд и прозрачность:
Я поняла, как важно в начале проекта обсудить с руководителем\куратором бонусный фонд, если он предусмотрен, и сразу донести информацию до команды. Критерии выполнения проекта должны быть понятны, чтобы каждый понимал, что он должен делать, чтобы получить премию.
Могу привести пример. Уже на этапе реализации проекта я провела небольшой опрос и поняла, что команда демотивирована тем, что не понимает, как и за что они получат бонусы. На ближайшем статусе я рассказала о правилах, и на этой же неделе почувствовала, как изменилось отношение ребят к задачам – они стали более внимательными и заинтересованными.
Вовлечение РП
Я начала относиться к подобным проектам как к полноценному внедрению, требовать от себя соответствующего вовлечения. Даже если у вас 2 часа в день на проект, не игнорируйте это. Если вы будете подключаться только в начале и в конце этапа – есть опасность, что вы пропустите напряженную ситуацию, которая однажды превратится в «сыгравший риск». Лучше не допускать пожаров, чем тушить их.
Мои правила коммуникации внутри команды:
В коммуникациях должна участвовать вся команда – не оставлять вне контекста разработчиков, технических специалистов, тех, кто работает удаленно — это важно.
Установочная встреча с командой – рассказывать, кто наш Заказчик, в чем его потребность и боли, что отличает его от других клиентов. Познакомьте всю команду с деталями проекта, расскажите предысторию взаимодействия. Это позволит «очеловечить» проект, чтобы он не был «одним из многих» + людям важно знать и понимать, что их работа важна, а установочные встречи помогают сформировать это понимание.
Регулярные статусы команды, дейли – несмотря на то, что задачи понятны. Дейли – это не только про план на день. Пять минут каждое утро – проводите их так, чтобы участники заряжались позитивом на день. Смол-токи, обсуждение новостей, мемы, маленькие традиции – все это работает и на типовых проектах и позволяет делать из сотрудников команду.
Регулярно организовывать общение вашей команды с командой Заказчика, например, подключать сотрудников на встречи по контрольным точкам/финализации этапа. Очень важно, чтобы вся ваша команда видела, что то, что для них является очередной понятной и не самой интересной задачей, несет большую ценность для Заказчика, как это помогает решать задачи, как старается (если старается) команда Заказчика для того, чтобы проект был успешен.
Информированность команды:
Я рассказываю команде о новых решениях на проекте, изменениях в команде заказчика, изменениях целей со стороны Заказчика (если такое случится), о планах на развитие. Не помещать команду в информационный вакуум – это главное. Очень часто невовремя донесенная до команды информация об изменениях приводит к неправильным проектным решениям и переделкам.
Если проект имеет потенциал масштабирования – подчеркиваю это в коммуникации. Зачастую типовой проект – это только начало, MVP, быстрая победа, после которой будет развитие с более интересными задачами. Если формируется бэклог проекта, сделайте доступ к нему для всех участников команды (ваш кэп).
Систематически запрашиваю обратную связь – это помогает выявлять потребности и точки роста, чего не хватает сотрудникам, чем помочь. Я провожу подобные опросы тет-а-тет на встречах по обсуждению задач, «заодно».
Поддержка мотивации:
Отмечать успехи команды – скорость закрытия задач, соответствие плану или опережение, благодарить сотрудников за вовлечение (хорошо проведенные встречи, оперативная коммуникация и т.д). Транслировать успехи на уровень департамента, пусть сотрудники видят, что их простой проект – это тоже повод для гордости.
Я отправляю благодарности сотрудникам на нашем Корпоративном портале и пишу о успехах в общий чат.
Ротация и развитие:
Можно инициировать ротацию сотрудников между проектами. Стандартные задачи позволяют команде восстановить ресурс после сложных внедрений: результат достигается быстро, требования прозрачны, а коммуникации минимизированы. Кроме того, такие проекты — отличный способ тестировать обновления продукта в реальных условиях, сохраняя экспертизу актуальной.
Рекомендую включать на подобные проекты новых сотрудников – это хороший способ быстро влиться в работу, познакомиться с методологией, пройдя через все этапы внедрения, прокачать навык бизнес-анализа и коммуникации с Заказчиком.
Полезно обсудить с руководителями планы на развитие сотрудников в вашей команде и грядущие проекты. Это поможет каждому участнику команды четко понимать сроки и границы своего участия в типовом проекте. Это полезно для всех, а не только для тех, кто выгорел.
Пробую внедрять практику «А что мы можем сделать иначе?». На таких проектах можно заняться поисками челленджа даже для типовых задач: новая технология, инструмент, использование обновлений продукта, новой фичи.
Мы с командами часто предлагаем улучшения для продукта, которые находим именно на типовых проектах, в том числе на основе обратной связи от Заказчика – это дает дополнительную ценность нашим задачам и развивает продукт.
Итоги
Конечно, РП не всесилен, и наш ресурс тоже конечен (тут я писала о том, как можно работать с выгоранием). Мы не всегда можем повлиять на объем проекта в самом его начале, но мы можем помочь сотрудникам чувствовать себя частью команды, которая делает действительно важное дело – помогает бизнесу достигать новых результатов, минимизируя затраты.
Задача руководителя проекта на типовом проекте – показать ценность такого проекта для каждого его участника. Это не «скучный проект», а полезный: личное развитие, работа в команде, результат для заказчика. Работа на таком проекте – это возможность для человека поработать в спокойном режиме, изучить себя и решить, что он хочет делать дальше.
Делитесь советами в комментариях, буду рада обменяться опытом!