Оптимизация процессов производства ПО
Внедрение практики малых инженерных команд

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

  1. Ориентация на конечную Е-Е функциональность, каждая производственная команда должна строиться во круг прозрачно сформулированной понятной бизнес-цели
  2. Качественное долгосрочное и среднесрочное планирование, несколько уровней планирования и практики быстрой проработки архитектуры/аналитики/оценки задач
  3. Разработчики должны писать код, в течение рабочего дня у сотрудника должна быть только 1 встреча, на которой он отчитывается о статусе работы
  4. Концепция малых инженерных команд, когда под конечную Е-Е функциональность собирается самодостаточная небольшая команда, заведомо способная добиться требуемого результата
  5. Управленческие позиции в разработке не свойство по умолчанию, а следствие желания создать конечную Е-Е функциональность и под это желание делегируются управленческие полномочия
  6. В идеальном случае руководитель малой команды – непосредственно участвует в производстве руками лично, по опыту идеальные руководители выходят из разработчиков/системных архитекторов или системных аналитиков
Использование данных подходов, неоднократно позволяло спасать, казалось бы, совсем
безнадежные проекты, выживать на расстрельных должностях, делать невозможный объем
работы в крайне сжатые сроки.

Пакет услуг:
  1. Проведение ретро команд разработки, определение ключевых точек роста
  2. Оценка текущего налога на эффективность
  3. Аудит процесса производства
  4. Помощь в декомпозиции работ и составления дорожной карты разработки основой функциональности, под модель малых инженерных команд, совместно с бизнес владельцами продукта
  5. Запуск малой инженерной команд-ы
  6. Процессный надзор и помощь в рамках производственной итерации
  7. Выработка рекомендация по структуре и управленческим позициям
  8. Проведение ретро команды по итогам производственной итерации
  9. Формулирование рекомендаций по дальнейшей оптимизации производства

Опционально:
1. В дальнейшем возможно привлечение к аналогичным работам в поддерживающем режиме
(помощь с планированием/формированием фича команд)