Як менеджери знають, чи людина хороший чи поганий програміст?

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

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

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

У чому секрет?

Зазвичай дивиться менеджер

• Чи програміст робить речі?
• Що думають про них їхні колеги? Код, який вони пишуть?
• Чи чітко програміст спілкується з менеджером?
• Чи любить програміст вчитися новим? Чи добре вони наставляють інших?
• Чи потрібно їм багато управлінської уваги, щоб завершити роботу?
• Здається, програміст отримує задоволення від своєї роботи?

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

* Однак, можливо, що в іншому контексті та оточенні вони будуть дуже щасливі та захоплені. Можливо, це просто той програміст, на який вони заперечували, і вони могли б дуже добре програмувати в іншому контексті. "Програміст" може означати дуже різні робочі місця в різних місцях. Але менеджер піклується здебільшого про свою роль «програміста» та наскільки добре підходить працівникові.

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

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

Ось деякі речі, на які я дивлюся, коли я в змозі видавати нагороди, але з величезним застереженням, що це абсолютно реакція кишечника, тому що нічого з цього не можна оцінити кількісно:

• Статус - чіткий, точний та своєчасний? Якщо обговорюється, чи є людина, що знаходиться на вершині статусу, чи трохи розмита в поточних питаннях? Чи є у людини правильне рішення підняти червоний прапор, коли щось загорілося?
• Вирішення проблем - важливі і запитання, і відповіді. Чи знає людина, коли звернутися за допомогою, або де вони крутять колеса на невизначений термін? А ще краще, коли інші мають проблеми, чи допомагає людина знайти рішення чи стати частиною проблеми? Навіть маючи хороший сенс відмовитися, коли проблема не у вашій області знань, варто кілька балів. Також є пункти для виходу за межі групи чи компанії та відвідування таких сайтів чи інших відповідей в Інтернеті.
• Увагу до процесу - зазвичай це досить очевидно - навіть у неанал-ретенційній компанії, якщо хтось перебирає систему, це спостерігається в хаосі, який вони залишають після себе. Якщо інші люди прибирають чужі риси, тому що вони не дотримуються вказівок чи архітектури, то у нас є проблема. Бонусні бали йдуть до тих , хто з'ясувати способи , щоб зробити консистенцію і якість легше .
• Коефіцієнт завершеності порівняно з помилками та складністю - будьте готові, але зробіть це правильно. У кожного є кілька помилок, але якщо хлопець швидко виконує справи і баггі, у нас є проблеми. Я, як правило, вважаю, що це не те, що ви можете оцінювати у щоденному сенсі - це має бути огляд на реліз, фазу чи фінансовий квартал.

І внесок інших людей. Часто я був у становищі, коли різні інженери відповідали за різні частини проекту. Іноді команда веде, а іноді просто власників певного результату виробництва (наприклад, "будівельник"). Люди ЛЮБИТЬ говорити про крайнощі - вчинки героїзму чи розчарування проблемних дітей. Зазвичай під час подальшої роботи над цими питаннями я багато дізнаюсь про НАРОДНІ партії.

Там також є чинник щодо управління людьми . Жоден інженер не такий, як будь-який інший. Тому вони не світяться в одному світлі. Один пише геніальний код помилки, але інший допомагає вирішити наскрізні проблеми, які порушують код кожного. Один чудовий особисто, інший - краще письмово. Один є невідповідним о 9:00 ранку, а один - до 15:00. Існує певна потреба відступити, з’ясувати, що найбільш вигідно команді і що може бути фактором особистої упередженості (наприклад, бажання вбити хлопця 4:00 ранку, просто тому, що я не можу працювати до 11: 00 ранку).

Це залежить від значної кількості залежно від технічної експертизи керівника.

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

Як правило, вони цього не роблять.

Ось чому програмування - це "Ринок лимонів". http://en.wikipedia.org/wiki/The_Market_for_Lemons

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

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

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

Як менеджери знають, чи людина хороший чи поганий програміст?

Почну з грубого узагальнення: більшість менеджерів не можуть сказати «хорошому» програмісту від «поганого» програміста.

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

як вони це роблять?

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

Менеджер, орієнтований на процеси, більше стосується "того, як все робити". Це означає, що вчасно приступити до роботи, одягнути правильний одяг і чи є у вас відповідний аркуш у звіті про TPS.

Людина працює добре, якщо її чимось доручать

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

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

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

• Чи вони швидко / регулярно / послідовно підкреслюють, де виникають проблеми з виконанням речей для задоволення визначених на даний момент вимог ... і ретельно дратують через це (це розробка програмного забезпечення зрештою, якщо ці проблеми недостатньо, це не справжній проект розвитку).
• Якщо вони в чомусь не впевнені, чи негайно це скажуть - тільки програміст, впевнений у власних силах, насправді це зробить (і вони знають, якщо вам це не подобається, вони можуть легко отримати іншу роботу). І навпаки, хтось, хто знає, що вони серйозно вийшли з глибини, схильний ховатися і шукати прикриття.
• Що говорять / мають на увазі інші програмісти в команді про інших програмістів? Якщо ви наполовину пристойний менеджер, ви перебуваєте в траншеях зі своєю командою програмування - особливо під час тестування інтеграції / виправлення помилок. Тож якщо ви не отримуєте подібного роду відгуки, хтось інший повинен виконувати вашу роботу.
• І моє улюблене: те, що я називаю програмістом «tomcat». Якщо через деякий час ви постійно помічаєте, що різні програмісти завжди меляться навколо одного і того ж столу програміста (якщо припустити, що вони виконують роботу та обговорюють якусь проблему, а не резидент-прохолодний та кумедний веб-продукт) ... то є причина, що інші програмісти тяжіють до столу цієї людини. Якщо вони вже не є лідером команди, то, ймовірно, їх слід зробити якнайшвидшим.

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

Менеджер може не знати, коли код, який ви пишете, блискучий або якщо його можна було б покращити величезним фактором, але те, що він знає, це: чи відповідали ви термін із кодом, який працював? Ви людина, якій можете довіряти, щоб вирішити проблеми, які створюють інші люди? Чи помітив клієнт або користувач проблему, яка перейшла до його менеджера? Чи трапилась велика катастрофа на вашому годиннику (Видалено таблицю користувачів, забув створити резервні копії, надіслав електронному листу клієнтам електронну пошту з даними про власні дані від іншого клієнта, який вони не повинні бачити тощо. Хтось похвалив йому вашу роботу (особливо в письмовій формі) )? Чи люди говорять добрі чи погані речі за вашою спиною?

1. У більшості випадків, коли ваш код не оцінюється вашим менеджером, він оцінюється вашими колегами (чи то формально, чи неофіційно, коли вони намагаються працювати з вашим кодом). Ваш начальник в деякій мірі використовуватиме думки ваших однолітків (знову-таки, формальних чи неофіційних).
2. Ваша загальна надійність і те, як швидко ви просуваєтесь і закінчуєте завдання, часто є дуже важливим фактором, окремим від вашої здатності кодування.
3. Зв'язок. Якщо ви багато робите і робите це добре, ваш менеджер повинен знати про це! (Звичайно, уникайте хвастощів). Навчіться "керувати своїм менеджером" і не просто бути пасивним. Допоможіть своєму начальникові знати, як ви працюєте.

Менеджери - самі кодери, і тому, простим спостереженням, можуть зрозуміти, чи добре це кодер чи ні.

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

Як менеджер, ось деякі речі, на які я дивився, оцінюючи своїх програмістів:

• Відгуки однолітків. Я попросив програмістів моєї команди та програмістів з інших команд надіслати мені відгуки про своїх людей.

• Повага поваги . Коли мої програмісти стикаються з проблемою, яку вони не можуть вирішити, вони говорять: «давайте запитаємо так-то і поради».

• Здійснює справи . Я кажу "Я хочу X", а наступного дня X робиться.

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

• Виправляє мене . Я кажу "Я хочу X", а програміст каже: "X неправильно, ми повинні робити Y, і ось чому".

Там не так багато хороших менеджерів (див. Пов’язане питання: як прогаммери знають, чи людина хороший чи поганий менеджер?). Керувати людьми добре - це важко і вимагає багато часу та наполегливої ​​праці. Як тільки я керував 5 людьми, у мене майже не було часу на програмування. Коли я керував 8+ людьми, я вже не міг ними керувати так добре, як вони заслужили.

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

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

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

Безвідповідальні просто пітимуть зі своїми «кишковими» реакціями, використовують якісь загальнонепідтримувані «метрики».

Це лайна стрілянина, але завжди можна кинути і сподіватися на щось краще в іншому місці.

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

Менеджер повинен дивитися на вимірювані. Які аспекти роботи є вимірюваними з точки зору виконання роботи, якості роботи. Вони можуть не знати, чи правильно ви виконуєте роботу, якщо ви не генеруєте безліч помилок чи не дозволяєте кінцевому користувачеві робити те, що потрібно робити.

Ваша робота коштує менеджеру грошей у витратах, тому вам потрібно мати фінансову вигоду, щоб продовжувати роботу.

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

Звичайно, могли. Вони здатні набити грубу силу за допомогою кодування, оскільки у вас 10 людей, які виконують роботу двох. Або клієнти задоволені, оскільки ви так дешево продаєте свою програму.

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

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

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

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

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

Іноді я думаю, що код завищений.

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

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