— Какое отношение имеет морская свинка к морю?
— Примерно такое же, как утконос к проектированию дирижаблей.
Я имею обыкновение во время прогулок прокручивать информацию из нескольких источников, сопоставляя куски. Одна из любопытных находок – почти полное соответствие статистических наблюдений Демарко и Листера в «Peopleware» и теоретических выкладок Голдратта в «Критической цепи».
Осенью 2011 я крутил в голове:
[1] «Стоя на плечах гигантов» Эли М. Голдратт © Eliyahu M. Goldratt, 2008
[2] «Производственный менеджмент: управление потоком» Одед Коуэн, Елена Федурко
[3] «История одной доски» (http://cartmendum.livejournal.com/tag/theboard).
Далее хотелось бы написать: «Как вдруг…», — но это будет неправдой. Это случилось не вдруг. Мне понадобилось пару недель, но, в конце концов, в голове сложилась достаточно цельная картинка.
За что именно я зацепился:
Типы потока принято классифицировать от доминирующего паттерна. В чистом (вырожденном) виде типы потоков можно изобразить следующим образом:
Если нужна более подробная информация, то лучше обратиться к статьям Одед Коуэна (Oded-Cohen) и Елены Федурко.
В мире производства ПО можно провести аналогию:
Главным отличием является то, что при производстве ПО часто нет материалов. Не совсем понятно, что использовать в качестве аналогии материалам в мире производства ПО. Заказы есть и там и там. Как правило, на заводе производство тоже не начинается без заказа. Вероятно, можно рассматривать в качестве материалов поступающие на вход идеи. В процессе разработки эти идеи трансформируются в спецификации требований, потом в архитектурные решения и, наконец, в конечный продукт.
Возможно, кому то захочется изменить классификацию. Мне, например, захотелось. Я предпочел бы добавить еще два типа:
Но это отступление от стандарта, а стандарта, даже плохого лучше придерживаться.
Самый простой для управления поток I-типа.
Но даже для такого типа существует ряд часто допускаемых ошибок. Наиболее часто допускаемая ошибка это применение «вталкивающих» моделей управления.
Рассмотрим классический пример характерный для IT-индустрии. Возьмем простую, даже тривиальную цепочку «Отдел продаж» -> отдел программирования -> отдел тестирования.
Схема процесса:
Пусть отделы могут обработать соответственно:
К этому добавим систему премирования, зависящую от числа обработанных отделом заказов. Логично, что отдел продаж будет брать все заказы, которые могут обработать. Так же логично, что большинство топ-менеджеров будет приказывать брать все заказы. Вот пример дискуссии примерно годовой давности:
> Бить сейлов по рукам и не давать им набирать проектов более чем успевают делать программисты. Естественно, что перед отделом программирования должен быть небольшой буфер проектов.
Первое, что сделает хоть минимально вменяемый руководитель фирмы, прочитав это — ударит по голове автора, потом выдаст ему Наполеоновскую треуголку и отправит в дурку. Это до какой степени охренения должны дойти программисты, чтобы решать, сколько фирме надо продавать? Я понимаю, что им трудно нарастить выработку до запрошенных продаж, но наличие возможности для продаж — это повод не бить сейлов, а работать над возможностями удовлетворения их запросов.
По-русски: в фирму деньги несут, а некоторые намерены их послать.
Итог достаточно очевиден. Производственная цепочка очень быстро забьётся выполняемыми заказами и среднее время выполнения заказа возрастет до неприличной величины. Для данного случая всего через полгода среднее время исполнения заказов возрастет до двух лет. Что не слишком конкурентоспособно, но встречается сплошь и рядом.
Балансировка участков по производительности также не приносит счастья. В системе возникают «биения» и среднее время выполнения заказа опять-таки возрастает до неприличных величин.
У Макса Крамаренко в блоге описано моделирование сбалансированной производственной цепочки:
Моделирование показывает, что в результате биений производственная цепочка быстро забивается. В конце эксперимента для короткой цепочки всего из 4 участков в производстве находилось полторы сотни задач. Переводя на «современный менеджерский» это означает, что задача трудоемкостью в четыре человеко-дня будет реализована через полгода. На вопрос менеджера: «Что ж так долго-то?!», — ответ прост: «Потому что так управляете».
Проблема потока этого типа – недостающие компоненты на сборочных операциях.
Производственная цепочка I-типа примитивна как грабли и незатейлива как молодой редис. Я полагаю что оптимальный способ управления такими цепочками был известен давным-давно, но к сожалению я пока не нашел информации, в каком веке впервые была описана эта методика. Однако, в какой то момент детство заканчивается и перед менеджерами встают по настоящему сложные задачи. С подобным вызовом, наряду с другими столкнулся Генри Форд. В ту пору производство автомобилей на предприятии Форда было производством A-типа. Сложным, со многими ветвями, но имеющим одну вершину. Одна единственная марка автомобиля, один единственный цвет. Отсутствие запаса любой детали на любом участке сборки приводит к увеличению времени производства автомобиля. Но чрезмерный запас деталей также приводит к увеличению времени, которое необходимо, чтобы из железной породы получить готовый автомобиль. Время увеличивается, т.к каждая деталь существенную часть времени проводит в очереди ожидания.
В 1913 году Генри Форд внедрил на своём предприятии конвейерный метод сборки автомобилей. А к 1926 году производственный цикл от добычи железной руды до получения готового автомобиля (состоящего более чем из 5000 деталей), находящегося на железнодорожной платформе и готового к отправке, достиг 81 часа!.. [1] Выдающееся достижение. Представьте себе сложность настройки процесса производства ПО, состоящего хотя бы из 50 производственных участков. Полагаю, что большинство современных менеджеров запросило бы сложную АСУ (автоматизированную систему учета) для управления потоком работ. Но в начале века не было компьютеров…
Вопреки расхожему мнению поточная линия Генри Форда это не привычный нам ленточный конвейер, по которому синхронно движутся собираемые автомобили. Это отдельные рабочие центры, с ручной передачей деталей. «Чтобы улучшить производственный поток, Форд ограничил пространство, предназначенное для складирования запасов незавершенного производства между каждыми двумя рабочими центрами. В этом и состоит сущность поточных линий, что подтверждается тем фактом, что первые поточные линии не имели никаких механических устройств, типа конвейеров, для перемещения запасов (незавершенного производства) от одного рабочего центра к другому.» [1]. За неимением компьютеров Форд создал визуальную систему управления работами. Предельно простую в использовании.
Да, естественно, эта система не заработала бы, если бы не было введено дополнительное правило: «когда выделенное место заполнено, рабочие, которые его заполняют, должны прекратить производство». Пойти погулять, вздремнуть, посидеть вКонтакте,…
Форд отказался от одного из основных положений современного ему менеджмента. Впрочем, и сейчас, 99 лет спустя мало что изменилось. Полагаю, приди Форд в типичную российскую фирму на собеседование и озвучь, что неполная загрузка сотрудников является необходимым условием для повышения доходов фирмы, ему сказали бы, что он не умеет управлять реальным производством.
Проблемы потока V-типа – «кража материала»;
Проблемы потока T-типа — «кража» и недостающие компоненты;
Визуальная модель Форда прекрасно работает для А-типа. Но как только появляется не слияние, но разветвление (один рабочий центр поставляет детали для нескольких центров) начинаются проблемы. Именно эти проблемы ликвидировали преимущество поточных линий Форда в тот момент, когда Дженерал Моторс вышла на рынок с широким модельным рядом. Менеджерам компаний снова был брошен вызов.
Перчатку поднял Таичи Оно, начавший работу в Toyota Motor Corporation в 1943 году. В середине 1950-х годов он начал выстраивать особую систему организации производства, названную впоследствии «Производственная система Toyota» (также ошибочно именуемую канбан, Lean, Just-In-Time).
У Оно, как и у Форда не было АСУ и он разработал визуальную систему управления потоком работ, основанную на канбан (вариант перевода: визуальная карточка). Однако эта система не принесла бы такого эффекта без дополнительных требований. В каждый момент времени на участках, имеющих запас по мощности необходимо делать одно из двух улучшений: или уменьшать размер партии (увеличивать число переключений и сопутствующих им потерь), или уменьшать время переналадки.
«В то время и до тех пор, пока TPS не получила всемирную известность, традиционным способом снижения времени переналадки считалось увеличение размера партии — «экономически обоснованный размер партии» был очень популярным термином, которому посвящались тысячи статей. Оно отбросил весь этот традиционный опыт.» [1]
Оно бросил вызов современной ему системе менеджмента. Логично, что ему этого не простили. С конца 40-х до начала 60-х годов его систему называли «отвратительной системой Оно».
Впрочем, и сейчас, спустя шесть десятков лет среди людей называющих себя сторонниками Lean, устранение переключений считается одним из мощнейших методов увеличения прохода. Оно так не считал. Полагаю, приди Таичи Оно на конференцию по бережливому производству и озвучь свои положения, ему бы сказали, что он просто не умеет управлять реальным производством.
А далее начинается самое интересное. Если рабочий центр участвует более, чем в одной из цепочек, то эти цепочки необходимо на схеме сложить:
Левый и правый потоки A-типа и могли бы управляться визуальной моделью Форда, но ввиду совместного использования рабочих центров «3» и «4» схема усложняется и нужно переходить к модели Оно. Если же не хочется использовать настолько сложную модель, то следует разделить рабочие центры «3», «4» на «3’», «3”», «4’», «4”»
Понимание применимости моделей управления и их сложности должно оказывать существенное влияние на принятие решения об изменении организационной структуре предприятия и регламентов разработки.
К негативным эффектам приводит и матричная система, когда у сотрудника сразу два руководителя: руководитель функционального подразделения и руководитель проекта. Даже Труффальдино плохо справлялся со службой двум господам. А в реальных фирмах на реальных проектах это приводит к фантастическому бардаку и чудовищному увеличению времени ВСЕХ проектов.
Иногда в крупных фирмах идут на жесткое пресечение случаев проявлений «Слуга двух господ». Одним из вариантов, о которых я слышал – это внутренняя биржа труды. Инженер соответствующей специализации находится в структурном подразделении (программист в пуле программистов) и подчиняется менеджеру пула. Подчиняется до тех пор, пока не будет передан в проект. После этого оно подчиняется только руководителю проекта. Отдача прямого распоряжения инженеру, занятому в проекте, кем-то кроме руководителя проекта – это залет, который вполне может закончиться кадровыми перестановками. Фирма немного проседает ввиду неполной занятости сотрудников, но выгоды от простоты управления настолько огромны, что перевешивают эти потери. В дополнение к этому используется принцип «Вассал моего вассала – не мой вассал» — командир взвода не может отдать приказ напрямую солдату. А если отдаст, то будет искать новых сержантов. Или сержанты будут искать нового командира взвода.
Популярный в РФ MSProject неплох для планирования проектов. Для планирования процессов он подходит несколько хуже. Для планирования процессов банальный трекер часто оказывается лучше. Но важно не это. И трекер и Project являются «Информационным холодильниками» (термин введен Алистером Коберном в одной из лучших книг по методологиям «Быстрая разработка программного обеспечения»). Для повышения эффективности разработки нужен «Информационный радиатор». И естественно, нужны правила управления работами.
Тут может сложиться впечатление, что доска — это информационный радиатор. На самом деле модные доски — это те же трекеры, то есть, те же холодильники. Что бы превратить доску в радиатор, нужно ее вешать в общедоступном месте. А как только под доску начинают использовать какой-либо web-инструмент, она тут же становится холодильником. Ну, если ее не выводить на плазму в коридоре или под потолком.
Несколько лет назад было предложено использовать доску, на которую помещаются стикеры с описанием задач. Сейчас это довольно модное увлечение. По запросу «Канбан доска» поисковик выдает массу ссылок на что-то вроде этого:
На рисунке явно изображена визуальная система управления для потоков I-типа. Не имеющая никакого отношения к системе Таичи Оно. Более того эта система более примитивнее чем даже система Генри Форда. Данная «прогрессивная» модель отстает от теории и практики науки управления потоком работ «всего» на 99 лет.
Казалось бы, ну назвали неправильно и что? А то, что неправильный термин дает иллюзию всеобщей применимости инструмента. Слишком часто консультанты пытаются применить эту доску для неподходящих типов потоков. Естественно, попытка терпит неудачу, но консультанты почему-то обвиняют исполнителей. «Вы просто неправильно использовали XP / SCRUM / Kanban / …» Господа, если завинчивание гвоздя крестовой отверткой потерпело фиаско, то не стоит винить исполнителя в том, что он держал отвертку неправильно. Нужно просто дать ему молоток.
Рекомендую с опаской и настороженностью относиться к «консультантам» по «XP / SCRUM / Kanban», которые не знают теории производственных потоков. Не то чтобы их совсем нельзя было использовать, но неумение применять теорию потоков, карт Шухарта, неумение складывать вероятности выполнения при существенных девиациях срока исполнения и прочее и прочее должны вас насторожить.
В дальнейшем я буду называть такую доску I-доской.
Что же касается правил управления, то на семинаре Сурен Самарчан (видеокаст: http://spmguild.org/news/618/) говорил, что задачу в производство можно брать, только если кто-то из программистов освободился. Достаточно легко можно понять, что это будет работать, только если ограничение системы (часто ошибочно именуемое именуемое «бутылочным горлышком») находится в начале производственной цепочки (смотри управление колонной туристов в книге «Цель» Голдратта).
Достаточно часто в изолированных маленьких кроссфункциональных группах разработки именно так и происходит. Ограничение находится в начале производственной цепочки. И все идет хорошо. Но как только ограничение системы переходит куда-то еще, … Все finita la comedia. Нужно систему «Немного подшаманить». Максим Дорофеев нашел эмпирическое правило «Число задач в производстве не должно превышать число программистов более, чем на 2». Нормальное такое шаманское правило.
Более интересный тюнинг доски был предложен Олегом (не указал фамилии) в статье «Канбан в IT (Kanban Development)» (http://habrahabr.ru/blogs/development/64997/ ).
А теперь самое важное. Видите цифры под каждым столбцом? Это число задач, которые могут быть одновременно в этих столбцах. Цифры подбираются экспериментально, но считается, что они должны зависеть от числа разработчиков в команде.
Напоминает поточную линию Форда, но примененную к потоку I-типа. Собственно, это и есть визуализация правила Генри Форда: «Объем незавершенного производства между двумя рабочими центрами должен быть ограничен».
Как ни странно, но часто ограничением системы выступает участок приемки задачи заказчиком. Мне известно минимум три фирмы, где наблюдался этот эффект.
Есть еще одно ограничение на использование I-доски. Это ограничение связано с эффективностью цикла на одном производственном участке (у одного исполнителя). Если эффективность цикла менее 50% то правило «у одного исполнителя только одна работа» начинает сбоить.
Примечание. Эффективностью цикла называют отношение времени обработки к общему времени нахождения на производственном участке. Если утром вам пришла задача, а сделали вы ее только перед уходом, то общее время – 8 часов. Если вы работали над задачей 2 часа, то эффективность цикла 25%.
Приведу примеры, когда ограничение в одну задачу у исполнителя в единицу времени будет неэффективным:
И еще одно ограничение. I-доска плохо визуализирует связи между задачами. Она неплохо подходит для процессов сопровождения с независимыми задачами и хуже для проектов. Хотя для коротких проектов со слабо связанными задачами может быть и подойдет.
Тем не менее, такая доска очень проста в использовании и если подразделение подходит для внедрения, то это один из эффективнейших способов управления потоками. Все таки и систему Форда и систему Оно достаточно сложно визуализировать.
Просто перед внедрением такой доски нужно пройтись по чеклисту:
Часто камнем преткновения становится поток сложного типа. Для упрощения типа потока действенным лекарством является выделение и изоляция отдельных проектных групп и функциональных подразделений.
Но, слишком часто мы слышим фразы: «Мы не можем его не дергать. Кроме него этого никто сделать не может. И полностью перевести его к нам нельзя. Нам он нужен всего на четыре часа в неделю.»
Выход лежит в устранении эффекта незаменимости. Пойдет и XP-шное совместное владение кодом, и введение стандартов кодирования и обучение смежным специальностям (одно из экзотических сочетаний, которое нам сильно помогло в одном из проектов это «системный администратор» и «компьютерный художник» в одном лице).
От разделения фирмы на изолированные группы можно получать выгоду тем большую, чем более кроссфункциональны специалисты.
В одной из фирм вы всерьез обсуждали целесообразность приема в группу разработки системного администратора, а в группу системного администрирования программиста.Коллеги утверждают, что это правило, внедренное в порядке эксперимента показало неплохой результат.
Андрей Орлов в «Записках автоматизатора» предложил простое эмпирическое правило: «Если программист стал незаменимым, немедленно увольте его».
Предложение вполне имеет смысл. Незаменимый сотрудник вполне может иметь высочайшую локальную производительность, но его незаменимость слишком сильно дестабилизирует поток.
Другим вариантом является уменьшение длины потока. Уменьшение числа рабочих центров способно кардинально изменить картину.
Любопытная задача, основанная на наблюдениях за реальными процессами в реальных фирмах.
Из наблюдений: Цепочки из пяти – шести рабочих центров не связанных жестким общим руководством, часто, делают бессмысленным запуск проекта в производство. Он станет ненужным раньше, чем его завершат.Относительно стабильны цепочки с двумя рабочими центрами. С тремя уже возникают проблемы. Цепочка 1->2->1, предположительно, более стабильна, чем 1->2->3.
Уменьшайте число рабочих центров в потоке создания ценности. Идите даже на увеличение прямых затрат. Стабилизация потока и уменьшение среднего времени выполнения заказа с лихвой покроет эти затраты.
Можете отказаться от выделенного аналитика – откажитесь. Можете отказаться от выделенного тестировщика – откажитесь. Если не можешь отказаться ни от выделенного тестирования, ни от выделенного анализа, попробуй объединить роли тестировщика и системного аналитика в одном лице.
Тогда нужно переходить на полноценную TOC. А в качестве визуализации системы управления работами я хочу попробовать систему изменения приоритета, предложенную Голдраттом в статье «Стоя на плечах гигантов». Только вот как ее реализовать в «металле»? Интересная задача для системного аналитика: «Понять идею, выбрать движок и написать постановку на кастомизацию». Чутье подсказывает, что в качестве движка вполне можно взять трекинговую систему middle уровня. TrackStudio может подойти.
Если перепутаете тип потока и попробуете применить I-доску для потока T-типа, то результат, возможно, удивит вас меньше, но последствия для фирмы будут существенно хуже, чем если бы вы перепутали лекарство при диарее.
— Примерно такое же, как утконос к проектированию дирижаблей.
Введение.
Я имею обыкновение во время прогулок прокручивать информацию из нескольких источников, сопоставляя куски. Одна из любопытных находок – почти полное соответствие статистических наблюдений Демарко и Листера в «Peopleware» и теоретических выкладок Голдратта в «Критической цепи».
Осенью 2011 я крутил в голове:
[1] «Стоя на плечах гигантов» Эли М. Голдратт © Eliyahu M. Goldratt, 2008
[2] «Производственный менеджмент: управление потоком» Одед Коуэн, Елена Федурко
[3] «История одной доски» (http://cartmendum.livejournal.com/tag/theboard).
Далее хотелось бы написать: «Как вдруг…», — но это будет неправдой. Это случилось не вдруг. Мне понадобилось пару недель, но, в конце концов, в голове сложилась достаточно цельная картинка.
За что именно я зацепился:
- Таичи Оно (Öno Taiichi) не понимал, почему его система работает.
- Существует несколько разных типов производственных потоков – V, A, T, I. Каждый тип потока ставит особые задачи.
- Неудачи внедрения доски Максима Дорофеева в некоторых подразделениях
- Ряд компаний не смог внедрить систему Тойота, несмотря на все приложенные усилия.
- Система Тойота и система Форда основывается на одинаковых принципах, но прикладные решения ограничены определенными типами производства.
Теория. Типы потоков
Типы потока принято классифицировать от доминирующего паттерна. В чистом (вырожденном) виде типы потоков можно изобразить следующим образом:
Если нужна более подробная информация, то лучше обратиться к статьям Одед Коуэна (Oded-Cohen) и Елены Федурко.
В мире производства ПО можно провести аналогию:
Главным отличием является то, что при производстве ПО часто нет материалов. Не совсем понятно, что использовать в качестве аналогии материалам в мире производства ПО. Заказы есть и там и там. Как правило, на заводе производство тоже не начинается без заказа. Вероятно, можно рассматривать в качестве материалов поступающие на вход идеи. В процессе разработки эти идеи трансформируются в спецификации требований, потом в архитектурные решения и, наконец, в конечный продукт.
 |
Дисклаймер. Я не уверен, что проблемы одного и того же типа производственной цепочки одинаковы для миров материального производства и мира разработки ПО. Это гипотеза, у которой есть много подтверждающих примеров. Но даже одно исключение может поставить эту гипотезу под сомнение. |
Возможно, кому то захочется изменить классификацию. Мне, например, захотелось. Я предпочел бы добавить еще два типа:
Но это отступление от стандарта, а стандарта, даже плохого лучше придерживаться.
| Есть подозрение, что Ж-тип это более правильное название Т-типа, просто американцам не повезло с алфавитом. ;-) |
I-тип
Самый простой для управления поток I-типа.
Но даже для такого типа существует ряд часто допускаемых ошибок. Наиболее часто допускаемая ошибка это применение «вталкивающих» моделей управления.
Рассмотрим классический пример характерный для IT-индустрии. Возьмем простую, даже тривиальную цепочку «Отдел продаж» -> отдел программирования -> отдел тестирования.
Схема процесса:
Пусть отделы могут обработать соответственно:
- Отдел продаж – 20 заказов в неделю
- Отдел программирования – 10 заказов в неделю
- Отдел тестирования – 5 заказов в неделю
К этому добавим систему премирования, зависящую от числа обработанных отделом заказов. Логично, что отдел продаж будет брать все заказы, которые могут обработать. Так же логично, что большинство топ-менеджеров будет приказывать брать все заказы. Вот пример дискуссии примерно годовой давности:
> Бить сейлов по рукам и не давать им набирать проектов более чем успевают делать программисты. Естественно, что перед отделом программирования должен быть небольшой буфер проектов.
Первое, что сделает хоть минимально вменяемый руководитель фирмы, прочитав это — ударит по голове автора, потом выдаст ему Наполеоновскую треуголку и отправит в дурку. Это до какой степени охренения должны дойти программисты, чтобы решать, сколько фирме надо продавать? Я понимаю, что им трудно нарастить выработку до запрошенных продаж, но наличие возможности для продаж — это повод не бить сейлов, а работать над возможностями удовлетворения их запросов.
По-русски: в фирму деньги несут, а некоторые намерены их послать.
Итог достаточно очевиден. Производственная цепочка очень быстро забьётся выполняемыми заказами и среднее время выполнения заказа возрастет до неприличной величины. Для данного случая всего через полгода среднее время исполнения заказов возрастет до двух лет. Что не слишком конкурентоспособно, но встречается сплошь и рядом.
Балансировка участков по производительности также не приносит счастья. В системе возникают «биения» и среднее время выполнения заказа опять-таки возрастает до неприличных величин.
У Макса Крамаренко в блоге описано моделирование сбалансированной производственной цепочки:
- http://maximkr.livejournal.com/18940.html
- http://maximkr.livejournal.com/18971.html
Моделирование показывает, что в результате биений производственная цепочка быстро забивается. В конце эксперимента для короткой цепочки всего из 4 участков в производстве находилось полторы сотни задач. Переводя на «современный менеджерский» это означает, что задача трудоемкостью в четыре человеко-дня будет реализована через полгода. На вопрос менеджера: «Что ж так долго-то?!», — ответ прост: «Потому что так управляете».
|
Это важно. Вина за огромную длительность выполнения заказа почти всегда лежит на системе управления потоком работ (менеджменте), а не на исполнителях. Ну а кто не верит – может сам попробовать написать имитатор и поэкспериментировать. Справедливости ради, следует упомянуть, что сбалансированную цепочку вполне можно использовать, если выполнять правило: «Среднее время простоя сотрудников должно быть не менее 20-25%». Но опять же, кто из менеджеров на это пойдет? |
A-тип и решение Форда
Проблема потока этого типа – недостающие компоненты на сборочных операциях.
Производственная цепочка I-типа примитивна как грабли и незатейлива как молодой редис. Я полагаю что оптимальный способ управления такими цепочками был известен давным-давно, но к сожалению я пока не нашел информации, в каком веке впервые была описана эта методика. Однако, в какой то момент детство заканчивается и перед менеджерами встают по настоящему сложные задачи. С подобным вызовом, наряду с другими столкнулся Генри Форд. В ту пору производство автомобилей на предприятии Форда было производством A-типа. Сложным, со многими ветвями, но имеющим одну вершину. Одна единственная марка автомобиля, один единственный цвет. Отсутствие запаса любой детали на любом участке сборки приводит к увеличению времени производства автомобиля. Но чрезмерный запас деталей также приводит к увеличению времени, которое необходимо, чтобы из железной породы получить готовый автомобиль. Время увеличивается, т.к каждая деталь существенную часть времени проводит в очереди ожидания.
В 1913 году Генри Форд внедрил на своём предприятии конвейерный метод сборки автомобилей. А к 1926 году производственный цикл от добычи железной руды до получения готового автомобиля (состоящего более чем из 5000 деталей), находящегося на железнодорожной платформе и готового к отправке, достиг 81 часа!.. [1] Выдающееся достижение. Представьте себе сложность настройки процесса производства ПО, состоящего хотя бы из 50 производственных участков. Полагаю, что большинство современных менеджеров запросило бы сложную АСУ (автоматизированную систему учета) для управления потоком работ. Но в начале века не было компьютеров…
Вопреки расхожему мнению поточная линия Генри Форда это не привычный нам ленточный конвейер, по которому синхронно движутся собираемые автомобили. Это отдельные рабочие центры, с ручной передачей деталей. «Чтобы улучшить производственный поток, Форд ограничил пространство, предназначенное для складирования запасов незавершенного производства между каждыми двумя рабочими центрами. В этом и состоит сущность поточных линий, что подтверждается тем фактом, что первые поточные линии не имели никаких механических устройств, типа конвейеров, для перемещения запасов (незавершенного производства) от одного рабочего центра к другому.» [1]. За неимением компьютеров Форд создал визуальную систему управления работами. Предельно простую в использовании.
Да, естественно, эта система не заработала бы, если бы не было введено дополнительное правило: «когда выделенное место заполнено, рабочие, которые его заполняют, должны прекратить производство». Пойти погулять, вздремнуть, посидеть вКонтакте,…
Форд отказался от одного из основных положений современного ему менеджмента. Впрочем, и сейчас, 99 лет спустя мало что изменилось. Полагаю, приди Форд в типичную российскую фирму на собеседование и озвучь, что неполная загрузка сотрудников является необходимым условием для повышения доходов фирмы, ему сказали бы, что он не умеет управлять реальным производством.
Более сложные типы и система Тойоты
Проблемы потока V-типа – «кража материала»;
Проблемы потока T-типа — «кража» и недостающие компоненты;
Визуальная модель Форда прекрасно работает для А-типа. Но как только появляется не слияние, но разветвление (один рабочий центр поставляет детали для нескольких центров) начинаются проблемы. Именно эти проблемы ликвидировали преимущество поточных линий Форда в тот момент, когда Дженерал Моторс вышла на рынок с широким модельным рядом. Менеджерам компаний снова был брошен вызов.
Перчатку поднял Таичи Оно, начавший работу в Toyota Motor Corporation в 1943 году. В середине 1950-х годов он начал выстраивать особую систему организации производства, названную впоследствии «Производственная система Toyota» (также ошибочно именуемую канбан, Lean, Just-In-Time).
У Оно, как и у Форда не было АСУ и он разработал визуальную систему управления потоком работ, основанную на канбан (вариант перевода: визуальная карточка). Однако эта система не принесла бы такого эффекта без дополнительных требований. В каждый момент времени на участках, имеющих запас по мощности необходимо делать одно из двух улучшений: или уменьшать размер партии (увеличивать число переключений и сопутствующих им потерь), или уменьшать время переналадки.
«В то время и до тех пор, пока TPS не получила всемирную известность, традиционным способом снижения времени переналадки считалось увеличение размера партии — «экономически обоснованный размер партии» был очень популярным термином, которому посвящались тысячи статей. Оно отбросил весь этот традиционный опыт.» [1]
Оно бросил вызов современной ему системе менеджмента. Логично, что ему этого не простили. С конца 40-х до начала 60-х годов его систему называли «отвратительной системой Оно».
Впрочем, и сейчас, спустя шесть десятков лет среди людей называющих себя сторонниками Lean, устранение переключений считается одним из мощнейших методов увеличения прохода. Оно так не считал. Полагаю, приди Таичи Оно на конференцию по бережливому производству и озвучь свои положения, ему бы сказали, что он просто не умеет управлять реальным производством.
Правила сложения
А далее начинается самое интересное. Если рабочий центр участвует более, чем в одной из цепочек, то эти цепочки необходимо на схеме сложить:
Левый и правый потоки A-типа и могли бы управляться визуальной моделью Форда, но ввиду совместного использования рабочих центров «3» и «4» схема усложняется и нужно переходить к модели Оно. Если же не хочется использовать настолько сложную модель, то следует разделить рабочие центры «3», «4» на «3’», «3”», «4’», «4”»
Понимание применимости моделей управления и их сложности должно оказывать существенное влияние на принятие решения об изменении организационной структуре предприятия и регламентов разработки.
 |
Пример. Пусть исторически сложилось так, что в фирме есть четыре разных центра разработки, отвечающих за поддержку четырех разных внутренних продуктов. В какой-то момент при первом центре была создана группа тестирования. Это нововведение оказалось достаточно эффективным и рассматривается вопрос о выделении группы тестирования в отдельный сервис, предоставляющий услуги тестирования всем четырем центрам разработки. За и против? Против: произойдет изменение типа потока, и возникнут проблемы управляемости. Вместо 4 цепочек I-типа будет одна сложная цепочка:  Если в рабочем центре тестирования будет обеспечен запас по мощности, то преобразование не приведет к негативным последствиям. Но что-то мне подсказывает (весь мой предыдущий опыт), что тестирование станет ограничением системы со всеми вытекающими печальными последствиями. |
|
Пусть исторически сложилось так, что в фирме есть один отдел, отвечающих за поддержку внутренних продуктов и выполняющий доработки для нескольких заказчиков. Возьмем достаточно распространенную структуру «программирование -> тестирование». Простейший, тривиальный I-поток, легкоуправляемый. В какой-то момент времени качество поставки перестало удовлетворять заказчиков и в фирме рассматривается вопрос о введении стадии приемки. За и против? Против: произойдет изменение типа потока, и возникнут проблемы управляемости. Вместо одной цепочки I-типа будет одна сложная цепочка.  Если поставки доработок организованы в пакеты, общие для всех заказчиков, то один единственный заказчик может блокировать как текущую, так последующие поставки всем остальным. |
К негативным эффектам приводит и матричная система, когда у сотрудника сразу два руководителя: руководитель функционального подразделения и руководитель проекта. Даже Труффальдино плохо справлялся со службой двум господам. А в реальных фирмах на реальных проектах это приводит к фантастическому бардаку и чудовищному увеличению времени ВСЕХ проектов.
 |
Отступление. В книжке Лайкера про систему разработки продукции в Toyota написано, что в исследовательских центрах Toyota как раз матричное управление. При чем, к этому они пришли осмысленно и менять этого не хотят. На самом деле у них есть много всяких других хитростей, делающих матрицу работоспособной. Одна из них то, что руководитель проекта является специалистом, обладающим огромным авторитетом у коллег. Как правило, он должен отработать в фирме 10-25 лет. В этом случае он лидер и формальные рычаги управления ему не обязательны. Матрица — это не зло, просто ее приготовить сложно |
Иногда в крупных фирмах идут на жесткое пресечение случаев проявлений «Слуга двух господ». Одним из вариантов, о которых я слышал – это внутренняя биржа труды. Инженер соответствующей специализации находится в структурном подразделении (программист в пуле программистов) и подчиняется менеджеру пула. Подчиняется до тех пор, пока не будет передан в проект. После этого оно подчиняется только руководителю проекта. Отдача прямого распоряжения инженеру, занятому в проекте, кем-то кроме руководителя проекта – это залет, который вполне может закончиться кадровыми перестановками. Фирма немного проседает ввиду неполной занятости сотрудников, но выгоды от простоты управления настолько огромны, что перевешивают эти потери. В дополнение к этому используется принцип «Вассал моего вассала – не мой вассал» — командир взвода не может отдать приказ напрямую солдату. А если отдаст, то будет искать новых сержантов. Или сержанты будут искать нового командира взвода.
Канбан-доска и морская свинка
Популярный в РФ MSProject неплох для планирования проектов. Для планирования процессов он подходит несколько хуже. Для планирования процессов банальный трекер часто оказывается лучше. Но важно не это. И трекер и Project являются «Информационным холодильниками» (термин введен Алистером Коберном в одной из лучших книг по методологиям «Быстрая разработка программного обеспечения»). Для повышения эффективности разработки нужен «Информационный радиатор». И естественно, нужны правила управления работами.
Тут может сложиться впечатление, что доска — это информационный радиатор. На самом деле модные доски — это те же трекеры, то есть, те же холодильники. Что бы превратить доску в радиатор, нужно ее вешать в общедоступном месте. А как только под доску начинают использовать какой-либо web-инструмент, она тут же становится холодильником. Ну, если ее не выводить на плазму в коридоре или под потолком.
Несколько лет назад было предложено использовать доску, на которую помещаются стикеры с описанием задач. Сейчас это довольно модное увлечение. По запросу «Канбан доска» поисковик выдает массу ссылок на что-то вроде этого:
На рисунке явно изображена визуальная система управления для потоков I-типа. Не имеющая никакого отношения к системе Таичи Оно. Более того эта система более примитивнее чем даже система Генри Форда. Данная «прогрессивная» модель отстает от теории и практики науки управления потоком работ «всего» на 99 лет.
 |
Что общего имеют между канбан доской и морской свинкой? Канбан-доска имеет примерно такое же отношение к канбану, как морская свинка к морю. |
Казалось бы, ну назвали неправильно и что? А то, что неправильный термин дает иллюзию всеобщей применимости инструмента. Слишком часто консультанты пытаются применить эту доску для неподходящих типов потоков. Естественно, попытка терпит неудачу, но консультанты почему-то обвиняют исполнителей. «Вы просто неправильно использовали XP / SCRUM / Kanban / …» Господа, если завинчивание гвоздя крестовой отверткой потерпело фиаско, то не стоит винить исполнителя в том, что он держал отвертку неправильно. Нужно просто дать ему молоток.
Рекомендую с опаской и настороженностью относиться к «консультантам» по «XP / SCRUM / Kanban», которые не знают теории производственных потоков. Не то чтобы их совсем нельзя было использовать, но неумение применять теорию потоков, карт Шухарта, неумение складывать вероятности выполнения при существенных девиациях срока исполнения и прочее и прочее должны вас насторожить.
В дальнейшем я буду называть такую доску I-доской.
Что же касается правил управления, то на семинаре Сурен Самарчан (видеокаст: http://spmguild.org/news/618/) говорил, что задачу в производство можно брать, только если кто-то из программистов освободился. Достаточно легко можно понять, что это будет работать, только если ограничение системы (часто ошибочно именуемое именуемое «бутылочным горлышком») находится в начале производственной цепочки (смотри управление колонной туристов в книге «Цель» Голдратта).
Достаточно часто в изолированных маленьких кроссфункциональных группах разработки именно так и происходит. Ограничение находится в начале производственной цепочки. И все идет хорошо. Но как только ограничение системы переходит куда-то еще, … Все finita la comedia. Нужно систему «Немного подшаманить». Максим Дорофеев нашел эмпирическое правило «Число задач в производстве не должно превышать число программистов более, чем на 2». Нормальное такое шаманское правило.
Более интересный тюнинг доски был предложен Олегом (не указал фамилии) в статье «Канбан в IT (Kanban Development)» (http://habrahabr.ru/blogs/development/64997/ ).
А теперь самое важное. Видите цифры под каждым столбцом? Это число задач, которые могут быть одновременно в этих столбцах. Цифры подбираются экспериментально, но считается, что они должны зависеть от числа разработчиков в команде.Напоминает поточную линию Форда, но примененную к потоку I-типа. Собственно, это и есть визуализация правила Генри Форда: «Объем незавершенного производства между двумя рабочими центрами должен быть ограничен».
Как ни странно, но часто ограничением системы выступает участок приемки задачи заказчиком. Мне известно минимум три фирмы, где наблюдался этот эффект.
Есть еще одно ограничение на использование I-доски. Это ограничение связано с эффективностью цикла на одном производственном участке (у одного исполнителя). Если эффективность цикла менее 50% то правило «у одного исполнителя только одна работа» начинает сбоить.
Примечание. Эффективностью цикла называют отношение времени обработки к общему времени нахождения на производственном участке. Если утром вам пришла задача, а сделали вы ее только перед уходом, то общее время – 8 часов. Если вы работали над задачей 2 часа, то эффективность цикла 25%.
Приведу примеры, когда ограничение в одну задачу у исполнителя в единицу времени будет неэффективным:
- Полицейские проекты (www.toc-center.ru/politseiskie_proekty.html )
- Написание ТЗ и ПМИ (ГОСТ 34.602 и 34.603). Документы сильно влияют друг друга и иногда проще писать одновременно два документа.
- Приготовление праздничного ужина. Поставленный вариться бульон требует участия человека во время варки от силы на пару минут. В это время вполне можно заняться приготовлением салатов. Если бы хозяйка готовила праздничный рождественский обед по системе Сурена Самарчана, то гости остались бы голодными. Просто там система неприменима.
- Часто в эту категорию попадают заявки, отправленные в службу техподдержки. Например, заявки требующие закупок часто имеют длительный период приостановки, во время которого сотрудник может заняться чем-то еще.
И еще одно ограничение. I-доска плохо визуализирует связи между задачами. Она неплохо подходит для процессов сопровождения с независимыми задачами и хуже для проектов. Хотя для коротких проектов со слабо связанными задачами может быть и подойдет.
Тем не менее, такая доска очень проста в использовании и если подразделение подходит для внедрения, то это один из эффективнейших способов управления потоками. Все таки и систему Форда и систему Оно достаточно сложно визуализировать.
Просто перед внедрением такой доски нужно пройтись по чеклисту:
- Поток I-типа? Если нет, то скорее всего придется отказаться от попыток внедрения простой доски.
- Ограничение находится в начале цепочки?Если нет, то позаботьтесь о питающем буфере. Придумайте подшаманивающее правило.
- Эффективность цикла на одном производственном участке более 50%?Если нет, то снимите ограничение на обработку только одной задачи одновременно.
- Поступающие заказы связаны между собой или могут выполняться изолированно?Если связаны, то вам нужно что-то другое для визуализации. Возможно, придется перейти на рисование сетевого графика. Возможно еще что-то.
Часто камнем преткновения становится поток сложного типа. Для упрощения типа потока действенным лекарством является выделение и изоляция отдельных проектных групп и функциональных подразделений.
Но, слишком часто мы слышим фразы: «Мы не можем его не дергать. Кроме него этого никто сделать не может. И полностью перевести его к нам нельзя. Нам он нужен всего на четыре часа в неделю.»
Выход лежит в устранении эффекта незаменимости. Пойдет и XP-шное совместное владение кодом, и введение стандартов кодирования и обучение смежным специальностям (одно из экзотических сочетаний, которое нам сильно помогло в одном из проектов это «системный администратор» и «компьютерный художник» в одном лице).
От разделения фирмы на изолированные группы можно получать выгоду тем большую, чем более кроссфункциональны специалисты.
В одной из фирм вы всерьез обсуждали целесообразность приема в группу разработки системного администратора, а в группу системного администрирования программиста.Коллеги утверждают, что это правило, внедренное в порядке эксперимента показало неплохой результат.
Андрей Орлов в «Записках автоматизатора» предложил простое эмпирическое правило: «Если программист стал незаменимым, немедленно увольте его».
Предложение вполне имеет смысл. Незаменимый сотрудник вполне может иметь высочайшую локальную производительность, но его незаменимость слишком сильно дестабилизирует поток.
Другим вариантом является уменьшение длины потока. Уменьшение числа рабочих центров способно кардинально изменить картину.
Любопытная задача, основанная на наблюдениях за реальными процессами в реальных фирмах.
Возьмем два потенциально интересных проекта. Оба они будучи выполненными прямо сейчас приносили бы по $2 000 каждый месяц в течении полутора лет (от момента сейчас). Потом рынок изменится и прибыль исчезнет. Соответственно, чем позднее окажется дата завершения проекта, тем меньше денег удастся получить.Будем считать, что человеконеделя трудозатрат стоит фирме $2 000Первый проект может быть реализован в рамках одного департамента по единым руководством по схеме:Двухнедельный цикл разработки в группе программирования + двухнедельный цикл тестирования и отладки совместно группами тестирования и программирования.Циклы жестко связаны, временного зазора нет. Чистое время реализации – 4 недели, трудозатраты – 6 человеконедель, расходы - $12 000Второй проект предполагает участие сотрудников 4 разных отделов, по неделе каждый. Параллельно запускать нельзя, только последовательно. Чистое время реализации – 4 недели, трудозатраты – 4 человеконедели, расходы - $8 000.Вопрос: «Каковы ROI проектов?»Совершенно неправильный ответ:Для первого проекта доход: 18*2000 = $36000…Дальше можно не продолжать, потому как вменяемому менеджеру, который знает теорию, известно, что проекты мгновенно не делаются.Просто неправильный ответ:Первый проект будет закончен через 1 месяц, итого доход (18-1)*…Дальше можно не продолжать, потому как вменяемому менеджеру, который знает не только теорию, но и жизнь, известно, что проекты мгновенно не начинаются.…Правильный ответ:Первый проект не может быть выполнен за месяц. Разве что прилетят инопланетяне и «соберут урожай». И невозможно это потому что очередь на реализацию длинная и забита «Задачами, которые давно обещали», «Задачами, которые поставил Сам» и «Просто важными задачами». Реальное время до финиша - месяца четыре. Вот теперь можно считать. Доход – (18-4)*2 000 = 28 000, прибыль – 28 000-12 000=16 000, ROI=133%.Второй проект продлится год. Еще раз. Год. И это в лучшем случае. Если за это время ничего не изменится и проект не заморозят. Большую часть времени проект проведет в очередях ожидания. Да, это реальные наблюдения за реальными проектами в реальной фирме. Доход (18-12)*2000 = 12 000. Прибыль – 4 000, ROI – 50%У второго проекта меньшее ROI, и несравненно более высокие риски. От второго проекта я рекомендовал бы отказаться, в пользу первого.Из наблюдений: Цепочки из пяти – шести рабочих центров не связанных жестким общим руководством, часто, делают бессмысленным запуск проекта в производство. Он станет ненужным раньше, чем его завершат.Относительно стабильны цепочки с двумя рабочими центрами. С тремя уже возникают проблемы. Цепочка 1->2->1, предположительно, более стабильна, чем 1->2->3.
Уменьшайте число рабочих центров в потоке создания ценности. Идите даже на увеличение прямых затрат. Стабилизация потока и уменьшение среднего времени выполнения заказа с лихвой покроет эти затраты.
Можете отказаться от выделенного аналитика – откажитесь. Можете отказаться от выделенного тестировщика – откажитесь. Если не можешь отказаться ни от выделенного тестирования, ни от выделенного анализа, попробуй объединить роли тестировщика и системного аналитика в одном лице.
А если и система Оно не применима?
Тогда нужно переходить на полноценную TOC. А в качестве визуализации системы управления работами я хочу попробовать систему изменения приоритета, предложенную Голдраттом в статье «Стоя на плечах гигантов». Только вот как ее реализовать в «металле»? Интересная задача для системного аналитика: «Понять идею, выбрать движок и написать постановку на кастомизацию». Чутье подсказывает, что в качестве движка вполне можно взять трекинговую систему middle уровня. TrackStudio может подойти.
Вместо послесловия
И постарайтесь не перепутать тип производственного потока вашей группы. Лечение диареи или запора достаточно простое. Но если перепутать лекарства, то результат вас может несколько удивить.Если перепутаете тип потока и попробуете применить I-доску для потока T-типа, то результат, возможно, удивит вас меньше, но последствия для фирмы будут существенно хуже, чем если бы вы перепутали лекарство при диарее.