Бережливое производство — это устранение процессов, которые не добавляют итоговому продукту ценности. Их обозначают как потери и делят на три типа: муда, мури и мура. Это японские термины, потому что впервые о потерях заговорил японец Тайити Оно, основатель бренда «Тойота».

Концепция потерь на производстве

Потери на производстве (муда) делятся на семь типов:

• перепроизводство,
• ожидание,
• транспортировка,
• излишнее перемещение,
• дефекты,
• излишняя обработка,
• запасы.

Как бороться с потерями

Опишем способы устранения тех потерь, с которыми часто сталкивается IT-сфера. Бороться с ними помогает внедрение метрик, анализ и фокус на рефлексию: искать нужно не виновных, а ошибки в процессах, которые привели к потерям.

Дефекты

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

Как измерить

• Подсчитываем общее количество дефектов.
• Разделяем подсчет по типу ошибок: блокирующие, критические, незначительные.
• Измеряем время, потраченное на устранение выявленных дефектов.
• Собираем обратную связь от реальных пользователей: она помогает выявить требования, пропущенные на этапе аналитики и исследований.

Как предотвратить

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

Перепроизводство

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

Как выявить

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

Как предотвратить

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

Ожидание

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

• ожидание согласования со стороны клиента;
• ожидание результатов работы специалистов;
• вынужденное ожидание (например, нужно обновить доступы или продлить лицензию).

Как предотвращать

• Составить календарный план, в котором будут учтены все стадии и метрики.

Что учесть в календарном плане:

Неиспользование творческого потенциала сотрудников

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

Как предотвращать

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

Транспортировка

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

Как измерять

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

Как предотвращать

Для быстрых релизов должны быть настроены процессы:

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

Излишнее перемещение

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

Как предотвращать

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

Инструменты работы с потерями

Чтобы внедрить инструменты бережливого производства, нужно знать команду и понимать, как устроены процессы в компании. Вот что необходимо:

1. Усовершенствованный календарный план
   Грамотное планирование — ответ на 90% потерь, а хороший календарный план — лучший друг.
2. • Руководители со стороны клиента и продакшена не уходят в отпуск, пока не согласовано ТЗ и дизайн.
   • Тестирование нескольких задач не пересекается и не идет одновременно.
   • В календарный план заложено время на правки и на срочные задачи от клиента.
   • Отпуска разработчиков на проекте не пересекаются.
   • Планирование общего календарного плана охватывает три месяца.
   • Заложено время на рефакторинг проекта.
2. Метрики дефектов
   Метрики помогают собирать статистику по тому, где и как часто мы ошибаемся. Дают возможность увидеть процесс целиком, а не отдельные детали пазла:
3. • сколько дефектов возникает после первичной реализации;
   • сколько багов возвращается разработчику после внутреннего тестирования;
   • какие допущены пробелы на уровне ТЗ;
   • сколько багов выявил заказчик после тестирования.
3. Сокращение излишней документации
   При высокой скорости разработки и быстрых изменениях в проекте лучше использовать чек-листы.
4. Вовлечение команды в обсуждение решений
   Стараться всегда обсуждать варианты решения с разработчиками. Последнее слово за архитектором, но каждый участник команды может высказать свое мнение. Стремиться, чтобы клиент тоже непосредственно общался с командой, потому что так сотрудники лучше поймут, что требуется.
5. Сокращение ожиданий и выравнивание планов по проекту
   Только сам специалист знает свои возможности, поэтому именно от него нужно получать расчет по срокам и трудозатратам. Если дедлайн срывается, нужно выяснить причину и найти решение, чтобы ситуация больше не повторилась.

Что почитать по теме

1. «Вальсируя с Медведями: управление рисками в проектах по разработке программного обеспечения». Том ДеМарко, Тимоти Листер.
2. «Deadline. Роман об управлении проектами». Том ДеМарко.
3. «Цель». Голдратт Элияху Моше.
4. «Цель-2. Дело не в везении». Голдратт Элияху Моше.
5. «Антихрупкость. Как извлечь выгоду из хаоса». Нассим Николас Талеб.