Как использовать японские подходы в IT. Часть 3: защита от дурака

На одного мудреца приходится 10 000 дураков.

Японская пословица.

(こんにちは) Конничива! Я Виктор, менеджер проектов в Selectel ^[1]. В предыдущих частях мы разобрались, что такое кайдзен, а также обсудили, как подходить к нему концептуально. Добро пожаловать в третью часть цикла о применении TPS/TBP (Toyota Production System/Toyota Business Practice) на практике в IT.

Мы в Selectel готовим новый сервис. Если арендуете серверы в рабочих или личных проектах, нам очень поможет ваш опыт ^[2] — записывайтесь ^[3] на короткое онлайн-интервью. За участие подарим плюшевого Тирекса и бонусы на услуги Selectel.

Когда производство растет, неминуемо возникает «нехватка рук». Это касается не только IT, но и других сфер. Крепких специалистов с рынка просто так не заберешь, а задач много и копятся они очень быстро.

Еще один важный вопрос — обучение ^[4]. Все мы знаем о динамичном росте EdTech: курсы ^[5], стажировки, обучение на рабочем месте, базы знаний и т. д. «Готовым» специалист становится за 6-12 месяцев, а иногда дольше. Однако у бизнеса есть и другой запрос — быстрее вывести сотрудника «на линию»: дать базовое количество знаний, закрепить наставника и отправить выполнять задачи. Например, собирать новую игру «три в ряд».

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

Иногда ошибки ^[6] допускает и опытный сотрудник. И если в некоторых сферах это относительно безболезненно (условно, в доставке еды), то на производстве промахи могут привести к остановке всего процесса.

Чтобы контролировать процессы и вовремя замечать отклонения, на производстве используют систему с благозвучным японским названием — Andon (Андон, в переводе с японского «лампа»). Простым языком, Андон — это шнур над конвейером (вспоминаем принцип «дзидока» из первой части ^[7]), которая соединена с контроллером для подачи сигнала. Это может быть что угодно: динамик с мелодией, световой столб, дисплей.

Базовый принцип работы Andon. Источник ^[8].

Пример №1

Кузов автомобиля движется по конвейеру, а установщик фары (оператор) видит, что не хватает отверстия для монтажа.

1. Оператор тянет за шнур.
2. Сигнал транслируется на дисплей, динамик или другое устройство вывода.
3. Конвейер останавливается.
4. Бригадир приходит на место, осматривает проблему и принимает решение о дальнейших действиях.
5. Если дефект массовый, процесс останавливают, чтобы не тиражировать проблему.

Андон позволяет:

• дать первичный сигнал о сбое;
• определить, где именно возникла проблема;
• остановить дальнейшую работу до устранения дефекта/принятия решения.

Пример №2

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

Что важно

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

Это как кнопка «Сообщить о нарушении» на форуме — любой может нажать, но отредактировать или удалить чужие посты имеет право только модератор.

Что делать, если мы не хотим, чтобы сотрудник в принципе совершал ошибку? Самый надежный способ — не дать ему возможности ошибиться.

Для этого используются системы типа Poka-yoke — буквально «защита от дурака». Мы регулярно встречаемся с ними в жизни. На уровне софта — хотя бы в виде форм для проверки пароля.

Рекомендую истинное мучение игру ^[9] с бесконечной (наверное) формой проверки пароля. Делитесь в комментариях концовкой, если сумели ее пройти.

Пример использования системы Poka-yoke на физическом уровне. Источник ^[10].

Таким образом, Poka-yoke — система проверки операции на корректность исполнения. Как она работает:

• Быстро дает обратную связь, если что-то не так;
• Проверяет ровно то, что должна проверять (не больше и не меньше);
• Простая в реализации — чаще всего это элементарные механизмы или базовые проверки в софте.

Система может быть представлена в виде программы, части системы Andon (в идеале) или физического ограничителя как на иллюстрации ниже.

Пример использования Poka-yoke в компьютере: SATA-разъемы, ассиметричные коннекторы у ОЗУ и NVMe.

Давайте вернемся к примеру о Васе. Допустим, в процессе коммита Poka-yoke не позволила бы вставить битую ссылку на URL: либо в результате срабатывания системы проверки кода в IDE, либо если важные URL хранились в конфиге с запретом на редактирование. Выходит, этой ошибки можно было избежать, так как у Васи не было бы шанса ее сделать.

Есть простая истина: уставший сотрудник — плохой сотрудник. Если вернемся к производству, то такие вещи, как перемещение коробок и компонентов на стеллажах — трудоемкий и изнурительный процесс. Но если прикрутить к полкам стеллажа ролики, то мы уменьшим усилия и увеличим пользу. Это и есть karakuri (каракури) — устройство (чаще механическое), которое выполняет функцию за человека.

Пример из автопрома:

Некоторые могли сразу вспомнить машины Голдберга:

Примеры использования каракури на предприятиях ГК «Росатом». Источник ^[11].

Что по поводу IT

В моем понимании любая автоматизация, которая срабатывает по сигналу/импульсу и не требует от человека сложных действий — это каракури. Например, если вы написали скрипт, который автоматически пересылает сообщения из трекера в мессенджер, то вас можно считать «каракуритуристом» (это когда не рисуешь забавные лица, а делаешь такие же по своей сути конструкции)!

Пример: хардкорное каракури для ЦОД

Допустим, у вас есть тележка с несколькими ярусами и сотрудник, который демонтирует серверы. Рассмотрим, как можно улучшить процесс.

• Сделать тележку, которая автоматически будет спускать сервер вниз по модели колеса или закрытия клапана. Сотруднику не придется наклоняться, что поможет снизить риск травм и повреждения техники, а также позволит брать больше оборудования.
• Реализовать ячейки под конкретные корпусы серверов — чтобы они вставали идеально и без перекосов (Poka-yoke).

Конечно, это решение скорее из разряда «интересные концепты», чем рабочее предложение для ЦОД. 🙂

Итак, мы сделали все по уму:

• прикрутили каракури — автоматизация рутины;
• защитились Poka-yoke — не даем совершать ошибки;
• подключили Andon — система вовремя сигнализирует, если что-то пошло не так.

Даже провели немаваши (пятый принцип из первой части ^[7]) — обсудили все с командами и рассказали им, «почему сотрудник в десятый раз положил прод» и что сделать, чтобы это больше не повторилось. Спойлер: все равно прод ляжет. Но что дальше? Что бы сделал самурай, когда даже палкой кэндо замахнуться нельзя?

Верный ответ — ничего, так как человеческая психика инертна. Это значит, что даже если вы придумали идеальный процесс и детально его объяснили, коллеги какое-то время продолжат делать «как привыкли». И это не про лень, а про естественные механизмы работы мозга. ^[12]

Важно помнить: перебор с контролем тоже вреден. Если коллеги погрязнут в километрах инструкций, описаний Poka-yoke и графиков в Confluence, они скорее начнут саботировать процесс, чем выполнять его осознанно. Здесь, как и в любом кайдзене, нужен баланс.

Есть два ключевых «оружия» против саботажа (явного и неявного).

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

Ценность. Сотрудник должен видеть, что лично ему дает нововведение. Если оно упрощает жизнь, экономит время и нервы, то со временем приживется органически.

Рассмотрим, какую «выгоду» получает сотрудник от внедрения нововведений.

• Респект от руководства (и не только в виде открытки в мессенджере). Например, можно вести рейтинг с сигналами Andon, которые помогли предотвратить масштабные проблемы.
• Меньше работать и уставать. Заранее поймал баг — не сидите всей командой до ночи.
• Больше времени на себя и жизнь вне работы. Меньше бардака и ошибок — меньше горящих ситуаций и переработок.

Должно пройти время, чтобы сотрудник принял, что нововведение и контроль делают его рабочую жизнь проще. Если человек видит, что система работает на него, а не против — он сам станет ее «адвокатом». А если этого не происходит — значит, во внедрении затесалась ошибка и нужно отправляться на поиски ключевых проблем. Об этом как раз поговорим в следующей части. またね (Матанэ!) — еще увидимся!