Разбор статьи РБК: почему пользователи влияют на проект сильнее, чем кажется

Это разбор статьи РБК о коммуникациях и заинтересованных сторонах в проекте внедрения. Исходный материал: публикация на РБК.

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

Именно в этом противоречии обычно и лежит проблема внедрения.

Что видно из описанной ситуации

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

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

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

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

Почему линейные сотрудники не являются второстепенными участниками

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

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

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

Ошибка в отношении к обратной связи

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

Управление проектом не должно превращаться в спор с пользователями. Оно должно переводить замечания в факты, решения и изменения плана.

Про роль руководителя проекта

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

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

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

RACI и недостающая роль поддержки

В статье упоминается матрица RACI. Это полезная базовая модель распределения ответственности: кто выполняет, кто отвечает за результат, с кем консультируются и кого информируют.

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

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

Подробнее о распределении ролей см. в статье про RACIS.

Что должно быть сделано до приемки

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

Вывод

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

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

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

Если проект зависит от поведения пользователей

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