Публикация была переведена автоматически. Исходный язык: Русский
Что такое Muda?
MUDA (無駄) - слово из японского языка, которое означает бесполезность, пустую трату или потери. В Toyota Production System (TPS) под muda понимали всё, что тратит ресурсы, но не добавляет ценности для клиента. Таким образом, устранив muda из производства, можно генерировать больше ценности при тех же ресурсах, либо генерировать такую же ценность при меньших ресурсах.
С какими Muda вы можете столкнуться в IT?
В традиционном бизнесе, в частности в TPS, выделили 7 видов Muda. В методологии Lean Enterprise для сферы услуг, которую в дальнейшем адаптировали и для разработки в IT, также выделили 8 вид. Давайте рассмотрим все 8 видов Muda:
- Перепроизводство
Трата ресурсов на то, что не будет использоваться. Например: команда приняла решение внедрить в приложение умный AI чат-бот, потратила множество ресурсов на наполнение базы данных и интеграцию со сторонними сервисами. Однако, продукт был специфический, и чат-бот работал нормально только для простых вопросов. По итогу 90% обращений продолжило идти в техническую поддержку.
- Ожидание
Периоды простоя, когда ценность не доставляется клиенту и обратная связь не доставляется от клиента. Например: новый модуль протестирован и уже 2 недели как готов к релизу. Но он еще не прошел согласование у юридического отдела, отдела коммуникаций и директора по развитию. Пользователи уже успели распробовать аналогичную фичу у компании конкурента, которая зарелизила модуль быстрее и ушли к ним.
- Транспортировка
Перемещение инструментов, людей и информации через избыточные этапы. Например: для корректной работы новой фичи одной команды, необходимы корректировки в сервисе, который разрабатывает другая команда. Тогда тимлид первой команды передает требования своему руководителю, который обсуждает это с CEO. Затем CEO передает эту задачу руководителю смежного департамента, который уже передает это тимлиду второй команды. Пока задача достигала второй команды, проходя через избыточные этапы, был потерян весь контекст и детали.
- Избыточная обработка
Усложнение производства и процессов, которые не приводят к приросту ценности. Например: стартап решил переписать приложение с монолита на микросервисы в целях оптимизации и масштабируемости. Но продукт был маленький и нагрузка невысокая. Теперь для малейшего обновления нужно синхронизировать 10 сервисов и прогнать несколько пайплайнов. для пользователя не поменялось ничего, а для команды замедлилась скорость работы.
- Запасы
Накопление неиспользуемых артефактов. Например: в бэклоге команды накопилось более 700 задач, многие из которых лежат там больше года. Никто их не закрывает, но они постоянно мешают приоритизации: команда тратит время на обсуждение и сортировку того, что никогда не будет реализовано.
- Лишние движения
Ненужные активности, не ведущие к созданию ценности. Например: в команде проходят дейлики, где каждый по кругу озвучивает статус своих задач. При этом все эти же статусы уже зафиксированы и обновляются в Jira. В результате люди тратят время на повторение информации, которая и так доступна в системе, а реальные блокеры и решения обсуждаются вскользь.
- Дефекты
Ошибки, приводящие к переделкам, требующим времени и денег, которые могли бы быть потрачены на генерацию ценности. Например: любые баги, которые влияют на функциональность продукта, вроде фантомного списания денег у пользователей Freedom Bank.
- Нереализованный потенциал людей
Когда способности сотрудников используются не по назначению или блокируются процессами. Например: в команде есть продуктовый аналитик, который умеет строить прогнозные системы, формулировать гипотезы и проверять их через A/B-тесты. Но руководство использует его только как секретаря по задачам - вести бэклог, писать тикеты и собирать статусы. Его сильные стороны в поиске роста и экспериментах не применяются, продукт топчется на месте.
Вероятно, многие примеры показались вам знакомыми. Мы разобрали, какие бывают виды muda в IT на конкретных кейсах. Знание этих потерь позволяет их быстрее замечать и устранять, и тем самым давать больше ценности пользователю теми же ресурсами или достигать тех же результатов меньшими усилиями.
Важно понимать, что устранение muda нужно не для бережливости или экономии, а для фокус на важном и про умение не закапываться в лишнем. Чем быстрее команда научится видеть эти ловушки, тем быстрее она будет расти.
Что такое Muda?
MUDA (無駄) - слово из японского языка, которое означает бесполезность, пустую трату или потери. В Toyota Production System (TPS) под muda понимали всё, что тратит ресурсы, но не добавляет ценности для клиента. Таким образом, устранив muda из производства, можно генерировать больше ценности при тех же ресурсах, либо генерировать такую же ценность при меньших ресурсах.
С какими Muda вы можете столкнуться в IT?
В традиционном бизнесе, в частности в TPS, выделили 7 видов Muda. В методологии Lean Enterprise для сферы услуг, которую в дальнейшем адаптировали и для разработки в IT, также выделили 8 вид. Давайте рассмотрим все 8 видов Muda:
- Перепроизводство
Трата ресурсов на то, что не будет использоваться. Например: команда приняла решение внедрить в приложение умный AI чат-бот, потратила множество ресурсов на наполнение базы данных и интеграцию со сторонними сервисами. Однако, продукт был специфический, и чат-бот работал нормально только для простых вопросов. По итогу 90% обращений продолжило идти в техническую поддержку.
- Ожидание
Периоды простоя, когда ценность не доставляется клиенту и обратная связь не доставляется от клиента. Например: новый модуль протестирован и уже 2 недели как готов к релизу. Но он еще не прошел согласование у юридического отдела, отдела коммуникаций и директора по развитию. Пользователи уже успели распробовать аналогичную фичу у компании конкурента, которая зарелизила модуль быстрее и ушли к ним.
- Транспортировка
Перемещение инструментов, людей и информации через избыточные этапы. Например: для корректной работы новой фичи одной команды, необходимы корректировки в сервисе, который разрабатывает другая команда. Тогда тимлид первой команды передает требования своему руководителю, который обсуждает это с CEO. Затем CEO передает эту задачу руководителю смежного департамента, который уже передает это тимлиду второй команды. Пока задача достигала второй команды, проходя через избыточные этапы, был потерян весь контекст и детали.
- Избыточная обработка
Усложнение производства и процессов, которые не приводят к приросту ценности. Например: стартап решил переписать приложение с монолита на микросервисы в целях оптимизации и масштабируемости. Но продукт был маленький и нагрузка невысокая. Теперь для малейшего обновления нужно синхронизировать 10 сервисов и прогнать несколько пайплайнов. для пользователя не поменялось ничего, а для команды замедлилась скорость работы.
- Запасы
Накопление неиспользуемых артефактов. Например: в бэклоге команды накопилось более 700 задач, многие из которых лежат там больше года. Никто их не закрывает, но они постоянно мешают приоритизации: команда тратит время на обсуждение и сортировку того, что никогда не будет реализовано.
- Лишние движения
Ненужные активности, не ведущие к созданию ценности. Например: в команде проходят дейлики, где каждый по кругу озвучивает статус своих задач. При этом все эти же статусы уже зафиксированы и обновляются в Jira. В результате люди тратят время на повторение информации, которая и так доступна в системе, а реальные блокеры и решения обсуждаются вскользь.
- Дефекты
Ошибки, приводящие к переделкам, требующим времени и денег, которые могли бы быть потрачены на генерацию ценности. Например: любые баги, которые влияют на функциональность продукта, вроде фантомного списания денег у пользователей Freedom Bank.
- Нереализованный потенциал людей
Когда способности сотрудников используются не по назначению или блокируются процессами. Например: в команде есть продуктовый аналитик, который умеет строить прогнозные системы, формулировать гипотезы и проверять их через A/B-тесты. Но руководство использует его только как секретаря по задачам - вести бэклог, писать тикеты и собирать статусы. Его сильные стороны в поиске роста и экспериментах не применяются, продукт топчется на месте.
Вероятно, многие примеры показались вам знакомыми. Мы разобрали, какие бывают виды muda в IT на конкретных кейсах. Знание этих потерь позволяет их быстрее замечать и устранять, и тем самым давать больше ценности пользователю теми же ресурсами или достигать тех же результатов меньшими усилиями.
Важно понимать, что устранение muda нужно не для бережливости или экономии, а для фокус на важном и про умение не закапываться в лишнем. Чем быстрее команда научится видеть эти ловушки, тем быстрее она будет расти.
Share
