196
Часть V . Сохраняя конкурентные преимущества
пертов-разработчиков в какой-то момент поняла, что существующие
методы ведения проектов могут привести как к успеху, так и к неуда-
че. В
промышленных условиях, где большинство проектов оканчива-
ется неудачей, они, как им казалось, нашли способ, ведущий к успеху.
Эта группа называла себя альянсом специалистов по быстрой раз-
работке ПО (Agile Alliance).
В индустрии в те времена считалось, что единственным способом
разработки проектов является спуск сверху вниз по цепочке серьезно
распланированных, жестко регламентированных процессов. Анали-
тики формировали список требований, передавали документацию
архитекторам, которые создавали архитектуру и передавали ее ди-
зайнерам, которые, в свою очередь, работали над детализированным
дизайном. Затем все это отдавалось разработчикам, перед которыми
стояла задача написать код дизайна на
каком-нибудь языке про-
граммирования. Наконец, спустя месяцы, а иногда и годы усилий код
собирался и отдавался группе тестировщиков, которые утверждали
его развертывание.
Иногда вариации на тему такого процесса давали неплохие резуль-
таты. Когда в начале проекта все в деталях знают, что им предстоит
делать, столь строгий подход к планированию позволяет получить
хорошо продуманное и качественное программное обеспечение.
Но в большинстве случаев исполнители не знали всех деталей реа-
лизации будущего проекта.
Чем больше и сложнее проект, тем менее
вероятно, что кто-то сможет вообразить все его особенности в мель-
чайших подробностях и написать спецификацию. Такой процесс на-
зывают
каскадным
, и в наши дни это слово почти всегда восприни-
мается как синоним плохого процесса.
В итоге члены альянса специалистов по быстрой разработке поняли,
что следование жестко регламентированному процессу хотя и по-
рождает хорошо протестированное и тщательно документирован-
ное программное обеспечение, но совсем не отвечает пожеланиям
пользователей. Их бунт выразился в создании гибких методик. Это
были
процессы разработки приложений, в которые легко вносились
изменения. На планирование и дизайн отводилось меньше времени.
Если программы гибкие, значит, их модификация
может
обходиться
дешево. Гибкие методики рассматривают изменения как неотъемле-
197
Совет 51 . Избегай каскадного планирования карьеры
мую часть процесса разработки и упрощаются, чтобы сделать этот
процесс по возможности дешевым и простым.
Сейчас все это звучит тривиально. Но
изначально гибкие процессы
стали источником конфликтов и дискуссий. В теории идея детального
планирования и жесткости выглядела без сомнений верной. Просто
на практике она работала далеко не всегда.
На ранних стадиях моего перехода к гибким подходам (особенно это
касается экстремального программирования) я начал рассматривать
все через призму гибкой разработки. Появлялись силы и мотивации,
выходящие за рамки написания программ. Как только я сталкивался
со сложной проблемой, то понимал, что постепенный подход к реше-
нию, допускающий изменения, в моем случае всегда является менее
сложным и более эффективным.
Но почему-то на осознание того факта, что самым сложным про-
ектом,
которым я когда-либо занимался, — самый напряженным
и важным — была моя карьера, потребовалось немало времени.
Я запланировал свою карьеру сверху вниз, как проект программы,
созданный в рамках каскадного процесса. В итоге со мной и с моей
карьерой начинали происходить те же вещи, которые возникают
в программных проектах.
Я успешно продвигался к должности
вице-президента корпорации
и директора по информационным технологиям. От зеленого програм-
миста я быстро шагнул к архитектору программного обеспечения,
руководителю и директору и мог легко представить, чем завершится
моя цепочка. Но при всех моих успехах я начал ощущать, что занима-
юсь не тем, что мне нравится. Более того, чем успешнее я становился,
тем меньше получал удовольствия от работы.
Я делал
для себя ровно то же самое, что строго регламентированные
процессы делают для заказчиков. Я
отлично
справлялся с созданием
для себя карьеры, которая была
мне не нужна
.
Сначала я не мог осознать, что подобная проблема решается просто.
Достаточно
поменять
свою карьеру. Это может означать что угодно.
Для меня это было возвращение к серьезным технологиям,
которые
изначально так восхищали меня в этой отрасли. Для моих знакомых
это был переход от системного администрирования к разработке про-
