Оптимизация процесса поставки ценности, с чего стоит начать

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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