Поради для сольного програміста, команда якого розшириться найближчим часом [закрито]

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

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

Зараз це лише я, кілька комп’ютерів і SVN-сервер. Я шукаю будь-які загальні рекомендації щодо створення команди з нуля.

Наведіть свій будинок у порядку та переконайтесь, що все налаштовано на спільні зусилля.

• Контроль версій - Ви згадали, що у вас вже є SVN-сервер, що чудово. Переконайтесь, що ви створили репо і організовували проекти стандартизовано.
• Автоматизовані побудови
• Програмне забезпечення для відстеження / помилок
• Тест на одиницю / інтеграцію
• Сервер безперервної інтеграції

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

найміть когось набагато компетентнішого за вас

... і маючи досвід роботи у великому проекті корпоративного програмного забезпечення.

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

Ви навчите їх вашій ринковій ніші.

Якщо ви не можете знайти таку людину, пропоную вам пройти тренінги, пов'язані з управлінням командою. Я пропоную вам сертифікат Scrum як стартовий.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Одне хороше джерело простих та основних навичок управління щодо того, що робити та як професійно, - http://www.manager-tools.com . Вони регулярно проводять подкасти з управлінських та кар’єрних порад, не кажучи вже про значний для вас каталог матеріалів.

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

1. Беріть участь у прийнятті рішень про прийняття на роботу і не бійтеся приймати вето на таких кандидатів. Вам потрібно буде тісно співпрацювати з командою, і вони представлятимуть ваших клієнтів та керівництво.
2. Створіть культуру чесності з членами своєї команди та чекайте від них чесності, особливо коли ситуації складні.
3. Навчіться делегувати, а потім зосередьтеся на рішеннях, а не обробляйте.

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