Больные одной болезнью симпатизируют друг другу. Несчастные понимают друг друга.

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

(こんにちは) Конничива! Меня зовут Виктор, я менеджер проектов в Selectel. Это шестая часть цикла о применении TPS/TBP (Toyota Production System/Toyota Business Practice) на практике в IT. Каким бы крутым специалистом вы ни были, одного этого недостаточно — нужно еще и уметь показывать ход своих мыслей. Но как это сделать так, чтобы вас поняли все? Рассказываю под катом!

Используйте навигацию, если не хотите читать текст целиком:
→ Визуальный стиль
→ Save your S, или правило 5S
→ Методология А3
→ Сценарии из жизни: A3 в реальной работе
→ Показал и рассказал

Визуальный стиль

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


Источник.

Попробуйте угадать, что здесь изображено. И нет, это не про борьбу с империализмом.

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

Взглянем, например, на лабораторию обучения TPS (Toyota Production Systems) в Rochester Institute of Technology:


Источник.

Что мы видим?

• Места для рабочих у конвейера разграничены — зеленые и красные полосы показывают, где можно стоять.
• Места для лотков обозначены и очерчены своим цветом.
• Цветные карточки в комоде справа — это heijunka-коробка — инструмент для «выравнивания» производства, но о ней, возможно, в следующий раз.
• В левом верхнем углу — цветные контейнеры с разными типами комплектующих/проводов.
• Световые столбы-андоны показывают рабочее состояние на конкретном участке.

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

А теперь представьте, что вы в первый раз на заводе: большинство элементов можно считать интуитивно, ведь так? ?И это не случайность, а результат продуманной системы. Та же логика (все должно быть понятно и стандартизировано) распространяется на информационные табло и доски, которые размещены на заводе.

Например, на картинке ниже видно три цветных блока (изолента — лучший друг инженера).
Легко предположить, что это отчеты первой, второй, и третьей смены на заводе, а также разделение по участкам (по вертикали).

Save your S, или правило 5S

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

• Seiri (Сортируй) — избавьтесь от лишнего и оставьте только нужное.
• Seiton (Упорядочь) — разместите все на своих местах.
• Seiso (Очисти) — уберите рабочее место, следите за чистотой.
• Seiketsu (Стандартизируй) — зафиксируйте стандарты порядка.
• Shitsuke (Поддерживай) — делайте это регулярно, на постоянной основе.

А вы уже заметили, что цикл Деминга из первой части цикла преследует нас по пятам? ? На практике принципы 5S можно использовать во всех процессах — даже для такого, казалось бы, банального действия, как перекладывание документов с левого края стола на правый. Главное — чтобы порядок был не ради порядка, а помогал работать.

Пример для инженеров

Однако примем, что порядок на рабочем столе — утопия, и вспомним Васю, который «опрокинул» прод. Мы упоминали этот пример в одной из предыдущих статей. Ладно, шучу, давайте оставим его в покое ? (не оставим, конечно). Рассмотрим, как может выглядеть 5S в IT-контексте.

• Seiri — скрипты для разных микросервисов разложены по своим Git-репозиториям.
• Seiton — скрипты «крутятся» в своих Docker-контейнерах на серверах.
• Seiso — запланированы бэкапы, а лишние логи микросервисов чистятся cron-задачами.
• Seiketsu — весь список микросервисов лежит в Wiki, каждый из них описан.
• Shisuke — при изменении в микросервисе все вносится в Git и Wiki, сборки и зависимости задокументированы.

Как быть менеджерам

Что делать с методологией 5S менеджерам? У руководителей проектов есть своя версия 5S — она касается не столько кода, сколько порядка в документах, задачах и коммуникациях.

Если меня разбудят через сто лет и спросят, чем занимается РП, я скажу:
«Показывает слайды и ничего не делает. Но иногда — запускает проекты».

Мудрость предков.

Когда нужно обосновать запуск проекта, у менеджера есть несколько подходов:

• Презентация со слайдами — визуальный/«американский» сценарий;
• Цифровой отчет — лаконично и по делу, только факты;
• Провести симпозиум — например, неформальный в бане. Этот аудиальный поход можно считать европейским.

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


Первый вопрос «менеджера-чайки» на сухие цифровые показатели.

Презентация со слайдами — больше про «продажу» и «обрисовку прекрасного будущего» тем, кто не принимает решений. Тут речь скорее не о деле, а о «церемонии». К слову, Артемий Лебедев хорошо описал абсурд ситуации еще в 2007 году.


Источник.

Преимущество презентаций — их можно переслать по электронной почте. Но как же жили наши «древние предки»? Пользовались факсами и бумагой — например, A3-документами.

Методология А3

В 1970-х производства активно расширяли, из-за чего нужно было передавать информацию быстро и четко. Так и родилась методология А3. Почему формат А3? Влада А4 тогда еще не было. Это был максимальный размер бумаги для факса. ?

A3 — это не просто документ, но одновременно и сториборд, карта рассуждений, а также обоснование решения. Его цель — не убедить красивыми словами, а показать «как мы к этому пришли». Помимо прочего, A3 позволяет быстро передать идею без «театра презентаций» и ожидать фидбэка.

Рассмотрим, как создать свой первый A3-документ.

1. Работаем — не торопимся «рисовать», а сначала разбираемся в ситуации.

2. Изучаем процесс — тут вам помогут предыдущие главы цикла.

3. Выделяем самые важные моменты — проблемы, повторные точки и непонятные узлы.

4. Определяем круг интересантов.

5. «Рисуем» А3 — на бумаге, в программах для визуализации или любым другим удобным способом.

6. Проводим nemawashi (митинги, летучки) и повторяем все со второго пункта, пока все не скажут «ок».

7. Profit!


Типичный шаблон A3-документа. Источник.

Что входит в структуру А3

Обычно A3 включает от шести до восьми блоков, из которых первые пять — обязательные:

0. Заголовок и место для подписей ЛПР (лиц, принимающих решения);

1. Бэкграунд — описание контекста и событий, как вышли на проблему;

2. Текущая ситуация — что происходит прямо сейчас;

3. Определение целей и задач — что мы можем сделать прямо сейчас;

4. Анализ коренных причин — почему возникла проблема;

5. Контр-меры — какие действия помогут;

6. План внедрения;

7. Поддерживающие действия и результаты;

Тот, кто читал предыдущие главы цикла, уже понял: мы прошли все пять пунктов и научились работать с ними в прошлых частях! ?

Небольшое домашнее задание: составьте свой А3 по мотивам предыдущих частей.

Методология A3 — это квинтэссенция TBP (Toyota Business Practice), визуальное оформление процесса принятия решений, которое помогает избежать бессмысленных совещаний и «танцев с бубном».

И если вы вдруг знакомы с P3.Express, то знайте: грамотно составленный A3 закрывает почти всю фазу A1-A10. То есть — документ для старта проекта в одном документе.


Фаза A1-A10 в методологии P3.Express. Источник.

Сценарии из жизни: A3 в реальной работе

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

2022 год, март. Проект: запуск мерча для инфлюенсерши. Шел уже девятый месяц, запуск откладывался трижды — по нашей и их вине. Команда перегорела, клиент устал, диалог был натянут. Как быть, что делать, выпускать ли? А если выпускать, то как потерять меньше денег (речи о заработке к тому времени уже не шло). Бюджеты, как вы понимаете, были освоены. ? Нужно было убедить клиента начать продажу и я оформил A3-документ.


Пройдемся по блокам.

0. Заголовок у нас на месте. Подписи были не нужны, так как стороны было всего две — агентство и клиент, который согласовывал идею (здесь не было нашей власти).

1. Во вводных можно видеть то, о чем часто забывают на «Lean-сайтах»: важно задать себе вопросы в духе «А зачем? А что?». Структура бэкграунда довольно простая: текущая ситуация (Current Situation), идеальная ситуация (Ideal Situation), наивысшая цель (Ultimate Goal). Мы будем работать с разницей IS и CS — зоной роста.

2. Анализ ситуации может включать что угодно: графики, картинки, цепочки процессов. Главное — подсветить «где ломается» (помним о step-back).

3. Ответив на вопросы «А что?» и «Где?» мы определяем для себя задачу и намечаем, что можем сделать.

4. На этапе поиска узких мест мы бьем зоны на сегменты и подсвечиваем корневые причины (root cause). Однако если мы посмотрим на второй пункт, то заметим, что разбираем не все подряд, а только элемент с красной меткой и шаг до/шаг после. Можно использовать любые методы визуализации — хоть диаграмму Исикавы из прошлой части. Здесь я использовал горизонтальное древо.

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

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

Показал и рассказал

Надеюсь, стало видно: правильно оформленная бумага — это не бюрократия, а инструмент. Он экономит нервы, структурирует мысли и помогает действовать. Не просто «поговорили и забыли», а показали, подумали и зафиксировали.

Мы разобрались, что стены текста или 100 слайдов с плашками — не всегда лучший способ донесения смысла. Но почему же тогда все продолжают их делать?


Ответ прост: люди любят то, что проверено и работает, но чаще выбирают то, что понятнее и комфортнее на старте — наверное, синдром утенка. Это нормально, но очень важно не становиться рабами своих фреймворков, а работать с тем, что мешает. ?

В следующий раз поговорим о Kanban. Ух, весело же будет! Еще увидимся (またね) матанэ!