Chief Product Officer и бэклог: зачем это бизнесу? Особенности ведения ИТ-бизнеса на современном рынке 

Сегодня же поговорим о совсем другой теме — СРО и его роли в компании. Кроме того, обсудим формирование бэклога и связи этой задачи с обязанностями СРО. Что же, если вам близка эта тема, поехали!

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

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

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

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

Пример. Во время своей работы я столкнулся с подобной ситуацией. Она была достаточно простой - разработчики решили добавить новую возможность в банковское приложение. А именно - при сканировании QR-кода должен был включаться фонарик. С точки зрения разработки - круто и интересно. С точки зрения бизнеса - смысла в реализации этой функции нет, даже в плане привлечения внимания пользователей. В большинстве случаев им это все не нужно, пользователю важно, чтобы приложение работало и делало то, что ему положено. И это все.

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

Здесь стоит отметить, что создание и развитие продукта (а также его продажа, само собой) - многозадачный процесс, в котором принимает участие большое количество разных лидеров и экспертов. А СРО - один из членов команды, роль которого - направлять экспертизу других лидеров в нужное русло, оптимальное для реализации бизнес-процессов.

Роль СРО также предполагает весьма тесное сотрудничество с другими членами команды руководителей, включая директора по маркетингу (СМО) и директора по работе с клиентами (ССО).

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

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

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

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

Для бизнеса крайне полезно проводить внутренний анализ метрик, включая приложения, сайт, платформы. Также обязательно нужно проводить А/Б тесты и CUSTDEV-исследования для разных групп клиентов. Еще много информации дает построение CJM и его анализ на "болевые точки". Не забывайте и о регулярных замерах NPS и CSI - в этом случае можно сформировать более полную картину востребованности продукта.

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

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

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

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

Ошибки при ведении бэклога:

Пример. Здесь можно привести кейс японской компании Shikumi Design. В течение нескольких лет задачи решались командой, если так можно выразиться, вразнобой - не все члены коллектива знали точный дедлайн. Приоритет выставлялся задачам "по интуиции" тимлида, причем выполнение тасков отслеживалось "вручную", без задействования средств автоматизации.

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

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

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

Здесь всё кажется достаточно тривиальным - проставляй значение приоритета для задач от 1 до N, выбрав что считать самым приоритетным 1 или N, но гораздо больший профит за единицу времени, потраченного на задачу можно получить, если рассматривать задачи сквозь два измерения - простоту реализации и эффект от внедрения (aka Easy and Impact или Impact Effort Matrix).

Добавив для каждой из задач два параметра:

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

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

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

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