The post has been translated automatically. Original language: Russian
What is Muda?
MUDA (無駄) is a Japanese word that means worthlessness, waste, or loss. In the Toyota Production System (TPS), muda was understood to mean anything that wastes resources but does not add value to the customer. Thus, by eliminating muda from production, it is possible to generate more value with the same resources, or generate the same value with fewer resources.
What Muda can you encounter in IT?
In traditional business, in particular in TPS, 7 types of Muda have been identified. In the Lean Enterprise methodology for the service sector, which was later adapted for IT development, 8 types were also identified. Let's look at all 8 types of Muda:
- Overproduction
Wasting resources on something that won't be used. For example: the team decided to implement a smart AI chatbot in the application, spent a lot of resources on filling the database and integrating with third-party services. However, the product was specific, and the chatbot worked fine only for simple questions. As a result, 90% of the requests continued to go to technical support.
- Expectation
Downtime periods when value is not delivered to the customer and feedback is not delivered from the customer. For example: the new module has been tested and has been ready for release for 2 weeks. But it has not yet been approved by the legal department, the communications department and the Director of Development. Users have already tried out a similar feature from a competitor company, which released the module faster and went to them.
- Transportation
Moving tools, people, and information through redundant stages. For example: for a new feature of one team to work correctly, adjustments are needed in a service that is being developed by another team. Then the team leader of the first team transmits the requirements to his supervisor, who discusses this with the CEO. The CEO then passes this task on to the head of the related department, who already passes it on to the team leader of the second team. While the task reached the second team, going through redundant stages, all the context and details were lost.
- Redundant processing
The complexity of production and processes that do not lead to an increase in value. For example: a startup decided to rewrite an application from monolith to microservices in order to optimize and scale. But the product was small and the load was low. Now, for the slightest update, you need to synchronize 10 services and run several pipelines. nothing has changed for the user, but the work speed has slowed down for the team.
- Stocks
Accumulation of unused artifacts. For example: the team's backlog has accumulated more than 700 tasks, many of which have been there for more than a year. No one closes them, but they constantly interfere with prioritization: the team spends time discussing and sorting out what will never be implemented.
- Unnecessary movements
Unnecessary activities that do not lead to value creation. For example: there are daily meetings in the team, where everyone voices the status of their tasks in a circle. At the same time, all these same statuses have already been fixed and updated in Jira. As a result, people spend time repeating information that is already available in the system, and the real blockers and solutions are discussed in passing.
- Defects
Mistakes that lead to alterations that require time and money that could have been spent on generating value. For example: any bugs that affect the functionality of the product, such as phantom debiting of money from Freedom Bank users.
- The unrealized potential of people
When employees' abilities are misused or blocked by processes. For example: the team has a product analyst who knows how to build predictive systems, formulate hypotheses and test them through A/B tests. But the management uses him only as a secretary for tasks - to keep a backlog, write tickets and collect statuses. His strengths in the search for growth and experimentation are not applied, the product is stomping on the spot.
Probably, many examples seemed familiar to you. We have analyzed the types of muda in IT based on specific cases. Knowing these losses allows them to be noticed and eliminated faster, and thus give more value to the user with the same resources or achieve the same results with less effort.
It is important to understand that eliminating muda is not necessary for thrift or economy, but for focusing on what is important and about the ability not to dig into the superfluous. The faster the team learns to see these traps, the faster it will grow.
Что такое 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
