Программист-фанатик

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Совет 52 Лучше, чем вчера

Исправить ошибку легко (в общем случае). Что-то идет не так? Тебе об этом кто-то сообщил? Если ты можешь воспроизвести ошибку, то для исправления достаточно устранить вызывающие ее факторы и удостовериться, что проблем больше не возникнет. Если бы все трудности исчезали так просто!

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

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

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