Объединенный интранет группы компаний «М.Видео-Эльдорадо» завоевал главный приз Russian Intranet Awards в 2020 году и серебро Intranet and Digital Workplace Awards. Этот внутренний продукт был разработан с нуля за шесть месяцев. То, что это удалось сделать в такие сроки и уровнем ценности, признанным внутри компании и за её пределами – результат применения продуктового подхода и гибких практик. Рассказываем, почему они были выбраны и какие элементы этой методики стали ключевыми.

Предыстория

В 2018 году произошло слияние компаний «М.Видео» и «Эльдорадо», которые к тому моменту были крупнейшими ритейлерами всего спектра электроники и бытовой техники в России. В объединенной компании трудятся около 30 тыс. человек. В ней – более тысячи магазинов, которые работают более чем в 200 городах России.

Для того, чтобы создать единую компанию, требуется масса усилий. «М.Видео» и «Эльдорадо» долгие годы самостоятельно формировали свои корпоративные культуры, и они совсем не были похожи друг на друга. И теперь для почти 30 тысяч сотрудников необходимо было транслировать не только уникальную стратегию для каждого бренда, но и единое видение группы компаний.

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

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

Зачем группе «М.Видео-Эльдорадо» нужен объединенный интранет

В принципе, ответ на этот вопрос очевиден. Цель интранета – максимально задействовать человеческий потенциал компании. Чтобы работать с максимальной отдачей и получать от своего труда не только зарплату, но и удовлетворение, нужно знать, чем живет компания, как развивается ее бизнес, какие ценности она исповедует, иметь возможность найти перспективы для себя и команды. И все это можно получить в интранете.

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

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

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

Постановка задачи

До объединения в каждой компании использовалась своя интранет-платформа. Это были SAP FIORI и SharePoint. Каждая из них – хороший инструмент, они позволяют агрегировать и визуализировать информацию, размещать сервисы. Но ни та, ни другая платформы нас не устраивали с точки зрения масштабируемости затрат на поддержку.

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

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

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

Важно: мы не пытались «продать» идею или продукт и как можно меньше говорили об интранете. В таких случаях коллеги могут быть необъективны и давать социально-ожидаемые ответы.

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

Вторым этапом подготовки была «продажа» идеи руководству. То, что интранеты «М.Видео» и «Эльдорадо» необходимо объединять, прекрасно понимали топ-менеджеры компании – ключевые заказчики и спонсоры проекта. Собственно говоря, инициатива, запрос на инновацию, исходил именно от них. Но то, что проект затрагивал все стороны жизни компании и все структурные единицы, накладывало свой отпечаток.

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

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

Продуктовый подход

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

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

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

Основные документы

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

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

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

Scrum

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

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

Одним из способом работать с неопределенностью в таких случаях было сочетание agile-подхода и фреймворка Scrum.

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

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

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

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

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



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

Если вы только идете в этот фреймворк — запаситесь терпением, постарайтесь обеспечить команду балансом где 1 FTE опытного сотрудника «обслуживает» или менторит 1 или лучше 0,5 FTE джуна/миддла и найдите грамотного скрам-мастера с техническим бэкграундом. Погрузиться в детали нашего опыта можно тут: часть 1, часть 2, часть 3.

И, тем не менее, Scrum позволяет сформировать реальную картину происходящего и вовремя внести необходимые коррективы.



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

Что дальше?

Сегодня наш проект и команда продолжает развиваться. Мы наметили переход на LeSS фреймворк, получили кратный рост метрик и сейчас переходим в парадигму внутрикорпоративного SuperApp.

P.S. На данном этапе нам очень нужны талантливые программисты. Если вы такой, приходите, будет интересно.