В любой сфере есть потери: лишние действия, затянутые процессы, ошибки, которые приводят к тратам ресурсов. Концепция бережливого производства учит их находить и устранять. На примере работы IT-компании рассказываем, как применять этот подход, какими инструментами пользоваться и с чего начать, чтобы внедрить его в работу своей команды.
Бережливое производство — это устранение процессов, которые не добавляют итоговому продукту ценности. Их обозначают как потери и делят на три типа: муда, мури и мура. Это японские термины, потому что впервые о потерях заговорил японец Тайити Оно, основатель бренда «Тойота».
- Муда — потери на производстве.
- Мури — потери, вызванные напряжением или перегрузкой людей, процессов или оборудования.
- Мура — неравномерность выполнения работ, результат муда и мури.
Концепция потерь на производстве
Потери на производстве (муда) делятся на семь типов:
- перепроизводство,
- ожидание,
- транспортировка,
- излишнее перемещение,
- дефекты,
- излишняя обработка,
- запасы.
Как бороться с потерями
Опишем способы устранения тех потерь, с которыми часто сталкивается IT-сфера. Бороться с ними помогает внедрение метрик, анализ и фокус на рефлексию: искать нужно не виновных, а ошибки в процессах, которые привели к потерям.
Дефекты
Дефекты — это ошибки, которые допускают разработчики, тестировщики, аналитики и другие участники команды. Самые дорогие ошибки — в самом начале пути: у аналитика, если он не проработал сценарии поведения системы и пользователей, или у архитектора, если он не учел всех требований и дальнейшего масштабирования продукта. Такие ошибки приводят к перерасходу бюджета и срыву сроков проекта.
Как измерить
- Подсчитываем общее количество дефектов.
- Разделяем подсчет по типу ошибок: блокирующие, критические, незначительные.
- Измеряем время, потраченное на устранение выявленных дефектов.
- Собираем обратную связь от реальных пользователей: она помогает выявить требования, пропущенные на этапе аналитики и исследований.
Как предотвратить
- Убедить клиента в необходимости проводить аналитику.
- Подготовить полноценные ТЗ, учесть возможные сценарии пользовательского поведения и взаимодействия систем.
- Вести журнал изменений требований с датами.
- Подключать всех сотрудников к процессу контроля качества.
- Давать задачу разработчикам проверять свой код на соответствие требованиям.
- Привлекать к оценке кейсов аналитика и руководителя проекта.
- Выборочно перепроверять результаты тестирования.
Перепроизводство
В диджитал-сфере под перепроизводством понимают ситуации, когда команда превышает уровень качества, достаточный для заказчика. Все, что выходит за его пределы, — это уже перепроизводство. Это не всегда плохо, но в определенных случаях может вредить проекту. Например, это избыточная документация, на которую уходят ресурсы разработчиков, тестировщиков и менеджера, и самое главное — она очень быстро устаревает.
Как выявить
- Общий принцип — отслеживать этапы работы, на которые уходит слишком много сил, а результат которых при этом меньше, чем хотелось бы. В примере с документацией нужно понять, какую ее часть можно безболезненно удалить, — любая документация на проекте должна работать на результат.
Как предотвратить
- Пересмотреть всю документацию.
- Договориться с командой о ревью и сокращении избыточных процессов на проекте, которые впустую тратят время.
Ожидание
Ожидание можно рассматривать как потерю, возникающую из-за неэффективного использования ресурсов и времени. Вся менеджерская логистика на проекте тоже относится к этому пункту. Есть три основных типа ожиданий:
- ожидание согласования со стороны клиента;
- ожидание результатов работы специалистов;
- вынужденное ожидание (например, нужно обновить доступы или продлить лицензию).
Как предотвращать
- Составить календарный план, в котором будут учтены все стадии и метрики.
Что учесть в календарном плане:
- поступление задачи от клиента и первичную обработку этой задачи менеджером;
- запуск задачи в разработку;
- завершение разработки и выход задачи в тестирование;
- тестирование и скорость закрытия баг-листа;
- время ожидания релиза после завершения разработки, тестирования и баг-фикса;
- простои из-за технических проблем;
- время на обновление тестовых стендов;
- время нахождения сотрудников в режиме ожидания задач;
- отпуска, общую загрузку сотрудников, занятых в проекте на других задачах, недельную нагрузку на сотрудника, а также болезни или увольнение.
Важно заранее определить возможные замены для сотрудников, учитывая их загрузку на других задачах. Следует заложить дополнительное время на ожидание согласований со стороны клиента и возможные простои, вызванные техническими проблемами. Необходимо также учесть график отпусков стейкхолдеров и представителей заказчика, чтобы избежать сбоев в работе.
Неиспользование творческого потенциала сотрудников
Эта потеря подразумевает любые ситуации, где не использованы возможности для креативного подхода в проекте. Например, когда все решения принимает только тимлид или менеджер, не привлекая команду и не используя ее опыт. Или когда клиент изначально задает слишком жесткие рамки, но при этом ожидает нестандартных решений.
Как предотвращать
- С клиентом — переговорами и расстановкой приоритетов: креативность или следование брендбуку.
- С командой можно работать так: чем ниже позиция, тем раньше высказывается человек на командных встречах, последним говорит менеджер проекта, выслушав все идеи. При этом ответственность за решение остается на менеджере.
Транспортировка
В оригинальной концепции это подразумевает ситуацию, когда компания уже произвела нужный продукт и все, что остается, — это доставить его конечному потребителю. В контексте IT сюда относится время между поставками релизов. Если работать долгими циклами, продукт становится слишком сложным, процесс тестирования занимает больше времени, а количество багов растет. Частые поставки снижают эти риски — чем меньше объем, тем меньше багов и проще их исправить.
Как измерять
Следует подойти с вопросом: можно ли исправить ошибку в течение половины рабочего дня? Если да, то все в порядке. Если нет, значит плохо спланирован спринт и нужно пересмотреть планирование следующих итераций.
Как предотвращать
Для быстрых релизов должны быть настроены процессы:
- Регламент правок для разработчика, описание пожеланий клиента, доступы ко всем ресурсам. Разработчик не должен совершать лишних движений, чтобы приступить к задачам.
- Для менеджера важна подготовительная работа — например, можно составить чек-лист по утверждению задачи у заказчика и процессу исправления ошибок. Это позволит быстрее обучать новичков, ничего не забывать и быстрее готовить документацию для клиентов.
Излишнее перемещение
Сюда могут входить переключения между задачами, постоянные перерывы, нерациональная организация рабочего места.
Как предотвращать
- Не переключаться между задачами без острой необходимости. Ответ на вопрос в мессенджере — это тоже переключение.
- Организовывать созвоны с утра или вечером, чтобы не дробить день и оставить достаточно времени для сосредоточения над рабочими задачами.
Инструменты работы с потерями
Чтобы внедрить инструменты бережливого производства, нужно знать команду и понимать, как устроены процессы в компании. Вот что необходимо:
- Усовершенствованный календарный план
Грамотное планирование — ответ на 90% потерь, а хороший календарный план — лучший друг. -
- Руководители со стороны клиента и продакшена не уходят в отпуск, пока не согласовано ТЗ и дизайн.
- Тестирование нескольких задач не пересекается и не идет одновременно.
- В календарный план заложено время на правки и на срочные задачи от клиента.
- Отпуска разработчиков на проекте не пересекаются.
- Планирование общего календарного плана охватывает три месяца.
- Заложено время на рефакторинг проекта.
- Метрики дефектов
Метрики помогают собирать статистику по тому, где и как часто мы ошибаемся. Дают возможность увидеть процесс целиком, а не отдельные детали пазла: -
- сколько дефектов возникает после первичной реализации;
- сколько багов возвращается разработчику после внутреннего тестирования;
- какие допущены пробелы на уровне ТЗ;
- сколько багов выявил заказчик после тестирования.
- Сокращение излишней документации
При высокой скорости разработки и быстрых изменениях в проекте лучше использовать чек-листы. - Вовлечение команды в обсуждение решений
Стараться всегда обсуждать варианты решения с разработчиками. Последнее слово за архитектором, но каждый участник команды может высказать свое мнение. Стремиться, чтобы клиент тоже непосредственно общался с командой, потому что так сотрудники лучше поймут, что требуется. - Сокращение ожиданий и выравнивание планов по проекту
Только сам специалист знает свои возможности, поэтому именно от него нужно получать расчет по срокам и трудозатратам. Если дедлайн срывается, нужно выяснить причину и найти решение, чтобы ситуация больше не повторилась.
Что почитать по теме
- «Вальсируя с Медведями: управление рисками в проектах по разработке программного обеспечения». Том ДеМарко, Тимоти Листер.
- «Deadline. Роман об управлении проектами». Том ДеМарко.
- «Цель». Голдратт Элияху Моше.
- «Цель-2. Дело не в везении». Голдратт Элияху Моше.
- «Антихрупкость. Как извлечь выгоду из хаоса». Нассим Николас Талеб.
