Как правильно применять продуктовый подход в управлении изменениями
Сейчас компаниям нужно меняться, как никогда, быстро. Однако традиционный проектный подход к управлению изменениями этого добиться не позволяет. Почему? Сначала участники процесса тратят массу времени и сил на написание детального технического задания (ТЗ). Проектный менеджер обычно владеет предметом не настолько глубоко, чтобы с легкостью разрешать проблемы, и превращается в жандарма, который всех контролирует и нервирует. В команду входят сотрудники других отделов, которые загружены работой и с трудом выкраивают время на подготовку ТЗ. В конце концов выясняется, что в ТЗ всего предусмотреть не удалось, нужно корректировать. Все участники используют этот момент, чтобы обнулить отсчет сроков. Поэтому проекты длятся месяцы и годы, не давая ожидаемого эффекта.
Альтернативный продуктовый подход быстрее и эффективнее. Его суть в том, что каждый проект рассматривается как самостоятельный бизнес по выпуску продукта со своими экономическими и финансовыми целями. Управляет продуктом его владелец, на котором лежит полная ответственность за финансовый эффект. Под продукт выделяется отдельная, независимая от остального персонала и освобожденная от других обязанностей команда. Разработка детального ТЗ становится неактуальной, она уступает место гибкому планированию задач короткими сессиями (спринтами) по 2–3 недели.
Однако многие компании при попытках внедрения продуктового подхода наталкиваются на трудности и не получают ожидаемого ускорения, потому что упускают ряд важных нюансов. Какие условия обязательны для того, чтобы продуктовый подход дал результаты?
1. Компетентный владелец продукта. Владелец продукта (product owner) – принципиально новая специальность, которая не может быть быстро выращена на старых кадрах. От такого сотрудника требуется мыслить конечным эффектом и готовность взять на себя полную ответственность за успех продукта. В промышленной компании во главе нового продукта по созданию модуля предсказания поломок на линии поставили вчерашнего проектного менеджера. Этот менеджер, годами выполнявший роль координатора и исполнителя, не был способен быстро поменять менталитет, что закономерно привело к провалу. Нужно либо нанимать новых людей, либо проводить комплексную переподготовку сотрудников для развития у них нужных навыков.
2. Полная занятость сотрудников. Продуктовая команда должна быть обеспечена всеми необходимыми ресурсами (людьми, технологиями и т. д.) для получения результата. Крупная компания, занимающаяся электронной коммерцией, использовала продуктовый подход для разработки алгоритма персонализации предложений на веб-сайте. Но руководители не освободили членов команды от части прежних обязанностей. Им приходилось переключаться между задачами, пострадали и скорость, и качество разработки.
3. Фокус на конечном эффекте. При продуктовом подходе главное – финансовые результаты, а пути их достижения команда выбирает сама. Тогда как при традиционном проектном управлении во главу угла ставится связка «задача – выполнение плана». Чтобы вбить эту новую реальность в головы менеджеров, руководителям надо действовать жестко. В крупной европейской торговой сети электроники и бытовой техники руководство, долго не получая эффекта от оптимизации продаж, приняло решение просто распустить продуктовую команду, перенаправив инвестиции на другие продукты. Это послужило уроком для остальных продуктовых команд.
4. Фокус на конечном пользователе. Конкурентный бизнес вращается вокруг клиента, такая же философия в продуктовом подходе. В крупном банке работу над моделью скоринга клиентских рисков продуктовая команда сразу построила вокруг конечного пользователя – отдела продаж, выдающего кредиты в отделениях банка. Сотрудники отдела продаж сразу были включены в команду. Вовлеченность конечных пользователей позволила не сбиться с дороги во время разработки продукта.
5. Реформы в остальных подразделениях компании. Для успешного запуска продуктов недостаточно, чтобы сама продуктовая команда работала по-новому. Необходимо постепенно модернизировать набор технологий, применяемых компанией, а также ключевые поддерживающие процессы (выделение инвестиций, наем сотрудников и т. д.). Иначе все попытки масштабировать успешные прототипы будут тормозиться из-за архаичной IT-архитектуры и бюрократии. С такой проблемой столкнулся крупный производитель одежды. Новая модель прогнозирования спроса на базе искусственного интеллекта прекрасно работала на тестовой выборке логистических центров, однако, когда началось тиражирование, компании пришлось много месяцев потратить на интеграцию разнородных информационных систем.-
Добавить комментарий
Для отправки комментария вам необходимо авторизоваться.