Комментарии 6
Всё по ТОС, а сама ТОС упоминается только как аббревиатура на картинке :)
На моей работе нет никаких проблем нарезать задачи в три раза меньше. Тогда Time-to-Market упадет примерно вдвое (непропорционально, т.к. существуют фиксированные по времени подзадачи). А что на длинных интервалах мы сделаем в полтора раза меньше полезной работы — на это никто не смотрит…
Да, действительно, нужно смотреть на ключевые метрики, при этом можно и нужно работать персонально с каждой. В данном случаи выбрали TTM для примера.
Если в ваших задачах есть ценность для пользователей при мелкой нарезки, лучше нарезать так. Если задачи двигаются быстрее, при этом пользы нет, то мы поработали с релизным циклом, а не с TTM.
Причин может быть больше. Но, если составить полное дерево, вы все равно придете к одной корневой причине.
Корневая причина всем и так понятна, а что толку?
Когда на проекте или в процессе много проблем начать надо с корневой причины (проблемы), а для этого точно диагностировать.
Смысл в фокусе прикладываемых усилий – если разрешить сперва именно корневую причину проблем, остальные могут решаться сами или оказывать меньшее негативное влияние на процесс в целом.
Найти слабое звено: делаем команду эффективнее без перегруза