Как оценить себя как профессионала. Мнение PM’а

Image via Shutterstock.

Привет, DOU! Меня зовут Александр и я — ПМ. Так сложилось, что по роду своей деятельности я не только руковожу проектами, но и выступаю эдаким карьерным советчиком для молодых (и не очень) разработчиков. Сейчас я работаю в компании, которая работает с JavaScript во всех его инкарнациях. Типичный JS-разработчик для меня — это молодой человек, парень или девушка, часто студент, с минимальным коммерческим опытом. Естественно, речь о тех, кто только-только «вошел в айти».

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

В этой статье не будет «серебряной пули» — каждый должен пройти свою дорогу самостоятельно. Но я попробую озвучить, возможно, самый сложный вопрос, который возникает в голове у каждого: «Сколько я стою как профессионал?» Читая форумы и просиживая в «болталках», я так и не нашел на него толкового ответа. Этот вопрос не задашь начальнику. Его сложно обсудить с коллегой (особенно, если вы едва знакомы). Я отвечу.

Факторы оценки

На самом деле, в этом вопросе много субъектива, но есть и целиком объективные факторы, прямо и косвенно влияющие на ваш заработок.

Эффективность

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

Поясню. Вы в срок и качественно решаете задачу, самостоятельно находя решение. Вы генерируете идеи, которые помогают коллегам справиться с их работой. Вы не оттягиваете на себя дополнительные административные и технические ресурсы («А пусть техлид мне объяснит персонально, я опоздал на стендап», «Мне нужен второй SSD, вон у коллеги за соседним столом их четыре»). Ваше слово всегда имеет вес. Своим присутствием в команде вы поднимаете общую производительность. С вами легко, приятно, надежно сотрудничать. Вы — эффективны.

Результативность

Это то, насколько хороши ваши технические навыки. Если из 10 поставленных задач вы в состоянии самостоятельно решить 9, то ваша результативность — 0,9 (высока, но не идеальна).

Коммуникативность

Ну куда без неё. Разработчик, не умеющий внятно донести свою мысль коллеге, существенно проигрывает как командный игрок. Особо желаемый навык — это уверенное владение иностранным языком (чаще — английским). «Не знаешь чем заняться? Есть свободное время? Учи язык» — этот совет всегда актуален.

Надежность

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

Перспективность

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

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

Еще 3 пункта, если вы PM

Перечисленные выше факторы — это лишь то, что касается разработчика. Менеджер проектов — несколько иная история. Но и тут есть три пункта, которые показывают высокий профессионализм:

Умение всегда держать связь с командой

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

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

Умение давать возможность учиться

Старайтесь комбинировать роли на проекте таким образом, чтобы более опытный разработчик мог обучать новичка. Здесь все просто и сложно одновременно. Просто, когда в таком формате заинтересованы обе стороны — ученик и, назовем его так, ментор.

Но иногда к ментору нужно искать подход. Тут могут быть сложности. Как правило, лишняя работа никому не нужна. Более того, опытный разработчик без энтузиазма относится к перспективе кого-либо обучать, да ещё и в свое свободное время. Здесь нужно искать индивидуальный подход. К примеру, предложить реализацию задачи с использованием нового, перспективного инструмента. Так было у нас на проекте, где мы решили отойти от решения на PhoneGap/Ionic в пользу нового для команды React Native. Техлид проекта был заинтересован в получении коммерческого опыта использования перспективной технологии, джун-разработчик нуждался в помощи ментора. Цели совпали. Профит!

Бывает, что опытный коллега дает рекомендацию на трудоустройство в компанию своему товарищу или знакомому. Компания получает нового «бойца». Тот, кто рекомендовал и тот, кого рекомендовали, попадают на один проект. Отличные отношения «наставник-ученик» складываются.

Умение формировать команды

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

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

Трезвая оценка собственной эффективности как профессионала помогает адекватно определить стоимость своей работы на рынке труда. Да и подсказать направление для роста.