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

И каппа тонет (Каппа — японский водяной). Конь о четырех ногах, да спотыкается. Чаще всего тонут хорошие пловцы.

Японские пословицы.

(こんにちは) Конничива! Я Виктор, менеджер проектов в Selectel ^[1]. Это пятая часть цикла о применении TPS/TBP (Toyota Production System/Toyota Business Practice) на практике в IT. Любому инженеру знакомо правило: работает — не трожь, не сломано — не чини. Но что делать, когда оно работает, но не так? Или работает, но часто ломается? Разбираемся под катом.

Используйте навигацию, если не хотите читать текст полностью:
→ Сушим сухари ^[2]
→ 10 000 ударов и сэнсэй Ху Ли ^[3]
→ Биомеханика опрокидывания прода ^[4]
→ Ловим карпа и бьем в цель ^[5]
→ Вместо пустословия ^[6]

Сюхари ^[7] — концепция этапов обучения, которая состоит из трех ступеней.

Все новое рождается на примере старого — например, сухарики (под пиво и нет). Процесс простой: берем хлеб, нарезаем кусочками и сушим в печке. Но что делать с задачей посложнее: произвести пару тонн сухарей ^[8], а не противень?

Любой процесс является простым, если он ограничен, достаточно декомпозирован, а на его реализацию есть ресурсы. Что получаем? Классический проектный треугольник.

Однако есть нюанс: результат должен быть на 100% предсказуемым и формализованным. Проще говоря, отлаженный процесс — это уже один из результатов проекта (в идеале).

От сухарей к карате

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

• Сю (от яп. 守 — «соблюдать»). Слушаем мастера, нарабатываем базу. В тексте фокусируемся на этой ступени.
• Ха (от яп. 破 — «прорываться»). Пробуем нарушать, экспериментируем.
• Ри (от яп. 離 — «отделяться»). Выводим свои правила.

Хороший пример — сцена из фильма 1984 года «Karate Kid» ^[9]. Да и вся каноническая трилогия — отличный иллюстратор подхода.

1. Ученик осваивает классический стиль (Окинавское карате).
2. Учится у разных наставников, находит новые решения.
3. Нарушает правила, идет к предыдущему пункту, далее — снова к первому. И все это циклично. (Тут вспоминаем о цикле Деминга из первой части ^[10]).

Классический цикл Деминга.

Смысл прост: чтобы добавить в процесс что-то свое, нужно сначала понять, как он работает сейчас. Важно помнить, что «там тоже не дураки сидели» — и выстраивали процесс не просто так. Но понимаем ли мы, как он устроен сейчас? Или как вообще это должно работать?

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

Например, ката в некоторых видах карате — это не просто разминка, а основа понимания движения. Без понимания биомеханики мы не сможем повторить движение корректно — и, скорее всего, не сможем научить этому других. Об этом даже есть интересные исследования ^[11].

Фрагмент ката в карате.

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

Подобное я, наверное, как и многие из читателей, слышал от IT-команд: «Мы пробовали решить проблему, но не получилось». Однако тут возникает закономерный вопрос: что конкретно не получилось? Или получилось, но не то, что ожидали?

В прошлой части ^[12] мы разбирали ситуацию, в которой Вася якобы положил прод. Однако при внимательном рассмотрении истиная причина суматохи — Кирилл смена endpoint без явного оповещения.

Пример инцидента.

Вспомним пример с процессом смены endpoint.

1. ○ Анализ потребности в смене endpoint.

2. х Согласование смены и дат смены.

3. Δ Оповещение всех интересантов, которые используют endpoint.

4. ○ Подготовка конфигов.

5. Δ Повторное оповещение всех интересантов, которые используют endpoint.

6. ○ Постановка задач на дежурных и смена endpoint.

Теперь разберемся в символах:

• ○ — кажется, что с шагом все нормально;
• Δ — есть вопросы;
• х — вот тут проблема.

Все наши «Почему?» привели нас ко второму пункту: процесс согласования был «поломан».

И тут «эффективный менеджер» остановится: крайний найден — теперь мы загоняем все согласования в Jira по кнопке и история завершена!

Однако мы так делать не будем. Перед нанесением (или получением) удара идет целый процесс: поворот корпуса, выброс руки, прицеливание и т. д. Выходит, что мастер всегда смотрит не «куда», а «как» и «для чего» (вспоминаем о принципе 5 Why ^[12]).

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

Чтобы найти и устранить настоящие причины проблем, а не только бороться с их симптомами, воспользуемся матрицей на основе 6M — классическим инструментом из производственной среды. Он заключается в разделении составляющих на части.

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

Пример диаграммы Исикавы.

6M — шесть групп причин

• Man (люди) — сотрудники, реализующие лица.
• Method (метод) — процессы, которые используют в процессе.
• Measurement (измерения) — все, что фиксирует выполнение процесса.
• Machine (машина) — «механизмы», которые применяют в процессе — например, микросервис на Python.
• Mother Nature/Environment (окружение) — условия, которые влияют на сотрудников.
• Material (материалы) — все то, при помощи чего реализуют продукт (шаблоны, паттерны, исходный код, кабели и прочее)

Что делать с кучей проблем

Мы выписали все, что потенциально влияет на сломанный endpoint. На вид — полный кавардак. Но если немного разобраться, то можно выделить три корневые причины — root causes (RC), те самые точки, в которые стоит «бить». Мы на них вышли сделав step-back (шаг назад) на основе уже изученных процессов, а именно — при помощи любимого genchi genbutsu. На рисунке ниже подсветили эти связи пунктирными линиями.

Перечислим ключевые проблемы.

• RC1 — текучка разработчиков. Классика жанра.
• RC2 — очень много Legacy. Классика жанра x2.
• RC3 — отсутствие механизма документирования изменений. А вот тут уже назревает вопрос.

«Эффективный» менеджер или тимлид скажет: «Наймем еще людей» или «Срочно переписывайте Legacy, но фича должна быть готова завтра». Но почему он сделал такие выводы? Основывался на эмпирическом опыте и знаниях из книг.

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

• что мы делаем,
• какую корневую причину (RC) лечит конкретное предложение,
• сколько это будет стоить,
• сколько времени займет,
• сколько усилий и рук будет нужно.

Разложив все в табличку и вспомнив про крестики, треугольники и кружки видим, что нам по-хорошему надо всего лишь прикрутить систему оповещения. Далее — связать ее с мессенджером, которым пользуются сотрудники (уверен, такие плагины есть для GitLab). Вуа-ля — важные события не пропущены, все в курсе!

Да, дальше нужно будет поработать и с Legacy, и со stage-средами, и с другими проблемами, но это уже другой этап. Главное — мы поняли, куда «бить», и делаем это сосредоточенно и эффективно.

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

Прозрачность и понятность — это уже полдела.

Что будет дальше — решать команде: будет ли это при пуше в git, через редактирование статьи в Wiki, через workflow Jira, на совещаниях и т. д. Это важный этап, но чуда не случится, пока все не договорятся внутри. 🙂

Nemawashi (митинги/летучки) — нужны и важны. Об обмене опытом мы говорили еще в первой части ^[10]. Пока ЛПР (лица, принимающие решения) не закоммитятся и не возьмут на себя ответственность — система будет буксовать.

Но как ЛПР показать, что процесс важен? Как подсветить работу? Об этом — в следующей части. (またね) Матанэ! (Еще увидимся)