Почему продуктовый подход не работает?

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

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

Почему такое может происходить? Давайте попробуем разобраться, посмотрев на сам переходный процесс между проектным и продуктовым подходами к управлению ИТ-разработкой.

Как работает проектный подход?

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

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

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

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

Когда управление проектами меняется на продуктовый подход?

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

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

А что это означает для людей?

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

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

Почему группа людей ещё не команда?

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

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

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

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

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

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

Как сделать команду командой?

Чтобы группа людей преобразовалась в команду, прежде всего надо дать ясную цель. Понятно, что команда объединяется вокруг развития продукта. Но это не всегда прозрачный процесс для ИТ-разработчиков, а следовательно цель становится непонятной. Там, где бизнес чётко видит предназначение существования ИТ-продукта и горизонт его развития, люди, обслуживающие процесс создания новых возможностей для этого продукта, работают практически вслепую.

Поэтому необходимо учитывать, что при переходе к продуктовому подходу расширяется роль бизнеса и степень его соучастия в процессах ИТ-разработки. Бизнес может и должен придать чёткость цели команды, максимально разъяснить значимость отдельных задач в работе и потока требований в целом. Сделать для разработчиков ясным внешний мир и те изменения, которые они в нем создают.

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

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

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

Нужен ли команде тренер?

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

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

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

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

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

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

Еще больше статей на:

#it#itil#devops#cleverics#itmanagment#ит