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

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

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

Обычный кодер, тестировщик, дизайнер или проектировщик в моменты, когда работа над проектом приостанавливается, будет бить баклуши или заниматься имитацией деятельности. Обычный программист, работающий с J2EE, NET или UNIX, не сможет ничего внести в проект на стадиях, не имеющих отношения к его непосредственной области деятельности. И дело тут не в том, каким из звеньев производственной цепочки ты себя ощущаешь (а высшим звеном тут всегда будет разработчик архитектуры). Дело в том, насколько полезным ты можешь стать.

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

Универсалы встречаются редко… и потому ценятся особо высоко.

Чтобы стать универсалом, нужно не связывать себя с определенной ролью или технологией. Определить свое место можно разными способами. Чтобы лучше представить себе возможности универсала, имеет смысл разбить перспективы карьеры в IT на набор независимых аспектов. Я выделил пять, но на самом деле их может быть бесконечное количество (все зависит от того, как лично вы делите темы):

♦ ступенька карьерной лестницы;

♦ платформа/ОС;

♦ код в сравнении с данными;

♦ системы в сравнении с приложениями;

♦ бизнес в сравнении с IT.

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

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

Еще одна искусственная (и непозволительная) граница разделяет платформы и операционные системы. Все более непрактично становится быть специалистом по UNIX, отказывающимся работать с Windows. То же самое касается .NET и J2EE и любых других инфраструктурных платформ. Долгосрочные перспективы на рабочем месте требуют независимости от платформы. У каждого из нас есть свои предпочтения, но их лучше оставить дома. Стань экспертом в одном и как следует разберись во всем остальном. Платформа — только инструмент. Специалиста по Windows можно нанять и на Филиппинах. А вот того, кто реально разбирается в разработке для Windows и UNIX и может помочь с интеграцией в обеих системах, лучше поискать в собственной стране. От подобных навыков не стоит отказываться, так как они относятся к умению работать в команде.