Программисты, бизнес и общее владение информацией

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

Для наглядности давайте сравним как со временем менялась трактовка тестирования ПО:

1. Myers, “The Art of Software Testing” [1979] defines testing as “the process of executing a program or system with the intent of finding errors.” The focus of software testing was on “finding errors” by using some destruction-oriented means.
2. J.E. Bentley, “Software Testing Fundamentals — Concepts, Roles, and Terminology,” [2005] Today software testing is defined as “a process of verifying and validating that a software application or program 1) meets the business and technical requirements that guide its design and development, and 2) works as expected”

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

Основная проблема на мой взгляд — это слабая вовлеченность разработчиков в бизнес-смысл и бизнесовые метрики, что характерно и для бизнеса тоже — у него порой времени и сил не хватает вникнуть в то, что там делают технари — главное, чтобы фичи быстрее выкатывались юзерам. Учитывая то, что разработчики непосредственно решают задачи бизнеса, а бизнес явно зависит от труда разработчиков, то проблемы вовлечения обоих сторон стоят остро. Можно даже предположить, что это один самых основных факторов почему разработка софта проваливается [1] [2].

Information Radiator

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

Как это сделать проще всего? Самый быстрый способ — это использовать паттерн “Информационный излучатель” [1] [2] [3]. Так раньше делали на производстве. В цехе, где, например, изготавливали детали, была огромная доска, на которой каждое утро руководители бизнес департамента рисовали все ключевые показатели предприятия: сколько было продаж, сколько было брака, какой рост, какое падение и так далее. Особенность информационного радиатора в том, что он находится в самом видном и доступном месте, его нельзя развидеть, доступ до него никак и ничем не ограничен.

У разработчиков, можно сказать, такая доска есть — это скрам-борда, где торчат все карточки со статусами, исполнителями и прогрессом. Сразу видно, кто чем занят, где простои, во что упираемся. Иногда разработчики строят себе дашборды, где получают инфу про ошибки с продакшена, про загрузку процессора, базы данных, смотрят на количество прилетающих запросов [1] [2]. Молодцы.

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

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

В информационный век информация для всех

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

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

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

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

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

Шлем общие метрики в Slack

Давайте вспомним где чаще всего в 2019 году пересекается вся команда? Правильно, в Слаке (замени на свой чат, где сидит и бизнес и девелоперы). Так вот, берем самый основной канал в чате (в Слаке это обычно #general) и заворачиваем в него все метрики, которые имеют значение для организации. Краши, ошибки с бэкенда, выжимку по регистрациям и конверсиям за сутки, иные показатели. Сделать это проще простого: у большинства систем есть уже готовые интеграции, а внутри кода продукта можно сделать вещание метрик через веб-хуки мессенджера [1] [2].

Примерно получится как на картинке ниже. Этот метод работает на самом старте, когда активности еще мало. Видно, что бизнесовые и технические ивенты в одном канале. Если это Слак, то сразу можно под ивентом ставить реакции или начать тред с обсуждением.

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

P.S. Without valuable and timely information, the organization dies *