Рис. 4.1. Команда в Хайдарабаде (Индия). Драгош – четвертый слева

Драгош сам вызвался возглавить команду, которая имела худшую репутацию в Microsoft с точки зрения клиентского обслуживания. В круг его обязанностей как агента изменений входило решение проблем длительного времени выполнения задач и плохо сформулированных, из-за сложившейся в компании конъюнктуры, ожиданий заказчиков. Некоторые из его предшественников на этой должности продолжали работать в компании с другими проектами того же подразделения. Они опасались, что если ему удастся улучшить производительность команды, то они будут выглядеть неудачниками.

Программисты и тестировщики этой организации следовали методологии PSP/TSP (Personal Software Process / Team Software Process). Такие требования компании Microsoft были записаны в контракте. Джон Де Ваан в то время – непосредственный подчиненный Билла Гейтса и большой поклонник Уоттса Хамфри из Института программной инженерии. Как глава Engineering Excellence в Microsoft, он мог требовать от IT-отдела и его поставщиков соблюдения определенных процедур. Поэтому изменение метода жизненного цикла разработки ПО было невозможным.

Драгош понял, что основная причина их проблем не в методе PSP/TSP и не в рейтинге зрелости организации. Более того, команда производила почти все, что от нее требовалось, с высоким качеством. Однако время выполнения запросов на изменения доходило до пяти месяцев и вместе с объемом бэклога продолжало бесконтрольно увеличиваться. Создавалось ощущение плохо организованной и почти неуправляемой команды. Высшее руководство не спешило выделять дополнительные средства на решение этой проблемы. Итак, сдерживающие факторы для изменений были связаны с политикой, финансами и правилами компании. Он обратился ко мне за помощью.

Я попросил Драгоша сделать изображение рабочего процесса. Он набросал схему, в которой описывался жизненный цикл для запроса изменений, после чего мы обсудили проблему. Рис. 4.2 – это факсимиле того, что он сделал. Фигурка PM (менеджера программ) изображает Драгоша.

Рис. 4.2. Изначальный рабочий процесс технического обеспечения в XIT с указанием времени выполнения Initial

Поступление запросов было бесконтрольным. Четыре менеджера продукта представляли и контролировали бюджеты для ряда клиентов, которые владели приложениями, обслуживаемыми XIT. Они добавляли новые запросы и дефекты, выявленные в процессе промышленной эксплуатации.

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

Когда поступал запрос, Драгош отправлял его на оценку в Индию. Согласно регламенту, оценку нужно было произвести и представить владельцам бизнеса в течение 48 часов. Так было легче вычислить ROI (прибыли на инвестицию) и принять решения по запросу. Раз в месяц Драгош встречался с менеджерами продукта и другими заинтересованными лицами: проводилась новая расстановка приоритетов в бэклоге и составлялся план проекта по запросам.

В то время в месяц обрабатывалось около семи запросов. В бэклоге было более 80 записей, и его объем продолжал увеличиваться. Таким образом, ежемесячно подвергались переоценке более 70 запросов, а обработка запроса занимала в среднем четыре месяца. В этом и крылась основная причина неудовлетворительной работы. Сами запросы были небольшими, но постоянное изменение приоритетов означало стабильную неудовлетворенность клиентов.