Чед Фаулер - Программист-фанатик Страница 43

Ничто не заставляло думать, что Novell проигрывает Microsoft. Компания Microsoft не выпустила волшебную реализацию Active Directory, которая заставила бы нас завопить: «Вот это да! К черту NetWare!» Но передовые технологии от NetWare постепенно стали устаревать. Под большинством NetWare-администраторов вода закипела еще до того, как они поняли, что котел нагревается.

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

1. Найди ловушку для обезьян. Назови свои жесткие критерии. Какие ценности, о которых ты даже не задумываешься, управляют твоими ежедневными действиями?

Нарисуй таблицу с двумя столбцами: «карьера» и «технология». В каждом столбце перечисли ценности, которые ты считаешь непоколебимо верными. К примеру, в столбце «карьера» укажи характеристики, которые всегда считал своими сильными сторонами. Перечисли и то, что считаешь своими слабостями. А как насчет карьерных устремлений? («Я хочу стать генеральным директором!») Укажи правильные пути достижения цели.

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

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

Это список твоих уязвимостей.

2. Знай своего врага. Выбери технологию, которую ты больше всего ненавидишь, и сделай на ее основе один проект. Разработчики имеют склонность разбиваться на конкурирующие лагери. Приверженцы .NET ненавидят фанатов J2EE, а те, в свою очередь, платят им той же монетой. Любители операционной системы UNIX ненавидят Windows, а любители Windows терпеть не могут UNIX.

Придумай простой проект и попробуй создать прекрасное приложение в рамках ненавидимой тобой технологии. Если ты пишешь на языке Java, покажи этим фанатам .NET, как настоящий разработчик использует их платформу! В лучшем случае ты поймешь, что столь ненавидимая тобой технология на самом деле не так уж плоха и на ее основе можно создавать приличный код. Кроме того, у тебя появится (разумеется, пока не развитый) новый навык, из которого в будущем ты, возможно, сумеешь извлечь выгоду. В худшем случае ты выполнишь практическое упражнение, получив дополнительную базу для своих аргументов.

Совет 51

Избегай каскадного планирования карьеры

В начале этого тысячелетия один небольшой протест сильно изменил всю индустрию разработки программного обеспечения. Группа экспертов-разработчиков в какой-то момент поняла, что существующие методы ведения проектов могут привести как к успеху, так и к неудаче. В промышленных условиях, где большинство проектов оканчивается неудачей, они, как им казалось, нашли способ, ведущий к успеху. Эта группа называла себя альянсом специалистов по быстрой разработке ПО (Agile Alliance).

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

Иногда вариации на тему такого процесса давали неплохие результаты. Когда в начале проекта все в деталях знают, что им предстоит делать, столь строгий подход к планированию позволяет получить хорошо продуманное и качественное программное обеспечение. Но в большинстве случаев исполнители не знали всех деталей реализации будущего проекта. Чем больше и сложнее проект, тем менее вероятно, что кто-то сможет вообразить все его особенности в мельчайших подробностях и написать спецификацию. Такой процесс называют каскадным, и в наши дни это слово почти всегда воспринимается как синоним плохого процесса.

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

Сейчас все это звучит тривиально. Но изначально гибкие процессы стали источником конфликтов и дискуссий. В теории идея детального планирования и жесткости выглядела без сомнений верной. Просто на практике она работала далеко не всегда.

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

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

Я успешно продвигался к должности вице-президента корпорации и директора по информационным технологиям. От зеленого программиста я быстро шагнул к архитектору программного обеспечения, руководителю и директору и мог легко представить, чем завершится моя цепочка. Но при всех моих успехах я начал ощущать, что занимаюсь не тем, что мне нравится. Более того, чем успешнее я становился, тем меньше получал удовольствия от работы.

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

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

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

Карьерные изменения — это не строительство небоскреба, они не потребуют выкинуть на помойку весь наработанный ранее опыт. В настоящий момент я целыми днями пишу программы на Ruby, но мой опыт руководителя, занимавшегося переводом операций в офшоры, остается актуальным и помогает в моих трудах. Работодатели и клиенты это понимают и используют данное преимущество.

Важно понимать, что подобные изменения не только возможны, но и необходимы. Как разработчик ты никогда не позволишь вовлечь себя в ненужный заказчику проект. Гибкие методики просто не дадут тебе этого сделать. О твоей карьере можно сказать то же самое. Ставь большие цели, но по пути постоянно вноси коррективы. Учись на собственном опыте и меняй цели при необходимости. В конечном счете нам всем нужен довольный заказчик (а в деле планирования карьеры ты сам являешься собственным заказчиком), а не выполнение требований.