Елена Правдина - Говорят, в IT много платят. Как построить успешную карьеру разработчика, оставаться востребованным и не выгорать [litres]

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

Воспитывайте самоорганизованность . Вы должны уметь встроить в свой ежедневный рацион час чтения новостей, изучения новой технологии, выбирать верные объекты освоения вне основной работы. На рабочем месте, в свою очередь, уметь спланировать свой день и неделю так, чтобы все требуемые фичи были реализованы в срок. Например, я начинаю свой рабочий день с анализа панели задач таск-трекера. Затем просматриваю почту и мессенджеры. Это позволяет не пропустить срочные вопросы, пришедшие поздно вечером, ночью или рано утром, и скорректировать план на день. Быстрое и важное сначала, крупное и плановое – «в рабочем порядке».Каждый срочный запрос предварительно переосмысливается и фильтруется – действительно ли здесь «горит» для пользователей и продукта, не имеет ли место наносной человеческий фактор? В точках взаимодействия с коллегами придерживаюсь принципа максимально оперативных «спрашивать и отвечать». Если вы точно знаете, что под конец разработки фичи вам понадобится дополнительное железо или дизайн новой иконки – запросите сразу. Распараллельтесь, узнайте о рисках раньше, чем возникнет неожиданная задержка от смены процесса выдачи квот или внезапная болезнь дизайнера. Со своей стороны, быстро выданная вами информация помогает не тормозить работу других команд и не навлечь справедливый негатив их ненароком сорванными сроками.

Современные методологии разработки, используемые в серьезных IT-компаниях, такие как Agile или Scrum, требуют адекватной оценки, планирования и обеспечения выполнения в оговоренный срок самим разработчиком. И если раньше менеджеры несли вину за срывы сроков, сейчас всё больше культура компаний ведет к тому, что ответственность за оценку времени и их соблюдение перекладывается на программиста. Если же вы, выбирая IT, грезите фрилансом и удаленной работой – самоорганизация понадобится вам вдвойне. Например, во фрилансе вы сами себе и менеджер, и руководство – необходимо верно рассчитать свою нагрузку и сдавать вовремя без лишних мотиваторов. А трудясь удаленно, без рабочей атмосферы офиса и темпа, задаваемого вашими коллегами бок о бок, приходится противостоять соблазнам и раздражителям, переключающим ваше внимание.

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

Привыкайте брать ответственность и проявлять инициативу . Тренируйтесь на других сферах – подумайте, как оптимальнее пройти от дома до работы или университета, как передернуть привычный шаблон поведения в стандартной ситуации, как сократить время сбора утром. Попробуйте мыслить нестандартно, организовать расстановку книг в домашней библиотеке или провести небольшой митап в известной вам области. Зачем? Затем, что это именно те важные софт-скилс, которые все чаще желает видеть в своих сотрудниках индустрия ПО. Методологии построения рабочего процесса, равно как и критерии оценки сотрудников, – быть может, сами того не осознавая, – исходят из наличия у топовых сотрудников способности предлагать улучшения, внедрять их в команде и… отвечать головой, если твой «улучшающий код» внезапно отправил сервера прилечь на пару часов на незаслуженный отдых. Подход управления разработкой Scrum поощряет участников команды, склонных брать на себя дополнительные роли, например, роль scrum-мастера. Подход с наличием начальника-надзирателя, увы, устарел. Сейчас до разработчика спускается задача, детали реализации которой, ожидается, предложит он сам.Более того, всё больше распространяется презентация результата заказчику напрямую самим разработчиком. А это значит, что вы должны уметь собрать информацию о проделанной работе со всей команды и красиво ее подать, общаться и выступать перед людьми, держаться уверенно, ориентироваться в моменте и немного быть политиком, отвечая на неудобные вопросы заказчика. Выступления на конференциях, написание статей, предложения по организации процессов учитываются наравне с ответственным и качественным программированием нужной фичи – прямой обязанностью разработчика. Проникнитесь, насколько нужные здесь качества далеки от стандартных базовых черт хорошего разработчика. По моему опыту, компании склонны нанимать «человека, умеющего говорить», чем подчас более глубокомысленного и вдумчивого специалиста с яркими чертами интроверта. Как по мне – уход не на ту тропинку с главной дороги, но реалии таковы, и вы должны быть к этому готовы.