Як додати нового розробника до команди

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

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

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

Це така ситуація:

• Ми наближаємось до порога закону Брукса - момент додавання нових розробників буде контрпродуктивним.
• Додаток відносно добре розроблений, але реалізація в деяких моментах хаотична (особливо старіший код).
• Є одиничні тести лише для більш пізнього коду. Коли цей проект розпочався, ми не регулярно проводили тести.
• Документація та коментарі неповні.
• Додаток є великим і складним.
• Клієнт записав майже кожну деталь про свій проект, дуже чітко та "дружньо до програмування".

Чи корисно зараз додати людину? Якщо так, то що ми можемо зробити, щоб допомогти новому розробнику інтегруватися в команду?

Редагувати:

Спонсор організовує інтернет-спортивну подію наступної весни. Він повинен розпочатися в конкретний день року. Ми не можемо це змінити.

Що нам потрібно зробити розробникам (я один із двох):

• Завершення існуючої програми (близько 25% роботи, яку потрібно виконати).

• Створення нового модуля, необхідного для організації цього заходу (близько 75% роботи, яку потрібно виконати). Цей новий модуль неможливо розробити без розуміння API основної програми.

Я не можу зробити точну оцінку часу, але ми в небезпечній ситуації.

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

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

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

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

Чи корисно зараз додати людину?

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

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

Не робіть цього.

І все-таки.

Традиційний вид

У своєму запитанні ви посилаєтесь на закон Брукса з Міфічного місяця людини .

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

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

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

Ларрі Пейдж та Сергій Брін провели два роки, обираючи початкову команду для Google. Ваш вибір для працівника номер три також повинен бути ретельним.

Спритний, новий вигляд тисячоліття

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

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

Техніка та соціальна інтеграція Agile для нового персоналу можуть використовувати:

• щоденні виписки
• парне програмування
• рефакторинг
• додавання пропущених одиничних тестів
• відгодівля худорлявої документації
• огляди коду

Жертв ягня

У « Організаційних моделях розвитку спритного програмного забезпечення» Джеймс Копліен обговорює групову динаміку та витрати на додавання нових членів команди. Його зразок «Жертв ягня» призначає все наставництво та навчання одній людині, захищаючи решту команди від перерви.

Це стратегія, яку ви можете розглянути.

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

В даний час наставництво проводиться однією людиною, в першу чергу під час ранкової суми та одразу після цього (8:30 ранку до близько 9:15 ранку, разом), а вдень між 12 та 3:30 (він працює 7 ранку - 3:30 вечора).

Мені подобається, що ви згадали Закон Брука. Чудово зроблено. Основна проблема при додаванні іншого розробника полягає в накладних витратах на швидкість і накладні витрати на синхронізацію з ними, де ви знаходитесь у проекті. Тому, якщо ви все-таки вирішите отримати третього розробника, я спробую це:

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

Якщо ви суворо дотримуєтеся закону Брука, ви, ймовірно, ніколи не зросте свою команду.

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

У вашому випадку? Я порекомендував би новій людині написати всі ці пропущені одиничні тести.

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

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

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

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

Ви кажете, що вам потрібно виконати 25% оригінальної роботи плюс нова робота. І вам потрібно зробити це за два місяці - коли вам знадобилося 18 місяців, щоб виконати 75% роботи. Якщо я дуже тупий, це вказує на мене, що ваші здібності до оцінювання приблизно в середньому для програміста, орієнтованого на код - тобто ви думаєте, що речі займуть вас приблизно від половини до третини, наскільки вони дійсно є.

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

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

Моя рекомендація:

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

Змінити Просто побачила дату тут. То як воно закінчилося? (Дякую Ars Technica за те, що вона поставила тримісячне запитання;)

Я хочу розглянути кілька способів:

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

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

Дата вже минула, але для тих, хто читає це пізніше.

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

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

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

Немає шансів повністю реалізувати цей проект у часові рамки. Якщо ви думаєте, що у вас залишилось 25% на проект, який досі потребував 18 місяців, то у вас залишилось щонайменше 6 місяців (з ~ 2 розробників). Додавання іншої людини це суттєво не змінить.

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

Я сподіваюся, що це спрацювало для вас.