4. Какие документы использует команда в Scrum в духе Toyota К стандартным артефактам Scrum добавляется «набор TPS‑документов»: 1. Расширенное визуальное управление (4 стены)
- Стена клиента: инциденты, жалобы, NPS/CSAT, динамика проблем.
- Стена производительности: качество, время, стоимость, продуктивность.
- Стена производства: поток user stories по стадиям, Takt, фактическая выработка.
- Стена проблем‑солвинга: текущие PDCA/A3, контрмеры, статус экспериментов. 2. Red bins (красные корзины) для дефектов
- Физические/виртуальные «корзины», куда складываются все случаи проблем с качеством на любом этапе.
- На их основе ведутся статистика причин и PDCA. 3. Матрицы компетенций и dojo‑планы обучения
- Таблицы навыков по членам команды и конкретные планы тренировок (написание user stories, TDD, CI и т.п.). 4. Документы PDCA / A3
- Формализованные карточки проблем: проблема → текущая ситуация → корневая причина → контрмеры → проверка → стандартизация.
Все это — не замена Scrum‑артефактов, а «вложенный TPS‑слой», который делает проблемы видимыми и учение — осознанным.
5. Какие результаты уже дал Scrum в духе Toyota Автор приводит цифры по 20 командам, внедрившим связку Scrum + TPS:
- Среднее снижение запаса необработанных инцидентов на 59%.
- Снижение потока новых инцидентов на 37%.
- Рост удовлетворенности клиентов примерно на 25%.
- Среднее сокращение lead time в 6,5 раз.
- Рост объема произведенной ценности (инциденты, изменения, новые stories) примерно в 3 раза.
- В юните 40 человек 5 сотрудников занимались инцидентами; после применения TPS за 6 месяцев инциденты сведены с 80 «висящих» и 3/день до нуля в стоке и 2 в месяц.
- Годовая стоимость обработки инцидентов упала с 720 000 € до фактически 0, освобожденный бюджет и ресурсы пошли в развитие продукта.
6. Когда командам имеет смысл изучать и пробовать Scrum в духе Toyota По сути, это ответ на вопрос: «Когда одного Scrum уже недостаточно?».
STW особенно уместен, если:
- Команда уперлась в потолок производительности: «делаем Scrum, но быстрее уже не получается».
- Постоянно тонете в инцидентах и переделках, качество «проседает», а проблемы тянутся из спринта в спринт.
- Есть ощущение, что Scrum‑церемонии проходят, но системного обучения нет.
- Нужно улучшать поток end‑to‑end, а не только работу внутри одной команды (много зависимостей, внешних очередей, задержек).
В таких контекстах стоит:
- Начать с честного визуального управления (4 стены) и расчета Takt внутри спринта.
- Ввести red bins и регулярный PDCA по качеству и потоку.
- Перепозиционировать Scrum Master как лидера TPS‑системы, а не модератора митингов.
Тогда Scrum в духе Toyota становится не модным словом, а способом превратить вашу команду в "обучающуюся производственную систему", которая сама видит проблемы, решает их и растет в мощности от спринта к спринту.
Как вам новый подход?
