Оптимизация процессов, как много в этой фразе многозначности. Как она по разному понимается инженерами и менеджерами! Как говорил один известный мотивационный коуч:
Надо работать оптимально и не надо работать не оптимально!
О, как же он прав! Поговорим как раз про оптимальность.
Все приведенные в примере события и люди вымышлены и все совпадения с реальными событиями или людьми просто случайность и ничего большего. Цифры приведены исключительно для создания драматического эффекта.
Итак, идет крупная конференция, и на ней представлен блистательный доклад, о том, как группа DevOps инженеров сократила время развертки новой бизнес-ценности на канареечном стенде с 12 часов до 2х. Впечатляющий результат! Где-то в середине зала печалится тимлид группы девопсов, у него-то аналогичное действие занимает часов пятнадцать. И он обращается к сидящему рядом продакту с болью в голосе:
— Эх, вот ведь как у людей, почему у нас не так? Почему у нас такие неоптимальные бизнес‑процессы!
Продакт смотрит на тимлида и говорит:
— Всегда есть нюансы. Докладчик не сказал важную вещь: а сколько у них эта бизнес‑ценность разрабатывается? Это важно! У нас она сначала лежит пару месяцев в бэклоге у заказчика, потом попадает к нам в бэклог, где лежит еще полгода. Потом мы ее анализируем, разрабатываем и тестируем. После чего она ждет приемку у заказчика и, вах, она в проде! Полтора года и готово. Как думаешь, есть ли разница в том, за сколько мы делаем выкатку, за час или за пятнадцать? То, что ты предлагаешь сделать, будет для нас субоптимизацией и никакой существенной пользы для поставки ценности заказчику не принесет.
Понятно, что тут можно начать большой спор, но лучше всего это описано у Голдрата в его книге "Цель". Кратко, оптимизация должна выполняться на узком звене, оптимизация не узких звеньев бесполезна (если кто не читал книгу, то настоятельно рекомендую к прочтению!). В книге также приведен алгоритм повышения эффективности процесса:
Определение системных ограничений.
Принятие решения о способе использования ограничений.
Согласование нового решения со всей системой.
Повышение пропускной способности ограничений.
Переход на пункт 1, если текущее ограничение устранено.
Да, вот так просто! И что самое важное: алгоритм прекрасно работает! Доказано многолетним применением ТОС (теории ограничении систем) в разных сферах. И многие айтишники попытались ее использовать для оптимизации своих процессов, но большого успеха в этом не достигли. Разберемся, почему так получилось.
Но сначала пара важных ремарок.
Первая. Оптимальность. Это не про "скорость". Оптимальность - это про выдачу предсказуемого и повторимого результата. А вот это уже позволяет нам проводить не только краткосрочное, но и долгосрочное планирование, что в свою очередь позволяет строить уже стратегию для компании.
Вторая. ТОС предназначен для материального производства! И полностью буксует перед интеллектуальной деятельностью, коей является разработка софта. Почему так происходит, мы рассмотрим подробнее.
На рисунке ниже представлена технологическая цепочка изготовления некой абстрактной детали.
![](https://habrastorage.org/getpro/habr/upload_files/bbc/cc9/e7b/bbccc9e7b4ebe3e83cee9af62fb6b500.png)
Важный момент: все операции, которые нам необходимо выполнить, чтобы из исходного сырья сделать деталь, нам известны. Мы можем построить для неё технологическую карту, а на основании нее найти узкое звено и оптимизировать процесс. Строго по алгоритму, предложенному Голдратом. Когда ТОС пробуют перенести на ИТ, обычно рисуют вот такую цепочку.
![](https://habrastorage.org/getpro/habr/upload_files/4f0/e03/e19/4f0e03e19878e8b3070f9657b52d39a2.png)
При рисовании этой цепочки обычно делается ряд опасных допущений, чтобы можно было использовать подход ТОС:
Первое, самое критичное допущение. Этап = Операция. Предположу, почему так. У Голдрата в книге есть роботизированный станок, который выполняет множество действий над деталью, и в части книги события разворачиваются вокруг него, а всю производственную цепочку под него подстраивают. И логично предположить, что вот, например, наша разработка - это вот такой станок. Но в материальном производстве это не так. Запросто может быть, что мы сначала сделали отверстия в детали, на роботе. Потом закалили, и снова вернули на робота, чтобы он нам все отполировал. Станок один, операции разные, вот этот нюанс обычно ускользает. У Голдрата об этом написано ближе к концу и вскользь. И что же получается: берется этап "разработка" и говорится, что это операция.
Второе допущение. Операции идут последовательно. Опять же. В материальном производстве так и есть. Невозможно точить и красить одновременно. В ИТ отрасли же наоборот, запросто. Можно анализировать, писать код и тестировать. Легко.
Третье допущение. Таска проходит через все операции обязательно, просто через некоторые очень быстро. Откуда это допущение берется? Скорее всего, она навеяна конвейером. Тут комментировать в общем-то нечего. Таска может быть проанализирована и конфигурирована - и будет готова, но без разработки и тестирования.
Вот эти три допущения приводят к тому, что критически важная информация для анализа не видна, она замаскирована в одной из «операций». Как результат: фокус смещается на того, кто больше всего "в мыле". Обычно это тестировщики - и отсюда сразу напрашивается простой вывод: именно тестировщики - это узкое звено нашей цепи. Проблема найдена, отлично! Но реальность может сильно отличаться.
Например, узким звеном может быть тот, кого не видно. Тестировщики же "в мыле", потому что они находятся в цепочке правее всех. И им приходится сглаживать флуктуации потока, а вот на это мощности их не хватает.
А как же выглядит технологическая карта для фичи? Попробуем представить, все еще крупными мазками.
![](https://habrastorage.org/getpro/habr/upload_files/d1f/d2a/696/d1fd2a6964954333bc398fda36c174c2.png)
Это примеры, причем может быть так, что для КАЖДОЙ фичи в релизе будет своя уникальная карта. Соответственно, в этом случае узкое звено будет в совершенно разных местах производственной цепочки. Разработка софта это интеллектуальный труд, а не потоковое производство однотипных деталей. Да, типов тасок у вас может быть не так много, например, штук 5, но это означает, что у вас 5 РАЗНЫХ узких мест, и для оптимизации их потребуются совершенно разные подходы. И не факт, что, расшив одно узкое звено, вы не похороните остальные. А если добавить, что операции и люди пересекаются в общем случае матрично, то на выходе мы получаем ад комбинаторной сложности, решение которого возможно, конечно... Но очень накладно и дорого.
А есть ли выход, если ТОС не применим? Есть, конечно! Надо переходить на вытягивающую систему, ограничить незавершенную работу и постараться перейти от "управления работой" на "управление знаниями", а для оптимизации необходимо визуализировать буфер между операциями. Напомню, что мы стараемся оптимизировать ВЕСЬ процесс поставки ценности, то есть сделать его управляемым и повторяемым, оптимизация без этих двух условий невозможна. Пробежимся по терминам. Вытягивающая система - это система, построенная на правилах, говорящих, что следующую порцию работы можно брать только тогда, когда в системе есть для этого доступная мощность. Для того, чтобы это работало, ограничивают количество незавершенной работы в системе. Например, на группе тестирования не может быть больше 5 тасков в работе. Нет, 6, 7 и 12 нельзя, это запрещают правила. Когда группа закончит работа над задачей и отправит дальше ее по процессу поставки ценности, у них освободится свободный слот и они ВОЗЬМУТ работу. Это и есть вытягивающая система. Самая простая аналогия, это принтер, который берет следующий лист, когда напечатал текущий. Как это выглядит в жизни.
Для удобства представления работы используется доска, например, как показано ниже на рисунке.
![](https://habrastorage.org/getpro/habr/upload_files/dea/c28/980/deac2898015ac268c48a2c04f2fbc1be.png)
Каждая колонка - это не просто этап работы, а рабочий центр, который фокусируется на задаче. Красная цифра - это МАКСИМАЛЬНОЕ количество незавершенной работы. В данном примере коллеги, отвечающие за этап разработки, могут втянуть к себе три задачи, но не больше. Еще раз повторюсь, мы снижаем вариации за счет того, что беремся за следующую работу только тогда, когда у нас есть возможность. Здесь вполне могут появиться вопросы. Давайте сразу разберем самые типичные:
— Получается, что если во всех колонках достигнут лимит, то новую работу в систему не добавить?
— Да. Если есть потребность в добавлении работы, необходимо явно исключить какую‑ то работу из системы.
— А раньше мы могли просто попросить взять еще работы и все было хорошо, зачем нам это?
— Но вы же хотите повысить эффективность? А это достигается только через предсказуемость и повторяемость. Если взять аналогию с принтером, вы, конечно, можете напихать в принтер бумаги, но печатать быстрее он не будет, да и сломаться может.
Теперь про ад комбинаторной сложности и способ его преодоления. Как я писал выше, построение тех. карты для фичи — дело очень сложное и весьма трудозатратное, плюс еще и не шибко помогающее нам в оптимизации. Для интеллектуального труда достаточно мыслить этапами, но есть нюанс — и о нем чуть дальше. Вернемся к доске. Именно поэтому на доске, показанной выше, выделены этапы, а не операции. Какие у нас есть этапы, мы знаем и также мы знаем, насколько близко этап находится к финалу. Поэтому дизайн доски легко сделать интуитивным и понятным. Происходит движение наших задач слева направо, и в процессе движения они становятся все более и более ценными. В них накапливается ценность для клиента, а также наше знание о задаче.
Теперь я могу ответить на вопрос: "Могут ли задачи перемещаться назад по доске или нет?" На это вопрос есть следующие ответы: да, нет и по ситуации ???? Третий вариант мы не будем рассматривать, а вот о первых двух поговорим.
Когда – ДА. Если у вас колонки — это этапы. Задача была на этапе тестирования, потом на этапе разработки, теперь снова на этапе тестирования. Все логично. Задачи могут перемещаться по доске в каком угодно направлении. Но есть нюанс, о котором в этом случае надо обязательно помнить! На колонку есть лимит, который нельзя превышать! И нужно проработать регламент на этот случай, как поступать. Вариантоd много, например, классический, через буферную колонку. О буферных колонках будет ниже.
Когда – НЕТ. Когда у вас в колонках не этапы, а уровни накопленного ЗНАНИЯ о задаче. Что я имею в виду: посмотрим на примере взятия задачи в работу. Задача лежит во входящих и у нас нет информации по ней, мы ничего о ней не знаем. Мы не можем ее взять и сделать, она нам неясна. Поэтому мы посмотрим на нее через призму бизнеса, т.е. выполним бизнес-анализ. В какой-то момент мы уже достаточно разберемся в проблематике задачи, чтобы приступить к системному анализу. И в этом момент мы двигаем задачу дальше. Теперь ее суть познают глубже, уже на уровне информационных систем. Предположим, что в процессе анализа появились вопросы уровня бизнес-процессов и нужно выполнить бизнес-анализ. Это не означает, что мы резко развидели все информацию о задаче ???? и она стала резко не пригодна к системному анализу. Нет, нам нужно прояснить некоторые аспекты. Это означает, что к задаче подключаются бизнес-аналитики, а сама задача как находилась в колонке системный анализ, так и находится. Вы управляете работой (знаниями о работе), а не людьми.
Надеюсь, я смог объяснить, в чем разница между подходами.
И сразу отвечу на вопрос: А как поставить лимит на колонку? Самое простое правило: количество человек, напрямую относящиеся к колонке+2. Для начала, самое то.
Переходим к инструменту оптимизации. У нас есть построенный процесс поставки ценности, теперь нам надо понять, где мы пробуксовываем. Для этого нам надо визуализировать буферы между этапами (уровнями знания) о задаче. Фактически делим колонку на две: "в работе" и "готово". Но при этом лимит остается общий на колонку! Пример такой доски приведен ниже.
![](https://habrastorage.org/getpro/habr/upload_files/df8/9ae/b89/df89aeb89cbc585b6a1a3c991d49aa75.png)
Да! Если все задачи находятся в колонке "готово", нельзя брать задачи в работу. Мы же помним, что мы хотим быть оптимальными с точки зрения поставки ценности клиенту! Колонка "готово" — это наш буфер, и одновременно индикатор того, где происходит затор, где больше всего скопилось незавершенки, перед каким этапом. Это видно на доске, это видно всем, и мы, как менеджеры, можем принять решение, как помочь коллегам разгрести завал. Можно добавить людей, можно попросить помощи коллег, можно попробовать другие значения количества незавершенной работы. Вариантов много. Главное, у нас есть база, которая позволяет проводить контролируемые эксперименты и позволяет получать быструю обратную связь.
P.S. Во всей статье ни разу не было использовано это слово… ????
gnuman
Канбаааан! Две чачи этому джигиту!
Sergey-Titkov Автор
Спасибо! Дзинь :)