Оптимизация процессов, как много в этой фразе многозначности. Как она по разному понимается инженерами и менеджерами! Как говорил один известный мотивационный коуч:

Надо работать оптимально и не надо работать не оптимально! 

О, как же он прав! Поговорим как раз про оптимальность.

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

Итак, идет крупная конференция, и на ней представлен блистательный доклад, о том, как группа DevOps инженеров сократила время развертки новой бизнес-ценности на канареечном стенде с 12 часов до 2х. Впечатляющий результат! Где-то в середине зала печалится тимлид группы девопсов, у него-то аналогичное действие занимает часов пятнадцать. И он обращается к сидящему рядом продакту с болью в голосе:

— Эх, вот ведь как у людей, почему у нас не так? Почему у нас такие неоптимальные бизнес‑процессы!

Продакт смотрит на тимлида и говорит:

— Всегда есть нюансы. Докладчик не сказал важную вещь: а сколько у них эта бизнес‑ценность разрабатывается? Это важно! У нас она сначала лежит пару месяцев в бэклоге у заказчика, потом попадает к нам в бэклог, где лежит еще полгода. Потом мы ее анализируем, разрабатываем и тестируем. После чего она ждет приемку у заказчика и, вах, она в проде! Полтора года и готово. Как думаешь, есть ли разница в том, за сколько мы делаем выкатку, за час или за пятнадцать? То, что ты предлагаешь сделать, будет для нас субоптимизацией и никакой существенной пользы для поставки ценности заказчику не принесет.

Понятно, что тут можно начать большой спор, но лучше всего это описано у Голдрата в его книге "Цель". Кратко, оптимизация должна выполняться на узком звене, оптимизация не узких звеньев бесполезна (если кто не читал книгу, то настоятельно рекомендую к прочтению!). В книге также приведен алгоритм повышения эффективности процесса:

1. Определение системных ограничений.

2. Принятие решения о способе использования ограничений.

3. Согласование нового решения со всей системой.

4. Повышение пропускной способности ограничений.

5. Переход на пункт 1, если текущее ограничение устранено.

Да, вот так просто! И что самое важное: алгоритм прекрасно работает! Доказано многолетним применением ТОС (теории ограничении систем) в разных сферах. И многие айтишники попытались ее использовать для оптимизации своих процессов, но большого успеха в этом не достигли. Разберемся, почему так получилось.

Но сначала пара важных ремарок.

Первая. Оптимальность. Это не про "скорость". Оптимальность - это про выдачу предсказуемого и повторимого результата. А вот это уже позволяет нам проводить не только краткосрочное, но и долгосрочное планирование, что в свою очередь позволяет строить уже стратегию для компании.

Вторая. ТОС предназначен для материального производства! И полностью буксует перед интеллектуальной деятельностью, коей является разработка софта. Почему так происходит, мы рассмотрим подробнее. 

На рисунке ниже представлена технологическая цепочка изготовления некой абстрактной детали.

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

При рисовании этой цепочки обычно делается ряд опасных допущений, чтобы можно было использовать подход ТОС:

Первое, самое критичное допущение. Этап = Операция. Предположу, почему так. У Голдрата в книге есть роботизированный станок, который выполняет множество действий над деталью, и в части книги события разворачиваются вокруг него, а всю производственную цепочку под него подстраивают. И логично предположить, что вот, например, наша разработка - это вот такой станок. Но в материальном производстве это не так. Запросто может быть, что мы сначала сделали отверстия в детали, на роботе. Потом закалили, и снова вернули на робота, чтобы он нам все отполировал. Станок один, операции разные, вот этот нюанс обычно ускользает. У Голдрата об этом написано ближе к концу и вскользь. И что же получается: берется этап "разработка" и говорится, что это операция.

Второе допущение. Операции идут последовательно. Опять же. В материальном производстве так и есть. Невозможно точить и красить одновременно. В ИТ отрасли же наоборот, запросто. Можно анализировать, писать код и тестировать. Легко.

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

Вот эти три допущения приводят к тому, что критически важная информация для анализа не видна, она замаскирована в одной из «операций». Как результат: фокус смещается на того, кто больше всего "в мыле". Обычно это тестировщики - и отсюда сразу напрашивается простой вывод: именно тестировщики - это узкое звено нашей цепи. Проблема найдена, отлично! Но реальность может сильно отличаться.

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

А как же выглядит технологическая карта для фичи? Попробуем представить, все еще крупными мазками.

Это примеры, причем может быть так, что для КАЖДОЙ фичи в релизе будет своя уникальная карта. Соответственно, в этом случае узкое звено будет в совершенно разных местах производственной цепочки. Разработка софта это интеллектуальный труд, а не потоковое производство однотипных деталей. Да, типов тасок у вас может быть не так много, например, штук 5, но это означает, что у вас 5 РАЗНЫХ узких мест, и для оптимизации их потребуются совершенно разные подходы. И не факт, что, расшив одно узкое звено, вы не похороните остальные. А если добавить, что операции и люди пересекаются в общем случае матрично, то на выходе мы получаем ад комбинаторной сложности, решение которого возможно, конечно... Но очень накладно и дорого. 

А есть ли выход, если ТОС не применим? Есть, конечно! Надо переходить на вытягивающую систему, ограничить незавершенную работу и постараться перейти от "управления работой" на "управление знаниями", а для оптимизации необходимо визуализировать буфер между операциями. Напомню, что мы стараемся оптимизировать ВЕСЬ процесс поставки ценности, то есть сделать его управляемым и повторяемым, оптимизация без этих двух условий невозможна. Пробежимся по терминам. Вытягивающая система - это система, построенная на правилах, говорящих, что следующую порцию работы можно брать только тогда, когда в системе есть для этого доступная мощность. Для того, чтобы это работало, ограничивают количество незавершенной работы в системе. Например, на группе тестирования не может быть больше 5 тасков в работе. Нет, 6, 7 и 12 нельзя, это запрещают правила. Когда группа закончит работа над задачей и отправит дальше ее по процессу поставки ценности, у них освободится свободный слот и они ВОЗЬМУТ работу. Это и есть вытягивающая система. Самая простая аналогия, это принтер, который берет следующий лист, когда напечатал текущий. Как это выглядит в жизни.

Для удобства представления работы используется доска, например, как показано ниже на рисунке.

Каждая колонка - это не просто этап работы, а рабочий центр, который фокусируется на задаче. Красная цифра - это МАКСИМАЛЬНОЕ количество незавершенной работы. В данном примере коллеги, отвечающие за этап разработки, могут втянуть к себе три задачи, но не больше. Еще раз повторюсь, мы снижаем вариации за счет того, что беремся за следующую работу только тогда, когда у нас есть возможность. Здесь вполне могут появиться вопросы. Давайте сразу разберем самые типичные:

— Получается, что если во всех колонках достигнут лимит, то новую работу в систему не добавить?

— Да. Если есть потребность в добавлении работы, необходимо явно исключить какую‑ то работу из системы.

— А раньше мы могли просто попросить взять еще работы и все было хорошо, зачем нам это?

— Но вы же хотите повысить эффективность? А это достигается только через предсказуемость и повторяемость. Если взять аналогию с принтером, вы, конечно, можете напихать в принтер бумаги, но печатать быстрее он не будет, да и сломаться может.

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

Теперь я могу ответить на вопрос: "Могут ли задачи перемещаться назад по доске или нет?" На это вопрос есть следующие ответы: да, нет и по ситуации ???? Третий вариант мы не будем рассматривать, а вот о первых двух поговорим.

Когда – ДА. Если у вас колонки — это этапы. Задача была на этапе тестирования, потом на этапе разработки, теперь снова на этапе тестирования. Все логично. Задачи могут перемещаться по доске в каком угодно направлении. Но есть нюанс, о котором в этом случае надо обязательно помнить! На колонку есть лимит, который нельзя превышать! И нужно проработать регламент на этот случай, как поступать. Вариантоd много, например, классический, через буферную колонку. О буферных колонках будет ниже.

Когда – НЕТ. Когда у вас в колонках не этапы, а уровни накопленного ЗНАНИЯ о задаче. Что я имею в виду: посмотрим на примере взятия задачи в работу. Задача лежит во входящих и у нас нет информации по ней, мы ничего о ней не знаем. Мы не можем ее взять и сделать, она нам неясна. Поэтому мы посмотрим на нее через призму бизнеса, т.е. выполним бизнес-анализ. В какой-то момент мы уже достаточно разберемся в проблематике задачи, чтобы приступить к системному анализу. И в этом момент мы двигаем задачу дальше. Теперь ее суть познают глубже, уже на уровне информационных систем. Предположим, что в процессе анализа появились вопросы уровня бизнес-процессов и нужно выполнить бизнес-анализ. Это не означает, что мы резко развидели все информацию о задаче ???? и она стала резко не пригодна к системному анализу. Нет, нам нужно прояснить некоторые аспекты. Это означает, что к задаче подключаются бизнес-аналитики, а сама задача как находилась в колонке системный анализ, так и находится. Вы управляете работой (знаниями о работе), а не людьми.
Надеюсь, я смог объяснить, в чем разница между подходами.

И сразу отвечу на вопрос: А как поставить лимит на колонку? Самое простое правило: количество человек, напрямую относящиеся к колонке+2. Для начала, самое то.

Переходим к инструменту оптимизации. У нас есть построенный процесс поставки ценности, теперь нам надо понять, где мы пробуксовываем. Для этого нам надо визуализировать буферы между этапами (уровнями знания) о задаче. Фактически делим колонку на две: "в работе" и "готово". Но при этом лимит остается общий на колонку! Пример такой доски приведен ниже.

Да! Если все задачи находятся в колонке "готово", нельзя брать задачи в работу. Мы же помним, что мы хотим быть оптимальными с точки зрения поставки ценности клиенту! Колонка "готово" — это наш буфер, и одновременно индикатор того, где происходит затор, где больше всего скопилось незавершенки, перед каким этапом. Это видно на доске, это видно всем, и мы, как менеджеры, можем принять решение, как помочь коллегам разгрести завал. Можно добавить людей, можно попросить помощи коллег, можно попробовать другие значения количества незавершенной работы. Вариантов много. Главное, у нас есть база, которая позволяет проводить контролируемые эксперименты и позволяет получать быструю обратную связь.

P.S. Во всей статье ни разу не было использовано это слово… ????