• Перевод

До сих пор, мое продвижение по карьерной лестнице было быстрым. В 2008 году, я начал работать на полную ставку программистом в должности Junior Developer . Там был славный босс и классные коллеги, и я получил первые навыки использования Java и.NET, вместе с полезным опытом. После 2-х лет на той работе, я чувствовал, что настало время двигаться дальше…

Я связался с рекрутерами, и в итоге получил предложение: должность Systems Analyst , вместе с достойной заработной платой и с удовольствием от того, что слово Junior исчезнет из названия моей должности. Как ни посмотри, это была хорошая сделка, и я принял предложение.

Прошло несколько лет, и я вновь стал искать возможности для карьерного роста. На текущем месте работы оценили мои навыки в качестве Systems Analyst , и собирались предложить должность Developer . Однако, я поменял должность на .NET Developer в другой компании. Как и в предыдущих случаях, смена места работы принесла с собой увеличение зарплаты и бонусов. Там я провел 3 года и был повышен до .NET Development Team Lead - поднявшись еще выше, как программист. Я руководил небольшой командой из 4-5 человек и дела шли очень хорошо. В конце концов, достигнув в той компании потолка в развитии, я двинулся дальше, став .NET Architect с соответствующей заработной платой и бонусами.

Замечу кое-что: на протяжении всей моей карьеры, кадровые специалисты (как из сторонних агентств, так и штатные) занимались «обзваниванием» кандидатов и общались по поводу вакансий, соизмеримых с текущей должностью (становясь более общительными по мере моего продвижения по карьерной лестнице). Будучи .NET Development Team Lead , я получал предложения работы в качестве от Senior Developer до Team Lead и Architect . А работая в качестве .NET Architect , мне предлагались должности от Team Lead до Architect и Manager . До сих пор это казалось разумным.

Около 5 месяцев назад я устроился на работу в Stack Exchange - компанию, которая мне очень нравится. Дела идут великолепно, и со мной никогда еще так хорошо не обходились за всю мою карьеру разработчика. У меня первоклассные заработная плата и бонусы, мои рабочие льготы невероятны, а мой босс действительно компетентный специалист и достойный человек - как и все коллеги. На данный момент, это верхняя планка в моей карьере.

А что становится интересным, так это название моей новой должности. В Stack Exchange я Web Developer . Это полное название. Не Manager , или Team Lead , или Architect , а Web Developer . Потому что Stack Exchange не та компания, которую волнуют звания и титулы. Мы нанимаем толковых людей, таких что доводят свою работу до конца (их слова, не мои), и разработчики здесь контролируют проекты от начала до конца. Это означает, что мы иногда выступаем в качестве менеджеров, иногда в качестве руководителей групп, и зачастую в качестве архитекторов, когда обсуждаем наилучший способ разрешить конкретную проблему, либо дизайн конкретной системы.

До тех пор, пока я не получил эту работу, я не понимал, как ущербна нынешняя индустрия найма. Всего 6 месяцев назад я получал звонки и предложения пройти интервью на должность Team Lead , Architect и Manager (с соответствующей зарплатой). Как вы думаете, какие позиции предлагают мне сейчас? Junior Developer и Intermediate Developer . С пропорциональным понижением зарплаты и бонусов. Предлагать мне подобные позиции - пустая трата как моего времени, так и времени рекрутера.

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

Конечно, я не настолько эгоистичен, чтобы оскорбиться предложением работы и оплаты, которые не соответствуют моим нынешним навыкам. Однако, меня беспокоит тот факт, что я не могу убедить большинство рекрутеров предложить что-то еще . Я взял на себя смелость объяснить одному кадровику, что Web Developer в Stack Exchange - это эквивалент (как мне кажется) должности Team Lead или Architect во многих других компаниях. Ответ был таков: «Будь это правдой, ваша должность и называлась бы подобным образом». Я был ошеломлен.

Поскольку не существует каких-либо стандартов для названий должностей разработчиков, очевидно, что Developer в Компании А может быть кем угодно в Компании B, начиная от Junior Developer и заканчивая директором по информационным технологиям. Это непредсказуемо. Особенно учитывая тот факт, что некоторые компании преувеличивают звания своих сотрудников в качестве бесплатного поощрения (вместо того, чтобы платить им как следует, например).

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

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

Например, Джон Доу - некомпетентный разработчик, работающий в маленькой конторе за скромную плату, но обладающий там гордым званием Senior Developer . Рекрутер в конечном итоге предлагает этому разработчику вакансию не только с аналогичным названием, но и с соответствующим окладом . Джон меняет место работы и тем самым делает гигантский прыжок вперед. Что происходит дальше, многие видели неоднократно… Джон не справляется и через 3-6 месяцев покидает компанию. Он был обманут системой званий (англ. credentialism - прим. перев.). Любой из нас скажет, что Джон замахнулся на слишком большой кусок пирога.

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

Индустрия найма находится в плачевном положении. Большинство рекрутеров наймет кого угодно куда угодно чтобы получить свой гонорар и выполнить план. Возникает вопрос: как мы, с помощью Stack Overflow Careers, полностью разрушим систему и построим заново? Время покажет, и я в предвкушении результатов.

IT - одна из самых динамично развивающихся и перспективных сфер деятельности. Люди несведущие всех, кто занят в сфере информационных технологий, обычно называют «айтишниками». Однако на самом деле IT-профессии многочисленны и разнообразны, а представители одной и той же профессии могут занимать в IT-компании разные должности. Вот о том, какие существуют должности IT-специалистов, мы и поговорим. Работа над сложными IT-проектами никогда не совершается в одиночку: всегда есть команда специалистов, каждый из которых осуществляет свою часть работы. В этой команде существует определенная иерархия должностей, от рядовых разработчиков до руководителя проекта. Давайте попробуем в этой иерархии разобраться. Начинающие программисты обычно начинают с позиции разработчика - Developer или Software Engineer (SE). При этом даже внутри разработчиков существует своя иерархия. Вчерашним выпускникам с минимальным опытом работы приходится начинать с позиции Junior SE (то есть младший разработчик), но по мере накопления опыта можно дорасти до SE (Middle SE), а потом и до Senior SE (старшего разработчика) . В описаниях вакансий обычно также указывается язык программирования, которым должен владеть соискатель на определенную должность, например, Junior Java Developer, Senior C++ Developer и т. п. Благодаря этому уже по названию должности можно понять главные требования к соискателю: язык программирования и профессиональный опыт. При этом старший разработчик должен не только хорошо знать соответствующий язык, но и уметь принимать определенные решения, касающиеся выбора оптимальной в каждом конкретном случае версии языка, среды разработки, компилятора и т. п. Помимо разработчиков, над проектом работают и другие специалисты, в частности, тестировщики ПО и специалисты по обеспечению качества (Quality Assurance Engineers, QA-инженеры). Границы между этими двумя должностями смазаны, однако различия все-таки есть. Задача тестировщика - проверить готовый продукт на несоответствие требований и наличие ошибок и задокументировать найденные ошибки. А задача QA-инженера - не только непосредственно тестирование. Он планирует тестирование и анализирует его результаты, ищет способы улучшить процесс разработки ПО и предотвратить дефекты. Таким образом, тестирование - это лишь узкая специализация в рамках QA. В компаниях с небольшим штатом QA-инженер может выполнять функции тестировщика, а в крупных компаниях эти должности часто разграничены. У QA-инженеров, как и у разработчиков, есть своя иерархия: Junior QA, Middle QA, Senior QA и т. п. Отдельно стоит упомянуть такую должность, как QA Automation Engineer, эти специалисты занимаются автоматизацией тестирования. QA Automation Engineer - это своего рода «гибрид» QA-инженера, тестировщика и разработчика. Он должен обладать знаниями в области как ручного тестирования, так и разработки. Также в проекте могут быть задействованы такие специалисты, как технические писатели (Technical Writers, Technical Authors). Технические писатели занимаются написанием различной документации, как внутреннего назначения, так и предназначенной для конечных пользователей ПО (руководства пользователя, справочные системы и т. п.). Технический писатель должен, с одной стороны, хорошо владеть языком, с другой - разбираться в технической стороне вопроса. Разумеется, в каждой команде должны быть руководители, координирующие процесс. Существуют различные руководящие IT-должности, в их числе Project Manager, Software Architect, Team Lead, Tech Lead. Project Manager (менеджер проекта) осуществляет управление проектов в целом: расставляет приоритеты, планирует выполнение задач, отвечает за организацию работы в команде, оперативное решение проблем, коммуникацию с заказчиком и т. п. По сути, менеджер проекта - не техническая должность, но знание технических нюансов необходимо, без него нельзя эффективно организовать рабочий процесс. Многие PM в прошлом были тестировщиками или разработчиками, а потом решили уйти в управление. Но случается и по-другому: на должность Junior PM берут человека без технического образования, зато с опытом менеджмента, и обучают его техническим нюансам. Если организационная деятельность PM"а направлена на менеджмент, то Software Architect (архитектор ПО) координирует именно техническую сторону процесса. Он должен иметь целостное видение будущего продукта и на его основе уметь находить оптимальные решения как с точки зрения команды, так и с точки зрения заказчика. В архитекторы ПО обычно уходят старшие/ведущие инженеры, которые не хотят отдаляться от технических задач. Должности Team Lead (руководитель команды) и Tech Lead (технический руководитель) - это нечто среднее между проектным менеджером и архитектором. Оба выполняют и менеджерскую, и техническую роли, однако у тимлида акцент сделан на менеджмент (коммуникация и организационные вопросы), у техлида - на техническую часть. Обычно должности Team Lead и Tech Lead занимают ведущие разработчики, которым пришла пора двигаться дальше по карьерной лестнице, но они не могут определиться, что их привлекает больше - менеджмент или техническая сторона. После некоторого времени работы в должности Team/Tech Lead специалист становится либо менеджером проектов, либо архитектором ПО. Еще одно отличие тимлидов и техлидов от проектных менеджеров и архитекторов ПО состоит в том, что зачастую тимлиды/техлиды координируют не весь проект, а лишь какой-то его аспект. К примеру, QA Tech Lead руководит группой QA-инженеров и отвечает непосредственно за тестирование и обеспечение качества. Для того чтобы эффективно спланировать процесс разработки, руководителям команд необходимо знать, в чем конкретно нуждается заказчик. Сбором такой информации занимается бизнес-аналитик. Его задача - исследовать проблему заказчика и составить подробный список требований для разработчиков, то есть техническое задание. Бизнес-аналитик должен хорошо разбираться в предметной области, иметь аналитическое мышление и уметь находить общий язык как с заказчиком, так и с командой разработчиков. Вышеперечисленные должности касаются в первую очередь разработки ПО, но в IT-сфере существуют и другие направления деятельности. Так, в сфере разработки игр востребованы геймдизайнеры которые разрабатывают правила, стиль и дизайн компьютерных игр. Геймдизайнер имеет общее видение игры, которое он должен донести до программистов и художников. В крупнобюджетных проектах есть иерархия геймдизайнеров - ведущий дизайнер, дизайнеры миссий (квестов, уровней), дизайнеры контента и т. п. В разработке сайтов не обойтись без верстальщиков и дизайнеров. А для того чтобы решать проблемы, возникающие у пользователей конечного продукта, существуют специалисты по поддержке пользователей. Такая должность может называться Desktop Support Engineer, Technical Support Engineer. Также нельзя не вспомнить о специалистах, которые обеспечивают стабильную работу компьютерного парка. Это в первую очередь всем известные системные администраторы (System Administrators), без которых невозможно нормальное функционирование информационной инфраструктуры. В небольших компаниях системный администратор - «на все руки мастер», у него есть масса обязанностей - от решения проблем пользователей до работы с сетями. Но в крупных компаниях обычно работают несколько категорий системных администраторов в зависимости от выполняемых задач: администратор баз данных, администратор сети, системный инженер (системный архитектор), администратор безопасности сети и т. п. Можно упомянуть и ряд «околоайтишных» должностей, которые не связаны непосредственно с разработкой. Это, например, менеджеры по продажам (Sales Managers) и рекрутеры (HR). Человек, работающий на такой должности, может не иметь технического образования, но при этом должен разбираться в технической стороне вопроса настолько, насколько это необходимо для эффективного выполнения обязанностей. К примеру, HR может не уметь программировать самостоятельно, но он должен разбираться в базовых понятиях, чтобы суметь проанализировать резюме соискателей и понять, кого из них стоит приглашать на собеседование с техническими специалистами, а у кого шансов нет изначально. А менеджер по продажам не сможет эффективно продавать продукт, если не знаком с его особенностями и потребностями целевой аудитории. Высшая руководящая должность в IT-сфере - это технический директор (Chief Technical Officer, Chief Technology Officer, CTO). Он отвечает за оптимизацию производства в целом, координацию работы руководителей отдельных команд, внедрение и поддержку новых процессов внутри компании, разработку новых продуктов или сервисов. Как и все топ-менеджеры, CTO отвечает не за конкретный продукт, а за компанию в целом.

Сейчас я являюсь собственником и техническим директором компании ByndyuSoft , работаю преподавателем на кафедре Информатики в ЮУрГУ и веду тренинги под общим названием Результативное программирование . Приведу профессии в виде списка:

• Учредитель IT-компании, B&Z
• Ведущий разработчик, fuse8
• Руководитель отдела цветной полиграфии, типография Алмаз
• Таксист
• Системный администратор, РГ Марк
• Кассир, Пятерочка
• Официант, несколько ресторанов в Америке
• Грузчик, склад тракторных запчастей

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

№0 Коротко о главном

Главное, чему меня научили и что я понял на собственном опыте, можно сказать одной фразой из трех слов:

Всё решают отношения

Кто заботится о заведении новых связей и поддерживает старые, тот ставит себя в очень выгодные условия. И это относится не только к карьере в IT, а вообще ко всему, чем вы занимаетесь.

И наоборот, если раскидываться отношениями, ставить себя выше других, вести себя предвзято и придирчиво, ну и конечно, считать себя Д"Артаньяном, а всех остальных таковыми не считать; то надо понимать, что дурная слава быстро разносится, а круг друзей, коллег и родственников не бесконечен.

Я несколько раз выступал с этой темой публично и просил аудиторию проголосовать за эту точку зрения. По моим наблюдениям только каждый пятый поддерживает эту позицию. Остальные согласны частично или полностью не согласны. Что интересно, из 20% согласных реально в этом направлении двигаются единицы.

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

№1 Устраиваемся на работу

Откуда брать опыт?

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

Вот несколько способов набрать необходимый опыт:

1. Участие в OpenSource проектах
   Мои друзья часто участвуют в OpenSource проектах. Они создавали свои проекты или поддерживали уже существующие. В этих проектах была и обратная связь от пользователей, и работа в команде, и выпуск версий, и планирование.
2. Просмотр кода OpenSource проектов
   В своё время я следил за развитием NHibernate, NAnt и ещё нескольких проектов на CodePlex. Я просматривал коммиты, которые делали разработчики. Разбирался в уже написанном коде и модульных тестах на этот код. Пытался понять принципы, по которым разработчики строили свои приложения. Делал также как они в своих программах.
3. Курсовые и диплом
   Если вы учитесь, то у вас есть отличная возможность взять проект посложнее и поинтереснее. Целых пять лет вы можете развлекаться с разработкой ПО. Вы можете пробовать разные подходы, по несколько раз переписывать свои программы. Учеба в университете - это уникальное время, когда у вас есть всё для саморазвития.
4. Фриланс
   Думаю, что многие из программистов, сделали хотя бы один проект для своих друзей, родственников или через сайты типа free-lance.ru . Работа на фрилансе дает возможность экспериментировать с разными языками, делая небольшие проекты или дорабатывая уже существующие. За небольшие деньги, делая проекты с низкими рисками, вы можете набраться опыта в нужной вам области. Сейчас на фрилансе представлены все языки программирования и платформы, так что эту возможность нельзя игнорировать.
5. Стажировки в компаниях
   Сейчас многие компании с удовольствием берут начинающих разработчиков к себе на стажировки. Вы можете поработать в таких крупных компаниях, как Microsoft, Intel и др., просто попав к ним на стажировку. На стажировках, конечно, не дают участвовать в критичных и крупных проектах, но вы сможете пообщаться с опытными разработчиками, возможно, поработать с ними в паре. Опять же по результатам стажировки могут и на работу пригласить. В нашей компании тоже есть стажировки для студентов, правда, места ограничены.

Найдите того, кто будет объяснять

Оглядываясь назад, я сделал неожиданное для себя замечание. Возьмем изучение шаблонов проектирования. Я читал много книжек, смотрел видео по этим темам, читал статьи. Но, всё это изучение закончилось бы ничем, если бы не два фактора. Во-первых, мне надо было применять это в реальных проектах. Во-вторых, я нашел тех, с кем можно было посоветоваться, кто мог бы доходчиво объяснить. И так по каждой теме. Будь то TDD, Agile, DDD или что-то другое.

Ищите людей, которые смогут вам объяснить. Вот несколько советов по их поиску:

1. Пишите тем, кто пишет статьи и книги
   Люди, которые пишут публичные статьи или книги, будут очень рады получить обратную связь от вас. Напишите им вопрос или уточнение по статье и вам обязательно ответят.
2. Ходите на конференции
   Сейчас в сфере IT набирается всё больше и больше конференций и встреч. Только в Челябинске есть .NETconf , SUNETA , и другие. Если вы живете в Москве или Санкт-Петербурге, то плотность IT конференций в месяц там очень высокая. Придя на конференции, обязательно захватите с собой визиток и не стесняйтесь их давать вашим собеседникам. Возьмите с собой ноутбук и спросите про проблему в вашем коде у докладчика, который рассказывает по близкой теме.
3. Расспрашивайте преподавателей
   Опять же студенты находятся в самом выгодном положении. У студентов есть специальный человек, который будет отвечать на их вопросы - преподаватель. Сейчас я преподаю в университете и с удивлением вижу, что лишь малая часть студентов по максимуму пользуются этой привилегией. Почему-то большая часть студентов стесняются спрашивать и уточнять.

Если вы ещё не уверены, стоит ли искать наставника или нет, то приведу известную фразу: «Если спросите, то будете дураком 5 минут, а если не спросите, то всю жизнь».

Будьте открыты

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

Упор на положительном

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

• я ненавижу Windows/Linux/Mac…
• я ненавижу.NET/Java/C++…
• я ненавижу IE/FireFox/Chrome…

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

Зачем вам эта работа?

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

Не все понимают, что такое цель. Приведу несколько примеров целей:

1. Хочу много денег
2. Хотите путешествовать
3. Хочу, чтобы меня все любили
4. Через 3 года хочу участвовать в проекте с численностью разработчиков 100 человек и зарплатой в 100 тыс. рублей в месяц

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

Когда ко мне на собеседование пришел потенциальный менеджер проекта, то я понял, что откажу после диалога:

• С какой целью вы пришли управлять проектами?
• Я хочу, чтобы меня все любили.

Что значит «все любили»? Когда это «все любили» наступит? Когда можно будет сказать, что вот сейчас меня все любят и цель достигнута?

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

Как составить резюме?

Первое, что увидит работодатель, будет ваше резюме. Резюме должно быть исключительно по делу. Работодатель после просмотра резюме должен знать ответы на вопросы:

1. Чего вы хотите?
   Укажите вашу цель явно, можно прямо первым предложением. Дальше надо понять, что вы уже добились.
2. Опишите предыдущий опыт
   Проекты с вашим участием, ваш личный вклад в эти проекты, вашу ответственность и результат.

Это было про то, что должно быть в резюме. А теперь как составить резюме? Эти маленькие хитрости должны вам помочь:

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

Собеседование

Я не буду говорить о психологической составляющей собеседования, только несколько советов:

1. Подготовьте резюме
   Да, вы уже присылали резюме. И все-таки принесите еще одну копию с собой. После собеседования можете оставить ваше резюме, если есть визитка, то вместе с ней.
2. Расскажите о ваших целях
   Не стесняйтесь рассказать о том, чего вы хотите добиться. Скажите о целях явно без намеков и хождений вокруг да около.
3. Расскажите о ваших достижениях
   Всё это уже описано в вашем резюме, но блеск в глазах при рассказе о собственных достижениях не оставит равнодушным собеседующего.
4. Собеседуйте компанию
   Вы пришли на собеседование не только, чтобы себя показать. Вам нужно убедится, что вы захотите работать в этой компании, если вам предложат должность. Задавайте вопросы о компании, цели компании, планы. Вы узнаете много интересного, плюс эти вопросы выделят вас среди десятка других кандидатов, которые приходили за неделю.

№2 Делаем карьеру

Векторы роста

Работа разработчика предполагает не просто кодирование изо дня в день. У каждого, кто занимается разработкой ПО есть как минимум 10 направлений для развития:

• Software requirements
• Software design
• Software construction
• Software testing
• Software maintenance
• Software configuration management
• Software engineering management
• Software engineering process
• Software engineering tools and methods
• Software quality

Саморазвитие

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

1. Чтение книг
   Я отдаю предпочтение бумажным книгам, которые заказываю в интернет-магазинах. Читаю примерно 1-2 книги в месяц. Бывает больше, но это норма.
2. Чтение статей
   Мой список блогов и ЖЖ в Google Reader постоянно обновляется и дополняется. Чтение статей помогает оставаться в курсе событий и тенденций IT мира.
3. Написание статей
   Написание статей помогает упорядочить мысли в собственной голове. Если вы не хотите публичности, то всё равно стоит писать статьи в закрытом блоге или просто в текстовом редакторе.
4. Участие в конференциях
   Я люблю много общаться и заводить интересные знакомства. Конференции для меня отличный источник и того, и другого.
5. Узнавать у коллег, в чем вам ещё нужно подрасти
   Это самый эффективный и психологически сложный способ «вытащить себя за волосы вверх». Спросить у своих коллег, чего мне не хватает, как мне стать лучше. Обязательно поинтересуйтесь - узнаете много интересного.

Сначала разработчик, потом менеджер?

Выстраивая свою карьеру разработчики часто думают: сначала я поработаю разработчиком, потом стану менеджером проекта. Встречали таких? Я сам сначала работал разработчиком, а потом стал менеджером проекта. Т.е. такая схема работает, но есть подводные камни, которые не очевидны для начинающих этот путь:

1. Менеджер!= Разработчик
   Хороший разработчик не превратится в хорошего менеджера.
2. Разные книги, разные подходы
   Когда я решил для себя, что буду руководить IT-проектами, то полностью сменил библиотеку и RSS-ленты. Переход от разработчика длился около двух лет и даже сейчас я еще не могу сказать, что чувствую себя на 100% руководителем, потому что просто не хватает знания и опыта. Сейчас для меня наиболее интересны: психология, управление проектами, методологии, управление рисками, управление персоналом, управление требованиями и т.д.
3. Разные границы ответственности
   Если говорить про иерархию в организации, то менеджер проекта и разработчик стоят на одной ступени. Отличие только в границах ответственности.
4. Вы кем хотите стать?
   Я еще раз предлагаю вам явно определить свои цели. Кем вы себя видите через 1-2 года? В зависимости от этого надо подбирать книги, конференции и RSS-ленты.

Технологии или подходы и принципы?

Есть такая тенденция: начинающие разработчики много внимания уделяют технологиям (языки программирования, платформы). Через несколько лет работы над коммерческими проектами намного больше внимания начитают уделять подходам и принципам разработки. Становится понятно, что «серебряной пули» как не было так и не будет, что выбор языка программирования зависит прикладной задачи, как и платформа.

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

У меня есть сборник книг, которые я советую разработчикам, вставшим на путь изучения принципов «