Летом 2004 года в Microsoft искали руководителя для команды, которую считали худшей в её подразделении. Команда сопровождала внутренние программы компании, закрывала 17 заявок на доработку за квартал, а обычная заявка ждала около пяти месяцев. Новый руководитель Драгош Думитриу ввёл правило, которое придумал вместе с Дэвидом Андерсоном, будущим автором книги о канбане. Заявку брали в работу, только когда освобождалось одно из немногих мест. Через год команда закрывала 56 заявок в квартал, втрое больше, а каждую сдавала обычно за две недели.
Канбан обычно представляют доской с колонками «в работе» и «готово». Но у этой команды доски не было, правило жило в электронной системе учёта заявок. Канбан - это прежде всего лимит незавершённой работы: новую задачу берут, только когда есть силы её делать, а доска лишь помогает видеть, где задачи стоят. Лимит был одним из трёх решений, которые подняли выработку, а последнюю треть прироста дали два новых сотрудника.
Руководство поначалу считало, что команде не хватает данных, и в вакансии требовало умения строить подробные отчёты о графике работ. Андерсон и Думитриу потом написали, что мешало другое - то, как работу принимали, планировали и ставили в очередь. Ниже - как был устроен лимит и как по своей доске посчитать, сколько ждёт заявка и где у команды узкое место.
Куда уходило время команды
В июле 2004 года разработку и тестирование для команды передали в Хайдарабад, в Индию. Там работали три разработчика и три тестировщика, а заявок приходило около одной в день.
Каждую новую заявку сразу отдавали на оценку разработчику и тестировщику, и по договорённости с заказчиками оценку делали в первую очередь. У каждого она отнимала около четырёх часов. По подсчёту Андерсона и Думитриу, оценки съедали до 40% времени команды, а сделать в итоге удавалось лишь около половины оценённых заявок. Остальные оказывались слишком большими или дорогими либо теряли смысл, пока ждали.
Раз в месяц руководители команды и четыре представителя заказчиков заново расставляли по важности всю очередь из 80 с лишним заявок, хотя команда успевала сделать шесть-семь в месяц. Обещанные сроки срывались и переносились снова и снова.
Как устроили лимит без доски
В сентябре 2004 года команду принял Думитриу. В октябре он пришёл на выступление Андерсона, чью книгу об управлении разработкой читал, не зная, что автор работает в той же компании, и попросил помочь.
Перед разработчиками поставили буфер - очередь на несколько мест. Заявка попадала туда, только когда место освобождалось, и только тогда заказчик получал срок в 25 рабочих дней. Кого поставить на свободное место, четыре представителя заказчиков решали по почте или по телефону, выбирая самое срочное. Остальные заявки ждали в общей очереди без обещанной даты.
К осени 2005 года в буфере обычно стояло около семи заявок, ещё пять были в работе, по одной у каждого разработчика. Перед тестированием был свой буфер, примерно на восемь заявок.
Раз срок обещали только заявке из буфера, оценивать каждую входящую стало незачем. Заказчики согласились считать все заявки одинаковыми по стоимости; разработка одной в среднем занимала пять рабочих дней. Теперь заявку оценивал тот, кто брался её делать, и оценка сразу шла в дело.
Сами авторы называют буфер механизмом, который сделал возможными два других решения. Он не пускал в работу больше, чем команда успевала сделать, и каждый вёл одну заявку до следующего этапа, не переключаясь между несколькими.
Что из этого применимо у вас
Начать можно с подсчёта по своей доске. Разделите число заявок в работе на то, сколько команда закрывает за неделю, и получите, сколько недель в среднем проводит в работе одна заявка. Это закон Литтла. Исследователь Джон Литтл доказал его в 1961 году, и формула одинаково верна для завода и для сервисного процесса. Допустим, в работе 40 заявок, а закрывают 10 в неделю. Тогда заявка идёт около четырёх недель, даже если саму работу делают за день. С лимитом в 20 заявок при той же выработке срок сократится до двух недель.
Лимит не прибавляет команде рук. Он сокращает время от взятия заявки до сдачи и делает срок предсказуемым, а общая очередь уменьшится, только если команда станет закрывать больше, чем приходит. В Microsoft выработку подняли решения, которые лимит сделал возможными, и их тоже можно примерить к себе.
- Давайте срок только заявке, для которой нашлось место в лимите. Остальные ждут в общей очереди без даты, а когда место освобождается, заказчик или руководитель выбирает следующую. Расставлять по важности всю очередь каждый месяц тогда не нужно.
- Найдите подготовку, которую делают заранее по каждой входящей заявке. Например, по каждой сразу считают сроки и стоимость, а в работу заявка попадает через месяц, и расчёт приходится делать заново. Если очерёдность можно решить и без него, перенесите расчёт на момент, когда заявку берут.
- Ищите узкое место там, где копятся карточки, и проверяйте наблюдением, у кого есть запас. В Microsoft тестировщики выглядели полностью загруженными. Когда оценки отменили, Думитриу две недели наблюдал за командой в Индии и увидел у тестировщиков запас. Одного из них перевели в разработку, и выработка выросла ещё.
Новых людей в Microsoft добавили только после этого. Автоматизация - такое же вложение, и направлять её стоит на этап, который тормозит весь поток. Когда ручная работа на этом этапе повторяется в каждой заявке - собрать сведения из документов, сверить данные, подготовить ответ по правилам, - её может готовить ИИ-агент, а проверять сотрудник. Если узкое место у вас именно такое, расскажите о нём Kvema - готовая постановка задачи для разговора не нужна. Какие права давать агенту, который разбирает заявки, показано на учебном примере.
Для переноса одних и тех же полей между системами агент обычно не нужен - часто хватает функции самой системы или программного робота.
Что дал новый порядок работы, а что - новые люди
С тем же составом из шести человек команда за девять месяцев дошла с 17 до 44 заявок в квартал. Авторы подчёркивают, что этот рост получен без новых людей и денег и без перемен в том, как команда проектировала, писала и тестировала программы. Затем добавили разработчика и тестировщика, и в следующем квартале команда закрыла 56 заявок.
По данным самих Андерсона и Думитриу, обещанный срок к тому времени соблюдали больше чем в 90% случаев, а в очереди осталось меньше десяти заявок вместо 80.
Зачем тогда доска
Сначала Андерсон описывал эту систему языком теории ограничений, а с 2005 года вместе с Думитриу стал называть её канбан-системой. По его словам, такая система не даёт перегружать людей.
Доска появилась позже и в другой компании, куда Андерсон перешёл в 2006 году. В январе 2007 года руководитель группы сопровождения программ заметил, что улучшения застопорились, а работа идёт так неровно, что никто не понимает, что менять дальше. По совету одного из сотрудников поток нарисовали на доске в коридоре, и с января по март она помогла найти следующие улучшения. Доска показывает, где стоит работа и где её скопилось больше, чем успевают сделать.
Прежде чем автоматизировать узкое место, проверьте, как на нём ловят ошибки, - для этого есть четыре вопроса к процессу из истории автозавода во Фримонте.
Источники
- Дэвид Андерсон и Драгош Думитриу о том, как команда сопровождения Microsoft стала из худшей лучшей за 9 месяцев - доклад на конференции по теории ограничений, ноябрь 2005, версия 1.3
- Дэвид Андерсон. Краткая история канбана в работе со знаниями - сайт автора, 21.07.2014
- Дэвид Андерсон о том, зачем нужна канбан-система и почему важно сокращать срок - сайт автора, 09.11.2011
- Джон Литтл о своём законе через 50 лет после доказательства - журнал по исследованию операций, 2011, перепечатка 2016
