Канбан Метод. T memarketologmanager
 Скачать 4.05 Mb.
|
|
t.me/marketologmanager Посвящается Шерон Предисловие Наверное, вы слышали о существовании Т-специалистов [1] , так вот, это — Т-книга. В ней есть и глубина раскрытия основного предмета, и определенная широта повествования. Понятно, что глубоко в ней рассматривается Канбан Метод — что это такое, как мыслят его приверженцы, советы по применению и т.д. Широту придают другие важные темы. Это, я надеюсь, будет полезно как для тех, кто интересуется методом, так и для тех, кто им уже пользуется, но ищет новые ориентиры. Я поставил себе задачу рассказать о «гуманном подходе к изменениям (начните с того, что есть сейчас)» не как об инструменте для повышения производительности, а как о методе управления, построенном на прочном фундаменте ценностей — методе, который помогает организациям становиться лучше для работников, клиентов и других заинтересованных лиц. Важнейшей особенностью этого метода управления является возможность его применения на самых разных уровнях — от отдельного человека и небольшой команды до стратегических бизнес-проектов. Не удивляйтесь, когда мы будем переходить от одного уровня к другому в соседних абзацах, — простота этой процедуры наглядно демонстрирует возможности Канбан Метода. Я взялся за эту книгу, имея за плечами большой опыт работы менеджером и основательное техническое образование. В последние годы мне довелось руководить проектами по глобальному развитию на четырех континентах, быть исполнительным директором, директором по информационным технологиям и интерим-менеджером. Хотя с тех пор, как мне в последний раз платили за написание компьютерной программы, прошло немало времени, это по-прежнему моя страсть, и даже сейчас я участвую в дискуссиях по архитектуре и проектированию систем. Естественно, читать эту книгу будет проще тем, у кого есть представление о разработке программного обеспечения, но это совсем не обязательное требование. Аналогичным образом я не рассчитываю на то, что читатели хорошо знакомы с такими подходами, как бережливое производство и аджайл, — мы будем обращаться к ним по мере необходимости. Главное, чтобы у вас было профессиональное любопытство и интерес к творческой интеллектуальной работе и к тому, как сделать ее более эффективной. Книга состоит из трех частей. В части I я представляю Канбан Метод (или просто канбан) по- новому, через призму девяти ценностей. Впервые я написал о них в начале 2013 г., и с тех пор им отводится центральное место в моей работе. В конце части I я рассказываю о некоторых новых понятиях — трех повестках и Канбан Линзе. Повестки канбана — это плод сотрудничества с моим другом и коллегой Дэвидом Андерсоном (создателем Канбан Метода), а линза придумана самим Дэвидом. Часть II всецело посвящена обеспечению широты. Канбан не является ответом на все вопросы — одним из его основных правил является использование моделей. Такая установка ориентирует приверженцев метода на широкое использование любых наработок, например системного мышления, бережливого производства, аджайл-подходов и теории ограничений. Я не собираюсь подробно рассказывать о них, но рассчитываю, что моя канбаноцентричность подтолкнет вас изучить их более глубоко и интегрировать в свое мировоззрение. Часть III рассказывает о процессе реализации Канбан Метода в организационном контексте. Дэвид называет это «Системным Подходом к Представлению канбана» (Systems Thinking Approach to Introducing Kanban — STATIK). Процесс является фундаментом нашего обучения методу на базовом уровне. Я модернизировал его, добавив информацию о девяти ценностях и повестках из части I и некоторых моделях из части II. Думаю, вы заметили, что я выделяю курсивом слова и фразы, используемые в качестве технических терминов, например начните с того, что есть сейчас является первым фундаментальным принципом Канбан Метода, серьезные игры подразумевают нечто четко определенное. Вы найдете большинство этих терминов в словаре. Такие термины, как баланс и клиентоориентированность, выделенные жирным шрифтом, входят в девятку ценностей канбана. Часть I Канбан в зеркале своих ценностей Мой подход к представлению Канбан Метода несколько необычен. Как правило, суть канбана объясняют на примере его фундаментальных принципов и основных практик. Я чуть отступлю от этой традиции и начну с девяти ценностей. В части I каждой из них посвящена отдельная глава. Они идут в следующем порядке: прозрачность, баланс, сотрудничество, клиентоориентированность, поток, лидерство, понимание, согласие и уважение. Это нисколько не мешает рассказу о принципах и практиках канбана, которые упоминаются в каждой главе. Для удобства я присвоил четырем Фундаментальным Принципам канбана обозначения от ФП1 до ФП4: ФП1: начните с того, что есть сейчас. ФП2: договоритесь об эволюционном развитии. ФП3: в качестве первого шага проявите уважение к существующим процессам, ролям, обязанностям и служебному положению. ФП4: поощряйте проявления лидерства на всех уровнях организации — от отдельного работника до высшего руководства. Таким же образом обозначены шесть Основных Практик: ОП1: визуализируйте. ОП2: ограничивайте объем незавершенной работы (Work-in- Progress — WIP). ОП3: управляйте потоком. ОП4: сделайте правила работы явными. ОП5: используйте циклы обратной связи. ОП6: улучшайте совместно, эволюционируйте через экспериментирование (используя модели и научные методы). Вместо подробного технического обоснования каждого принципа и практики я хочу представить точку зрения инсайдера, объяснить, как люди, практикующие канбан, — менеджеры, рядовые сотрудники и внешние эксперты — подходят к решению организационных проблем. Ценности помогают сосредоточиться на сути принципов и практик и упростить их адаптацию к потребностям текущей ситуации. В последней главе части I девять ценностей представлены в разбивке по трем повесткам и вводится еще один полезный инструмент — Канбан Линза. Глава 1 Прозрачность Мы находимся на одном из верхних этажей нашего сверкающего нового офиса, выходящего на вокзал Ньюгати в Будапеште. На часах 9:30, и традиционный стендап митинг в полном разгаре. Все оживлены больше обычного в предвкушении похода через дорогу за кофе и пирожными, чтобы отпраздновать наш последний этап «обучения». Я угощаю — накануне я оставил текущую сборку программы на несколько часов без внимания, а ИТ-директор не должен так поступать. Но сначала нам нужно решить более важный вопрос. Тибора и Мате волнует карточка (стикер желтого цвета), которая вот уже несколько дней красуется в столбце «Выполнено» на доске нашей команды. В разговор вмешивается Ди, предлагая свою помощь: он уверен, что сможет убедить отдел эксплуатации в том, что новая ценовая кривая, представленная этой застрявшей карточкой, более надежна, чем старая. Можно ожидать, что она будет реализована в производстве через день-два. Предложение Ди с благодарностью принимается, и мы переходим к следующей карточке. Этих нескольких моментов достаточно для того, чтобы продемонстрировать первую ценность канбана — прозрачность. Любой может видеть наш рабочий процесс на большой доске. К ней прикреплены карточки, каждая из которых представляет рабочий элемент. Карточки располагаются в столбцах, которые обозначают этапы выполнения работы («Выполнено» — это один из этапов) или стадию нашего глобального производственного процесса. Мы понимаем важность регулярной обратной связи и проводим стендап митинги. Мы сформулировали ряд правил, которые определяют нашу работу, причем большинство их вывешены рядом с доской. Одно из них гласит, что разработчики отвечают за выполнение рабочих элементов до тех пор, пока не получат обратную связь от пользователя о том, что они сделали то, что нужно. Второе правило подчеркивает, что обучение — особенно такую его форму, как «я больше не сделаю подобную ошибку», — следует подкреплять пирожными. Описанные события происходили в 2009–2010 гг., когда Дэвид Андерсон собирал отзывы о только что сформулированных им фундаментальных принципах и основных практиках Канбан Метода. Мы — это люди вроде меня, которые уже применяли эти идеи, — обсуждали и уточняли их в нашем групповом мейл-листе. Через несколько недель наши отклики вошли в «синюю книгу» Дэвида [2] . У нас появился документально зафиксированный метод! Прозрачность — главная ценность канбана. С нею связаны три из шести основных практик: ОП1: визуализируйте; ОП4: сделайте правила работы явными; ОП5: используйте циклы обратной связи. Рассмотрим их по порядку. Основная практика 1: визуализируйте Практика, выраженная единственным словом «визуализируйте», кажется не совсем конкретной. Однако большинство действий, связанных с Канбан Методом, осуществляется с использованием конкретного средства визуализации — канбан-доски. Эти доски необходимы для реализации канбан-системы — визуальной системы управления производством, которая имеет ряд очень полезных свойств. Мы подробно рассмотрим их в последующих главах, а сейчас сосредоточимся на визуальных аспектах. Если бы мы использовали электронную доску, то она, возможно, выглядела бы, как показано на рис. 1.1. Вместо стикеров на доске используются иконки, которые можно перемещать по экрану. Независимо от вида доски (электронная или физическая) стикеры или иконки называются японским словом «канбан», что можно перевести как «визуальный символ». Мы предпочитаем оперировать более привычными терминами карточка (или тикет — я использую эти два термина взаимозаменяемо) и рабочий элемент, причем под первым понимается визуальное представление, а под вторым — содержание. В этой книге рабочие элементы представляют собой четко определенные элементы интеллектуальной работы, например характеристики продукта, который надо создать, или заявки на обслуживание, которую необходимо выполнить. Они не обязательно связаны с разработкой программного обеспечения — мы видели примеры использования метода юристами, отделами кадров, отделами продаж и генеральными директорами. Во всех этих случаях большая часть работы выполняется в головах или в компьютерах сотрудников. Без доски работа остается невидимой. Это может показаться банальным, но очень важно, чтобы карточки были подвижными. Их перемещают из одного столбца в другой по мере выполнения рабочего элемента. Это позволяет моментально увидеть объем незавершенной работы на любом этапе выполнения проекта. Попробуйте сделать такое с помощью плоского списка задач! Если размер доски достаточен, а сами карточки яркие, то можно видеть ситуацию даже из противоположного конца комнаты: какая работа блокирована (в ожидании чего-либо); кто над чем работает; какие виды работ выполняются и в каком соотношении; какой объем работы имеется на каждом этапе выполнения. Когда вся эта информация постоянно на виду, очень быстро понимаешь, как должны идти дела. Освоив такой подход, сразу видишь, когда появляются отклонения от нормы и требуется вмешательство или коррективы. Визуализация и изменения В канбане цель визуализации и других форм прозрачности двояка — показать необходимость действия и помочь сделать правильный выбор. Это работает на двух уровнях: действие в форме работы, которую необходимо выполнить; правильный выбор рабочего элемента, которому нужно внимание; действие в форме изменений в системе; правильный выбор при обосновании изменения, определении его масштабов и внедрении. Как вы будете реагировать, когда доска показывает, что не все идет как надо? Ниже перечислены несколько вариантов ответов, типичных для руководителя или наставника: 1. Не стоит волноваться, все обойдется, как обычно. 2. Я, как руководитель, приму меры и буду следить за ситуацией, пока все не уладится. 3. Я внесу изменения в систему. 4. Они понимают, что привело к такому развитию ситуации? Они хотят внести изменения в систему? Как мне им помочь? 5. Я уважаю их способности вносить необходимые изменения в такой ситуации. Каждый из этих ответов может быть верным в конкретной ситуации, но некоторые кажутся более зрелыми по сравнению с остальными. Подталкивая к действию и поддерживая правильный выбор, канбан побуждает к более зрелой реакции (ответы 4 и 5). Любая организация, сознательно следующая этим установкам и использующая стиль лидерства, стимулирующий их применение, уверенно движется к совершенству. Ответ 5 (и, в меньшей степени, ответ 4) ориентирован на еще один очень интересный аспект — на самоорганизацию. Самоорганизация — прекрасная вещь. Она означает не просто то, что люди способны действовать самостоятельно, хотя это чрезвычайно важно для успеха, но и то, что система может перестраивать сама себя для более эффективного решения проблем. Самоорганизация в полном смысле слова усиливает гибкость и устойчивость, а тот факт, что ей не требуется внешнее вмешательство, обеспечивает ее масштабирование. Самоорганизация эффективна и гуманна как с точки зрения работы системы, так и ее изменения. Изменения системы при визуальном управлении осуществляются быстро и недорого. Сотрите на доске одну-две линии, проведите другую и передвиньте несколько карточек (или несколько раз кликните мышкой). С учетом того, что влияние изменений может быть огромно по сравнению с затраченными усилиями, такая работа с системой открывает большие возможности. Здесь включается механизм самоусиления: канбан-система организует работу; люди организуются вокруг работы; взглянув свежим взглядом на канбан-систему, люди понимают, что они могут работать по-другому и лучше, и они меняют систему. Основная практика 4: сделайте правила работы явными Канбан-доски очень эффективны с точки зрения организации работы, однако некоторые аспекты системы не так легко описать с помощью визуального языка карточек, цветов, столбцов и т.п. Иногда лучше использовать короткие правила. Это не законы, продиктованные сверху, это способ, позволяющий участникам системы одинаково понимать принципы ее функционирования. Это еще одна сторона прозрачности — наряду со стратегией превращения невидимого в видимое мы стремимся сделать неявное явным, но если (и только если) мы считаем, что это поможет принимать лучшие решения. И снова нам нужен рычаг — несколько тщательно подобранных слов, отражающих суть намерения, а не толстый документ, который охватывает все. Я видел правило, состоящее всего из одного слова «Демо!» на доске над соответствующим столбцом — этого вполне хватало, чтобы подкрепить рабочую договоренность. Многие правила описывают качества, которыми должны обладать рабочие элементы, входящие или покидающие столбец, например: Рабочие элементы в колонке «Готово» не должны задерживаться более пяти дней. В Будапеште мы называли это «правилом пяти дней», которое позже превратилось в «правило двух дней». Рабочие элементы не могут перемещаться в столбец «Тест» до тех пор, пока они не пройдут ревью и не будут продемонстрированы всей команде. Наклейки на доске или рядом с ней типа «<5 дней на разработку», «Разбор программы» или «Демо!» превосходно напоминают о том, чего ждет команда в ближайшем будущем. Правила могут иметь и более общий характер: Стабильность продукта имеет больший приоритет, чем устранение ошибок при тестировании; при этом и первое, и второе имеют более высокий приоритет перед новой разработкой. Принимаясь за новый проект, проинформируйте заинтересованных лиц, если они могут повлиять на выполнение имеющихся работ. Эти примеры не являются универсальными, но их достаточно просто перенести в похожие обстоятельства. Они встречаются довольно часто. Иногда попадаются основополагающие принципы, которые перенести в похожие обстоятельства проще, чем правила, — например, «отпраздновать окончание обучения» перенести проще, чем «есть пирожные». Однако в правилах, которые уникальны для каждой ситуации, нет ничего плохого. Так что все определяется контекстом! Правила и изменения Мы вводим новые правила, когда считаем, что дополнительная ясность поможет либо сделать лучший выбор, либо сделать этот выбор более эффективно. Когда мы задумываемся о новых правилах, самое время поговорить о причинах этого, например: Более крупные рабочие элементы обычно вызывают больше трудностей по сравнению с мелкими. (Это может быть больше, чем предположение — у нас, возможно, есть факты, подтверждающие данную гипотезу.) В целом лучше закончить что-либо, чем начинать дополнительную работу. (К этому можно отнестись как к житейской мудрости — «Перестаньте начинать, начните заканчивать!» — или как к проверенной временем теории.) Когда мы делаем правила явными, это сразу вызывает необходимость проверки правильности базовых идей. Если реальность не совпадает с этими идеями, то мы будем постоянно входить в противоречие с правилами. Это создает дискомфорт, способствующий переоценке идей и дальнейшему обучению. По этой причине полезно начинать с простых правил, которые отражают сложившуюся практику (что, фактически, делается большую часть времени независимо от официальной политики) и совершенствуются по мере необходимости. Принцип «начните с того, что есть сейчас» здесь важен так же, как и в других ситуациях. Запишите эти правила и попробуйте опровергнуть их. Например, всегда ли есть смысл устраивать здесь демонстрацию? Может быть, результат 10-дневной работы и так хорош? Стратегия — делать явным то, что прежде подразумевалось, применима к определению самого Канбан Метода. Наличие циклов обратной связи и практика их использования были настолько «очевидны», что никто не подумал об их включении в его первоначальную редакцию. Основная практика 5: используйте циклы обратной связи Несмотря на это упущение, обратная связь очень важна. В ее отсутствии признаки проблем в системе останутся незамеченными или к ним отнесутся так небрежно, что толку от этого не будет. Циклы обратной связи необходимы для того, чтобы сделать прозрачность эффективной движущей силой изменений. Как и в случае визуализации, формулировка этой практики открыта для интерпретации и творческого применения. Так и было задумано. Чтобы подойти к проблеме более конкретно, рассмотрим три рядовых примера собраний, где всегда есть возможности для появления разных видов обратной связи. В конце этого раздела мы рассмотрим циклы обратной связи, основанные на количественных показателях. Стендап митинги Если рекомендовать какую-нибудь аджайл-практику, то я выбрал бы стендап митинги, которые проводятся стоя. Некоторые группы отказываются от таких совещаний, не видя в них особой пользы, но через несколько дней или недель, когда дела начинают идти плохо, возвращаются к ним. Все дело, возможно, в кажущейся фамильярности такой практики. Стендап митинги — это настолько короткие совещания, что большинство участников могут без труда простоять от начала до конца. Они проводятся регулярно (часто ежедневно). Быстрота приходит с практикой: участники понимают, что к чему, информируют о том, что изменилось, сообщая только необходимые подробности, и соблюдают дисциплину, не отвлекаясь на посторонние разговоры. Стендап митинги могут иметь разные формы: неформальные, неструктурированные, без определенной повестки совещания (это трудно рекомендовать); опрос, который проводит руководитель (когда менеджер проекта заслушивает отчет подчиненных); совещания в офисе, возможно в скрам-формате, когда все по очереди отвечают на вопросы: Что я делал вчера? Что я планирую делать сегодня? Какие препятствия мешают мне работать? [3] ; обзор рабочих элементов на доске. Обзор проводится справа налево, начиная с рабочих элементов, которые близки к завершению. Совещание прекращается, когда продолжение рассмотрения рабочих элементов левее по потоку становится уже не эффективным; обзор канбан-доски справа налево, но с обсуждением только тех рабочих элементов, которые заблокированы или выполнение которых находится под угрозой. Совещания в скрам-формате, как и совещания, связанные с обзором выполнения рабочих элементов на доске, поддерживают нашу установку на повышение прозрачности принимаемых решений — над чем и как работать, когда нужно вмешаться и помочь в выполнении задачи, когда отступить на шаг и посмотреть, как фактически функционирует вся система. Конечно, регулярные стендап митинги являются важным фактором создания сплоченной команды. Члены команды получают огромную пользу от них, причем не только в результате информирования о том, как идут дела, но и потому, что регулярные отчеты помогают получить представление о работе коллег. По мере формирования атмосферы доверия и углубления понимания потребностей коллектива общение становится более откровенным и продуктивным. Одним словом, эти 15 минут тратятся не зря. Наверное, вы не удивитесь, узнав, что я решительно предпочитаю форматы, связанные с обзором доски. Они укрепляют мысль о том, что мы вместе хотим довести работу до финишной черты, фокусируют внимание на цели, а не на человеке, отвечающем за данный участок работы. Однако я не зацикливаюсь на них и считаю, что по мере того, как члены команды знакомятся с нашими методами и друг с другом, они могут легко и естественно переходить от одного стиля общения к другому независимо от того, формальные они или неформальные. Вы тоже проводите похожие совещания? Тогда, следуя правилу делать неявное явным, задайте себе вопрос: почему вы проводите их в таком формате? Удается ли вам полностью реализовать свои намерения? Помогают ли совещания решать проблемы посредством самоорганизации коллектива или нет? Совещания по пополнению Совещания по пополнению — еще одна широко распространенная практика [4] . Это форум, на котором входная очередь рабочего процесса (или, если хотите, его бэклог) пополняется новой работой. Кроме того, это прекрасная возможность оценить удовлетворенность заказчика, изучить его потребности и сопоставить их с возможностями команды. Такое совещание является важным циклом обратной связи, потому что дает возможность получить оценку со стороны. Я не буду сосредотачиваться на механике совещаний по пополнению по двум причинам: 1. Они очень сильно зависят от конкретной ситуации. Например, то, как вы работаете с одним внутренним заказчиком, очень сильно отличается от того, как строится работа с несколькими внешними заказчиками. Планируйте процесс так, чтобы он соответствовал ситуации, и будьте готовы к проведению совещаний по мере необходимости или полному отказу от них. 2. Я не раз видел, как команды зацикливаются на потребностях процесса (или, что еще хуже, на потребностях любимого процесса его организатора) в ущерб заказчику. Кому в действительности служит этот бег с препятствиями? Другие виды совещаний Некоторые совещания являются внешними по отношению к рабочему процессу, поскольку их функция заключается в управлении изменениями. Популярная аджайл-практика, которая иногда используется совместно с Канбан Методом, предусматривает регулярные ретроспективные собрания на уровне команды. Есть варианты, когда для проведения изменений делают оперативные совещания «на месте». Мы же настоятельно рекомендуем проводить еженедельно или раз в две недели обзор сервиса (service delivery reviews) на уровне команды или подразделения (иногда такие совещания называют обзором возможностей системы — system capability reviews) и ежемесячные операционные обзоры (operations reviews) на уровне филиала. На таких совещаниях команды делятся друг с другом и (в идеале) с представителями заказчика и организации в целом информацией о своей производительности, инцидентах и произведенных усовершенствованиях. Возможно, вы уже проводите похожие или такие же совещания. Конечно, цель состоит не в том, чтобы проводить как можно больше совещаний, а в создании условий, при которых регулярно и своевременно работающие циклы обратной связи дают максимальный эффект. Эти условия заслуживают самой тщательной подготовки. Циклы обратной связи на основе метрик График на рис. 1.2 — это моя накопительная диаграмма потока (cumulative flow diagram — CFD). Я сделал ее следующим образом: 1. Раз в несколько дней я подсчитывал, сколько карточек находится в каждом столбце доски. 2. Определял общее количество законченных рабочих элементов, чьи карточки были сняты с доски (по этой причине график называется накопительным). 3. Визуализировал эти значения с помощью диаграммы с областями и накоплением в Excel, выстраивая их таким образом, чтобы завершенная работа оказывалась внизу. В наши дни вы можете получить такую диаграмму бесплатно в онлайн-пространстве с помощью вашего любимого канбан- инструмента. Даже тот, кто никогда не видел такую диаграмму, может разглядеть на ней столь типичное для начала проекта «раздувание» области незавершенной работы, затем «ступеньки», обозначающие передачу крупных частей работы с одной стадии на другую (в основном, релизов) и, ближе к концу, более плавный ход сдачи работ. Да, на графике есть несколько заметных выступов, но приятно сознавать, что мы справились с проблемами. В моем распоряжении были и другие способы узнать, что поставка осуществляется, но этот график ясно показывал, что время производства на протяжении процесса, частота поставки и даже стиль поставок меняются. И все это было видно на одном графике! Другие виды визуализации и количественных показателей помогают специалистам увидеть, как распределяются затраты времени, получить более глубокое представление о внутренней работе процесса и об удовлетворенности потребителя услугами. Прозрачность как ценность Прозрачность — важнейший атрибут канбана. Она помогает принимать правильные решения в отношении текущей работы и системы в целом. Прозрачность стимулирует самоорганизацию — усиливает осмысленность, способность быстро приспосабливаться к обстоятельствам и гибкость. Она же обеспечивает обратную связь, давая возможность увидеть, что работа движется и есть результаты. Прозрачность стимулирует формулирование и уточнение внутренней логики на многих уровнях. Повышение прозрачности означает, что на поверхность выносится больше материала, появляется больше стимулов к переменам. Ограничением здесь служит лишь такой аспект, как уважение. Мы надеемся, что по мере «взросления» организации аппетит к увеличению прозрачности будет расти. Вообще говоря, чем больше прозрачности, тем лучше. Однако одной прозрачности как таковой недостаточно. Она не является заменой эффективному сотрудничеству; изменения в отсутствие согласия вряд ли приживутся. Иногда мы намеренно сочетаем прозрачность с другими ценностями, например с клиентоориентированностью во время собраний по пополнению. Короче говоря, ключ к расширению пределов прозрачности в вашей организации может заключаться в восьми других ценностях. Глава 2 Баланс Основная практика 2: ограничивайте объем незавершенной работы Баланс — это ценность, тесно связанная со второй основной практикой канбана: ОП2: ограничивайте объем незавершенной работы (WIP — work- in-progress). В первой части этой главы я продемонстрирую, как ограничение WIP на канбан-доске работает в качестве механизма координации для реализации вытягивающей системы. Позже мы рассмотрим другие случаи проявления баланса в канбане. Вытягивающие системы для интеллектуальной работы Рассмотрим столбец «Тест» на доске (рис. 2.1). В правом верхнем углу столбца «Тест» стоит цифра 4. Она обозначает WIP-лимит, т.е. максимально допустимое в этой зоне количество рабочих элементов. В приведенном примере общее количество рабочих элементов в столбце «Тест» (включая два его подстолбца «В работе» (In Progress) и «Выполнено» (Done)) не должно превышать четырех. Наше приложение выделяет лимит, потому что эта часть доски в данный момент максимально загружена. Теперь посмотрим, что происходит на рис. 2.2, когда карточки перемещаются вправо, причем как внутри, так и (что важно) за пределы выделенной зоны. Зона «Тест» на доске теперь не заполнена целиком. Пространство в подстолбце «В работе», оставшееся пустым, играет очень важную роль — оно сигнализирует, что можно вытянуть туда карточку из соседнего (левого) столбца. Вытягивающая система работает следующим образом: по мере того, как работа движется к завершению (вправо по доске), эти сигналы (освободившиеся ячейки) перемещаются в начало (влево), показывая, что можно по мере готовности перетягивать на свободные места другие рабочие элементы. Когда есть участки столбцов с ограничениями (собственными или общими), а сигналы и перемещения могут сдвигаться влево очень быстро, система представляется связанной, как это и должно быть. Канбан-доска дает нам нечто совершенно особенное — практичную вытягивающую систему для нашего нематериального продукта, интеллектуальной работы. Если не устанавливать WIP-лимиты, то сигналы для перемещения карточек теряются. Перемещающийся влево поток сигналов останавливается, как только достигнет столбца, в котором отсутствует ограничение (в данном случае это столбец «Предложено» (Proposed) на левом краю доски). Эти неограниченные (или бесконечные) очереди приобретают огромную важность, когда измеряется время, необходимое для прохождения работы через систему. Мы называем время на перемещение рабочего элемента от одного столбца без ограничения, до другого столбца без ограничения, через столбцы с WIP-лимитами временем производства канбан-системы. Оно может очень сильно отличаться от времени производства заказчика — времени выполнения заказа с точки зрения клиента [5] Баланс Загрузки и Возможностей Рассмотрим ситуацию на доске (рис. 2.2) с точки зрения людей, наиболее тесно связанных с этими самыми столбцами «Тест». Они могут быть тестировщиками или теми самыми разработчиками или аналитиками, которые занимались этими участками работы на более ранних стадиях; в интересах самоорганизации на доске это не отражается. Однако доска позволяет убедиться в том, что объем работы в этой зоне не выйдет (или не должен выйти) за пределы возможностей. Это значит, что мы предприняли серьезные шаги к тому, чтобы избежать перегрузки людей, не доводить ситуацию до такого состояния, когда она становится, в лучшем случае, контрпродуктивной, а в худшем — негуманной. Стоит сделать завершение работы приоритетным по отношению к ее началу, и качество работы повысится — это объясняется тем, что у сотрудников появится возможность сосредоточиться на меньшем количестве задач. В результате на доске будет больше свободных ячеек. Чем меньше рабочих элементов на каждом участке производственного процесса, тем быстрее завершится работа в целом, а результаты обратной связи появятся раньше. Тем не менее время от времени создается впечатление, будто WIP-лимиты заданы неверно. Когда они слишком высоки, то вроде не оказывают особого влияния на процесс. Но если приглядеться, то становится очевидным, что выполнение многих рабочих элементов застопоривается из-за нехватки людей. Если WIP-лимиты установлены слишком маленькими, то слишком большая доля работы может оказаться заблокированной в любой момент времени из-за того, что отдельные части системы «зависли», а люди сильно недозагружены. Такие ситуации должны служить причиной для обсуждения и подробного изучения, а также для внесения корректив. Естественной реакцией может быть изменение лимитов, но слишком спешить не стоит. Сначала удостоверьтесь, что все, кого это касается, разобрались в причинах создавшейся ситуации, и действуйте, исходя из этого. Ограничения WIP намного полезнее воспринимать не как простые политические рычаги, а как механизм обратной связи и полноценные факторы усовершенствований в масштабах всей системы. Когда вы уменьшаете объем WIP, то делаете намного более очевидными другие проблемы (а они могут мешать еще сильнее). Решите их, и тогда объем WIP можно будет уменьшить дополнительно — он даже может уменьшиться сам собой [6] . Это еще один механизм самоусиления, причем очень мощный. Его очень успешно в течение многих десятилетий использует компания Toyota [7] Противоположностью этого механизма я считаю порочный круг, который возникает, когда главной заботой становится постоянная занятость людей. В этом случае первая реакция на застопорившуюся работу заключается не в решении проблемы, а в начале выполнения еще одной рабочей задачи, что приводит к увеличению объема WIP в системе. Чем больше незавершенной работы, тем больше время ожидания у тех, кто будет ее завершать, а значит, проблема только усугубляется. Задержки и одновременное выполнение множества задач оказывают негативное воздействие на качество и являются причиной — да вы и сами, наверное, догадались — ошибок и переделок, большего объема застопорившейся работы и WIP. Слишком много работы в сочетании с плохим качеством — вам нравится такая комбинация? Другие способы ограничить WIP Я бы не хотел создавать впечатление, что WIP-лимиты на уровне столбцов — это единственный способ ограничения объема незавершенной работы. Он достаточно действенный, но иногда работает лучше в сочетании с другими механизмами. Их можно условно разделить на две основные категории: 1. Уменьшение размера пакетных транзакций — сокращение размера (в плане бюджета и продолжительности) проектов, интервалов между релизами, а также размеров спринтов, размера пакета разрабатываемого функционала и т.д. 2. Уменьшение количества событий, развивающихся параллельно, — сокращение количества бизнес-инициатив (к которым привязаны проекты), сокращение количества сопутствующих проектов в расчете на группу или отдел, сокращение количества рабочих элементов в расчете на группу или на человека и т.д. Здесь в нашем распоряжении множество рычагов! Выберите правильный, и вы увидите, что другие поддаются легче как в техническом, так и в психологическом смысле. Ограничение объема незавершенной работы разными способами позволяет довести его до такого уровня, который когда-то мог казаться недостижимым. Ситуация в Будапеште, с которой начинается глава 1, сложилась не сразу. Я пришел работать в организацию, которая просто «подсела» на WIP. Как это часто случается в молодых компаниях, им было просто очень трудно сказать «нет». Это относилось не только к взаимодействию с внешними заказчиками — не говорить «нет» превратилось в привычку и в отношениях между подразделениями компании. От одного совещания к другому списки необходимых дел (а таких списков было очень много) становились все длиннее и длиннее. Через несколько недель после моего появления в организации и начала плавного и спокойного использования Канбан Метода на совещании руководства случилось очень важное событие. Марк Дикинсон, наш управляющий директор, объявил, что с этого момента персональные списки задач становятся достоянием истории, и мы немедленно от них отказываемся. Сказать, что я обрадовался, было бы сильным преуменьшением — на мой взгляд, произошел существенный прорыв, очень важный для всех нас. Затем мы стали свидетелями множества таких прорывов. Несколько месяцев спустя количество бизнес-инициатив было сокращено до минимума, остались лишь те, что наиболее эффективно поддерживали нашу бизнес-стратегию. Это, в свою очередь, повлияло на проекты, часть которых были приостановлены или полностью отменены. Как только появилась возможность присмотреться к нашим проектам повнимательнее, оказалось, что вовсе не те из них, что стояли первыми в очереди, являлись более срочными. Обнадеживало то, что в большинстве случаев процесс смены приоритетов (в сфере ИТ) шел, не дожидаясь моего вмешательства — иногда проекты добровольно отзывали их спонсоры (мои коллеги из руководства). Не знаю, приходилось ли вам сталкиваться с отменой уже выполняемых проектов, но, по моему опыту, это бывает достаточно редко. Если это случается регулярно, то происходит что-то необычное. Баланс срочной работы и работы с привязкой к дате Не все работы похожи друг на друга, и это особенно справедливо для интеллектуальной работы. Многие руководители пытаются отрицать разнообразие или избавиться от него, не понимая, что намного лучше воспользоваться им. Давайте подробно рассмотрим небольшую часть нашей доски, показанной на рис. 2.3. Пусть вас не смущают непонятные названия трех рабочих элементов, сконцентрируйте внимание на различиях в их визуализации. Для начала возьмем две верхние задачи Tokyo gateway upgrade и Swap curve. Рабочий элемент Tokyo gateway upgrade помечен карточкой с иконкой в виде календаря, т.е. это рабочий элемент с привязкой к дате. В данном примере речь идет о том, что интерфейс Токийской фондовой биржи должен измениться в определенный день, поэтому нам нужно к этому моменту обновить системы соответствующим образом. Если мы осуществим эти изменения слишком поздно, то не сможем торговать на данной площадке, и это может обойтись организации слишком дорого. Однако слишком ранняя поставка не принесет выгоды — более того, она может быть даже вредной. Рабочий элемент Swap curve совсем другой. Он представляет совершенно независимую функциональность. Чем скорее он будет выполнен, тем раньше начнет приносить пользу. В отличие от предыдущего примера, этот рабочий элемент не привязан к дате, он является срочным. Если мы сможем завершить выполнение срочного рабочего элемента раньше рабочего элемента, привязанного к определенной дате, то это прекрасно. Однако приоритет переходит к рабочему элементу с привязкой к дате, как только возникнет опасение, что он оказывается под угрозой. И в том и в другом случае мы получаем хорошие результаты [8] Одинаковый подход к этим рабочим элементам ничего хорошего не принесет. Например, если привязать срочный рабочий элемент к произвольно выбранной дате, то можно поставить под угрозу выполнение рабочего элемента, который изначально имел привязку к дате. Если считать оба рабочих элемента срочными, то у нас не будет возможности избежать риска срыва графика. Таким образом, ни один из этих подходов не способствует принятию правильных решений. Многие команды разработчиков страдают из-за того, что либо привязывают все рабочие элементы к определенной дате, втискивают слишком много работы во временне окна, либо, что еще хуже, привязывают каждый рабочий элемент к дате индивидуально. В результате оценочные сроки превращаются в обязательства. Целевые показатели продуктивности растягивают обязательства до предела, и это происходит в тот момент, когда начинаются первые заминки! Классификация на основе рисков и классы обслуживания Рабочий элемент Try MongoDB (оставшийся в столбце) не кажется ни привязанным к дате, ни срочным. Но разве из-за этого он становится неважным? По этому рабочему элементу судить трудно, но где мы окажемся через год или два, если не будем экспериментировать и делать неафишируемую работу, |