Код заради коду
«Найняли людини - добре пройшов співбесіду. Міддл. Сам мене знайшов через DOU », - розповідає Володимир Железняк, СТО невеликий продуктової компанії FundSeeder.
Через тиждень ознайомлення / роботи нового співробітника дали завдання - дописати пару рядків ( «відправити лист за дією користувача, см. Приклад, як ми це робимо ось тут»). В результаті виявилося, що він переписав багато старого коду, підтягнув пачку нових бібліотек.
На думку керівництва, для мідл на другому тижні роботи у великому проекті - така поведінка дещо несподівано. Коли з'ясували ситуацію, виявилося, що цей програміст вважав, що його найняли на рефакторинг проекту і впровадження кращих практик. Тоді йому пояснили, що про рефакторінгу можна буде поговорити через кілька місяців, коли він в достатній мірі зрозуміє проект, а поки від нього вимагається просто виконання завдань з розробки.
У підсумку це завдання з відправкою листа повертали на доопрацювання два рази - і кожен раз там в коді було щось дуже несподіване - нові директорії, новий API і т.д. Це все добре - але тоді, коли воно дійсно потрібно. Часто вирішити проблему можна набагато простіше і менш витратним способом - варто тільки вникнути і розібратися.
Співробітника звільнили на третьому тижні роботи - за нерозуміння зв'язку між написанням коду і бізнес-потребами проекту.
А нам все-одно
Про наступний випадок розповів Олексій Колупаєв, СТО стартапу MeinFernbus. Коли шукали програміста на одну з вакансій, їм підвернувся кандидат, який не знав потрібного фреймворка. Тоді йому запропонували написати щось на цьому фреймворку для себе, придумати і реалізувати простенький проект. У 90% випадків здобувачі після такого зникають, але цей розробник виконав завдання, показав нормальний результат, і його взяли.
Згодом, коли спала підвищена працездатність, властива тільки що найнятим працівникам, виявилося, що новий співробітник регулярно косячіт, але не бачить в цьому якогось екстраординарного явища, takes it easy. В принципі, людині властиво помилятися, ще й новому. Але неприємні моменти накопичувалися. Висновки не робилися.
Після цього компанія перервала його випробувальний термін.
Сам собі на умі
Цей пункт присвячений опрацьованим soft skills і навичкам особистої ефективності.
Олексій Коваль, СТО проекту UA2WEB, стикався з ситуацій, коли проект переріс одну людину, а ця людина виявляється нездатним перебудуватися з роботи поодинці на працю в команді. Виглядає це так: проект починає одна людина, проект росте, неминучим стає участь більшої кількості виконавців, менеджерів, а людина не може інтегруватися, не може або не бажає спілкуватися з іншими людьми, приймати колективні рішення. Можливо, він пише непоганий код, його робота як раз і привела до успіху проекту, але на етапі приєднання інших учасників його доводиться звільняти
Ще один кейс, про який варто згадати - коли фахівець не бажає вибудовувати відносини з менеджментом компанії. Такий випадок був в практиці Насті шафранового, hr-менеджера Timecode. Розробник, хороший технічний фахівець, повністю ігнорував робочі міттінгі, не попереджав, що у нього не виходить бути присутнім. Довелося з ним попрощатися після випробувального терміну.
Схожа ситуація - некоректна поведінка з замовником. За словами Сергія Немчінского, тімліда в IntroPro, якщо розмова про аутсорс, то за подібні промахи людей звільняють о 24 годині. Надто вже аутсорс залежить від замовника. Жорстоко, але варіантів немає - знайти нового розробника істотно простіше, ніж замовника