Прирост продуктивности и эффективности разработчиков с помощью HealthOS

Обсудим прирост продуктивности и эффективности разработчиков с помощью HealthOS.

Автор текста: Александр Александрович Прозоров

Что такое продуктивность и эффективность?

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

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

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

Виды потерь

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

 

No Модельные потери Потери при разработке контейнеризованных приложений Механизмы уменьшения потерь в HealthOS Мультипликатор HealthOS
1 Перепроизводство Разработка невостребованных функций, АРМ, документации Автоматизация разработки карт знаний; компиляция исполняемого кода приложений на основе карт знаний; автоматизация жизненного цикла релиза, включая канареечные релизы; движение релиза приложений по кнопке 100
2 Ожидания Ожидание доступа технической учётной записи к кластеру, согласования ролевой модели ServiceAccount микросервиса и т.д. Автоматическое развёртывание скомпилированных компонентов, прохождение QualityGate по меткам автоматических средств тестирования, анализа и аудита; эластичная инфраструктура в облаке 100
3 Лишние запасы Незавершенная работа, разработка утилит «про запас» и т.д. Расширение объёма прикладных знаний путём разработки новых разделов тезауруса и карт знаний; релиз нового приложения по запросу 100
4 Транспортировка Передача артефактов между исполнителями в рамках производственных процессов Автоматическая передача артефактов в рамках автоматических процессов производства (гиперавтоматизация pipeline) 100
5 Лишние перемещения Переключение контекста внимания разработчика с одного инструментального интерфейса на другой и так до 8-10 разных интерфейсов Снижение количества интерфейсов разработчика: во время разработки используется Конструктор; во время тестирования — EBPM Engine Control plane и Ассистент 2
6 Брак Ошибки в архитектурной постановке, программном коде, параметрах конфигурации, документации пользователя, разработчика и администратора Автоматизация выявления ошибок в тезаурусе, карте знаний, конфигурационных параметрах приложений — это снижение брака путём включения тестирования в начальные этапы разработки (shift left testing) 10
7 Ненужная обработка Составление отчётов, согласование действий и тд Автогенерация документации (отчётов); панели управления; автоматическое выполнение действий в рамках модели доступа роли 100
8 Нереализованный потенциал Отказ от саморазвити в области своей компетенции из-за многочисленных изменений инструментов и методов разработки Фокус на освоении новых знаний в целевой предметной области и упрощении инструментальных интерфейсов 10

 

Ролевая модель HealthOS

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

No Роли типовой команды разработки Роли команды разработки HealthOS Коэффициент использования роли в проекте HealthOS Техстек роли HealthOS
1 Лидер команды Лидер команды 1 Локальные LLM; Конструктор; Ассистент; BPMN Engine control plane; Аудитор рисков; Карты знаний
2 Менеджер продукта Врач-методист 0,25 — 1 Локальные LLM; Конструктор; Ассистент; Аудитор рисков; Карты знаний
3 Архитектор Архитектор 0,25 — 0,5 Architecture as code (data model, API design, data processing pipeline, ML-pipeline); BPMN Engine control plane; Аудитор рисков; Локальные LLM; Карты знаний
4 Data Scientist Модельер 0,25 — 1 Стандартный ML-стек; Локальные LLM; Карты знаний
5 ML-разработчик ML-разработчик 0,25 — 1 Linux, CUDA, Kubernetes, Python, Postgres, Redis, QDrant, Kafka, OpenAPI; Локальные LLM; Карты знаний
6 Аналитик Аналитик 1 Локальные LLM; Конструктор; Ассистент; Аудитор рисков; Карты знаний
7 Дизайнер интерфейса Отсутствует
8 UX-аналитик UX-аналитик 0,1 — 0,25 Конструктор; Ассистент; Локальные LLM
9 Frontend разработчик Frontend разработчик 0,25 — 0,5 JS, React, OpenAPI; Локальные LLMI
10 Backend разработчик Backend разработчик 0,25 — 1 Java, Python, Postgres, Elasticsearch, Redis, QDrant, Kafka, OpenAPI; Локальные LLM
11 Тестировщик Тестировщик 0,25 — 1 Python, Postgres, Elasticsearch, Redis, QDrant, Kafka, OpenAPI; Локальные LLM
12 DevOps инженер DevOps инженер 0,25 — 0,5 Linux, CUDA, Kubernetes, Postgres, Elasticsearch, Redis, QDrant, Kafka, Nexus, GitLab, Ansible; Локальные LLM

 

Приоритеты заказчиков

На мероприятии Arch.Meetup (запись здесь), которое прошло 14 мая 2024 года в Sber Agile Home на Кутузовском проспекте 32, участники в кулуарах активно обсуждали результаты опроса крупных корпоративных заказчиков, в состав которых входят такие компании, как Сбер, ВТБ, Альфабанк, Сибур, на предмет направлений повышения продуктивности и эффективности команд разработки контейнеризованных приложений.

Обсуждались результаты 12 интервью и 50 заполненных анкет. Приводим ТОП5 проблем потери производительности и эффективности:

  • Порочная пропорция «работа с кодом/все остальное» — «20/80». Необходимо её привести к виду «80/20».
  • Нет автоматического развертывания инфраструктуры. Необходимо автоматизировать.
  • Нет автоматические доступы. Необходимо автоматизировать.
  • Нет автоматического интеграционного тестирования. Необходимо автоматизировать.
  • Нет времени на долгие согласования постановок на сценарии интеграции. Необходимо автоматизировать.

 

Выводы

С учетом вклада механизмов устранения потерь в продуктивность и эффективность команды разработчиков, а также с учётом того, что ролевая модель меньше по составу и позволяет одновременно использовать некоторые роли разработчиков в нескольких проектах одновременно, HealthOS может обеспечить суммарный прирост продуктивности и эффективности команды разработчиков проекта в 10 и более раз по отношению к типовой команде. Что полностью отвечает приоритетам крупных корпоративных заказчиков.