2013-08-22
Я работал в IT-индустрии 8 лет, и за это время сменил четыре разных компании. Я пересекался с десятками программистов. Они все разные. Я наблюдал за тем, как одни строили успешную карьеру; других устраивала текущая должность и многолетняя работа в одной и той же компании; единицы увольнялись. На основе своих наблюдений я решил составить список советов, которые, на мой взгляд, помогут разработчикам добиться успеха на своём рабочем месте.
1) Не стесняйтесь задавать вопросы
Я заметил, что некоторые программисты стесняются попросить помощи в свои первые дни в компании, например, когда не совсем понимают рабочий процесс или работают над заданием, не имея возможности разобраться с его подоплёкой. А ведь дело-то простое – всего лишь нужно попросить помощи или разъяснений. Или вы предпочитаете потерять кучу времени, сражаясь с проблемой, решение которой на самом деле знает любой менеджер?
Другая проблема состоит в том, что людям неловко задавать вопросы даже тогда, когда их просят об этом. Например, в прошлом году главный разработчик и управляющий нашей компании посетили один из наших региональных офисов, чтобы лично познакомиться с разработчиками и сделать пару презентаций. Они попросили нас подготовить список тем и вопросов, которые нас интересовали. Мне было странно видеть, насколько мало людей внесло свои вопросы в список, несмотря на то, что вопросов было множество, от «почему мы используем NoSQL в этом модуле» до «какие функции приложения наибошлее популярны среди наших клиентов». Не бойтесь задавать вопросы!
2) Ищите свою нишу
Часто случается, что проекту компании явно не хватает ресурсов. Это означает, что у вас есть возможность выбрать себе направление деятельности или хотя бы дать менеджеру знать о своих предпочтениях в деятельности. Одним нравится присоединяться к свежим проектам и разработке новых функций, другие предпочтут команду, где работают сотрудники, с которыми они уже знакомы.
Мне кажется, лучше выбирать проект или функцию, с которой незнакомо большинство ваших коллег. Если передо мной стоял выбор, я выбирал задание из того модуля, в котором был только один специалист. Поначалу приходилось проводить много времени, знакомясь с рабочим процессом и кодом. Зато потом, когда я уже был хорошо знаком с модулем, оказывалось, что в нём необходимо реализовать ещё множество опций. Менеджеры делали заявки всё на новые и новые функции. Неудивительно, что эти задачи направлялись мне, поскольку я был одним из первых работников в этом модуле.
3) Посмотрите приложению «в лицо»
В настоящее время почти все корпоративные приложения имеют достаточно сложную структуру и состоят из многих модулей, в создании которых используются абсолютно разные технологии. Например, приложение, над которым я работаю сейчас, состоит из трех частей:
- Модуль, взаимодействующий с соц.сетями и собирающий данные;
- Модуль, обрабатывающий полученные данные;
- Модуль пользовательского интерфейса.
Каждый модуль разрабатывается и поддерживается разными командами разработчиков. Модули отличаются технологией, но их объединяет одно бизнес-решение. Если будет введена новая функция, она будет реализована во всех трёх модулях.
Тем не менее, совсем немногие люди понимают цельный бизнес-процесс. Каждый раз, когда обсуждается новый функционал, менеджеры приглашают к обсуждению людей, которые могут дать квалифицированную оценку требуемых изменений в каждом модуле. Поэтому, если вы имеете представление о цельной картине, у вас больше шансов принять участие в таком обсуждении.
Помимо этого, когда вы представляете себе общую картину, вы понимаете суть и сложность задач, решаемых в каждом модуле. Некоторые задачи и технологии, используемые в одном из модулей, могут стать интересны именно вам. Помните: значительно проще переключиться на новую технологию внутри компании, где вы уже выросли до старшего разработчика, чем найти новую работу.
4) Делайте то, что нужно, а не то, что хочется
Некоторые очень талантливые программисты имеют серьезный недостаток: у них очень узкая сфера интересов, и как только их просят сделать что-то другое, их производительность и качество работы резко снижается, потому что они не могут сконцентрироваться на том, что им не нравится. Например, человек обожает экспериментировать со Scala, но ему приходится работать с Hibernate и SQL; либо же ему нравится совместная работа, а он работает на фронтенд.
Если вам не повезло, и вы один из таких программистов, которому приходится работать с нелюбимыми технологиями, – смените работу. Если вы просто временно помогаете другим разработчикам в сферах, которые вам не нравятся – продолжайте показывать профессионализм. Просто напомните менеджерам о своих предпочтениях, чтобы они не слишком часто просили вас работать над тем, что вызывает у вас отвращение.
То же относится к задачам с разной приоритетностью. Звучит как очевидная истина, но постарайтесь вспоминать её почаще: лучше взяться за задачу с высоким приоритетом, чем за более привлекательную для вас задачу с низким приоритетом. Будьте профессионалом!
5) Делитесь знаниями и помогайте коллегам
Вы когда-нибудь встречались с разработчиками, которые гораздо продуктивней работают в одиночестве? Это может быть признаком плохих коммуникативных навыков. Иногда бывают и более тяжёлые случаи – хотите верьте, хотите нет, – но есть разработчики, которые не хотят делиться опытом. Эгоистично, да? Такие люди либо хотят стать незаменимыми работниками, либо желают, чтобы жизнь коллег стала такой же тяжёлой, как и их собственная. Неудивительно, что такое поведение быстро становится заметным, и не сулит такому «волку-одиночке» ничего хорошего.
Кроме того, если вы работаете в региональном офисе, помните: если один ваш коллега не справляется с работой, страдает репутация всего офиса. Поэтому, если можете помочь коллеге – просто помогите, это выгодно всем.
6) Старайтесь давать реалистичные прогнозы
Слишком оптимистичные прогнозы – это популярная проблема многих программистов.
Очень часто мы забываем учитывать время, которое проводим за:
- Решением непредвиденных проблем;
- Тестированием функциональности в среде разработки;
- Написанием функциональных и интеграционных тестов;
- Решением других приоритетных задач, падающих в течение дня.
Порой нам просто неловко озвучить правдоподобные сроки, потому что боимся испугать ими менеджера. В таком случае я обычно разделяю задачу на несколько подзадач, чтобы общий срок не выглядел настолько отдалённым.
Слишком оптимистичные прогнозы в большинстве случаев приводят к печальным результатам: вы передаёте задачу тестировщикам с кучей ошибок, оправдывая себя: «Всё равно отдел тестирования возвращает первую версию со списком комментариев, так что у меня ещё будет шанс исправить все эти баги»… А всего лишь стоило указать менеджеру реалистичные сроки выполнения.
7) Тесты, тесты, тесты!
Из-за своих неправильных оценок сроков исполнения одни программисты передают проект отделу тестирования с большим количеством ошибок, а другие закрывают свои задачи до крайнего срока, хотя их никто не торопит. Они хотят продемонстрировать свою высокую производительность, что, несомненно, похвально, но, к сожалению, редко сулит что-то хорошее. Помните, что лучше протестировать код более тщательно, но один раз, чем возвращаться к нему впоследствии многократно.
Сейчас очень популярна методология непрерывной интеграции, которая подразумевает выпуск кода несколько раз в неделю. Если такой подход используется в вашей компании, и вы передаёте в обработку код, полный ошибок, в лучшем случае отдел тестирования найдёт ваши ошибки, вернёт его вам и начнёт вас поторапливать, а в худшем – в производство пойдёт код с ошибками.
Нужно подчеркнуть важность функциональных и интеграционных тестов. Именно они – первый индикатор отката. К сожалению, некоторые пишут тесты только с одной целью – проверить покрытие кода. В результате получаются тесты без оператора контроля ошибок вовсе. Такой код нужно отслеживать и отсекать в процессе просмотра, что тоже является хорошим способом для улучшения качества кода.
8) Все совершают ошибки
Вам нравится работать с людьми, которые предпочитают искать не решение, а виноватого? Мне – нет. К сожалению, иногда мы сами ведём себя абсолютно так же, не осознавая этого. Как этого избежать?
- Если вы работаете вместе с коллегой над функциональностью, и он немного задерживает процесс, вместо того чтобы обвинять его перед менеджером, помогите ему. Это и ваша проблема тоже, ведь вы оба несёте ответственность за выполнение задачи вовремя.
- Если вы исправляете ошибку и обнаруживаете, что, к примеру, её причиной стало изменение, внесенное Петей, это не означает, что нужно об этом говорить в корпоративном Skype-чате. Все мы порой совершаем ошибки, и с вами это тоже может случится. Даже если вам встретится очень страшненькая часть кода, нет никаких причин объявлять автора этой части во всеуслышание.
- Если у вас сложилось плохое мнение об одном из ваших коллег, это не означает, что вам нужно делиться им с другими сотрудниками и особенно с менеджерами. По крайней мере, пока вас не спросят. Будьте уверены – ваш менеджер и без вас знает сильные и слабые стороны каждого разработчика в вашей команде.
Если же, наоборот, вы заметили, что ваш коллега проделал огромную работу, сообщите об этом своим коллегам и менеджеру. Например, пару недель назад одному моему сотруднику пришлось приехать в офис в 7 утра, чтобы запустить один из модулей нашего приложения со своего ноутбука. Конечно, он заслужил хотя бы слова благодарности в корпоративном Skype-канале.
9) Продвигайте свою компанию в соц.сетях
Каждый программист использует соц.сети. Ну ладно, почти каждый. Да, я знаком с двумя настоящими талантами, игнорирующими любые социальные сети. Я могу понять, почему они не используют Facebook, поскольку этот ресурс создан для личностного общения, но почему бы не воспользоваться профессиональными сервисами вроде Linkedin? Мимо вас пройдет множество новых карьерных возможностей, если вас нет в соцсетях.
Присмотритесь к своей компании: наверняка в ней организуются семинары, она спонсирует конференции, участвует в событиях, ведёт блог и т.д. Почему бы не рассказать об этом и в своём профиле? Конечно, это не значит, что вам нужно репостить все новости, публикуемые вашей компании – только те, которые по душе лично вам. Также существует множество сайтов, где разработчики пишут обзоры компаний, в которых работают. Почему бы не написать и о своей?
И ещё. Знали ли вы, что один из самых простых способов поговорить с руководителем или техническим директором сегодня – это поговорить с ним в Twitter? 🙂
10) Хозяйке на заметку
Несколько советов, которые помогут вам заслужить хорошую репутацию среди руководителей и коллег:
- Подстройтесь под часовой пояс работодателя. Многие работают удалённо, и зачастую работника с работодателем разделяет несколько часов. В таких случаях стоит выделить один час вечернего времени для обсуждения текущих вопросов со своими коллегами с другого континента.
- Помогайте компании на выходных и в праздники. Порой возникают ситуации, когда нужно помочь компании тогда, когда вы этого не обязаны делать. В прошлом году я согласился поработать в новогоднюю ночь. Нужно было всего лишь следить за системой мониторинга ошибок. В ту ночь ничего не произошло, работы не было совсем, зато компания была мне очень благодарна.
- Участвуйте в собеседованиях, проводимых компанией. Если у вас есть возможность быть интервьюером на собеседовании, используйте её. Это неоценимый опыт. Во-первых, вы развиваете свои навыки общения. Если интервьюеров несколько, всегда интересно слушать вопросы, которые задают коллеги. И наконец, ваше мнение о соискателе тоже будет учитываться, а это очень важно, ведь соискатель – ваш потенциальный коллега.
Это были советы от киевского разработчика, живущего в Монреале, Юрия Лопотуна.
