Данная статья будет интересна специалистам, которые занимаются управлением разработкой новых продуктов в сфере машиностроения и металлообработки. Инструмент, который я предлагаю использовать — это канбан на фундаменте приоритетов.
Когда я только пришел в компанию работать менеджером проектов (а это произошло почти полтора года назад), меня усадили за большой стол переговоров директор и главный инженер и сказали: у нас много проектов и по ним проведена большая подготовительная работа; как говориться:
— Наливай, да пей!
Директор — человек высокого полета, потому всем проектам был присвоен высокий приоритет. А высокий приоритет предполагает, конечно, браться за все и сразу. Но так не бывает в условиях ограниченных ресурсов. Примерно год проекты так и воплощались в жизнь: всех да по чуть чуть. В итоге за год появился только один большой и хороший продукт.
И вот я начал копать, какие задачи необходимо решить прежде, чтобы эффективно управлять проектами.
Задача №1: Сформулировать цели
Первая важная проблема — отсутствие сформулированных целей. Если целей нет, то дальше планированием можно даже не заниматься.
Любая деятельность начинается с целеполагания. Любая компания должна иметь цель. На основании целей расставляются приоритеты проектов. Вектор развития, а соответственно и цели компании формулирует руководство компании. Первое, что необходимо было сделать — это усадить за стол переговоров директора и главного инженера, чтобы определиться с целями. И вот я, директор и главный инженер за пару совещаний расставили приоритеты проектам.
В конце февраля была закончена работа над дорожной картой проектов, в которой каждому проекту присвоена важность. Важность обозначена числом от 1 до 100. Чем больше число, тем приоритетнее проект. Этой дорожной картой руководствуется каждый член команды в своей повседневной деятельности. Если стоит выбор делать задачу с важностью 95 или с важностью 89, то выполняется в первую очередь задача с важностью 95. Все достаточно прозрачно и понятно.
После этого стало можно приступать к запуску проектов на основании приоритетов, а не вслепую.
Задача №2: Управлять ограниченными ресурсами
Вторая важная проблема — ограниченность ресурсов.
В нашей компании всего перманентно в разработке находится порядка 30 проектов разной сложности (от типовых со стандартными решениями до нетривиальных, требующих поиска нестандартных решений). Проектная же команда состоит из двух инженеров-конструкторов, технолога, снабженца, дизайнера, маркетолога, операторов-наладчиков станков, начальника производства, технического писателя (итого 8-9 человек). Таким образом, естественным образом возникает конфликт ресурсов как внутри проектов, так и между проектами и операционной деятельностью. Стоит отметить, производство серийных продуктов (так называемый production) имеет наивысший приоритет, так как именно он production приносит деньги компании.
Мной был проведен анализ решений: как управлять ресурсами? Практически весь материал в интернете отсылал к опыту IT-компаний в области проектного управления. Изучив информацию про agile, scrum, kanban, классический способ управления проектами и тот опыт производственных компаний, который был в открытом доступе, мне для реалий нашего производства показался наиболее подходящим именно kanban (далее по тексту «канбан»). В скором времени была приобретена магнитная доска размером 1,8м х 1м, которая и превратилась в канбан-доску. Кроме того, канбан доска решила и еще задачу визуализации проектной деятельности.
Задача №3: Визуализировать проектную деятельность
Третью важная проблема — визуализация и наглядность.
К моменту начала внедрения канбан-принципов мы уже использовали мощный инструмент планирования — это систему управления бизнес-процессами Elma. Однако, к сожалению, в ней не так все наглядно и общей картины по проектам не видно. Канбан-доска же в наглядности очень удобный инструмент.
Как же реализована канбан-доска?
Ниже кратко приведу, как же организована работа с канбан-доской у нас на предприятии.
Доска разлинована по горизонтали по ресурсам. Цифра в скобках напротив имени обозначает количество задач, которое может одновременно выполняться одним человеком (ресурсом). По вертикали столбцами выделены основные проекты. Также есть общий столбец для менее приоритетных на данном этапе проектов.
В правом нижнем углу выписаны приоритетные проекты от высшего к низшему:
На первом этапе реализации канбан-доски задачи обозначались только стикерами с цветовой дифференциацией. У нас проекты разделены на три этапа (контрольные точки):
— выпуск опытного образца (розовый стикер);
— подготовка выпуска пилотной партии (оранжевый стикер);
— выпуск пилотной партии и завершение проекта (зеленый стикер).
Также бледно-желтым выделены промежуточные задачи, по которым требуется дополнительный контроль.
Легенда отображена в левом верхнем углу доски:
Стикер также имеет свою структуру. На стикере отображено краткое наименование проекта, его номер и краткое содержание задачи. В содержании также по необходимости указываем сроки завершения задачи и наиболее важную информацию:
Соответствие проекта номеру вывешено справа на доске.
Каждый рабочий день в 10.00 мы с командой собираемся на летучке у канбан-доски, где каждый отвечает на три вопроса:
— Что сделано за прошлый день?
— Какие проблемы возникли?
— Что планируется сделать за предстоящий день?
На летучке не обсуждаются пути решения задач и проблем, а лишь озвучивается проблемы; обсудить проблемы предлагается отдельно после летучки или в рабочем порядке. Таким образом, во-первых, команда синхронизируется и всем всегда ясно, что происходит на проектах, а во-вторых, мозг человека просыпается и включается в работу. В общем-то я даже на себе заметил, что активность моя после летучки повышается. Одновременно летучка — это инструмент быстрого реагирования и гибкость.
Данная модель была позаимствована из scrum:
Для вопросов, требующих длительного и тщательного обсуждения, мы выделяем отдельное время на проектных совещаниях; проходит оно каждую среду.
В какой-то момент стало понятно, что стикеров все-равно много для быстрого ориентирования. Каждый стикер я предложил нумеровать цифрой 1, 2, 3, 5, 8 (числа Фибоначчи, которые также часто используются для оценки сложности и/или длительности задачи в проектной деятельности). Каждая цифра означает количество дней, которое потребуется для выполнения той или иной задачи. Статус цифр обновляет непосредственно исполнитель задачи. Тем самым на летучках можно быстро оценить, по каким задачам нужно сегодня спросить с исполнителя. Если это цифра 5 или 8, то задача еще в работе и ее обсуждать в данный момент не требуется. Если же это цифра 1 или 2, то я прошу члена команды рассказать о статусе задачи, так как по плану необходимо ее закрывать и передавать на следующий этап.
Цифры нанесены белым корректирующим карандашом на гибкий магнит. Также есть магниты с символом "!" (внимание, срочно, важно, обратить внимание) и "||" (пауза, задача приостановлена):
Стикер с выполненной задачей перемещается в столбец готово. А это значит, что задачу можно передавать следующему исполнителю.
Завершенные задачи перемещаются с канбан-доски на небольшую доску у окна, чтобы всегда можно было отследить прогресс работы команды.
Говоря об эффективности такого подхода, можно отметить, что за первый квартал 2017 года было закрыто два больших и сложных проекта и несколько мелких типовых проектов.
Как говорят в компании Тойота, канбан — это инструмент тонкой настройки. Вот и у нас настройка происходит непрерывно и еще будет сделано много усовершенствований для удобной и эффективной работы.
Комментарии (23)
Comlan
15.03.2017 09:22-1Прошлый год я ходил на защиту дипломов у инженеров-машиностроителей в наш университет, зрителем (сам учился на ФАМ, 14 лет назад окончил). Один студент представлял проект (внимание!) картотеки. Металлический гроб с ячейками на шарнирах и направляющих. Когда он закончил доклад в воздухе повис вопрос — зачем всё это?! Нуууу, замешкался он, для библиотек например. Может в том, что у нас плохо с машиностроением, немного виноваты и мы, а не только наше «правительство»?
Сам стараюсь искать и изучать различные методы управления проектами. И ваш опыт очень интересен. Однако я считаю, что наглядность деревьев из цветных листиков сильно преувеличена. Это же так несовременно и неповоротливо. Не сам метод управления, но его реализация. Присоединяюсь к вопросу:
а вы рассматривали электронные варианты досок?
И небольшое наблюдение. Обратите внимание на невербальное общение у вас в команде (это ведь ваша команда?)
Я не вижу здесь единой команды и тем более лидера.
Удачи вам в вашей работе.
rum
15.03.2017 10:03А что не так с руками у людей на фотографии?
Comlan
15.03.2017 10:06Вы их видите? А дальше сами поищите информацию об этом.
Aleks_ja
15.03.2017 10:18-12 человека, что левее стоят под кондиционером, им холодно. Девушка — vip гость — сидит, остальные позируют.
Toshiro
15.03.2017 10:25+3Это все полная фигня. Положение рук определяется комфортом, а не каким то там мистическим психосоматическим языком тела.
Когда долго стоишь на ногах, руки устают висеть, поэтому или складываешь их на груди, или кладешь в карманы, за спину, на пояс, облокачиваешься на что-то.
Если для вас это значит что-то большее, то это не у команды проблема, а у вас синдром поиска глубинного смысла.
Comlan
15.03.2017 10:37-1Если на летучках возникает такая ситуация
долго стоишь на ногах, руки устают висеть, поэтому или складываешь их на груди, или кладешь в карманы, за спину, на пояс
, то она доставляет дискомфорт. Вы любите работать когда вам неудобно работать? Вот здесь и проявляется то, что вы назвали
все полная фигня
Однако я думаю, что для автора статьи этот несостоявшийся спор не имеет вообще никакого значения.
Давайте с вами думать, что все замерзли в свитерах под неработающим кондиционером. И что всё это фигня.
Скажете что-нибудь про доски?
medvoodoo
15.03.2017 10:15+1Мы от такой доски отказались, стикеры постоянно отваливаются. Имхо, редмайн на порядок удобнее :)
Aleks_ja
15.03.2017 10:22-1На самом деле, проще начать с доски физической + столько информации сразу не влезет на монитор + доска всегда паказывает борд — нужно просто поернуть голову.
Comlan
15.03.2017 10:43+1Проще конечно. Тем более так начали делать в Японии в 1950 году. А ещё, там система оповещения была об ошибках на производственной линии, когда рабочие дёргали за верёвку, тем самым подавая сигнал всем остальным. Это ведь тоже проще, чем городить электронную систему с кнопками. Не так ли?
Aleks_ja
15.03.2017 11:58-1А как насчёт остальных аргументов?
Comlan
15.03.2017 13:46+1столько информации сразу не влезет на монитор
у нас в конструкторском отделе разрабатывают чертежи (сборочные в основном) A0 формата, на «мониторе» естественно, и я пока ни разу не слышал, чтобы кто-нибудь попросил кульман, распечатал на A0 и сказал — вот теперь всё влезло, теперь удобно
alexoron
15.03.2017 21:03столько информации сразу не влезет на монитор
Почему Вы так решили?
Есть инструменты где это все продумано, точнее зуминг предусмотрен, как например такой сервис
ViViVi
15.03.2017 14:02+1Каждый рабочий день в 10.00 мы с командой собираемся на летучке у канбан-доски, где каждый отвечает на три вопроса:
— Что сделано за прошлый день?
— Какие проблемы возникли?
— Что планируется сделать за предстоящий день?
«Что сделано за прошлый день?» и «Что планируется сделать за предстоящий день?» — не должно обсуждаться, так как это видно из канбан доски и тем самым сокращает время обсуждения.
«Какие проблемы возникли?» — в канбане вы узнаете об этом почти сразу (в зависимости о того какого уровня команды, предприятия… у вас используется канбан), так как это остановит весь процесс.
Спасибо за статью!
Dmitriy_ua
15.03.2017 21:05Разве стикеры не клеятся в процессе этих Scrum-ов? Иначе ежедневные «летучки» действительно теряют смысл…
ruslasib
15.03.2017 21:08Имеются свои особенности, и мы только в начале освоения этого инструмента. Некоторые вещи приходиться адаптировать. Спасибо за комментарий, обращу внимание на этот момент.
Utopia
15.03.2017 21:04… Когда я говорил, что люди важнее процессов, вы продолжали устраивать agile тусовки и устанавливать скрам-доски (канбан). Теперь у нас тотальный скрам, а проекты (НИВА), согласитесь, делаются (ездит) все так же хер*во.
ruslasib
15.03.2017 21:05Мы не конвейер АвтоВАЗ — мы делаем качественные детали и узлы для оффроуд автомобилей:)
KrakaZyabrik
16.03.2017 10:091) Напоминает замену калькулятора на счеты. На мой взгляд всем совершенно не нужно видеть всю доску целиком и понимать кто и что делает. Каждый конкретный сотрудник скорее всего заинтересован только в отображении его задач. Возможно ПМ-у было бы удобно увидеть такую картинку для принятия какого-нибудь решения. Но опять же думается, что более полезными окажутся какие-то более специализированные запросы. Так что мало того, что оно нужно не всем, но даже тому, кому нужно в таком жестком (физическом) виде польза весьма сомнительна.
2) Отсутствие какой-либо гибкости представления, фильтрации, сортировки и т.д. История изменения? Права на операции? Интеграция с другими системами и т.д. и т.п.
3) Не понятно, какую проблему решает доска? На вскидку она являет собой некий глобальный мега-отчет по всем проектам и сотрудникам. Как можно с помощью этого отчета что-то там оптимизировать и улучшать? Перед тем как ввести данное новшество был проведен анализ проблем, которые она была призвана решить, а после — анализ того, были ли решены проблемы?
Думаю, что полезной была бы некая автоматизированная система, способная подсказывать каждому сотруднику чем он должен заниматься в данный момент (какой именно задачей). Данное знание она должна выводить на основе многих входных параметров (приоритеты, опыт сотрудника, загруженность, параметры проекта, риски и т.д.). Ну и приделать кучу разных отчетов. Вот она точно что-то позволила бы оптимизировать.
tupikoff
16.03.2017 10:11Визуализация и летучки — это классные шаги!
Прикольная идея про магниты и написанные на нём цифры!
Но фактически ваша визуализация — это половина доски задач Scrum. Сейчас там нет списка того, что надо сделать вообще и в ближайшем спринте.
Причем еще доска разделена по людям, а это значит работа индивидуальная и сама визуализация не мотивирует помогать друг другу.
Kanban визуализация предполагает, что вы на ней отразите весь workflow вашей работы (построите так называемый Value Stream Map). Как то, что вы продаете, та ценность, которую вы наносите, развивается: от идеи до поставки. Например карточка — это проект и он двигается по доске, на которой отражены этапы работы над проектом. Например: конструирование, технологии, снабжение, наладка, дизайн, маркетинг, документация. Что то идет последовательно, что то можно визуализировать параллельно и т.д. Как это у вас в жизни. Если стадии у вас всегда разные, не предсказуемые, например работа исследовательская, то вам надо использовать Scrum, а не Kanban.
Далее в Kanban вводится ограничение количества одновременно делаемой работы (WIP). Но ограничиваем именно сколько ценностей, того, что продаем мы делаем одновременно. Для чего? Для сокращения time to market. Теоретически это обоснованно законом Литтла, вывод из которого: чем меньше очередь, тем быстрее мы её обработаем. Как раз на это нацелен Kanban: сокращаем WIP, чтобы уменьшить time to market, а значит быстрее нанести ценность.
Сейчас из графика приоритетов у вас WIP в среднем 15 — столько проектов одновременно в работе. Это вам надо сокращать. Ограничить например до 5 и не запускать следующий проект, пока один из текущих не завершится.
Ну далее Kanban развивается в сторону того, что вы уже начали делать: летучки, метрики, эволюционное развитие, поддержка инициатив.
Вообще — это я рассказал вам про Kanban Дэвида Андерсона. Кстати недавно вышла его книжка на русском.
sah4ez32
Спасибо за статью! Ждем от вас продолжения по улучшению вашего процесса!
Ну а теперь вопросы, а вы рассматривали электронные варианты досок (к примеру Trello)?
Как идею восприняли "рядовые" инженеры, какие эмоции?
Какие перспективы развития видите в этом инструменте?
А рассматривали вариант применения подходов Agile?
Может не хватает каких-то специфичных для этой сферы ИТ-инструментов в работе процесса?
Fesor
Канбан является пожалуй самым "гибким" подходом из всех "гибких методологий". Он прекрасно встает практически на любой процесс разработки и способствует его оптимизации. Теория ограничений, lean, toyota way и все такое.
А просто скажем взять "команду" которая привыкла работать определенным образом и сказать им "так ребятки с понедельника работаем по скраму" это так себе идея и она далека от "гибкости". Намного удобнее взять существующий процесс, навесить ограничения и фиксить ботелнеки формируя свой процесс.
ruslasib
Спасибо за отхыв!
Мы некоторое время думали насчет доски в электронном виде и для начала решили, что дешевле будет на первом этапе реализовать ее физически (доску мы тысяч за 6 купили), так как не совсем было понятно приживется у нас этот метод или нет.
Параллельно ведем переговоры с компанией Elma, чтобы они к своей системе прикрутили канбан доску. Если говорить о персональных предпочтениях, то мне удобно работать с тем, что можно физически потрогать, подвигать, пощупать.
По поводу восприятия членами команды у всех по-разному. В целом позитивно воспринимают и понимают необходимость изменений. Тем не менее необходимо регулярно напоминать об имеющемся инструменте и подсказывать, как делать так, чтобы он работал. Первое время даже приходилось звать команду на летучку, сейчас же все сами приходят. Также пересмотрели график работы офиса: у нас появилось окно с 8.00 до 10.00, когда каждый сотрудник может сам выбрать во сколько ему приходить на работу. Единственное правило: ровно в 10.00 все должны быть на летучке — за опоздания хоть на секунду штраф 500 рублей.
Про agile и ИТ-инструменты ничего пока сказать не могу. Может вы что посоветуете?