IТ-аудит — это изучение и экспертная оценка всей IТ-инфраструктуры компании с точки зрения достижения бизнес-целей. Какие пункты входят в отчёт?

Вводные данные

В это разделе указываем людей, которые принимают участие в аудите. Бизнес-заказчика, команду заказчика и команду it~bp.

Предпосылки

От бизнеса

• Уход СТО и риск потери важных знаний о проекте и его реализации.
• Недостаточный темп реализации функционала, требуемого для достижения бизнес-целей.
• Регулярная просрочка сдачи функционала.
• Большое количество недоработок и багов на продакшене.
• Низкая скорость реакции технической команды на коррекции курса от команды бизнеса.

От технической команды

• Отсутствие технической документации.
• Отсутствие фокуса на реализацию целевого функционала.
• Планирование бизнеса без учёта актуального технического состояния системы.
• Недостаточный бюджет и, как следствие, количество специалистов в команде.

Бизнес-цели:

1. агрегация необходимой и доступной информации о техническом состоянии системы, её архитектуре и рисках от уходящего СТО;
2. разработка действий необходимых для управляемого и планируемого процесса разработки;
3. повышение NPS за счет стабилизации качества релизов

Список проведённых интервью

1. Общая встреча с бизнес-командой.
2. 3 встречи с СТО.
3. Встреча с менеджером проекта.
4. Встреча с ведущим backend разработчиком.
5. Общая встреча с командой разработки.
6. Встреча с лидером бухгалтерии.
7. Встреча с менеджером продукта.

TL:DR

В этой заметке для удобства восприятия разделяем процесс производства на:

• постановку;
• аналитику;
• разработку;
• поддержку.

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

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

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

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

Рекомендации размещены в разделе предлагаемое решение.

Общие комментарии

Видно, что база знаний заполнена лишь частично и существует одновременно на 2-х разных площадках. Подобный объём описания продукта говорит о несистемной работе бизнес-аналитика и специалиста по тестированию. Прямой функцией бизнес-аналитика является описание существующей системы и вносимых в неё изменений. Нам заявляли что описание системы можно получить из таск-трекера. Это говорит об отсутствии общего и целостного представления о системе. Вместо этого предлагается работать с фрагментами знаний, распределёнными между задачами на различных досках таск-трекера, включающего брошенные и неактуальные доски.

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

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

Управление качеством

Работа специалиста по тестированию подразумевает разработку планов тестирования, чек-листов, тест-кейсов и отчётов о тестировании. На данный момент информация о качестве продукта скорее отсутствует, то есть реально его оценить достаточно сложно.

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

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

Управление знаниями

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

Изучая описание API можно сделать вывод, что единого подхода к определению приоритетов разработки и законченности процесса не было. От команды была получена информация, что методов объективной приоритизации не использовалось. Это повлекло за собой существование одновременно нескольких версий API, имеющих как уникальный, так и пересекающийся функционал.

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

Предпосылки и проблематика

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

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

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

По мнению команды разработки часто приоритет выполнения задач определяется по принципу «кто громче кричит». При этом не проводится анализ актуальности, затрат и возможной ценности для бизнеса. То есть задачи делаются просто для того, чтобы что-то делать и кого-то успокоить. Со стороны бизнеса ситуация может выглядеть по-другому и иметь необходимые артефакты, но для команды это не очевидно. На дистанции это влечёт за собой снижение инициативы разработчиков, так как непонятна система координат для их оценки.

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

Критичным моментом является то, что у продукта отсутствуют «продуктовые метрики», которые позволяли бы оценивать эффект от тех либо иных изменений. То есть владелец продукта будет вынужден заявить о необходимости внедрения продуктовых метрик. Это порождает риски появления сходной ситуации с маркетинговыми метриками. При этом следует понимать, что управление продуктом тоже является затратным решением.

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

Следует отметить, что на уровне высшего руководства присутствовало понимание о том, каких стратегических задач с точки зрения бизнеса следовало добиваться:

• кратно снизить стоимость обслуживания на одного клиента;
• обеспечить удержание клиентов;
• привлечение новых клиентов, после того, как система будет способна их принять.

Делаем предположение о наличии корневой проблемы на C-1 уровне.

Предлагаемое решение

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

1. Ввести мониторинг и анализ бизнес-метрик: стоимость обслуживания на одного клиента с возможностью декомпозиции на стоимость ряда операций по обслуживанию клиента.
2. Получить доступ к информации о причинах оттока новых клиентов. Убедиться, что работа происходит с верной целевой аудиторией (при привлечении неверной ЦА задача удержания становится нереализуемой).
3. Пересмотреть KPI отделов. Например, KPI отдела продаж должен быть завязан не только на привлечении новых клиентов, но и на их удержании. При этом KPI отделов должны быть плотно увязаны между собой и привязаны к достижению общего результата.

• Рекомендуем обратить внимание на модель «сквозного процесса». То есть должна быть построена полная экономическая модель: от привлечения новых клиентов через процесс обслуживания до повторных закупок услуги. При этом следует выделить функциональные участки и определить реальные, целевые и финансовые затраты на каждый участок.

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

Таким образом откроется возможность производить правильную приоритизацию задач с точки зрения бизнеса и производить анализ инициатив (запросов на разработку) по упрощённой схеме:

1. сколько надо потратить ресурсов и времени?
2. сколько дополнительной ценности мы получим и через какое количество времени?

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

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

1. процесс управления изменениями, который в обязательном порядке должен включать в себя расчёт необходимой прибыли и расчёт новой ценности для бизнеса, то есть экономическое обоснование.
2. процесс управления инцидентами, который в обязательном порядке должен включать в себя анализ возникающих у потребителей проблем, которые могут являться причинами отказа от продукта.
3. процесс управления знаниями. На данный момент продукт не описан, носителями знаний являются только люди, которые могут заболеть, уволиться и тд.
4. процесс управления качеством. При расширении продукта в текущем формате прогнозируются критические проблемы с качеством.
5. необходимо долгосрочное планирование развития продукта — дорожная карта с измеримыми целевыми показателями. Горизонта планирования в 1-2 спринта недостаточно.

Технические замечания

1. Для клиентского приложения по состоянию «as is» провести полное регрессионное тестирование, составить список ошибок и определить приоритеты исправления. От бизнеса поступают жалобы на то, что невозможно провести оплату из самого приложения. С точки зрения бизнеса такие проблемы являются критическими и должны исправляться с максимальным приоритетом.
2. Провести анализ инцидентов, выделить проблемы (причины отказа функционала, причины массовых обращений), определить приоритеты исправления проблем. Сверить список проблем со списком ошибок регрессионного тестирования. Большая часть проблем должна быть найдена при регрессионном тестировании.
3. После исправления критичных и важных ошибок и проблем, составить дорожную карту полного отказа от АК, произвести декомпозицию задач, составить план работ. Задача имеет высокий приоритет для бизнеса и должна быть закончена прежде, чем начнётся выполнение задачи с обычным приоритетом.

3.1) Отказ от АК позволит также отказаться от интеграционного кода с АК и части легаси-кода, что даст возможность не производить его рефакторинг и снять с поддержки большой блок функционала.

4. Провести ревизию интеграции с банками. На данный момент заявляется об интеграции через API со «Сбербанком» и «Тинькофф», интеграции с «Альфа-банком» и «ВТБ» через сервис Cashoff, а так же интеграции на базе парсинга личных кабинетов для «Открытия», «Модуль и Точка». Для «Открытия», «Модуль и Точка» необходимо проработать вопрос их реальной востребованности и рассмотреть возможность произвести интеграцию через API. Для «ВТБ» и «Альфа-банк» дождаться от банков реализации OpenAPI, мигрировать на него, после чего отказаться от Cashoff.

4.1) Банк «Открытие» заявляет о наличии JSON API + ссылка.

4.2) Банк «Модуль» заявляет о наличии API + ссылка.

4.3) Банк «Точка» заявляет о наличии OpenAPI + ссылка.

5. На данный момент существует 3 версии API с фрагментарным перекрытием функционала. Необходимо провести работы по проектированию целевой версии API и удаления первых трёх версий API.

5.1) Для сохранения обратной совместимости, эндпоинты старых версий API сразу не удаляются, вместо этого их тела заменяются на обращения к целевой версии API (пишутся адаптеры).

6. Разрабатывается новый сайт. Сейчас используется гибрид Тильды и вставок на React. Целесообразно заказать на аутсорсе разработку нового сайта. Функционал у текущего сайта минимальный, стоимость разработки с нуля находится примерно в диапазоне затрат на 1-1.5 FTE разработчика.

7. На данный момент в системе одновременно используются Yandex ClickHouse (сбор и анализ метрик), Prometheus на Яндекс.Облако (сбор и анализ метрик, рассылка уведомлений, дашборды), Prometheus на Селектел (сбор и анализ метрик, рассылка уведомлений, дашборды), Grafana (дашборды), ELK [аналог связки Prometheus + Grafana] (сбор и хранения логов). Нужно определить что из этого вообще актуально и нужно, после чего ликвидировать лишние элементы и разобрать этот «зоопарк».

7.1) Обратить внимание ещё на Google Cloud Firestore. Возможно его функции дублируются Yandex ClickHouse.

8. Задокументировать описание и API существующих микросервисов, в частности MS «Прокси», MS «операции», MS «Лиды», MS «Бухгалтерия».

9. Составить дорожную карту полного отказа от MS «Сервер», произвести декомпозицию задач, составить план работ.

Рекомендуемая команда:

Мы предлагаем рассмотреть возможность коррекции технологического стека основного продукта в связи с высокой стоимостью специалистов и технологическими рисками. Бэкенд перевести на Python, а мобильные приложения на кроссплатформенный Flutter. Это позволит сократить объём разработки и сделать более гибким найм. Если при обсуждении это будет выглядеть невозможным, то необходимо изменить количество профильных специалистов в списке.

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

Подчёркиваем, что рекомендуемая команда учитывает только задачи внутри актуального и известного нам продукта Cifra. При необходимости, команду следует увеличивать пропорционально росту нагрузки, ориентируясь на выбранные показатели.

Собранные в процессе артефакты

В этом разделе собираем все документы, которые получили до, во время и после аудита.