Команда Microsoft сократила сроки на 90% — не трогая ни одного процесса
В 2004 году команда XIT оказалась в ловушке. Контракт с Microsoft жёстко фиксировал методологию — PSP/TSP. Менять процессы нельзя. Корпоративные нормы — священны. А среднее время выполнения запроса доходило до 155 дней.
Менеджер Драгош Думитриу не стал бороться с системой. Он сделал кое-что проще: ограничил количество задач, которыми команда занимается одновременно. Не новая методология, не революция — просто правило: не бери новое, пока не закончил текущее.
Почему это сработало? Когда разработчика заставляют работать в многозадачном режиме, он теряет эффективность на переключении между задачами. Ограничение незавершённой работы убирает переключения — и время, которое «утекало» между задачами, возвращается в продуктивную работу.
За пять кварталов время выполнения упало со 155 дней до 14. Пропускная способность выросла втрое. Надёжность — на 90%. Команда стала лучшей среди всех инженерных коллективов Microsoft. И всё — при полном сохранении контрактных процессов.
💡 Иногда главный враг продуктивности — не плохой процесс, а слишком много работы в процессе. Прежде чем менять методологию, попробуйте просто ограничить количество параллельных задач.
❓ Сколько задач одновременно «в работе» у вашей команды прямо сейчас — и знаете ли вы это число точно?
📚 Источники: Дэвид Андерсон — «Канбан. Альтернативный путь в Agile»
