Привет, Хабр! Меня зовут Вика, я HR‑менеджер компании «Синимекс». Вместе с командой мы развиваем ИТ‑бренд: помогаем инженерам выступать на конференциях, писать статьи и делиться кейсами.
Я хочу рассказать историю о том, как мы в «Синимекс» попытались «автоматизировать хаос» в DevRel‑процессах и что из этого получилось. Возможно, наш опыт поможет кому‑то сэкономить время и ресурсы.
Мы в «Синимекс» три года развивали техбренд. Инженеры выступали на конференциях, писали статьи. Всю информацию мы оформляли в обычных таблицах (рис. 1).
Количество мероприятий, спикеров и материалов росло, а вместе с ним росло количество таблиц. В какой‑то момент данные о мероприятиях, спикерах и материалах оказались разбросаны по десяткам таблиц, облачным папкам, локальным ПК, календарям и старым чатам.
Да и сами таблицы оказались не самым удобным решением.
В разных таблицах один человек мог иметь разный статус.
Чтобы узнать, кто выступал год назад, нужно было искать «ручками».
Сроки и ссылки по каждому мероприятию приходилось обновлять в нескольких местах вручную.
Из таблиц не было понятно, что делать дальше, с какими материалами и так далее
Чтобы привести в порядок этот хаос, мы могли купить готовую CRM. Но подходящей не нашлось: все требовали кастомизации или дополнительной работы. Можно было сделать базу на Wiki, но тогда мы не решили бы задачу с подачей заявок и уведомлениями. Да и визуализация календаря уступает специализированному интерфейсу.
Поэтому мы выбрали продуктовый подход. Мы решили не просто автоматизировать таблицы, а проверить гипотезу: можно ли связать сущности в единый жизненный цикл?
Мероприятие → заявка → подготовка → выступление → материал → публикация → история эксперта.
Итак, мы собрали команду и разработали SPA (Speaker Platform Automation).
В SPA появились (рис. 2):
календарь мероприятий (от таблиц в этом контуре отказались),
карточки участников с историей выступлений,
библиотека материалов с комментариями,
формы для самостоятельных заявок сотрудников,
уведомления о дедлайнах и даже геймификация с корпоративной валютой.
Мы за год дошли от требований до продакшена. Мы настроили выгрузку сессий, провели демо, сделали анонсы в корпоративных каналах, продвигали систему в комьюнити спикеров. Молодцы? Молодцы!
Но мы столкнулись с тем, что система была удобной HR‑у, который ведет процесс, а конечному пользователю (инженеру), который может выступать редко, она особо и не нужна. Ему проще написать HR‑у в мессенджер, как и раньше.
Со временем многое изменилось. Мы отказались от партнерства на конференциях, часть активных спикеров ушла из компании, мы стали искать лидов через конференции с бизнес‑аудиторией. А вот привычки сотрудников практически не изменились. Да и процесс оказался недостаточно масштабным, чтобы поддерживать отдельный продукт в новых условиях.
Мы приняли решение не масштабировать SPA, хотя HR использует ее для администрирования, наполнения библиотеки и ведения календаря мероприятий.
Можно только порадоваться, что MVP позволил валидировать гипотезу до того, как мы потратили ресурсы на масштабирование инструмента, который оказался неактуален.
Теперь, прежде чем писать любой внутренний инструмент, мы задаем себе 5 вопросов:
Как часто возникает сценарий? Оцениваем не количество функций, а частоту их использования.
Кто регулярный пользователь? Это должен быть не только владелец процесса (HR), но и конечные сотрудники.
Что пользователь получает лично? Если ценность только у администратора, adoption будет низким.
Что можно оставить ручным? Не каждый процесс нужно автоматизировать.
Какой минимальный сценарий должен стать привычкой? Возможно, платформа и не нужна. Можно начать с одного действия, которое имеет смысл перенести в систему.
Итак, SPA не стал корпоративной платформой, которой пользуются все инженеры компании. Но он и не был ошибкой. Мы связали данные, которые раньше жили в разных местах, проверили гипотезу о жизненном цикле контента и, главное, поняли, что масштаб процесса и частота потребности — это то, что стоит оценивать до начала разработки, а не после.
Сейчас SPA работает как внутренний инструмент HR‑команды. А фреймворк из пяти вопросов мы применяем каждый раз, когда возникает идея «а давайте автоматизируем». Иногда ответ — «да, давайте». А иногда — «давайте пока оставим таблицу». И это тоже нормальный результат.
