Як оцінити себе як професіонала

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

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

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

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

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

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

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

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

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

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

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

надійність

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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