Масштабированный скрам. Как организовать гибкую разработку в крупной компании - страница 20

История Microsoft Word исекретного инструментария разработчика – классический пример динамики краткосрочного «улучшения» с последующим долгосрочным ухудшением. Речь идет о первом релизе Microsoft Word для Windows [Spolsky04]. Программа была выпущена на несколько лет позже, чем ожидалось. Почему? Потому что менеджеры старались соблюсти первоначально составленный график и давили на разработчиков, чтобы уложиться в срок.

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

Рис. 2.2. иллюстрирует базовую динамику того, что происходит, когда менеджеры давят на людей с целью соблюсти первоначальный график, и почему такое «быстрое решение» проблемы медленного прогресса в краткосрочной перспективе вроде бы ускорило работу команды, но в долгосрочной – замедлило ее еще больше. В этой модели мы частично опустили более глубокую динамику, которая будет рассмотрена дальше и представлена на рис. 2.3.

Итак, в качестве «быстрого решения» менеджеры Microsoft уговаривали, подкупали (обещанием премий) и угрожали разработчикам Word, чтобы те уложились в первоначальный график. В результате разработчики вполне предсказуемо прибегли к своему секретному инструментарию – множеству практик, известных как «грязные хаки», которые ведут к написанию грязного кода (без тестов, без инспекции, с игнорированием известных дефектов, копипастом, плохим дизайном и т. д.), чтобы быстрее выпускать новую функциональность. Как видите, у разработчиков тоже есть «быстрые решения» своих проблем.

Поначалу казалось, что эта тактика обладает магическим действием. Чем настойчивее менеджеры давили на разработчиков, тем активнее те использовали свой секретный инструментарий и тем быстрее выпускались «фичи», что усиливало убеждение менеджеров, будто давление на разработчиков помогает. Но у этого обманчивого ускорения имелся отложенный эффект в виде долгосрочного замедления разработки (мы рассмотрим это чуть дальше). Развитие негативной динамики первое время оставалось незамеченным, поскольку последствия использования секретного инструментария проявились не сразу и руководство считало, что менеджерам не нужно самим быть опытными разработчиками, чтобы разбираться в деталях исходного кода или же регулярно проверять его состояние.