Продуктовый метод и гибкие подходы в разработке интранета

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

После интеграции М.Видео и Эльдорадо объединённая компания реализует стратегию One Retail. Наш главный приоритет — улучшение покупательского опыта в любой точке контакта с компанией. Мы хотим, чтобы наши покупатели получали максимум пользы на всем пути взаимодействия с М.Видео и Эльдорадо. Причём в любом направлении: как в покупке, так и в возврате товара.

Главная страница интранета М.Видео-Эльдорадо

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

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

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

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

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

Как выбрать фреймворк для реализации продуктового подхода

Перед тем, как считать NPV (чистую приведенную стоимость) и IRR (внутреннюю норму доходности), защищать бюджет и готовить бизнес-кейс, нужно понять, какой продукт будет приносить максимальную ценность для компании.

RAT — тестирование наиболее рискованных гипотез

Например, в некоторых случаях нужен не интранет, а другое решение. Поэтому, независимо от выбранных вами методов, лучше начать с RAT (тестирования наиболее рискованных гипотез) или MVP (минимально жизнеспособный продукт) и дальше принимать решение о создании продукта. Только после оценки следует выбирать фреймворк, который лучше всего подойдет именно вам: PMBok, PRINCE2, SCRUM, Kanban-метод или что-то другое.

1. RAT — Riskiest Assumption Tests — Тестирование предполагаемых рисков/ тестирование предположений
2. MVP — Minimum Viable Product — Минимально жизнеспособный продукт

При выборе фреймворка лучше отталкиваться от того, что именно и в каких условиях вы хотите сделать. При глубоком понимании будущего продукта, наличии на рынке подходящих коробочных решений, которые не потребуется кардинально изменять, или работе в среде с высокой степенью определенности прекрасно подходят «водопадные методы» реализации проектов (семейство PMBok). У нас был нестандартный бизнес-контекст, высокая сложность окружения (недавняя интеграция), цифровизация процессов нетипичных для интранета (постановка массовых задач) и много неизвестного, поэтому мы выбрали философию Аджайл и фреймворк Скрам. Нам кажется, это один из лучших способов достижения целей в таких условиях.

Почему Скрам стал основным фреймворком

Будет правильно, если я признаюсь перед читателями в том, что Скрам был выбран как способ спасения от неопределенности. В первую очередь это касалось объемов работ, которые наша внутренняя команда просто физически не могла охватить даже на этапе концептуального проектирования. Конечно, может показаться, что интранет достаточно простая система, которую можно спроектировать от А до Я, нарисовать красивые диаграммы ганта и запустить через 6-12 месяцев в продуктив.

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

Далее за всем этим стоит архитектурный ландшафт компании, комплексная среда интеграций с другими системами.

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

Все это должно было быть реализовано в адаптивном и высокопроизводительном коробочном решении или в недрах самостоятельной разработки. Еще до выбора решения, когда мы только начинали, Скрам показался нам «серебряной пулей». Мы многое не знали о процессе и философии, и отчасти это был прыжок веры, который с последствиями и синяками все же оправдал себя.

В чём преимущества Скрама

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

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

Как именно работает Скрам

Скрам позволяет получать готовый к использованию фрагмент программного обеспечения сроком от 1 до 4 недель. Это значит, что вы сможете быстрее чем обычно получать обратную связь от пользователей и заказчиков и, соответственно, сразу решать проблемы и точнее угадывать реальные потребности бизнеса, получая наилучший Market-Fit продукта.
Функционал модуля обратной связи

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

Модуль обратной связи

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

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

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

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

Насколько оправдано запускать Скрам впервые при создании интранета

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

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

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

Интранет — это идеальное место для начала аджайловой трансформации, когда важно менять не только методы, но и культуру

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

Какие минусы у Скрама и продуктового подхода к разработке

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

Если и можно назвать это минусом, то выбранный нами фреймворк Скрам, особенно если он запускается впервые, требует крайне высокой квалификации, дисциплины, смелости и терпения для команды, руководства и стейкхолдеров (заинтересованных в проекте людей). То же самое можно сказать про водопадную модель, однако уровень концентрации на результате, уровень стресса и ответственности в Скраме для нас оказался значительно выше, чем в «водопаде».

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

Сейчас мы провели работу над ошибками, дали друг другу честную обратную связь и получили максимальную прозрачность ресурсного управления, оптимальную производительность и возможность давать больше ценности в единицу времени. Ретроспективно могу сказать, что самое губительное для подобных экспериментов — это попытка объединить водопадные и гибкие методы. Если будете повторять, уделите особое внимание составлению договора в формате «time and material» и убедитесь, что все участники процесса действительно разделяют ценности подхода.

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

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

Мне кажется, все издержки, которые несет философия Аджайл и фреймворк Скрам, с лихвой перекрываются их преимуществами.

Рекомендую начать изучение Скрама с трёх книг:

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

Ежедневный стендап продуктовой команды М.Видео-Эльдорадо

В каких компаниях продуктовый метод и гибкие подходы не сработают

Продуктовый метод существует очень давно, в общепринятом понимании как задокументированный факт он сформировался в компании Procter & Gamble в 30-х годах. Уверен, что какие-нибудь древние ремесленники и торговцы Рима или Вавилона также исповедовали основные принципы данного метода :) Метод достаточно универсален и может применяться в любой области коммерческой деятельности.

Если говорить о гибких подходах к созданию продукта, тут вопрос дискуссионный. Например, в медицине и областях с высокой степенью риска Аджайл может быть применим ограниченно. Однако научно-исследовательские и опытно-конструкторские работы (R&D), которых в доказательной медицине и медицине высоких технологий достаточно много, — чистой воды Аджайл. Скрам как метод основан на постоянной проверке идей через практику, он по духу близок научному методу, что очень важно, если мы хотим создавать действительно полезный продукт.

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

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

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

Погружение в мир Аджайл рекомендую начать с прослушивания замечательного подкаста «Серебряная чпуля» и изучения страницы agilebasics.

Советы начинающим продуктовым менеджерам интранета

1. Быть открытым к изменениям
2. Не бояться ошибок: открыто обсуждать их и делать выводы
3. Постоянно учиться и сразу применять полученные знания на практике.
4. Управлять приоритетами и заинтересованными сторонами
5. Искать финансовые и нефинансовые выгоды от внедрения и развития вашего решения
6. Развивать дипломатические и переговорные способности.
7. Регулярно задавать вопросы себе и команде:
   Каким образом наш продукт делает компанию успешной?
   Какие метрики у продукта ключевые?
8. Кто ключевая целевая аудитория и чем она живет?
   Что мы можем улучшить в следующей итерации?
9. Ставить шкуру на кон без летальных исходов для себя и команды (об этом в книге Николаса Талеба «Рискуя собственной шкурой»).
10. Запастись терпением

Вам также может быть интересно: 

— Как за полгода запустить первую версию обновленного интранета
— Как повысить эффективность интранета
— Как сделать интранет для международной организации? Кейс ЮНИСЕФ