Як оцінити себе як професіонала. Думка PM'а

via Shutterstock.

Привіт, DOU! Мене звати Олександр, я — ПМ. Так склалося, що за родом своєї діяльності я не тільки керую проектами, але і виступаю таким кар'єрним порадником для молодих (і не дуже) розробників. Зараз я працюю в компанії, яка працює з JavaScript у всіх інкарнаціях. Типовий JS-розробник для мене — це молодий чоловік, хлопець або дівчина, часто студент, з мінімальним комерційним досвідом. Природно, мова про тих, хто тільки-тільки «увійшов в айті».

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

У цій статті не буде «срібної кулі» — кожен повинен пройти свою дорогу самостійно. Але я спробую озвучити, можливо, найскладніше питання, що виникає в голові у кожного: «Скільки я стою як професіонал?» Читаючи форуми і просиджуючи в «болталках», я так і не знайшов на нього тлумачного відповіді. Це питання не задаються начальнику. Його складно обговорити з колегою (особливо, якщо ви ледве знайомі). Я відповім.

Фактори оцінки

Насправді, в цьому питанні багато субъектива, але є й цілком об'єктивні фактори, які прямо і побічно впливають на ваш заробіток.

Ефективність

Ви можете володіти приголомшливо ефективної навчанням, вкладати весь вільний час в самоосвіту, але це майже ніяк не вплине на вашу ефективність. Ефективність — це співвідношення сил і засобів, витрачених вами на вас для досягнення задовільного результату.

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

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

Це те, наскільки гарні ваші технічні навички. Якщо з 10 поставлених завдань ви в змозі самостійно вирішити 9, то ваша результативність — 0,9 (висока, але не ідеальна).

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

Ну куди без неї. Розробник, не вміє виразно донести свою думку колезі, суттєво програє як командний гравець. Особливо бажаний навичка — це впевнене володіння іноземною мовою (найчастіше англійською). «Не знаєш чим зайнятися? Є вільний час? Вчи мову» — ця порада завжди актуальне.

Надійність

Сказав — зробив. В цьому питанні компромісів бути не повинно. Можливість покластися на слово колеги — це дорогого коштує. Повірте, професіонал просто не має права бути необов'язковим базікою. Це якість здорово підвищить вашу значимість і цінність в очах як рядового члена команди, так і вашого керівника.

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

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

Отже, це основні, на мій погляд, якості будь-якого командного гравця. Так чи інакше, всі вони визначають професіоналізм і ринкову ціну. Звичайно, на підсумковий результат оцінки впливає набагато більше факторів. Я перерахував лише ті, які залежать від вас персонально.

Ще 3 пункти, якщо ви PM

Перераховані вище чинники — це лише те, що стосується розробника. Менеджер проектів — дещо інша історія. Але і тут є три пункти, які показують високий професіоналізм:

Вміння завжди тримати зв'язок з командою

На практиці це означає, що ви, як керівник, повинні створити в колективі атмосферу довіри і єдності. Часто буває, що особисті проблеми колеги вас не хвилюють аж до слова «зовсім». Наслідком цього може стати ситуація, коли абсолютно несподівано, ви залишитеся без розробника, але з діркою на проекті. І відбудеться це з цілком об'єктивних причин (хвороба, розлучення, теща приїхала, кіт захворів). Ось тільки ви про це дізнаєтеся вже за фактом.

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

Вміння давати можливість вчитися

Намагайтеся комбінувати ролі на проекті таким чином, щоб більш досвідчений розробник міг навчати новачка. Тут все просто і складно водночас. Просто, коли в такому форматі зацікавлені обидві сторони — учень і, назвемо його так, ментор.

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

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

Вміння формувати команди

Короткострокові цілі на проекті повинні бути однаковими у всіх членів команди. Завжди. Я вважаю, що це дуже важливо. Наведу приклад: Петя і Вася зацікавлені створити проект у строк, із задовільним рівнем якості (чітко за планом і специфікації). Саша бризкає ідеями і бажає розвинути продукт, додавши щось нове і, на його погляд, корисне. Такі люди не спрацюються ніколи в рамках одного проекту. По можливості, об'єднуйте людей в одну команду, використовуючи це правило.

Всі ці пункти можуть здатися очевидними. Але навіть найочевидніші речі необхідно повторювати. Ще і ще раз. Щоб не виникали питання про те, «чому мені не хочуть платити більше, адже я освоїв безліч фреймворків на дозвіллі (але завалюю поточний проект)?» або «чому мені роблять зауваження, проект адже зданий вчасно (з моторошною атмосферою в команді, половина якої задумалася про звільнення)?»

Твереза оцінка власної ефективності як професіонала допомагає адекватно визначити вартість своєї роботи на ринку праці. Та й підказати напрямок для зростання.

Опубліковано: 03/08/16 @ 07:00
Розділ Різне

SEO Блог