Подходы оркестровки и хореографии в мире менеджмента разработки ПО

В предыдущей статье из этой серии я рассказывал про принципы SRP и IoC в мире менеджмента. В этой статье я продолжу перекладывать технические подходы на истории, связанные с управлением разработкой программного обеспечения. Здесь мы рассмотрим подходы оркестровки и хореографии в контексте паттерна Saga, служащего организации взаимодействия частей распределенных систем. А потом попробуем отобразить эти же подходы на менеджмент разработки айтишных систем. Кстати, про то, как мы пришли к этому подходу можно прочитать в статье “Эволюция процессов в фронтовых командах привлечения Tinkoff”.

Оркестровка и хореография

Мы живем в мире распределенных систем, которые надо как-то синхронизировать между собой. Для того, чтобы организовать этот процесс сквозных консистеных измений в IT мире обычно используют паттерн Saga. Этот паттерн имеет две вариации: оркестровка и хореография. Как они выглядят в реальном мире представлено ниже на изображениях

Хореография
Орекстровка

И хоть первым идет снимок с хореографией, т.к. балерины эстетически выигрывают у дирижера, но мы начнем наше обсуждение с оркестровки.

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

Пример дирижера за работой

Хореография (choreography) — вариант с распределением принятия решений и последовательности действий между участниками саги, которые преимущественно коммуницируют посредством обмена событиями. В хореографии уже нет дирижера, который отдает команды всем участникам … но есть балетмейстер, который ставит “танец”, так, чтобы все участники попадали в музыку со своими движениями. Как это выглядит можно увидеть на видео, приведенном ниже

Пример хореографии в действии

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

Проектный и процессный менеджмент

Различие проектного и процессного управления в базовом виде расписано в PMBoK (5th edition) и основано на том, что проектный менеджмент направлен на успешное выполнение проектов, где

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

А процессный менеджмент направлен на эффективную реализацию операционной деятельности (для IT компаний — это разработка софта, который решает проблемы заказчиков). В том же PMBoK это определяется так:

управление операционной деятельностью — это область управления, которая связана с постоянным производством
продуктов и/или услуг. Сюда относится обеспечение эффективности операционной деятельности за счет использования необходимых оптимальных ресурсов и удовлетворения потребностей заказчиков. Это связано с управлением процессами, которые превращают входы (например, материалы, компоненты, энергию и труд) в выходы (например, продукты, товары и/или услуги)

Если вспомнить про оркестровку и хореографию, то несложно провести параллели между

  • оркестровкой и управлением проектами
  • хореографией и управлением операционной деятельностью

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

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

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

В итоге, нам надо как-то поддерживать соблюдение зафиксированных регламентов и ритуалов. Один из вариантов такого поддержания процесса в Scrum методе — это выделение роли скрам-мастера, который следит за тем, чтобы скрам был каноничным именно по красной книге Джеффа Сазерленда. Этот человек фактически становится придатком процесса и начинает напоминать дирижера, но уже не в контексте оркестра, а в контексте танца:)

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

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

а также принципы сервисной парадигмы, которой он придерживается:

  1. выясните потребности и ожидания заказчика (хмм, а разве это не базовый способ сделать что-то нужное и продать его?)
  2. управляйте работой, дайте людям организоваться вокруг нее (“неожиданный” совет для организации процессов)
  3. развивайте правила, чтобы улучшить показатели (а вот это стоящий пункт)

Примечательны практики Канбана, которые говорят, что:

  1. визуализируйте (визуализируйте цепочку нанесения ценности — важно для дизайна процесса)
  2. ограничивайте незавершенную работу (важный, но не всем очевидный совет, легко автоматизируется)
  3. управляйте потоком работы (хороший совет, позволяющий автоматизацию на базе систем с event driven architecture)
  4. используйте явные правила (хороший совет еще с PEP 20 — The Zen of Python aka “Explicit is better than implicit”)
  5. вводите петли обратной связи (вообще древняя история с времен 40х годов 20 века и цикла PDCA Деминга-Шухарта)
  6. улучшайте и эволюционируйте (и будет вам счастье)

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

В итоге, мой идеальный процесс — это message-based хореография с enforcing’ом договоренностей посредством автоматизации. Идеальный менеджер в этом случае — это дизайнер процесса, продуктом которого и является этот процесс. Продукт хорош, если этот процесс ориентиран на выдаваемый командой результат и удобен команде, участвующей в процессе. Для того, чтобы процесс не превратился в карго-культ этот дизайнер отслеживает обратную связь стейкхолдеров и метрики процесса. В случае отклонений он тюнит процесс и подстаивает его под изменившуюся реальность. В моем идеальном мире скрам-мастера способны выжить и приносить пользу, только если они способны поменять свой подход. Надо уйти от прокрустова ложа Scrum’а и дальнейшего babysitting’а инвалида по референсному процессу к изначальному дизайну кастомного процесса конкретно под продукт и команду.

Director of digital ecosystem development department at Tinkoff. Bachelor at applied math, Master at system analysis, Postgraduate studies at economics.

Director of digital ecosystem development department at Tinkoff. Bachelor at applied math, Master at system analysis, Postgraduate studies at economics.