Почему культура изменений работает в Toyota, но буксует в IT?

Когда я впервые зашла на производственную линию Тойоты, меня накрыла какофония мелодий. Это был звук андона - оператор оповещал о проблеме на участке. Бригадир тут же шёл на место, помогал разобраться или останавливал линию, чтобы предотвратить брак. Ошибки выявляют и исправляют сразу, улучшения (он же кайдзен) — ежедневная практика.

После Тойоты я пришла в IT, и меня поразила…тишина. Никто не поднимал тревогу из-за багов или проблем в процессе. Затем я стала работать Скрам мастером, и поняла, что в Scrum говорят про улучшения, но это формальность: “обсудим на ретро”. Создатели Scrum вдохновлялись производственной системой Тойоты. Они переняли идею “гибкости” и “адаптивности”, но по факту изменения часто идут тяжело.

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

Тойота не просто ищет ошибки, она создаёт условия, где их невозможно игнорировать. Андон — это не про кнопку. Это про культуру открытости. Каждый сотрудник может остановить конвейер, чтобы исправить проблему. В IT «кнопка» есть — ретро, стендапы, фидбэк-сессии. Но если команда не видит ценности в этих ритуалах, они превращаются в формальность.

Я долго пыталась понять: почему у Тойота реальна гибкая на изменения, а в IT часто инициативы идут из-под палки. Чтобы разобраться, я подобрала 5 практик Тойоты, которых мне особенно не хватало на новом месте.

👀1. Genchi Genbutsu - “приди и посмотри”.

Чтобы разобраться в проблеме, нужно быть там, где она возникает, а не строить гипотезы, сидя на стуле. Конечно, в условиях удаленной работы за компьютером совершать GG (гэгэ, как говорят на заводе) сложнее.

В чем сложность: на производстве ошибки можно увидеть, потрогать, почувствовать. В IT нужно лезть в код или общаться с людьми.

Как использовать в IT: поговорить с пользователем, организовать теневое наблюдение за них, даже просто самому протестировать продукт. Не стоит полагаться только на метрики.

🔍2. Виноват не человек, а процесс.

На Тойоте эта концепция - база. Ошибся? Значит, нужно улучшить процесс, чтобы ошибка не повторилась: найди коренные причины несовершенного процесса и прими меры по улучшению. Искать козла отпущения - ценности не прибавит. Конечно, начальники - люди, и могут поддаться эмоциям, но это скорее исключение. Например, если оператор перепутал правую и левую деталь, дело не в его невнимательности, а в неидеальной системе. Решение? Простая маркировка исключает путаницу, снижает человеческий фактор.

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

Как использовать в IT: сразу провести ретроспективу в стиле

“5 почему”. Это снизит напряжение, сделает сотрудника вовлеченным, замотивирует его, потому что он нашел причины и контрмеры. Лидеры также могут делится своими ошибками и выводами.

🏭3. Посещение гембы

Гемба - это производство, место создания ценности. В IT - это код, пользовательский опыт, работа в команде. На Тойоте и начальников, и специалистов офиса поощряют как можно чаще ходить на производство и общаться с операторами.

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

Как использовать в IT:

🌱4. Kaizen

Улучшать можно все, и неважно изменение большое или маленькое. На Тойоте есть KPI по написанию кайдзен отчетов - предложения об улучшениях на рабочем месте. Есть два вида отчетов:

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

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

Scrum тоже ориентирован на улучшения, для этого есть ретроспектива. Но есть нюанс.

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

Как использовать в IT:

👷🏼5. Shop-floor meeting

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

В чем сложность: Scrum предполагает открытость, но если в компании нет культуры доверия, люди не будут честно говорить об ошибках.

Как использовать в IT:

Культура улучшений — это не про андон, не про ретро и не про Agile. Это про смелость говорить о проблемах и готовность что-то менять.

Это были мои субъективные выводы.

А что в вашей команде звучит громче: тревожный сигнал проблемы или комфортная тишина, скрывающая проблемы?