×

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

Image via Shutterstock.

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

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

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

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

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

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

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

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

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

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

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

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

Надежность

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

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

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


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

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

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

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

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

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

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

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

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

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

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

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


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

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

Все про українське ІТ в телеграмі — підписуйтеся на канал DOU

👍ПодобаєтьсяСподобалось0
До обраногоВ обраному1
LinkedIn

Схожі статті




50 коментарів

Підписатись на коментаріВідписатись від коментарів Коментарі можуть залишати тільки користувачі з підтвердженими акаунтами.
Если вопрос организации труда и профессиональных заболеваний в IT будет интересен, напишу об этом в другой раз (просьба оставлять комментарии).
+1

So far, найкращий спосіб «оценить себя как профессионала» — це сходити на співбесіду.

Не завжди працює в повному обсязі. Бо «дешево придбати, дорого продати» ....

Если вы будуте укладываться в сроки и установленный уровень качества любой ценой, то есть риск для последующих проектов искать/нанимать новую команду. Старая разбежится.

Вот здесь согласен. Кракосрочные задачи очевидны — сдать вовремя и по ТЗ. Среднесрочные — сохранить workflow ламинарным — уже не так очевидны. А о долгосрочных — вообще мало кто задумывается. Это — ниша для профессионала. ИМХО.

Ви й досі питаєте в гребців, скільки їм ще грести до берега? Ой-йой... Не пробували складати метрики й збирати статистику виконання задач? Ви ж менеджер, це ваш прямий обов’язок

Думаєте сертифікат одразу зробить красиво? Я б не чекав...

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

По поводу эффективности: можно хорошо работать, качественно — но сам видел ситуацию, когда на человека скидывают задачи все больше и больше (юзают по полной программе, сам когда-то такой был).Пословица «Больше всех в колхозе работала лошадь, но председателем она так и не стала» отражает суть этой проблемы.

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

Результативность — такие же траблы как и с выполнением в срок — очень сильно зависит от задачи.

Надежность — стоит помнить что это в реальности временное качество, на 40 процентов зависит от личных жизненых условий, на 40 от адекватности менеджмента (постановка нереальных задач), и 20 процентов уже личное расдолбайство.

Перспективность — это вообще странная характеристика, все люди имеют перспективу, не все ею пользуются

Эффективность и результативность может зависеть от проекта и коллег. Надежность может зависеть от качества менеджмента.

Я бы выделил так:

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

Спасибо за статью!

Большое спасибо за отзыв. Полезно.

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

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

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

Я старался рассматривать стандартные, прогнозируемые случаи. Спсибо за отзыв.

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

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

И тут задача тимлида/ПМа распределить задачи, что бы тот, кому нравится делать новое и брызгал идеями — занимался новой функциональностью, при этом в паре с более спокойным человеком, с которым он в хороших отношениях — они будут друг друга уравновешивать :)
А для тех, кому нравится спокойная работа — всегда тоже найдутся свои задачи по багфиксу и небольшим новым фичас :)

Никакое утверждение не абсолютно. Включая и это утверждение.

Коллеги, буду признателен за комментарии.

Якщо оцінювати в сукупності команду — які фактори оцінки?

Як для простого коментаря — стисло відповісти не вийде, перепрошую. Але в наступному, опишу детально у статті.

Напишите, пожалуйста, про организацию труда и проф.заболевания. Заранее спасибо.

Проф заболевания — насколько я понимаю у нас ключевое — спина. Кстати, кто как с эти справляется?

думаю еще испорченное зрение, головные боли.

шею, про шею не забудьте!

И про жопу, про жопу! xD геморой и все такое)

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

У нас в компании — массажный стол и профессиональный массажист. Правильная мебель, подобранная по росту. Режим.

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

Синдром зап"ястного канала!

Да, обязательно. Сейчас обобщаю материал. Думаю, в скором времени подать на ДОУ. Профильное медицинское образование у меня — сертифицированый врач по гигиене труда (профилактика проф.заболеваний), так что думаю — будет интересно.

Александр, а на других ресурсах есть Ваши статьи? Или порекомендуйте сторонние ресурсы по гигиене труда. Буду признательна.

Пока нет. Спасибо за интерес к теме. Рекомендую наблюдать за информацией, побликуемой Державною службою з охорони праці. Сложно порекомендовать какой-либо конкретный ресурс. Все-таки отрасль знаний довольно таки специфическая. Боюсь показаться занудой, но для понимания механизмов хотя бы базовое медицинское образование необходимо. И, да — профзаболевания в ITи их профилактика — отдельная большая тема. Занимаюсь этим вопросом довольно давно, планирую в ближайшее время рассказать о тех решениях, которые использует наша компания.

Ожоги на пятой точке — признак опытного ПМа :)

Или неопытного интернет-борцуна

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

Самое главное проф. заболевание(или расстройство) — гиподинамия. Если с ней не бороться, то к 50 годам можно получить целый букет необратимых изменений в организме.

Не нужно мне тыкать. И предсказывать мое здоровье и здоровье моих предков.

Підписатись на коментарі