Канбан Метод в конструкторском бюро довел половину коллектива до истерики. Почему?

Несколько лет назад я работала в крупном конструкторском бюро. Свое дело я любила, а вот процессы в компании — не очень. Поэтому решила сломать систему и внедрить модный Канбан Метод. Но многое пошло не по плану.

Канбан Метод в конструкторском бюро довел половину коллектива до истерики. Почему?

Привет! Я Мария Украинцева и сейчас работаю консультантом по Канбан Методу в компании Neogenda. А до этого была инженером и заместителем начальника отдела в конструкторском бюро. Оно разрабатывает софт для гражданской и военной авиации и тогда сильно нуждалось в организации процессов. Расскажу, как я пыталась внедрить Канбан Метод и таск-трекеры и с какого раза у меня это всё-таки получилось.

Устала от переработок, задач в стол и решила организовать процессы

Мы в бюро почти всегда работали в режиме аврала. Все вокруг были перегружены, оставались допоздна, работали по выходным, но при этом не видели особых результатов. Работа отправлялась либо в стол, либо нам приходилось всё переделывать, потому что заказчики жаловались.

Однажды мне всё это надоело и я решила обсудить проблемы с коллегами. Оказалось, что руководители отделов программистов и инженеров тоже страдали от бардака. Вот что нам всем мешало:

  • Неорганизованность. У нас в команде был таск-трекер Jira, и начальники отделов требовали, чтобы все задачи ставились через него. Но в 15–20% случаев люди всё равно получали задачи в курилке, а в Jira вносили только после нескольких напоминаний. При этом 40% задач попадали в работу уже горящими — их записывали в ежедневник и забывали.
  • Хаотичность. Даже руководители отделов слабо представляли, кто чем занимается и когда будет готово. Все процессы видел только главный конструктор — у него на стене висела большая доска, около которой все что-то без конца обсуждали.

При этом конструкторское бюро как-то работало: программы выходили, а клиенты их получали. Но я понимала: можно сильно лучше. Главное — решить вопрос с псевдосрочными задачами и упорядочить работу. Поэтому мы с двумя коллегами решили немного изменить работу отделов. Начали с программистов, инженеров и тестировщиков.

Внедрила таск-трекер и показала, кто перерабатывает, а кому не хватает рвения

Тогда я еще не знала, что такое STATIK и как он помогает распутывать проблемы компаний. Я просто логически пришла к мысли, что перед изменениями нужно пройти три этапа:

  • Выяснить цель — зачем нам менять рабочие процессы.
  • Узнать, в каких областях самые серьезные проблемы — в нашем случае это то, чем были недовольны мы и наши пользователи.
  • Наметить пути решения — что помогло бы нам упорядочить процессы.

STATIK — это аббревиатура от Systems Thinking Approach to Introducing Kanban. Переводится как «системный подход к использованию Канбан Метода». Идеальный вариант — провести встречу в команде, чтобы каждый смог сказать, чего не хватает в работе.

Канбан Метод — это управленческий метод, который помогает определять, управлять и совершенствовать процессы производства нематериальных продуктов и оказания услуг.

Чтобы начать работать по Канбан Методу, важно провести STATIK — подойти системно к вопросу, чем недовольны заказчики и клиенты и почему это произошло. А потом подумать, как улучшить систему и клиентский сервис.

Когда мы обсудили всё в нашей команде влияния из трех человек, получилась вот такая схема ↓

Тогда мне казалось, что проблемы, которые я выделила, касаются всех, поэтому будет легко внедрить изменения
Тогда мне казалось, что проблемы, которые я выделила, касаются всех, поэтому будет легко внедрить изменения

Вот что интересного появилось в бюро на этом этапе.

Общая маркерная доска у начальников отделов. По ней можно отслеживать движение конкретных заказов. Фото у меня нет, но я сделала примерную табличку, как она выглядела.

Разные карточки мы планировали обозначать разными цветами. Идеальный вариант, когда задача проходит по всем стадиям и не возвращается. Но без блокеров не обходится — это когда мы по какой-то причине не можем выполнить задачу
Разные карточки мы планировали обозначать разными цветами. Идеальный вариант, когда задача проходит по всем стадиям и не возвращается. Но без блокеров не обходится — это когда мы по какой-то причине не можем выполнить задачу

Выезды к клиентам. Пользователи часто звонили и жаловались на продукт, поэтому мы предложили инженерам выезжать к клиентам и контролировать установку ПО. Многие из сотрудников, которые работали в бюро годами, — «старички» — отказались, а новые сотрудники — «молодежь» — согласились.

Постановка задач в Jira. Начальники отделов договорились, что если задачи нет в Jira, ее можно смело не делать. Все задачи по переделкам стандартизировали: не принимали их без информации, зачем нужна задача, для какого проекта, кому и когда ее сдавать. Так мы планировали избавляться от лишней работы и выявлять потенциальные проекты в стол еще на этапе постановки задачи.

Также у нас появился прототип Канбан Метода — тогда он был в Jira. Мы создали доски для разных отделов, колонки с задачами для каждого сотрудника и этапы, через которые проходят задачи. Таким образом я хотела понять, сколько реально времени уходит на задачи.

Все изменения мы внедрили сверху вниз — приказом от начальника.

Чтобы не оставлять коллег один на один с изменениями, мы собрали совещание с начальниками отделов и директором, и я рассказала, как всем пользоваться. Доволен был только директор, а сотрудники посчитали, что все наши идеи от лукавого. Открыто возразить при этом никто не смог, поэтому мы начали работать.

Прозрачная система учета задач вскрыла косяки. Например, показала, что у кого-то из команды в очереди 40 тикетов, а у кого-то всего 4. «Старички» перестали получать премии, потому что не ездили к заказчикам, — за них это делала «молодежь». Директору не нравилось, что тикетов слишком мало — он считал, что люди могли бы работать больше и быстрее. Обстановка в команде накалялась.

Сейчас я понимаю, что изменения были слишком глобальные и затрагивали личные интересы «старичков». Им нужно было перестраиваться и выполнять работу, которую не хотелось делать. Они не понимали, зачем всё это нужно, и не хотели принимать новую систему.

Попробовала объединить команду вокруг общей цели, но всё стало еще хуже

Я искала выход из ситуации и сходила на профильную конференцию. После нее мне пришла в голову мысль объединить команду в общую систему. Я посчитала, что это поможет людям организоваться и сфокусироваться на том, чтобы закрывать задачи. Дополнительно я попробовала продвигать идею улучшений в клиентском сервисе. Несмотря на то, что некоторые сотрудники ездили к клиентам и настраивали им софт, он всё равно периодически не работал.

На этом этапе я попробовала внедрить WIP-лимиты для сотрудников, суть которых в том, чтобы не брать новые задачи, пока в работе их и так много. Так мы могли бы равномернее распределить работу. Вот как выглядела новая схема ↓

Мы сместили фокус с себя на клиента, чтобы организовать работу и объединиться
Мы сместили фокус с себя на клиента, чтобы организовать работу и объединиться

Новая схема вызвала еще большую волну негодования. «Старички» были вынуждены обсуждать свои задачи с коллегами, организовываться вокруг процессов и передавать друг другу карточки. Им это не нравилось, поэтому они начали бастовать: перестали заводить новые карточки в таск-трекере, удаляли старые задачи.

В итоге почти весь объем задач взвалили на «молодежь», и мы работали без выходных. Со временем у директора лопнуло терпение. Он внедрил свою систему контроля за сотрудниками: поставил сканеры отпечатков пальцев на вход и выход на всех этажах и стал снова требовать отчеты, но не раз в месяц, как раньше, а каждую неделю. «Старички» стали саботировать все изменения, плести интриги. Например, пакостили: переписывали версии программ так, чтобы нашей работы не оставалось. Когда мы замечали это, коллеги прикидывались, что сделали всё случайно. Хотя точно знали, как всё работает. Параллельно они постоянно жаловались директору, что так работать невозможно. Он не реагировал, потому что не хотел их трогать.

В итоге меня всё это задолбало, я уволилась и устроилась в банк.

Вернулась помогать, когда «старички» поуходили на пенсию, а «молодежь» устала от хаоса

Прошло два года, я успела поработать в нескольких Скрам Командах и использовала Канбан Метод в некоторых сервисах коммерческого банка. С бывшими коллегами продолжала общаться — в конструкторском бюро у меня осталось много друзей. Краем уха слышала, что в отделах ничего не меняется и всё так же плохо.

При этом руководителям всё еще хотелось наладить процессы — к нам на тренинг пришел начальник отдела программистов. Он рассказал, что состав команды сильно изменился: «старички» ушли на пенсию, а костяк теперь состоит из «молодежи». Они знакомы с таск-трекерами и в основном не испытывают к ним неприязни.

Чтобы навести порядок, нужно было начинать всё с нуля — в этот раз я решила работать только с программистами. Они сами стремились к изменениям, поэтому выше вероятность, что Канбан Метод приживется.

Провели STATIK-встречу и выяснили, кто чем недоволен. Например, программистов не устраивали постоянные переделки — за собой и коллегами. Еще не нравилось, что сроки ставят с потолка, но никто по факту в них не попадает.

Такую доску мы собрали во время STATIK. В левом верхнем углу — проблемы, которые всех раздражают. В левом нижнем углу — потребности отдела. В центре — визуализация рабочих процессов. Справа — место под Канбан Систему
Такую доску мы собрали во время STATIK. В левом верхнем углу — проблемы, которые всех раздражают. В левом нижнем углу — потребности отдела. В центре — визуализация рабочих процессов. Справа — место под Канбан Систему

Разработали поток обработки заказов. В нем мы отметили, из каких этапов состоит работа, кто на каком этапе подключается и какой результат считать готовым.

Таким получился процесс для отдела программистов
Таким получился процесс для отдела программистов

Классифицировали задачи, которые поступают в отдел. Например, самые частые — сборка дистрибутива, разработка или доработка внутреннего ПО. Самые редкие — разработка ПО для нового оборудования или доработка документации. Мы договорились о сроках на каждую задачу, но оставили пространство для маневра. Например, любая задача могла стать срочной в любой момент.

Сделали прототип Канбан Метода в Jira. У программистов появились WIP-лимиты, мы стали следить за временем работы по всем тикетам и учитывать количество доработок. Через полгода поняли, что надо переезжать в новый таск-трекер, и выбрали Kaiten.

В Kaiten, в отличие от Jira, намного проще собирать и выгружать статистику. Если в Jira нужно установить плагины, выгружать всё в таблицу, а потом объединять и анализировать, то в Kaiten всё работает прямо внутри программы. Например, нажимаешь в интерфейсе «Построить накопительную диаграмму потока» и видишь все задачи: в очереди, в работе, готовые.

Начальник отдела рассказал, что персональный Канбан Метод в Kaiten оказался успешным. Команда смогла настроить процессы так, как нужно для работы над задачами.

Вот пример одной из таких досок. В одном окне видно входящие задачи, долгосрочные проекты и текучку
Вот пример одной из таких досок. В одном окне видно входящие задачи, долгосрочные проекты и текучку

Другие отделы тоже стали понемногу меняться. Например, инженеры организовались сами, начали общаться с программистами, завели таск-трекер и постарались визуализировать процессы. Я не предлагала им помощь — в команде еще остались люди, для которых я враг номер один. Но наблюдать за процессами приятно.

Сейчас я понимаю, что подталкивала к изменениям людей, которые были к ним совсем не готовы. Специалистам казалось, что я внедряю Канбан Метод для того, чтобы показать их косяки руководству. Поэтому многие изменения встречаются в штыки.

Думаю, мне стоило плотнее работать с программистами, но по-другому. Нужно было сместить фокус на то, чтобы попадать в ожидания заказчика. А людей объединить вокруг переработок и доработок. Еще стоило поддерживать значимость «старичков» как ведущих экспертов с уникальными знаниями, которые знают процессы лучше всех.

Также было необходимо обеспечить первоначальную эмпатию к Канбан Системе. Первым шагом к этому должна была стать совместная ее разработка и Kaiten: нормальный удобный таск-трекер, который значительно снижает негатив от изменений.

Поделитесь, как вам атмосфера в конструкторском бюро? Сталкивались ли с такими командами?

Хотите избавиться от хаоса в задачах и процессах? Попробуйте Kaiten, это бесплатно.

4949
34 комментария

Очень узнаваемая история, увы. Часто такую команду не переделать, пока большая часть сотрудников, которая по 20 лет работает и ничего менять не уйдет просто, даже если работают максимально неэффективно

2
Ответить

Много где такое, да. Но на самом деле можно проводить орг изменения и без переделки всей команды) люди же профессионалы, они умеют работать и делают это круто

Ответить

К сожалению, ваш подход к изменениям рушит индустрию и только прививает ненависть к всем видам Technical/Product Management.

У вас ничего не получилось, потому ваши свистелки не решали корень проблемы и не меняли сам процесс управления продуктом внутри компании.

Надеюсь, что в следующий раз, вы всё-таки сможете грамотно коммуницировать со "старичкам" и прислушиваться к их мнению, чтобы понять действительные проблемы в системы и научиться изменять её снизу вверх.

Дизайн Канбана - это оптимизация ПОТОКА внутри процесса. А не сам процесс /методология управления проектами.

Вы технически не можете уничтожить процесс и заменить его рядом потоков. Даже если в вашей голове картина мира сложилась таким образом - процесс на самом деле никуда не исчез.


«Мы работаем по Канбану». Это тоже некорректно - Канбан используется для обёртки существующего процесса, его можно применить к Scrum, XP, DSDM, Водопаду, и это будет полезно. Но судя по вашей иллюстрации, Chaos Engineering, приукрашенный Канбаном, из вашей системы никуда не делся. От сюда и корень проблем.

Канбан применяют к уже существующему процессу, а не как что-то отдельное.

Эволюция процесса основана на понимании Business Value ваших продуктов, клиентов, культуры внутри компании, ментальных заскоков владельцев и инвесторов. Без глубокого анализа этих составляющих вы не можете построить эффективный процесс улучшающих важнейшие бизнес метрики.

1
Ответить

Конечно, статья отражает предыдущий опыт, может подсказать, как не надо делать, если вы внимательно читали) в целом ваш комментарий справедлив, но у меня, как аккредитованного тренера и консультанта по Канбан Методу от Kanban University, есть замечания к некоторым вашим утверждениям. Найду время на днях и прокомментирую подробно

Ответить

Это всё не так.:)
«Иди напиши пару формул [на снегу]» Штирлиц

Ответить

Тут от самого коллектива зависит - кто-то более гибкий, кто-то менее

1
Ответить

Тоже да. Но работать можно с любым коллективом, просто нужны разные практики в зависимости от уровня организации, культуры и прочего

Ответить