Ни для кого не секрет, что ключевой задачей любого бизнес‑продукта является прибыль. Но весь ли успех продукта зависит от бизнес‑фич?
Я начальник центра компетенций развития платформенных решений и инфраструктуры систем малого бизнеса в Росбанке. Основная цель нашей команды — обеспечение стабильной и непрерывной работы сервисов. Иными словами, наша команда не делает бизнес-доставки. Вместо этого мы фокусируемся на технических вещах: формирование работы с техдолгом, мониторинг, поддержка клиентов и сервисов, непрерывная доставка этих самых сервисов, практики тестирования и т. д.
В коллектив входят лидеры всех компетенций, имеющихся в бизнес‑командах (которые как раз и делают эти самые бизнес‑фичи), разработчики, сконцентрированные на сервисных фичах, а также специалисты, которых нельзя отнести к какой‑то одной команде — в общем работающие на всех. К таким относятся 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 и есть ценность технического долга, а также верных инженерных решений и практик.
