Продолжим говорить об использовании потоков создания ценности для описания системы управления. Тема продолжает оставаться дискуссионной.
Коллеги в наших внутренних обсуждениях озвучивают идею, что потоком можно назвать только ту деятельность, пропускной способностью которой вам удается управлять. Если быть более конкретным, то там, где вы управляете скоростью и объемом задач, проходящих через область продуктивной деятельности команды .
Конвейер
Такое предположение об определении потока, в формате конвейера, очень быстро приводит нас к тому, что в формат включаются только работы, которые выполняются (или могут быть выполнены) в виде достаточно жесткой последовательности операций исполнения/обработки. Тогда мы действительно можем управлять мощностью этого потока через управление очередями задач, лимитами на количество одновременно выполняемых работ, при помощи втягивающих систем и т.д.: kanban-story. Под это формат неплохо подпадают задачи software delivery, развитие программных продуктов, работы по сокращению технического долга, деятельность по устранению сбоев (с оговорками), работы по изготовлению неуникальных изделий и металлоконструкций, выпекание пирожков.
К использованию конвейера ввиде универсального механизма организации выполнения работ есть существенное НО: значительное количество работ ИТ-команды не укладывается в формат конвейера. Изыскания и эксперименты, диагностика и решение проблем, рутинные работы по обслуживанию, работа с формированием бэклога, управление активами и конфигурациями, учения по непрерывности.
Часть этих работ, например RnD, не имеет строго определенной последовательности характерных работ. Так, чтобы мы могли наглядно управлять очередями работ различной природы, аналогично конвейерным операциям.
Часть задач не имеет такой последовательности вовсе (одноэтапные задачи “взял-сделал”).
Часть задач требует коллаборативных усилий, иногда неоднократных, заранее неизвестных ресурсных компетенций (отвлекаемых от конвейерного производства), отвечающих за различные виды работ. Наглядность управления очередями при прохождения задачи по этапам опять же теряется. У разных задач будут различающиеся шаги обработки “конвейера”: лимиты на ограничение числа одномоментно выполняемых задач перестают быть релеватными проходящему потоку задач, перестают эффективно влиять на объем незавершенной работы. Лимиты начинают становиться узким местом из-за потери предсказуемости нагрузки.
Коллеги говорят: “Работы, которые по своей природе не укладываются в поток, и не нужно вкладывать в него. Найдите обособленный способ управления ими”.
Если двигаться по этому пути, то становится понятно, что мы должны будем выделять некоторые сегменты от общих производственных мощностей нашей команды на их выполнение.
Можно выделять время вертикально, разделяя условную “трубу” на сегменты: “две недели пишем новый код, неделю занимаемся R&D, неделю работаем с техдолгом”.
Можно выделять время горизонтально, выделяя доли от объема трудозарат, которые должны быть потрачены на те или иные задачи, контролируя наличие результатов, достигнутых за заданное время.
Этот подход к разделению задач разной природы подталкивает нас к определенной дилемме, связанной с людьми: с одной стороны, вот наша команда (другой у нас нет), она состоит из ограниченного числа известных людей, вместе отвечающих за результат. С другой стороны, разделяя задачи по принципиально отличающимся блокам, мы очень близки к концепту, что вот эти профессиональные люди занимаются разработкой ПО (их производительность измеряется временем прохождения задач по конвейеру, пропускной способностью и другими метриками), а вот эти люди с другими компетенциями занимаются эксплуатацией или исследованиями, и их результаты измеряются совсем другими метриками. Здравствуйте silos, “мы и они”, “перебрасывание через стены” и прочие радости.
С этим, конечно, можно бороться ротацией сотрудников, армейскими способами “награды и наказания общие по результату”, но во всех без исключения вариантах есть свои слабые стороны. Придется выбирать, чем жертвовать, акцентироваться на тех или иных аспектах решаемых командой задач.
Поэтому изначальный посыл называть конвейерную деятельность по генерации, так называемой, ценности, потоком создания ценности, мне кажется не вполне корректным.
Мнение
Персонально меня от постулата “не конвейер – не поток” отталкивает понимание того, что в работах, обеспечивающих “гарантию” услуг, очевидно, есть вполне измеримая ценность.
Деятельность, обеспечивающая гарантию, обеспечивает определенную уверенность в том, что добавленная развитием ценность utility не будет умножена на 0 или дискриминирующий коэффициент, за счет того, что услугой не смогут воспользоваться.
Ценность “гарантии” может измеряться комбинацией показателя доступности услуги и характеристик активной пользовательской базы, опираться на оценку негативных или положительных рисков.
Исследовательская и изыскательская деятельность может измеряться через наличие принятых бизнес и/или технических решений на основании полученного знания, через доказанное снижение неопределенности в достижении желаемого командного результата.
Ценности “полезности” (основной вклад – конвейер разработки и развития) и “гарантии” не суммируются друг с другом, а перемножаются.
На мой взгляд, поток создания ценности – это способ наглядного обоснования того, что ваша деятельность по достижению ценностного результата доказательно обеспечивает эту самую ценность в терминах бережливого производства. Это слой управления, лежащий строго над управлением потоками задач.
Задачи различных видов, попадающие в условную (а где-то вполне настоящую) бэклог-мясорубку потока создания ценности, должны быть оценены с точки зрения их влияния на общий доносимый результат команды, классифицированы и направлены в надлежащие процессы обработки, как то: конвейер развития, задачи на исследования бизнес-аналитикам, проверку бизнес и технических гипотез. Здоровье каждого из этих исполняющих и обрабатывающих процессов измеряется собственными метриками (где-то lead time, где-то availability), а здоровье команды/ совокупного потока ценности – итоговым (финансовым, опционально) результатом и сбалансированной картой показателей процессов, которые показывают, что общая донесенная ценность работы команды не нулевая.
Все в этом мире создается через процессы. Можно выдумывать различного рода эвфемизмы типа “потоков создания ценностей”(это не процесс?), но сути это не меняет. К моему большому разочарованию команда ITIL настойчиво не хочет или не может построить наконец нормальную модель бизнес процессов ИТ службы. Будь эта модель создана – все эти вопросы отпали бы сами собой. Стало бы очевидно на пример, что если “одноэтапные задачи «взял-сделал»” не связаны с моделью по входу и выходу, то эти задачи безсмысленны. Было бы понятно, на основании чего начинаются R&D и что должно происходить с их результатами. Ну и т.д.