Барабан-буфер-канат в Microsoft

История начинается с молодого программиста компании Microsoft, Думитриу Драгоса, решившего превратить команду разработчиков XIT SE с наихудшими показателями в одну из восьми лучших IT групп в компании. Спустя девять месяцев, компания XIT стала самой эффективной в своем подразделении: продуктивность повысилась на 155%, время выполнения заказа сократилось с 5 месяцев до 2 недель, а количество выполненных в срок заказов увеличилось с нуля до почти 90%.

Компания XIT Sustained Engineering отвечала за обслуживание более 80 приложений для внутреннего использования сотрудников Microsoft по всему миру. В их обязанности входили разработка и тестирование по заявкам на небольшие изменения от клиентов (зачастую починка багов/ошибок). В первом квартале 2005 года производительность XIT была самой худшей за все время ее существования — они выполняли лишь одну пятую часть заявок (и отставание все росло). Нет необходимости говорить, что четыре группы внутренних клиентов, которым требовалась поддержка их приложений, были очень недовольны.
Компания XIT получала как минимум одну заявку на изменение в день, или 85 за квартал. Но средняя продуктивность команды из трех разработчиков была равна 6.5 заявок для каждого (т.е. всего около 20). В итоге они выполнили всего 17 заявок за предыдущий квартал:

При поступлении новой заявки на изменение сначала необходимо было приблизительно оценить время ее выполнения. Соглашение между компанией XIT и их внутренними клиентами предусматривало, что данная оценка должна быть произведена в течении 48 часов, что означало обработку в приоритетном порядке.

И здесь мы видим проблему – на оценку заявки разработчику и тестировщику требовалось по 4 часа каждому, т.е. оценка каждой заявки занимала их целый рабочий день. Одна заявка в день, один день на ее оценку – они стояли на месте. Только проведение оценки занимало до 40% общей мощности:

Ситуация становилась все хуже. Историческая справка показала, что команда полностью выполняла только около 50% заявок. Оставшиеся 50% были либо слишком большими, либо слишком дорогими, либо уже потеряли актуальность. Значит, 15-20% от общей мощности тратились напрасно на оценку работ, которые никто никогда не собирался выполнять:

Что еще хуже: даже для выполненных работ оценка практически никогда не использовалась, потому что с момента начала работы проходило так много времени, что оценку пришлось бы делать заново.

Это означает, что почти вся работа по оценке (или 40% от общей мощности) выполнялась напрасно:

Поскольку отставание было очень большим, приходилось постоянно менять приоритеты. Ежемесячные встречи по установке приоритетности становились все более и более напряженными, поскольку клиенты начинали бороться за то, чтобы их заявки были выполнены в первую очередь. Доверие было разрушено, клиенты перестали верить, что их заявки будет рассмотрены как первостепенные.

Знакомая ситуация?

Для решения проблемы Думитриу предложил три шага (в сотрудничестве с Дэвидом Андерсоном, который один из первых применил ТОС в разработке программного обеспечения). Сейчас это может показаться просто здравым смыслом, но концептуальный фундамент TOC укрепил доверие и стал основой для деликатных изменений в работе команды и общения с клиентами.

Первым шагом было введение в работу буфера, имеющего восемь слотов очереди для команды разработчиков, которая была узким местом в системе. Целью было остановить поток новых заявок, входящих в узкое место, где необходимость срочной оценки съедала ресурсы, сдвигала график и требовала постоянного изменения приоритетов и сроков.

Теперь руководители проектов брали на себя обязательства по срокам только после того, как будет проведена оценка, определен объем и выделен слот в очереди. Это позволило руководителям проектов обещать реальные сроки. Это ограничило входящий поток заявок до объема, который команда могла реально выполнять. Это сократило время, затрачиваемое на обработку заявки, потому что разработчики были сфокусированы на одной задаче, вместо переключения между приоритетами или уклонения от новых поступающих запросов. Ежемесячные обсуждения приоритетности стали гораздо менее напряженными.

Вторым шагом стал отказ от предварительной оценки. Вместо оценки была принята исходная посылка, что на каждое изменение потребуется в среднем 5 дней (плюс пара дополнительных правил для экстренных случаев). Это стало возможно только после того, как буфер позволил сократить и стабилизировать среднее время выполнения одной заявки.

Третьим шагом стало перераспределение ресурсов для оптимизации узкого места. Один человек был переведен из отдела тестирования в отдел разработки, что изменило соотношение сотрудников с 3:3 до 4:2.

Когда мощность ограничения была полностью использована и расширена за счет имеющихся ресурсов, пришло время для последнего шага: дальнейшего расширения узкого места (и системы в целом) путем найма большего количества разработчиков. Добавлять дополнительные мощности до того, как вы полностью используете имеющиеся, также бессмысленно, как увеличивать количество полос на автостраде перед мостом.

Общее количество выполненных заявок выросло с 17 до 56 за квартал. Общее отставание было сокращено с 80 заявок в очереди до 10, а затраты на один запрос сократилась с среднем с $7500 до $2900. Клиенты снова были счастливы.

Многие предполагают, чтобы использовать TOC в современной интеллектуальной работе, потребуются сложные продвинутые решения. Как показывает наш случай, можно успешно использовать простые подходы, как Барабан-буфер-канат, потому что ограничение продуктивности инженеров-программистов (и других сотрудников) связано не с тем, как они выполняют свою работу, а большей степени с менеджментом, планированием и приоритетами в управлении очередями работ.

Другими словами, инжиниринг может быть узким местом для всей организации, но менеджмент может быть узким местом для улучшения инжиниринга.

Автор: Tiago Forte
Источник

Книга в подарок

Опубликована наша книга «Прорыв. Единственный путь развития бизнеса». Это бизнес-роман о производственном предприятии, столкнувшимся с «потолком» в своем развитии. Для прорыва в развитии руководству и персоналу приходится преодолеть собственные, выстраданные на опыте, но устаревшие убеждения. Читателю предлагается пройти через этот прорыв вместе с героями. Вы увидите трудности такой трансформации, осознаете природу сопротивления изменениям и реальный путь к таким изменениям.
Подпишитесь на наш Telegram-канал и получите книгу в подарок!

Получить подарок

---

Лучшие статьи каждую среду в нашей рассылке. Присоединяйтесь к TOCpeople!

Подписаться

Нажимая на кнопку «Подписаться», я принимаю условия Политики конфиденциальности.