Спроси разработчика. Как стать лидером рынка с помощью создания собственного ПО - [80]

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

Если вы когда-либо задавались вопросом, что, черт побери, делают разработчики, почему все идет именно так и почему вы иногда получаете эти невероятно разочаровывающие ответы, то вам полезно побольше узнать о том, как работает методология аджайл. Не менее важно понимать, как ею злоупотребляют и доводят до крайностей, которые необязательно помогают делу. В некоторых компаниях аджайл может стать источником разочарования как для руководителей и менеджеров, так и для разработчиков. Создание компании, практикующей аджайл, важно, но для этого руководители должны понимать преимущества и недостатки методологии аджайл, прежде чем слепо принимать ее.

Почему именно аджайл?

В 1980-х и 1990-х гг. результаты разработки программных продуктов были нередко провальными. Даже крупные софтверные компании не справлялись со стремительно растущей сложностью проектов, меняющимися требованиями и большими затратами времени. Эти проблемы преследовали все организации – большие и малые, от стартапов до крупных компаний. Например, опытный программист и предприниматель Митч Капор, создавший в 1980-х гг. программы Lotus 1–2–3 и Lotus Notes, в 2002 г. профинансировал амбициозный проект по созданию системы для совместной работы под названием Project Chandler. Шесть лет спустя после неудачи с поставкой продукта, который лишь отдаленно соответствовал первоначальным целям, проект был закрыт. Даже выдающаяся софтверная компания той эпохи Microsoft с трудом справлялась с гигантскими проектами подобного рода. В 2001 г. Microsoft начала работу над самым амбициозным обновлением своей операционной системы Windows, инициировав проект под кодовым названием Longhorn. На создание этой системы ушло пять лет, на полпути была произведена ее серьезная переоценка, и она появилась в 2006 г. под названием Windows Vista. К моменту ее выхода на рынок разработчики отказались от многих функций и не смогли реализовать те инновации, которые Билл Гейтс и Стив Балмер задумали полдесятилетия назад. Как ни странно, но такие примеры были не исключением, а нормой.

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

Джефф Сазерленд – один из ученых-компьютерщиков, положивших начало методологии аджайл, и активный критик старого метода каскадной разработки. С 1960-х гг. он считался стандартом в софтверной индустрии, но Сазерленд называет его «колоссальной ошибкой», которая «обошлась в сотни миллиардов долларов из-за провальных проектов только в США». По словам Сазерленда, каскадная разработка заканчивается неудачей в 85 % случаев в проектах стоимостью более $5 млн. В 2004 г. исследование 250 крупных софтверных проектов показало, что 70 % из них страдали от серьезных задержек и перерасхода средств или были прекращены до получения результата.

Австралийская авиакомпания Qantas потратила $200 млн на разработку проекта под руководством IBM и расторгла рассчитанный на 10 лет контракт через четыре года. Но это было только первое ее фиаско. В 2008 г. Qantas отказалась от программного комплекса для управления авиационными запчастями Jetsmart, который обошелся в $40 млн и был настолько плох, что авиаинженеры прозвали его «Тупой самолет» (Dumbjet).

В своей книге «SCRUM: Революционный метод управления проектами»[8] Сазерленд рассказывает историю масштабного правительственного проекта, который был спасен методологиями скрам и аджайл. В 2000 г. ФБР инициировало рассчитанный на пять лет проект Virtual Case File по переводу устаревшей бумажной системы учета в цифровой формат. Исполнители контракта использовали устаревший каскадный метод, и в 2005 г., потратив $170 млн, ФБР пришлось отказаться от проекта и начать все сначала. Исполнение следующего проекта, получившего название Sentinel, с бюджетом $451 млн поручили компании Lockheed Martin. Lockheed также использовала каскадный подход и к 2010 г., за пять лет работы, потратила $405 млн, а сделала только половину. По оценкам компании, ей требовалось еще $350 млн, чтобы закончить работу за шесть‒восемь лет. Однако пара инновационных ИТ-руководителей из аппарата ФБР взяла проект на себя, сократила команду разработчиков с сотен человек до 50, разместила их в подвале штаб-квартиры ФБР и выполнила работу за 20 месяцев и $12 млн. Как? С помощью методологии аджайл.