Ни для кого не секрет, что ключевой задачей любого бизнес‑продукта является прибыль. Но весь ли успех продукта зависит от бизнес‑фич?
Я начальник центра компетенций развития платформенных решений и инфраструктуры систем малого бизнеса в Росбанке. Основная цель нашей команды — обеспечение стабильной и непрерывной работы сервисов. Иными словами, наша команда не делает бизнес-доставки. Вместо этого мы фокусируемся на технических вещах: формирование работы с техдолгом, мониторинг, поддержка клиентов и сервисов, непрерывная доставка этих самых сервисов, практики тестирования и т. д.
В коллектив входят лидеры всех компетенций, имеющихся в бизнес‑командах (которые как раз и делают эти самые бизнес‑фичи), разработчики, сконцентрированные на сервисных фичах, а также специалисты, которых нельзя отнести к какой‑то одной команде — в общем работающие на всех. К таким относятся Dev‑Ops инженеры, специалисты, занимающиеся написанием автотестов, поддержкой клиентов и прочими узкопрофильными зонами ответственности, покрывающие обширный спектр потребностей бизнес‑команд. В то время как бизнес‑команды работают по Scrum, платформенная (к коей мы и относимся) работает по принципу kanban и концентрируется в основном на долгоиграющих доставках, которые принесут пользу «не прямо сейчас, а когда‑то потом».
И вот тут начинается самое интересное: как человеку, не осведомленному в технических вещах и не понимающему ценности того же технического долга, показать, зачем вообще мы нужны и почему технический долг — это важно? И в данном аспекте я затрагиваю именно бизнес‑линию. Несомненно, есть вещи, которые лежат на поверхности. Взять тот же CI/CD. Он нужен, чтобы быстро вывести функционал в тест, а затем в продакшн. Всё предельно понятно.
А что дальше?
«Вот вы сделали CI/CD, а чем вы еще занимаетесь таким уж полезным? В чем ценность вашей команды?»
Работая еще DevOps‑инженером в новоиспеченной команде ДБО для малого бизнеса (далее речь пойдет только об этой системе), на которой и опробовался впервые Scrum‑подход разработки, где предстояло как построить CI/CD‑конвейер с нуля, так и заниматься прочими инженерными вещами, я начал задаваться вопросом:
«Вот есть Scrum-команда, она что-то там делает, я залил это в продакшн, а что происходит потом?»
А потом, конечно же, не обходится без багов. Появляются ошибки приложений, за которыми надо следить. Возникают первые недовольные отзывы, инциденты. И вот тут мы подошли к самому интересному. Разработчики, инженеры, администраторы, как правило, сконцентрированы в первую очередь на технических вещах. Им в большинстве случаев нет дела до того, что кто‑то там испытывает трудности с сервисом, сколько таких людей, что они при этом чувствуют.
«Есть баг, поправлю, как будет время»
Оговорюсь сразу, мой путь развития в IT начинался как раз с клиентской поддержки, и у меня есть достаточный опыт понимания, что чувствует клиент, даже если я вижу только обращение. Поэтому поставленные передо мной задачи виделись мне изначально шире, чем просто сделать. За доставленными сервисами нужно еще и следить, но просто следить мало. Нужно делать это максимально эффективно и удобно, чтобы «клиентская боль» была как можно менее продолжительной и возникала как можно реже. Так начал развиваться собственный продукт мониторинга (но об этом я расскажу в другой статье), основная суть которого — в быстром и удобном оповещении о проблемах и их визуализации на дашбордах.
Шаг за шагом вслед за расширениями бизнес‑команд и появлением новых бизнес‑продуктов появлялось видение того, чего не хватает для шлифования «клиентоориентированной инженерки» если не до идеала, то до высокого уровня. В конечном счете и образовалась отдельная сервисная команда, которая и призвана обеспечить это самое качество. Наши сервисы пережили непростой путь от монолита до микросервисов, и практики за плечами было достаточно чтобы понимать, куда двигаться дальше.
И вот пришло время и ответить на вопрос: а в чем ценность технической команды с точки зрения бизнеса? Если с точки зрения бизнес‑фич все прозрачно — есть доставка, она приносит деньги — то для чего нужен весь этот технический долг, автотесты, мониторинги и вот это все?
Платформенная команда сравнима с бойцами невидимого фронта. Ее суть состоит в том, чтобы удержать текущих клиентов (в идеале — чтобы текущие клиенты при этом рекомендовали приложение и приводили новых) за счет стабильности и высокой скорости работы и иных инженерных подходах в работе сервисов. Эти задачи как раз и решают качественно написанные автотесты, закрытие дыр безопасности, использование новых технологических подходов back‑end\front‑end сервисов, развитие мониторинга, архитектуры и подходов поддержки к закрытию инцидентов.
Главной задачей клиентоориентированной инженерки было четко получить ответы на следующие вопросы:
Определить фокусы — что нам нужно сделать как команде в первую очередь для того, чтобы клиент испытывал «меньше болей» при пользовании продуктом? Какова будет родительская цель?
Какую задачу будем выполнять?
Что нам даст выполнение этой задачи согласно поставленным родительским целям?
При смене мышления технической команды на клиентоориентированное и ответе на вопрос «А как бы я хотел, чтобы это работало при использовании сервиса? А что меня бесит в текущей реализации?» рождались интересные идеи, образовывались новые подходы к разработке, доставке и поддержке продукта. Немаловажную роль в понимании куда и как двигаться также играли SUS‑опросы (анкетированный опросник с заранее заготовленными тэгами проблематик) и график Pain Index.
Pain Index (ITSD) — это часть аналитической система внутри банка, показывающая динамику уровня клиентской боли и доступности критичной функциональности сервисов в зависимости от прироста клиентской базы, времени суток, праздничных дней и т. д. в сравнении с аналогичным прошлым подобным периодом.
Скажу сразу: мы не всегда знали, что происходит у команд в соседних направлениях, какие подходы использовали они, но мы прибегали к этой информации в действительно сложных ситуациях, экономящих наше же время.
На сегодняшний день в банке стартовал стрим «Инженерной прокачки», суть которого — помочь внедрить централизованные стандарты к разработке и надежности систем. Этот уровень зрелости образовывается из определенного набора best‑practice следующих направлений:
Dev-Ops
SRE
QA
Development
Analytics
Architecture
У каждой практики есть свой вес, и из их выполнения высчитывается соответствующий уровень инженерной зрелости, коих насчитывается 6: start, bronze, silver, gold, platinum, diamond. Уровень инженерной зрелости формируется путем соотношения выполненных подпрактик в каждой практике:
Расчет производится в общем числовом выражении:
0-20 |
start |
20-40 |
bronze |
40-60 |
silver |
60-80 |
gold |
80-90 |
platinum |
90-100 |
diamond |
Для каждой подпрактики в рамках конкретной инженерной практики (Dev, DevOps, SRE, QA, etc) рассчитывается инкрементальное значение (инкремент):
Инкремент = «вес подпрактики» поделить на «сумма весов всех подпрактик в рамках рассчитываемой практики» умножить на «значение подпрактики (0 или 1)»
Проведя подсчет баллов, мы выяснили, что у нашего приложения самый высокий уровень инженерной зрелости не только из всех опрошенных команд, но и по шкале градации (92,8 балла).
Что в итоге?
Ценность технической команды, конечно же, не складывается лишь из выполнения набора крутых высокотехнологичных задач или практик. Именно из-за смены мышления на клиентоориентированное и внимания к пользовательскому опыту и рождаются правильный технический долг и задачи.
Они не всегда могут быть интересными с технической точки зрения, они могут быть рутинными, долгими, даже изматывающими, но именно это и образует основной вклад команды в клиентоориентированность с точки зрения бизнеса.
«Прибыль зависит не только от от бизнес-доставок»
Откладывая на потом пожелания и жалобы текущих клиентов на работу сервисов, вы повышаете риск стагнации из‑за постоянной карусели ухода старых клиентов и привлечения на их место новых. Избежание этого самого риска стагнации, удержание лояльности/уровня NPS и есть ценность технического долга, а также верных инженерных решений и практик.