Які якості потрібні senior - розробнику , або Як заробляти на 1000 доларів більше ? - SEO Blog - все про пошукову оптимізацію та веб розробку українською.

Які якості потрібні senior - розробнику , або Як заробляти на 1000 доларів більше ?

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

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

Не обійдеться і без згадки тих, хто якось мене надихав. =) Це Денис Циплаков з семінаром про те, які якості потрібні senior-розробнику, і Сергій Бережний зі своїми тренінгами. Семінар Дениса був дуже цікавим сам по собі, а для мене взагалі потрапив в яблучко - він проходив якраз коли я задумав написати цю статтю, і я несказанно зрадів можливості поіспользовать чужі думки в своїх цілях, ніж я зараз і займуся. По ходу того семінару я робив нотатки і зараз привожу їх тут. Ось думка Дениса (вірніше, те, як я його почув) на те, якими якостями повинен володіти сеньйор:

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

Я згоден з більшістю з цих пунктів, але хотів би зробити акцент на трохи інших речах.

Коли ти сказав, що ти крутий, і ніхто не сперечається, то ти крутий

Сеньйор «по Циплакова» вийшов дуже крутим, але мені здається, йому не вистачає однієї якості для більш швидкого просування - уміння заявити про свою крутизну. Ніхто про тебе так не подбає, як ти сам. Треба заявляти про свої вміння вголос і займатися «саморекламою».

Ти ж не Памела Андерсон, у якої всі сильні сторони відразу видно, тобі ще потрібно довести, що вони у тебе є.

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

Про всі свої бажання і проблемах треба говорити! Кеп вчить, що, поки ти не сказав про те, чого хочеш, ніхто не знає, що ти цього хочеш .

Проявляти ініціативу

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

Приймати рішення і нести за них відповідальність

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

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

Треба відстоювати свою точку зору.

Управляти очікуваннями

Що краще - зробити естімейт для ТАСК п'ять днів і вкластися в нього або зробити естімейт три дні, але виконати роботу за чотири? У переважній більшості випадків перший варіант набагато краще. Кожен естімейт формує очікування. Спочатку у PM, потім у замовника, потім у клієнтів замовника. Дуже неприємно на кожному рівні спілкування обгрунтовувати причини затримки, не кажучи вже про те, що затримка - це додаткові гроші, які викладає замовник (або ваша компанія, в залежності від типу договору). Нікому не подобається платити більше, ніж було заявлено спочатку. Крім того, коли ми вилазимо за рамки естімейта, то поспішаємо, на нас тисне час, пишемо неякісний код.

Не варто боятися збільшити естімейт, якщо є побоювання, що не встигнемо. Треба обов'язково з кимось радитися в разі сумнівів! Думка «я і так минулого разу збільшив естімейт, на цей раз зменшу» користі не принесе, врешті-решт, є хтось, хто повинен помітити постійно завищені естимейт з вашого боку і запитати, чому так відбувається. Якщо ніхто такого не каже, значить, це просто звичайний страх здатися поганим фахівцем («а раптом хтось скаже, що на цей таск з головою вистачить у два рази менше часу»).

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

Уміння розставляти пріоритети!

Це скілл розробника № 1. Не можна, ні в якому разі не можна дозволяти собі займатися «чимось цікавим», коли в тебе є завдання, за якими з тебе спитають і які хоча б трохи складніше, ніж вивести список всіх продуктів на сторінку. Ми ж усі знаємо, що завжди знайдеться щось, про що ми не подумали, коли уявляли собі рішення задачі, і що це обов'язково призведе до поспіху. Треба якими способами змушувати себе дотримуватися правило «Зараз я зроблю це, це найважливіше, а вже потім це, якщо вистачить часу» , хоча звичайно ж відразу хочеться зайнятися останнім, воно ж найцікавіше. Ми не все знаємо і не все можемо передбачити. Наприклад, хто б міг припустити, що за запитом «спітнілий мексиканець» в пошуку картинок Гугла буде купа фотографій Брюса Вілліса?

Дуже допомагає встановлення дедлайнів типу «На цей Ресерч час до 14:00, ні про що інше в цей час не парюся, але в 14:05 я вже повинен займатися чимось іншим».

Забивати на деякі речі!

Це я про те, що треба завжди пам'ятати, хто нам платить гроші, і про те, що є така штука, як business needs. Нам може не давати спокою питання з минулого ТАСК який «ну вааще не зрозумів чому не працював» і який довелося вирішити іншим способом, але все одно треба робити саме те, що потрібно замовнику в даний момент. Плюс далеко не завжди треба вникати в суть кожної заплутаної проблеми, якщо її можна вирішити простіше. Якщо щось пофіксити якимсь незрозумілим способом («ну це чиста магія ...»), то не завжди потрібно витрачати пів дня і весь мозок на те, щоб зрозуміти, чому так сталося. Щоб зрозуміти, чи варто це робити, треба подумати, чи носить проблема системний характер, чи повториться вона ще коли небудь і чи окупляться ті години, які зараз можна витратити на її глибоке вивчення. Якщо цього не знає навіть Чак Норріс, то треба просто взяти і забити на це.

Визнавати і виправляти помилки

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

Взяти і зробити

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

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

прискіпуватися до себе

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

Так як все-таки заробити купу грошей?

Можна з'їздити на море, гарненько засмагнути і спробувати отримати гроші в банку під ім'ям Уілла Сміта. Але це може не спрацювати. Є інший геніально простий спосіб. Треба попросити у себе в компанії стільки, скільки хочеться, і якщо не дадуть, то запитати, що треба робити, щоб дали. І потім це робити.

Що буде, якщо все попросять підвищення?

Комусь може здатися, що я закликаю всіх постійно просити підвищення і що це може бути дуже невигідно компаніям. Але я переконаний в протилежному: компаніям це вигідно. У нас, до нашого величезного щастя, галузь така, що найчастіше чесне ведення гри вигідно всім. Будь розробник не відмовиться від просування нагору. Тому якщо він просить підвищення - це чесно. Якщо він говорить про це, компанія вправі просити й одержувати більше від нього, просто так ніхто не стане платити більше грошей. Це теж чесно. В результаті це вигідно всім - розробник щасливий, а компанія отримує людину, яка готова бути дуже продуктивним, принаймні, якийсь час. Звичайно, існує межа зарплати, вище якого стрибнути дуже складно, і в такому випадку доведеться виходити в самостійне плавання. І, звичайно, ніколи не варто забувати про здоровий глузд.

Опубліковано: 31/08/12 @ 09:42
Розділ Різне

SEO Блог