С чего всё начиналось в Технической Вселенной

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

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

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

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

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

Взгляд из Бизнес-галактики

[Продакт]: Вы когда-нибудь слышали, как тихо скрипит интерфейс? Нет, это не звук перегруженного сервера и не баг в JavaScript. Это звук человеческого разочарования. Именно его я услышала, когда начала разбираться, как в нашей большой компании создается и живет контент.

Диагноз: цифровой хаос на уровне ДНК.

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

Наши контент-менеджеры – тоже герои. От руководителя департамента до специалиста – каждый из них ежедневно несет знания тысячам сотрудников. Но их оружие было сломано. У них не было навыков вёрстки, а идея «добавить немного HTML» вызывала лёгкую панику. Результат был предсказуем:

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

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

• Документный черный ящик. Загруженный PDF-файл с загадочным названием Отчет_Финальный_Новый_2.pdf – это не контент, а ребус для сотрудника.

Мы стали «входным окном» для всех бед. К нам летели все жалобы – от неработающих форм за пределами нашей зоны ответственности до вопросов по смыслу контента, к которому мы не имели никакого отношения.

Команда Интранета превратилась в службу поддержки для системы, которой не существовало.

От скрипа к карте: как мы переводили боли в требования

Мы могли бы пойти классическим путём: собрать хотелки стейкхолдеров, набросать ТЗ и отдать разработке. Но мы поступили иначе. Мы пошли исследовать.

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

Затем мы сделали Lean Canvas. 

Это стало переломным моментом. Мы перестали думать в парадигме «какие фичи сделать» и начали думать «какую работу должна выполнить наша система для пользователя?».

Пример:

Боль: «Я потратил полдня, пытаясь сделать красивую страницу в стороннем конструкторе, а она всё равно смотрится вне бренда».

«Работа» (Job-To-Be-Done): «Создать визуально согласованную и профессиональную страницу без привлечения разработчика и дизайнера».

Решение в Canvas: универсальный конструктор страниц с набором предзаданных, brand-compliant блоков.

Итогом этой работы стал не просто список функций, а УЦП (Уникальное ценностное предложение) будущей CMS, сформулированное на языке выгоды:

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

Это стало нашей главной продуктовой мантрой. Всё, что мы делали дальше, мы проверяли на соответствие этому утверждению.

От мантры к бэклогу: формирование первого пула возможностей.

С чётким УЦП и картой «работ» на руках мы сформировали первый бэклог. Он не был случайным набором фич. Это был прямой ответ на реальные боли:

Конструктор страниц (Core): ответ на визуальный раздрай и сложность вёрстки. Фича закрывает «работу» по созданию страниц без технических навыков.

Новости и управление баннерами: ответ на фрагментацию информации. Закрывает «работу» по централизованному управлению важнейшим контентом.

Опросы (поп-апы): ответ на необходимость быстрого сбора фидбека. Закрывает «работу» по интерактивному взаимодействию с аудиторией без разработки.

Управление меню: ответ на проблемы навигации и нахождения информации. Закрывает «работу» по поддержанию логичной и понятной структуры.

Обучение и карьера: ответ на «документный чёрный ящик». Закрывает «работу» по структурированному представлению сложной информации (курсов, вакансий) в едином формате.

Обратите внимание: мы изначально не планировали делать «крутой редактор». Мы планировали дать инструмент для решения конкретных бизнес-задач.

Эволюция: как продукт рос вместе с доверием пользователей

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

Онбординг: мы заметили, что пользователи не замечают новые фичи. Раньше это требовало правок кода. Теперь мы просто добавили в админку модуль интерактивных подсказок и турников. Продукт вырос из потребности в коммуникации.

Праздничные подложки: раньше это было болью для разработчиков («Владимир, срочно нужно залить снежинки на главную!»). Мы сделали инструмент, чтобы управлять этим самостоятельно в пару кликов. Продукт вырос из потребности в оперативности.

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

Кто команда? Все!

Разработка: наши герои, которые говорили с нами на языке возможностей, а не ограничений.

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

Потребители: все сотрудники компании. Их молчаливое одобрение и рост просмотров страниц – главный KPI нашего продукта.

Happy End