Канбан Метод. T memarketologmanager
 Скачать 4.05 Mb.
|
|
Чьи потребности исследуются на этой стадии процесса и каким образом? Чьи потребности не исследуются, и какие риски это несет? [13] Чему мы учимся на этой стадии из того, что не знали (или не могли знать) раньше? Каким образом работа на этой стадии помогает сфокусироваться на том, что понадобится в будущем? Что еще нужно изучить? Как лучше справляться с неопределенностями — двигаться вперед или сделать шаг назад? Применяя эту логику ко всем этапам процесса вплоть до самого начала, мы ориентируемся уже не на заданные требования, а на удовлетворение потребностей, которые нужно обнаружить и исследовать. Надо не оглядываться назад, оправдываясь и доказывая, что мы делаем программное обеспечение «в соответствии со спецификацией», а смотреть вперед, работая над удовлетворением потребностей, которые пока еще не раскрыты. Мы не особенно надеемся на, казалось бы, безупречный процесс, который сделает нашу работу за нас, а ищем пути более эффективного обучения. Творческая интеллектуальная работа — это не то, что мы уже знаем. Это (тут я сознательно прибегаю к техническому жаргону) процесс поиска знаний. Используйте канбан-доску для того, чтобы она постоянно напоминала вам о вопросе «Что мы не знаем?». Предваряющий канбан Я бы хотел схематично показать один из более сложных вариантов доски, который сам использую для управления своей рабочей загрузкой (рис. 4.1). Его основной отличительной особенностью является наличие трех столбцов под шапкой «Идеи». Обратите внимание на то, что их уменьшающиеся лимиты объемов незавершенной работы наводят на мысль о последовательном исключении. Такой дизайн полезен, если нужно упорядочить идеи и задачи, которые можно выполнить в будущем, помимо управления текущей рабочей нагрузкой. Ниже я привожу два основных приема, позволяющих эффективно использовать такую доску: 1. Научитесь мысленно закрывать крайние левые столбцы до тех пор, пока не придет время пополнить столбцы, расположенные правее, или изменить приоритеты. Вскоре это превратится в привычку. Кроме того, нет никаких сомнений в том, что вы используете систему вытягивания. Если вы хотите пополнить очередь в столбце «Готово», то можете сделать это, используя только относительно небольшое количество рабочих задач (всего пять) в столбце «Приоритет 1», что намного легче, чем рассматривать весь набор идей. 2. Сбалансируйте стремление добавить на доску новые идеи с готовностью убрать с нее рабочие задачи, которые с большой вероятностью никогда не дойдут до столбца «Готово». Удаленные рабочие задачи можно поместить в архив, чтобы проанализировать в будущем, или полностью уничтожить (я предпочитаю передвигать отдельные рабочие задачи в область промежуточного хранения «ниже линии» и периодически разбираться с ними). Понятно, что ограничение зоны незавершенных работ является напоминанием о следовании этим двум правилам. Как только доска начнет заполняться, вы увидите, что занимаетесь исключением рабочих задач из числа приоритетных намного чаще. И это очень полезно и разумно! В этом варианте доски меня вдохновляет идея сита приоритетов — метод из книги «Персональный канбан» [14] Мой неожиданный переход к этой теме сейчас может показаться странным (мы кратко вернемся к нему в части II), но я использую этот дизайн в качестве модели для предваряющего канбан (Upstream Kanban). Это название ввели для обозначения практики применения системы канбана до процесса поставки. Предваряющий канбан — это организация потребностей и развитие идей таким образом, чтобы всегда имелся хороший выбор по предложениям, когда появляются свободные возможности поставки. Этот дизайн подкрепляет два принципа, кажется, забытых портфельными менеджерами некоторых наших крупнейших корпораций: Мы генерируем больше идей, чем можем использовать — на самом деле, если бы было наоборот, то у нас появилась бы причина бить тревогу. С течением времени мы аккумулируем больше идей, чем можем эффективно использовать. Идеи не могут развиваться только за счет своих собственных достоинств — они конкурируют с другими идеями. Более того, в любой момент могут появиться новые идеи, которые вступают в конкуренцию с уже существующими. Когда рабочие задачи входят в столбец «Готово», происходит нечто странное: эта система имеет очень точно выраженную точку вовлечения. По левую сторону от нее мы были бы счастливы видеть рабочие задачи, сдвинутые назад по срокам или вовсе исключенные из списка. Справа от нее мы видим рабочие задачи, о которых можно сказать следующее: мы считаем, что что-то идет не так, если эти рабочие задачи не выполняются достаточно быстро, и сожалеем о затраченных впустую усилиях, если от задач отказываются, когда они практически готовы. Как и в процессе поставки, эффективность предваряющего процесса зависит от тех же ценностей, которые мы уже рассматривали: Прозрачность: система должна сделать так, чтобы мотивы трудного выбора, который предстоит сделать, были видимыми. Логическое обоснование принятия решения должно быть явным. Решения должны быть в центре циклов обратной связи (например, совещаний, посвященных приоритизации). Баланс: объем незавершенных работ в системе контролируется, как с целью надежного поддержания уровня предложения высококачественных идей, так и для своевременного принятия решений. В случае необходимости можно получить дополнительный контроль, распределив незавершенные работы по заказчикам, бюджетной линии, категории риска, стратегической инициативе и т.д. Сотрудничество: качественная оценка рабочих задач для дальнейшей разработки делится между их инициаторами и теми, кто будет их выполнять. Вместо создания преждевременного риска в системе все вовлеченные в процесс стороны (которых может быть несколько) не торопятся принимать окончательное решение, пока не наступит нужный момент. Теперь давайте посмотрим, что к сказанному добавляет клиентоориентированность: Чьим потребностям, по нашему мнению, соответствуют эти идеи? Достаточно ли быстро мы удовлетворяем потребности? Что говорят нам данные? Что говорят нам люди? На чем могут основываться эти потребности? Какие потребности могут оставаться неудовлетворенными? Как мы можем это проверить? Если резюмировать сказанное: можем ли мы лучше понять, что станет нужным в будущем? Предугадывание потребностей Если существует единственная идея, которую я хотел бы донести до вас в этой главе, то она заключается в следующем: перестройте мышление — прекратите делать то, что просят, выполнять запросы, удовлетворять требования и т.д. Переориентируйте процесс на определение и удовлетворение потребностей. Это сдвиг с внутреннего ракурса (что, как нам кажется, мы знаем) на внешний (что еще можно выявить). Это также переход от прошлого (что нам говорили) к будущему (когда будут удовлетворены потребности заказчика). Этот акцент на будущем хорошо отражен в заключительных словах «Обещания компании Toyota своим клиентам». Я обнаружил их на табличке, прикрепленной на стене позади стола клерка, обслуживающего заказчиков у дилера Toyota недалеко от моего дома: …заблаговременно предугадывать потребности в мобильности отдельного человека и общества в целом. Задумайтесь об услугах, которыми вы пользуетесь. Разве вам не понравится, если поставщик этих услуг заблаговременно предугадает ваши потребности? Какие инновации им понадобятся, чтобы сделать это возможным? Можете ли вы перенести такой стиль мышления на свое рабочее пространство? Глава 5 Поток Когда наша команда была сформирована, то оказалось, что мало кто в ней имел опыт работы с такими процессами, как аджайл. Половина моих подчиненных были новичками в части применяемых нами технологий — они не были знакомы даже с языком программирования и никогда прежде не сталкивались с такими методами, как непрерывная интеграция и управление версиями. Но даже в таких условиях они продолжали разрабатывать приложения высокого уровня сложности, используя простые и надежные процессы, способные давать заказчикам новые функции определенного качества в течение часов или дней. Как стала возможна такая трансформация? Наш подход заключался не в обучении членов команды новым процессам или в предложении взять на себя новую роль. Мы просто перешли к применению Канбан Метода, с которым вы знакомитесь сейчас. Короче, мы визуализировали свою работу, продолжая выискивать самые серьезные препятствия, встречающиеся на пути потока задач и стараясь устранять их. Основная практика 3: управляйте потоком (еще раз) Я опять обращаю внимание на мою собственную расширенную версию третьей основной практики канбана: ОП3 (расширенная): управляйте потоком, добивайтесь плавности, своевременности и хороших экономических результатов, предугадывая потребности клиента. О том, как управлять потоком для обеспечения своевременности, мы поговорим ближе к концу этой главы. Большая ее часть будет посвящена плавности. Плавность Канбан не уникален в своей приверженности принципу плавности. В некоторых кругах эта приверженность намного сильнее — она просто перерастает в одержимость! Подготовка менеджеров в компании Toyota включает в себя многочасовое наблюдение за поточными линиями в поисках мельчайшего отклонения от идеальной плавности. Главная идея здесь заключается в том, что не существует настолько плавного производственного процесса, что дальнейшее улучшение не является возможным и целесообразным. Идея начать с наблюдения за производственной линией не очень хорошо подходит для творческой интеллектуальной работы, даже если мы практикуем канбан. Но, как бы то ни было, мы начинаем чувствовать настоящий дискомфорт, когда видим прерванную, заблокированную, незавершенную или возвращенную для переделки работу. Это происходит даже в тех случаях, когда сложившиеся в данный момент в бизнесе обстоятельства, казалось бы, служат удовлетворительным оправданием. Если эта прискорбная ситуация вызывает вопрос «Что это за процесс, который так легко позволяет такому случиться?», то мы уже сделали важный шаг вперед. В книге «Вопрос культуры» [15] Даниэль Мезик напоминает, что мы можем одновременно уделять внимание только ограниченному количеству вещей и событий. Независимо от осознания этого факта при создании своих систем управления производством мы выбираем то, чему будем осознанно уделять внимание. Привнося прозрачность в поток нашей работы, мы делаем именно такой выбор. Как заметил Мезик: «Канбан уделяет явное внимание потоку». Как выглядит поток? Вот несколько признаков того, что работа приобретает характер потока: Вы видите, что между стендап митингами выполняется все больше рабочих задач. Их точное число и частота появления зависят от размера задач, количества людей в команде и интервалов между стендап митингами, однако в большинстве из них ежедневно отмечается некоторый прогресс. Разбивайте крупномасштабные рабочие задачи на более мелкие части (но по-прежнему ценные), если прогресс не очень заметен. С учетом численности сотрудников значительное количество рабочих задач выполняется без помех, что дает уверенность в обеспечении прогресса. Вы чувствуете (и даже можете подтвердить количественно), что рабочие задачи решаются быстрее и более предсказуемо. У рабочих задач сходного типа и размера производственные циклы становятся короче и вписываются в более узкий временной диапазон. Если этого не происходит, то у вас есть к чему стремиться. Если же происходит, то задайте себе вопрос, можно ли еще улучшить поток с помощью этих широких мер. Но ни на секунду не сомневайтесь, что такая возможность существует. Хорошо, когда есть возможность наблюдать признаки потока и даже оценивать его количественно, но не стоит недооценивать ощущения. Очень приятно ощущать, что рабочие задачи выполняются, что рабочая нагрузка не отягощена проблемами, что можно с достаточной долей уверенности делать прогнозы. Это придает уверенность всем — клиентам, организации и тем, кто выполняет работу. Обзор доски (еще раз) В предыдущей главе предлагалось анализировать рабочий процесс с точки зрения клиентоориентированности. Анализ начинался с удовлетворенности клиента и шел в обратном направлении к его исходным потребностям с изучением каждого этапа через линзу получения знаний. Попробуем применить тот же подход к изучению потока, но уже с другой линзой. Зачем идти в обратном направлении? Это заставляет сосредоточиться на том, что действительно нужно, чтобы работа шла потоком, а не на выискивании возможных способов выполнения задач в каждой точке рабочего процесса. В переносном смысле (и возможно даже физически) мы стоим на правом краю канбан-доски и размышляем о том, что мешает плавно довести работу до завершения, вместо того чтобы стоять на левом краю и придумывать способы быстрого выталкивания работы в растущую кучу в центре системы. Протокол канбан- летучек — это своего рода инструмент мышления! Какой будет наша новая линза? Когда мы уделяем более пристальное внимание потоку, то задаем применительно к каждому столбцу примерно такие вопросы: Как рабочие задачи покидают эту стадию процесса? По каким критериям мы определяем их готовность? Как выражены эти критерии? Каким образом мы получаем сигнал о готовности рабочей задачи к перемещению далее по потоку? Как долго рабочие задачи обычно находятся в данной стадии? Какую часть этого срока они находятся в активной работе по сравнению с ожиданием? Каковы самые важные причины непредсказуемости — они связаны с рабочим процессом или с ожиданием? Рабочие задачи обычно ждут высвобождения внутренних ресурсов или их выполнение зависит от внешних факторов? Какая часть ресурсов на этой стадии ушла на переделку? Или это всего лишь жалоба [16] на то, что выполненная работа не полностью удовлетворяет потребности клиента? Как рабочие задачи добираются до этой стадии процесса? По каким признакам мы узнаем, что они готовы к началу работы над ними? Внимание: подобные вопросы позволяют сделать следующие предположения: 1. Процесс имеет разумные цели — удовлетворение правильных потребностей клиента. 2. Рабочий процесс имеет разумные ограничения — он начинается с правильных вопросов и заканчивается правильными результатами. 3. Рабочий процесс разумно организован — он выстроен таким образом, чтобы как можно быстрее служить источником высококачественного обучения. Я видел достаточно примеров обратного, чтобы понимать потенциальную опасность подобных предположений. Ниже я привожу два из них. Однажды я помогал оптимизировать процесс, цель которого заключалась в принятии предложений по изменению дизайна или отказе от них. Было очевидно, что этот так называемый процесс управления изменениями полностью оторван от фактического процесса реализации изменений — его цели и содержание были либо неправильно выбраны, либо рассогласованы. Излишне говорить, что клиента очень недолго удовлетворяли его результаты. Процессы разработки программного обеспечения часто осуществляются в предположении, что думать о приемо- сдаточных испытаниях нужно ближе к окончанию проекта. Это сдвигает возможность ценного обучения к самой последней стадии процесса работы над проектом. Всегда есть более широкий контекст Мы уже видели, как клиентоориентированность создает для команд стимулы думать о более широком контексте, чем их непосредственная работа. Поток делает то же самое по многим измерениям. Размышляя о потоке, нам часто приходится думать о том, как то, от чего мы зависим — материал, информация, идеи и даже люди, — оказывается в нашей части системы. Ведь они не попадают туда в нужное время случайно. Точно так же мы не можем ожидать, что работа всегда будет выходить от нас в подходящий момент, если не подумаем о том, что происходит за нашими стенами, и не убедимся, что маршрут выхода свободен. Вы, наверное, к настоящему моменту поняли, что на самом деле канбан не нацелен на повышение персональной или коллективной продуктивности. Да, мы часто работаем над улучшением системы в пределах своей зоны ответственности, но не ограничиваемся только теми проблемами, которые можем решить исключительно своими силами. Зачастую мы выходим за ее пределы, работаем с другими людьми над более крупными, комплексными проблемами. В данном случае сотрудничество не просто помогает получить результат, оно способствует концентрации коллективных усилий там, где они больше всего необходимы. Несколько простых примеров Ниже я привожу фрагменты списка усовершенствований, осуществленных нами в 2009–2010 гг. Некоторые из них могут показаться чересчур специфическими из-за привязанности к разработке программного обеспечения, но большая часть содержит идеи, которые можно перенести в другие сферы деятельности. Фрагменты расположены в порядке «справа налево», т.е. в обратном порядке относительно процесса поставки готового продукта клиенту. Как было рассказано в предыдущей главе, в конце процесса мы добавили стадию верификации со стороны клиента. Наша первоначальная цель заключалась в ускорении перехода от «просто передано» к «фактически внедрено». Оглядываясь назад, можно сказать, что это изменение стало катализатором конкретного сотрудничества с клиентом, которое, в свою очередь, позволило гарантировать хорошие результаты работы. Кроме того, нам удалось значительно сократить общее время, переделки, жалобы и объем прекращенной работы. Автоматический выпуск релизов. То, что изначально требовало нескольких часов интенсивной ручной работы, сопряженной с высоким риском ошибки, теперь можно сделать за несколько минут с высокой надежностью, кроме того, у нас появилась возможность быстрого отката назад в случае, если что-то пошло не так. Автоматическое тестирование. Мы начали с покомпонентного тестирования низкого уровня, однако постепенно автоматизировали бльшую часть приемо- сдаточных испытаний. Мы научились анализировать результаты тестирования до того, как перейти к анализу кода прикладной программы, и с учетом этого внесли ряд существенных усовершенствований в кодовую базу. Это, в свою очередь, не просто повысило качество тестов, которые мы написали, но и дало возможность существенно упростить тестирование изменений, которые мы вносили в будущем. Внедрение в практику правила «демонстрируй!». Оно требует, чтобы разработчик каждой вновь написанной программы демонстрировал ее всей команде, а не только аналитику. Только после этого работа перемещается из раздела «Разработка» в раздел «Тестирование». Это предотвращает преждевременное перемещение работы из раздела в раздел и создает хорошие возможности для обмена знаниями и генерирования идей. В том, что касалось анализа кода, мы придерживались принципа «никаких сюрпризов», но на современный манер. Мы считали, что в анализе кода нет необходимости, когда он написан методом парного программирования (разработка программного продукта с участием двух программистов, совместно работающих за одним компьютером). «Правило пяти дней». Мы совместно постановили, что на выполнение рабочей задачи, как правило, не должно уходить более пяти дней. Со временем это правило превратилось в «правило двух дней». Мы доработали это правило c исключением (его следует задействовать с осторожностью), которое касается рабочих задач, которые не так легко разбить на составные части. Введение ежедневных перемещений рабочих задач с целью получения поддержки вместо еженедельных. При старой системе (еженедельные перемещения) случались регулярные и длительные задержки разработки, что сказывалось на предсказуемости наших результатов. С внедрением системы ежедневной ротации у нас появилось правило, в соответствии с которым запросы на получение поддержки передавались по утрам. Такая практика давала возможность гарантированно получать необходимую помощь даже в том случае, если ее объем был велик (мы находили баланс между потоком работы, связанной с поддержкой, и потоком работы, связанной с разработкой программных продуктов). Мы тщательно следили за тем, откуда чаще всего исходят запросы на поддержку, и предлагали разработать и внедрить там локальные правила. По мере решения общих проблем и с организацией совместного обучения в смежных отделах количество обращений за помощью пошло на убыль. Поток в крупной организации Чем больше становится организация, тем больше сервисов требуют ее потоки. Обычно какие-то сервисы задействованы в одном потоке, а остальные используются в нескольких и, возможно, являются аутсорсинговыми. Некоторые сервисы являются частью «главного потока», а другие используются только по запросу. На рис. 5.1 показаны некоторые проблемы масштаба. При значительных масштабах возникает масса возможностей для задержек и срывов. Группа, ответственная за получение запросов на выполнение работ, и группа, ответственная за выполнение работы, — это две разные группы. Использование средств коммуникации, основанных на принципе «выстрелил и забыл» (особенно электронной почты), приводит к тому, что работа остается незамеченной. Возникают нестыковки представлений о «Сделанном» и «Готовом» у сотрудников или команд. Эти качественные проблемы могут быть вызваны ошибками при следовании правилам или неудачным сотрудничеством, а зачастую тем и другим вместе. Производственная деятельность осуществляется не на той стороне границы организации в отрыве от наиболее необходимых навыков или источников информации. Процесс включает в себя ненужные шаги, которые можно было бы без проблем встроить в другие этапы, а также шаги, которые можно разложить на компоненты и перенести на более ранний срок, чтобы быстрее получить важную обратную связь. Неадекватное внимание уделяется общекорпоративным сервисам, от которых зависит главный поток. Эта проблема играет двоякую роль: проблема зависимости от одного сервиса представляет собой первичную проблему другого сервиса, а последняя, в свою очередь, является проблемой как видимости (запросы поступают слишком поздно от людей, которые необязательно понимают, о чем просят), так и управления возможностями (запросы делаются без учета общей рабочей загрузки). Работа выполняется порциями, которые слишком велики и представляют собой, например, многомесячные или многолетние проекты, не приносящие клиентам никакой пользы на промежуточных этапах. Проблема катастрофически усугубляется тем, что выполнение больших порций новой работы начинается без учета их воздействия на уже выполняемую работу (другие большие порции). |