Юлия Князева
IT-директор, CIO, Санкт-Петербург
История о том, как удалось наладить коммуникации с разработчиками и клиентами и сократить затраты бизнеса более чем на 90%.
В этой статье не будет никакой магии и танцев с бубнами. Я расскажу на конкретном примере, как мы сократили затраты бизнеса на 94% в компании, в которой трудится международная команда. Сделали мы это за счет целенаправленного структурирования коммуникаций и повышения уровня доверия между отделами продаж и разработки. Но обо всем по порядку.
Итак, география команды — это Европа, Россия, Украина и Нигерия. Описывать буду действия, которые мы предприняли в начале 2022 года, то есть в период накаленной геополитической обстановки.
Проблема
Понятно, что стартап — это про скорость, большие вызовы, свободу и, конечно, мечту стать Unicorn. И каждый приходит в стартап со своим представлением о реализации проекта, определенными ожиданиями и амбициями. В нашу команду заходили ребята с такой мотивацией:
- Иметь причастность к высоким технологиям, ведь бизнес компании реализовывается на рынке криптовалюты.
- Свобода. Все хотели быстро воплощать свои идеи без муторных согласований.
- Люди. У нас правда собрались умные и классные.
Всех объединяла вера в продукт и возможность стать лидером в своем сегменте. Из-за того, что компания удаленная (есть только штаб-квартира) — мы ни разу не собирались в офисе.
Компанию мы строили с нуля и основными отделами были Business Sales (продажи) и отдел разработки, где каждый занимался своими задачами. Разработка — производством продукта с определенным функционалом и надлежащего качества, Business Sales — привлечением клиентов и продажами. Разработчики были загружены по 10 часов в день, а продажи любыми способами привлекали клиентов.
И так как все происходило динамично, то между ключевыми людьми из подразделений мы создали еженедельные созвоны. Это точка синхронизации между продажами и тимлидами из разработки, цель которой было ответить на вопросы:
- Для продаж: на какой стадии сейчас продажа? Кто в пайплайне из потенциальных клиентов? Есть ли у них специфичные запросы к функционалу продукта? С кем конкурируем?
- Для разработки: на какой стадии разработка функционала? Когда будет готова?
Таким образом продажники должны были выходить со встречи с пониманием, что они могут обещать клиентам, включая функционал и сроки. А разработчики должны получать понимание, что стоит включить в бэклог по функционалу, и можно ли как-то ускорить разработку.
Но поскольку жизнь стартапа очень подвижна, потому что нам нужно было быстрее выйти на рынок и заполучить наибольшее количество клиентов, предоставив качественный продукт, то в какой-то момент продажи пообещали предоставить функционал одному клиенту примерно через неделю. И когда дело дошло до разработки, выяснилось, что миссия невыполнима.
Тогда мы решили, что при таких вопросах нужно не дожидаться еженедельного созвона, а быстро все уточнять в рабочем чатике. И это привело к тому, что мы начали страдать хаотичными звонками и бесконечными переписками в Slack. Это занимало у всех кучу времени, а инженерам стало сложно переключаться с бизнес-целей на технические задачи, потому что уровень контекста везде разный. И по факту мы получили снижение производительности.
Отчасти, это похоже на конфликт целей и интересов. Потому что личностного конфликта ни у кого нет — оба отдела нацелены на результат, но формулируют его все основываясь на своих критериях.
Нужно понимать, что отдел разработки в IT — это люди, которые большую часть времени работают над техническими решениями, и все остальное их просто отвлекает. Поэтому инженеры не любят объяснять дважды и «разжевывать» все по сто раз.
Логично, что у нас встала задача выстроить прозрачный отдел коммуникаций, который будет понятен и удобен для продаж и разработки.
Решение
Для решения этой задачи мы внедрили Kanban доску. В компании мы пользовались двумя инструментами — Jira и Notion. Но отдел продаж не использовал Jira, плюс они оставляли какие-то заметки просто у себя в телефонах. Учитывая это, мы переключились на Notion, в котором и создали доску.
- У нас на Kanban-доске в Notion отображались задачи, сформулированные в терминах бизнеса. Имеется в виду, что задачи, которые имели существенную ценность для клиента и могли быть непосредственно проданы, были приоритетными.
- Каждая карточка на доске содержала информацию о статусе задачи и ожидаемых сроках ее готовности. Это позволяло продажам понимать, какие функциональные возможности они могут обещать клиентам и насколько быстро их можно предоставить. Созвоны стали более эффективными, поскольку обсуждение технических деталей, которые были несущественны для Business Sales, были полностью исключены.
Также по мере развития стартапа мы перешли на собственную систему управления проектами с кодовым названием Heartbeat. Она включала в себя следующее:
- Созвоны. Строго один раз в две недели.
- Участники — продажи и тимлид из разработки.
- Цель — мониторинг и обсуждение ключевых бизнес-целей на квартал.
Такой подход мы позаимствовали у Amazon, он также известен как 6-Pager. Это когда каждая квартальная цель формулируется четко и конкретно и разбивается на подцели — Strategic Priorities. Это позволяет иметь ясное понимание того, как достижение подцелей приведет к достижению главной квартальной цели.
Для упрощенного мониторинга рисков и статусов задач на каждом созвоне мы применяли следующую систему по статусам:
- Красный кружок: задача находится в серьезной опасности и существенно отстает от плана.
- Желтый кружок: задача требует внимания и может перейти в красный статус через некоторое время.
- Зеленый кружок: задача идет по плану и укладывается в дедлайн.
- Готово для использования клиентами: задача завершена и готова к использованию.
Я подписывала NDA, поэтому не могу показать внутренние материалы нашей доски, но вот как это может выглядеть:
Логично, что особое внимание мы уделяли желтым и красным задачам. Для желтых — назначали ответственного, кто расписывал план шагов, чтобы вернуть зеленый статус. А для красных — проводили отдельную встречу два раза в неделю на 15 минут. На них обсуждалось, что сделано, что планируем делать, разрешение/брейншторм для технически сложных задач. Такие встречи проводятся до тех пор, пока статус не перейдет в желтый.
Также раз в 1-1,5 месяца мы организовывали встречи, на которых отвечали на вопрос, действительно ли достижение подцелей приведет нас к достижению главной квартальной цели. Это позволяло иметь объективный взгляд на текущий прогресс и вносить необходимые корректировки в приоритеты и планы. Сначала такие созвоны занимали час, а затем стали всего по 30 минут.
Такие встречи я называю «сшивкой» двух департаментов. Потому что на них сшиваются смыслы — к ключевым смыслам бизнеса «пришиваются» возможности их технического выполнения.
На моей практике почти все компании сталкиваются с тем, что отделы, ориентированные на результат в деньгах, и отделы, ориентированные на продукт или процесс, преследуют свои цели. Здесь важно встать в «тапки» собственника бизнеса и посмотреть на компанию как бы сверху. Тогда становится ясно, что оба отдела выполняют необходимые задачи и не могут привести к прибыли друг без друга. И если между отделами есть недопонимание, то вот, что стоит сделать:
- Определить ключевые результаты. У нас по методике Amazon 6-pager это были квартальные цели.
- Взять уже используемый в компании и отделами инструмент, где будут видны результаты и прогресс каждого отдела. У нас в начале это была доска Notion и CRM.
- Слушать и слышать друг друга, а также собирать обратную связь. Тут можно выбрать одного ответственного и улучшать процесс. У нас в компании это была я, и в итоге мы пришли к внутренней системе Heartbeat.
Результат в цифрах
А теперь наглядно в цифрах цифру 94%. Старый метод коммуникации у нас включал:
- Еженедельный созвон с разработкой — 90 минут (в час мы никогда не укладывались).
- Каждый день переписка в чате с разработчиками, ожидание ответов, переключение с задачи на задачу — 1-2 час в день или 7 часов в неделю.
- Коммуникации с потенциальными клиентами постоянно затягивались, так как дать ответ сразу было невозможно. А во время простоя и ожидания информации для клиента бизнес переключался на другие задачи. Это просто ментальная нагрузка, которую невозможно просчитать в часах.
Итого в месяц получалось: 1,5*4 + 7*4 = 34 часа – затраты бизнеса на взаимодействие с разработкой и актуализацией информации.
C новым процессом мы получили:
- Еженедельный созвон с разработкой — 30 минут.
- Каждый день переписка в чате с разработчиками — 0 минут, поскольку информацию можно взять во внутренней системе.
- Коммуникации с потенциальными клиентами больше не затягивались. Бизнес стал свободно оперировать данными и может сразу предоставлять актуальную информацию.
Итого затрат в месяц: 0,5*4 = 2 часа
И получаем результат: ( (34-2)/34)*100%= 94%
В итоге затраты продаж сократились на 94%. Ребята из разных отделов стали лучше понимать друг друга, а инженеры вернулись к разработке и больше не отвлекались на обсуждение готовности функционала продукта.