Портал №1 по управлению цифровыми
и информационными технологиями

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Учебные курсы и сертификация
специалистов по ИТ-менеджменту

Добавить комментарий

Ваш адрес email не будет опубликован. Обязательные поля помечены *

  • Рубрики

  •  
  • Авторы

  •  
  • Самое свежее

    • VI форум «Управление данными — 2021»: наведите порядок в данных!
      23 сентября 2021 года издательство «Открытые системы» в шестой раз проведет в Москве масштабный форум «Управление данными — 2021», объединяющий всех, кто определяет стратегию работы с данными, воплощает ее в жизнь и управляет предприятием на основе объективных достоверных данных. Участники форума обсудят не только инновационные стратегии и бизнес-модели работы с корпоративными данными, но и конкретные архитектурные и технологические решения.
    • Простые уловки, как ускорить процесс разработки программного обеспечения
      С некоторыми вещами люди из бизнеса вынуждены соглашаться, и одна из них заключается в том, что никто не хочет сердить свою команду разработчиков. Часто они являются краеугольным
    • Почему каждая инициатива DevOps должна начинаться с оценки возможностей
      Внедрение практики DevOps идет полным ходом. Организации сосредоточены на том, как внедрить возможности DevOps в командах и как масштабировать DevOps в масштабах предприятия. Но важным аспектом любого пути масштабной трансформации является оценка возможностей команды или организации на этом пути.
    • Что такое процесс и что такое практика в ITIL®4
      Продолжаем публиковать короткие видеоролики, посвященные актуальным вопросам управления ИТ. Сегодня поговорим о том, что такое процесс и что такое практика в ITIL4. Это не переименование процессов в практики, это два отдельных понятия. Рассказывает Игорь Фадеев, ITIL 4 Managing Professional и ITIL 4 Strategic Leader, аккредитованный тренер по ITIL4.
    • Аудит. Что может быть скучнее?!
      На прошедшей неделе участвовал в аудите (в качестве объекта аудита). Большинство людей, проходивших аудит, подозреваю, разделяет это ощущение: «Бюрократия, формальности и т.п.»
    • Как технический долг вредит вашей команде программистов — и вашей безопасности приложений
      Техническая долг может серьезно повлиять на здоровье организации - и на психическое здоровье ваших разработчиков. Более половины из 200+ членов инженерных команд, опрошенных в рамках отчета Stepsize "Состояние технического долга в 2021 году", считают, что технический долг негативно влияет на моральное состояние их команд.
    • Что люди не понимают в управлении потоком создания стоимости
      Нет ничего плохого в самом управлении потоками создания ценности (VSM), но есть много плохого в том, как его рассматривают и обсуждают блогеры, отраслевые маркетологи и другие, которые часто смешивают его с DevOps и Agile. Это не одно и то же.
    • 5 основных тенденций развития искусственного интеллекта и машинного обучения на 2022 год
      Вот несколько основных тенденций, к которым вашему бизнесу стоит начать готовиться. Искусственный интеллект и машинное обучение становятся доминирующей частью технологической
    • 6 тенденций в ИТ, за которыми нужно следить
      Чтобы выжить во время пандемии, организации обратились к ИТ, чтобы помочь справиться с последствиями - как негативными, так и позитивными. В некоторых отраслях, таких как телемедицина и видеоконференции, бизнес резко вырос, и ИТ-отделам таких компаний пришлось в спешке справляться с нагрузкой. В других, например, в сфере путешествий и развлечений, бизнес резко просел. Кроме того, возобновилось стремление к цифровой трансформации.
    • Восход Desktop-as-a-Service: что это такое и зачем вам это нужно?
      Широкое распространение облачных вычислений добавило в наш словарь множество сокращений, наиболее распространенными из которых являются SaaS, PaaS и IaaS. Действительно, наступила эра облачных решений, которые доставляют программное обеспечение, платформу и инфраструктуру потребителям и предприятиям по запросу и с оплатой по мере использования.
  •  
  • Вход

  • DevOps
    Kanban
    ITSM
    ITIL
    PRINCE2
    Agile
    Lean
    TOGAF
    COBIT