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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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