Однажды разработчики программного обеспечения отвечали за код лишь на собственном ПК. Затем с формированием культуры DevOps все стали отвечать за продакшен. А кто отвечает за бизнес? Почему он у нас довольно часто остается в стороне? Почему разработчики программного обеспечения до сих пор по старинке надеются на прослойку в качестве предназначенного менеджера, аналитика?

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

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

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

Как это сделать легче всего? Быстрейший способ — это применять паттерн “Информационный излучатель”. Так раньше делали на изготовлении.

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

У разработчиков, можно сообщить, такая доска есть — это скрам-борда, где торчат все карты со статусами, исполнителями и прогрессом. хорошо видно, кто чем занят, где простои, во что упираемся.

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

А представлены ли на данных дашбордах бизнес метрики? Представлено ли там, сколько пользователей сегодня зарегистрировалось и сколько из них сделали конверсию? Понимают ли техники ROI от заключительной рекламной кампании? Осознают ли они во сколько денежных средств обходится бизнесу вовлечение клиента? Видят ли они сколько было переходов на целевой сайт с последней кампании по рассылке корреспонденций по черной базе емейлов?

Довольно часто оказывается, что бригада, которая пилит софт для бизнеса вообще не интересуется бизнес данными. Бывает и хуже — бизнес сознательно не позволяет доступ создателям до собственных супер-секретных-не-дай-бог-конкуренты-увидят метрик. Ребята! У них ваш код и доступы для клауда, где данный код крутится. Wake up, Neo. Разработчики достаточно давно должны зайти в круг доверия, как и ваш бухгалтер.

Отныне у нас нет деления метрик на технические и нетехнические. Если мы пишем софт для бизнеса, то все, все метрики — бизнесовые для бизнеса и технические для инженеров. Метрики одни и доступны они всем. Трактовка разнообразная и установление решений на собственных уровнях различное. А владение метриками общее.

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

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

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

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

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

ОК, ясно. А как легче всего организовать доступ к таким метрикам? Бизнес офигеет что-нибудь там изучать в этих ваших Кибанах и Графанах, а техники не могут переносить бизнесовые эксельки и вообще они не имеют времени на изучение признаков в Google Специалисте. Есть отдельную дашбору, в которой будет все представляться так, чтобы всем было ясно нет ни времени, ни ресурсов.

Давайте вспомним где в первую очередь в 2019 году пересекается вся бригада? Правильно, в Слаке (поменяй на собственный чат, где сидит и бизнес и застройщики).

Итак вот, берем самый основной канал в чате (в Слаке это как правило #дженерал) и сворачиваем в него все метрики, которые имеют значение для организации. Заглядывайте на сайт https://utro.ru/release/2025/01/21/1557313.shtml если Вас интересуют форумы программистов.

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

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

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

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