Как добавить нового разработчика в команду

24

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

Теперь этот клиент получил важное спонсорство, и они организуют мероприятия, связанные с этим проектом. Так что теперь у нас есть срок в 2 месяца, и мы не можем его пропустить.

Мы думаем о добавлении нового разработчика в команду, и мне интересно, что мы можем сделать, чтобы помочь его интеграции.

Это ситуация:

  • Мы приближаемся к порогу закона Брукса - момент, когда добавление новых разработчиков будет контрпродуктивным.
  • Приложение относительно хорошо разработано, но реализация в некоторых моментах хаотична (особенно старый код).
  • Есть модульные тесты только для более свежего кода. Когда начался этот проект, мы не проводили регулярные тесты.
  • Документация и комментарии являются неполными.
  • Приложение является как большим, так и сложным.
  • Клиент записал почти каждую деталь своего проекта в очень понятной и «дружественной к программисту» форме.

Это хорошая идея, чтобы добавить человека сейчас? Если так, что мы можем сделать, чтобы помочь новому разработчику интегрироваться в команду?

РЕДАКТИРОВАТЬ:

Спонсор организует спортивное мероприятие в Интернете на весну следующего года. Это должно начаться в определенный день года. Мы не можем это изменить.

Что мы, разработчики (я один из двух), должны сделать так:

  • Завершение существующего приложения (около 25% работы предстоит сделать).

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

Я не могу сделать точную оценку времени, но мы находимся в рискованной ситуации.

lortabac
источник
11
Вы не на пороге закона Брукса, который был принят более года назад.
Рифал
3
Вы не написали ни слова о том, какую цель вы ставите на этот срок. Добавить некоторые функции, специфичные для этого спонсора? Сделать презентацию продукта для событий? Создать инсталляционный пакет? Исправить некоторые из наиболее важных проблем? Какие проблемы у вас есть, которые вы не можете решить с вашей нынешней командой?
Док Браун
Сколько времени, по мнению двух разработчиков, им потребуется самостоятельно? 3 месяца (при расчете 2 разработчика * 3 месяца равняется 3 разработчикам * 2 месяца)?
шарфридж
@DocBrown Я добавил больше деталей к вопросу. Надеюсь, теперь стало понятнее.
Лортабак
«Документация и комментарии неполные» ... «Клиент записал почти каждую деталь своего проекта в очень понятной и« дружественной к программисту »форме». Попросите нового парня перевести записи клиента в проектную документацию, а затем: «Существуют модульные тесты только для более свежего кода. Когда этот проект начался, мы не проводили регулярные тесты», чтобы он писал и выполнял тесты. Он не будет мешать вам и будет участвовать в проекте
Mawg

Ответы:

24

Лучше всего не бросать нового разработчика в огонь, а вместо этого вытащить некоторые функциональные возможности и / или исправления ошибок, к которым у разработчика не должно возникнуть никаких проблем. Найдите область, которая требует работы, для которой человеку не нужно знать всю архитектуру, требования и кодовую базу одновременно. Может быть, он или она работают над документацией, чтобы быстрее изучить систему.

Nik
источник
Добавление юнит-тестов для старого кода и исправление ошибок - вот некоторые идеи, которые может сделать новый разработчик - конечно, с поддержкой и обзорами кода другими. Может быть, есть необходимость в автоматическом тестировании пользовательского интерфейса? Это также то, что новый разработчик может сделать и многое узнать о приложении.
Ганс-Петер Стёрр,
18

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

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

Компромисс в том, что в обмен на временную помощь вы получите код, написанный посторонним. Чтобы уменьшить этот риск, убедитесь, что вы оба выполняете все проверки кода вместе с ним. Убедитесь, что вы просматриваете и понимаете все его юнит-тесты тоже.

dasblinkenlight
источник
5
Это зависит от того, насколько далеко они позади. Консультант обойдется дороже и возьмет с собой знания, когда уйдет. Также поиск любого, который потребовал бы почти нулевого времени запуска, вероятно, желаемое за действительное.
Ник
1
@ Ник Я согласен, более высокая стоимость - определенно компромисс; так же знания уходят из проекта. Трудно найти начинающего стартера, особенно в короткие сроки, но я видел, что это было сделано в нескольких критичных по времени проектах. Однако стоимость их найма была довольно высокой.
dasblinkenlight
Я сделаю некоторые исследования, но опытного консультанта может быть трудно найти в моем районе. Как вы думаете, можно ли будет работать с кем-то из другого города? Или расстояние еще больше замедлит процесс?
Лортабак
3
Я думаю, что закон Брука применим и к опытному консультанту, поэтому я не думаю, что это будет реальным решением проблемы.
Док Браун
@lortabac Добавление кого-то для удаленной работы с вами, скорее всего, замедлит работу. Насколько гибки спонсоры в обрезании требований к дополнительному модулю? Вы можете попросить их отсортировать новые функции в порядке важности и решить, каков абсолютный минимум требований, которые вы должны выполнить, чтобы событие имело смысл. Если вы не можете получить «пожарного» на местном уровне, сокращение области может быть хорошим планом действий на случай непредвиденных обстоятельств.
dasblinkenlight
14

Это хорошая идея, чтобы добавить человека сейчас?

Нет. Если это вообще возможно, попытайтесь заставить клиента договориться об уменьшении объема.

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

Buhb
источник
4
+1. Несмотря на все благонамеренные другие предложения с более высоким рейтингом, я думаю, что это, скорее всего, единственное, что действительно сработает в такой ситуации.
Док Браун
Согласитесь от всего сердца. Если у вас осталось два месяца, и вы просто думаете о найме кого-то сейчас, вы не получите много от нового найма. Если вам не повезло, или у вас уже есть кто-то компетентный, вы либо потратите два месяца на поиски (и отвлекаете от собственной продуктивности), либо наймете кого-то, что только ухудшит ситуацию. Не торопись с наймом.
JMK
10

Не делай этого.

Еще.

Традиционный вид

В своем вопросе вы ссылаетесь на закон Брукса из « Мифического человека» .

Добавление рабочей силы в поздний программный проект делает это позже.

Игнорировать закон Брука несет цену. Не многозадачность. Сосредоточьтесь на доставке вашего минимально жизнеспособного продукта (MVP). Затем сфокусируйте свою энергию на подборе, предоставлении ресурсов, обучении и управлении новым членом команды.

Два месяца так коротко. Запланируйте рекрутинг со списком выгорания, и вы увидите, как много времени это может занять.

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

Agile, New Millenium View

Конкуренция стимулирует динамичное объединение сейчас больше, чем в эпоху, когда был написан «Мифический человеко-месяц» (середина 1960-х). Долгая карьера в одной компании ушла. Сейчас мы часто мигрируем между проектами и компаниями. Быстрое построение команды создает успех. Медленное наращивание является серьезным ограничивающим фактором. Хорошие примеры - проекты с открытым исходным кодом, стартапы и более широкое использование командных проектов на курсах по информатике.

Потенциально гибкие команды учитывают ограничения в своих графиках. Они не опаздывают, потому что они оптимизированы для доступных ресурсов. Интеграция новых сотрудников является еще одним препятствием и рассматривается как компромисс между краткосрочными и долгосрочными целями. Команда Agile постоянно интегрирует код, так почему бы и не люди?

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

  • ежедневные ссоры
  • парное программирование
  • рефакторинг
  • добавление недостающих юнит-тестов
  • откармливание скудной документации
  • код отзывы

Жертвенный Агнец

В « Организационных моделях гибкой разработки программного обеспечения» Джеймс Коплиен обсуждает групповую динамику и затраты на добавление новых членов команды. Его паттерн «Жертвенный ягненок» назначает все наставничество и обучение одному человеку, защищая остальную команду от перерыва.

Это стратегия, которую вы можете захотеть реализовать.

Другая стратегия заключается в назначении новых наставников, которые будут отвечать на вопросы новых сотрудников на определенные часы каждый день. Если вы можете сэкономить только одного парня, возможно, он работает без перерыва по утрам или после обеда и отвечает на вопросы во второй половине дня или утром соответственно. Прошлым летом в моей группе было десять стажеров, поэтому многие люди были прерваны.

В настоящее время наставничество осуществляется одним человеком, в основном во время и сразу после утренних разборок (с 8:30 до 9:15, вместе взятых), а во второй половине дня с 12 до 3:30 (он работает с 7:00 до 3:30. вечера).

DeveloperDon
источник
Эта книга немного дорогая, но я собираюсь проверить это.
Зеленый,
Возможно, вы сможете найти выдержки из книг, которые я упоминал в Интернете, возможно, в книгах Google. Я одолжил книги Брукса и Коплиена в своей местной университетской библиотеке.
РазработчикDon
6

Я рад, что вы упомянули закон Брука. Красиво сделано. Основная проблема с добавлением другого разработчика - это накладные расходы на их ускорение и накладные расходы на синхронизацию с ними информации о том, где вы находитесь в проекте. Поэтому, если вы решите получить третьего разработчика, я бы попробовал это:

  • Дайте новому парню ту область, где затраты на скорость невелики, и он сможет начать работу как можно быстрее. Это будет во многом зависеть от того, кого вы нанимаете и какими навыками они обладают.
  • Убедитесь, что эта область слабо связана с другими областями приложения, чтобы затраты на синхронизацию были меньше. Отправлять его на интенсивную работу с БД и реорганизовывать таблицы может быть слишком много.
  • Делайте все возможное, чтобы поддерживать моральный дух. Как уже отмечали другие, добавление нового члена команды может вызвать стресс, поэтому, возможно, помогут инвестиции в газированные напитки.
зеленый
источник
возможно, определите области, в которых нужно работать, и начните с того, что новый человек начнет писать тесты для существующего кода, чтобы помочь им лучше понять систему, прежде чем погрузиться в ее изменение / добавление.
StevenV
@ StevenV это отличная, отличная идея. Написание тестов для компонентов, которые вы не знаете, очень быстро познакомит вас с ними. И система будет более тестируемой, когда вы закончите. :)
Green
5

Если вы строго следуете закону Брука, вы, скорее всего, никогда не увеличите свою команду.

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

В твоем случае? Я бы порекомендовал новому человеку написать все эти недостающие юнит-тесты.

  1. Это крайне необходимо в качестве защиты от ошибок регрессии, которые сожгут вас быстрее, чем любое замедление Брукса.
  2. Новый человек будет изучать внутренности вашей системы. Это что-то вроде испытания в огне - но их вывод не входит в производственный код, так что там небольшой риск.
  3. Установите жесткое ограничение на количество времени, которое могут занять другие члены команды. Например, пусть они ставят в очередь вопросы и позволяют общаться с другими членами команды только 30 минут в день, пока не будет соблюден конечный срок.

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

Эд Йедон отлично прокомментировал закон Брука. Он сказал: конечно, добавление людей заставит вас идти медленнее - но когда проект находится в опасности, единственное управление временем привлечет новых людей. Итак: возьмите их, сведите к минимуму влияние на текущую версию и избавьтесь от плохих исполнителей, как только сможете. Таким образом, со временем вы сможете построить сильную команду.

Ralff
источник
3

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

HLGEM
источник
3

Вы говорите, что вам нужно выполнить 25% оригинальной работы, плюс новую работу. И вам нужно сделать это за два месяца - когда вам потребовалось 18 месяцев, чтобы выполнить 75% работы. Чтобы быть очень грубым, это указывает на то, что ваши способности оценивания являются средними для программиста, ориентированного на код, то есть, вы думаете, что на это у вас уйдет примерно половина или треть, пока они действительно это делают.

Heroics может позволить вам доставить продукт, на который вы заключили контракт, но это не принесет вам или вашему клиенту никакой пользы. В этих условиях он будет дрянным и испорченным, и вы будете работать на парах.

Имейте в виду, что время, которое вы тратите на работу, также сильно повлияет на вашу готовность - это не то, что вы можете просто сделать в выходные, нужно время, чтобы найти талантливых сотрудников, которые хорошо подходят. Ожидайте потратить, по крайней мере, пару недель на поиск, собеседование и т. Д. Ожидайте, что вы и ваш работающий сотрудник будете терять около 10 часов в неделю продуктивного времени во время поиска.

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

Сядьте с вашим клиентом, объясните, что вы над головой, и поработайте с ним, чтобы уменьшить охват до минимума.

Редактировать Только что видел дату здесь. Так как же это закончилось? (Спасибо Ars Technica за размещение трехмесячного вопроса;)

Марк Рай
источник
Через несколько дней после публикации этого вопроса я покинул компанию. Как правильно отмечали некоторые комментарии к Ars Technica, были более глубокие проблемы, которые я не упомянул в этом вопросе. Я просто хотел получить мнение по этому конкретному вопросу.
Лортабак
2

Есть несколько способов, которые я хотел бы рассмотреть:

  1. Задержитесь с наймом нового разработчика до истечения крайнего срока, чтобы было легче сосредоточиться на передаче знаний о предметной области новому парню. Это было бы моим предпочтением, так как это может быть немного сложным в нескольких отношениях.

  2. Привлеките нового разработчика для работы с документацией, модульными тестами и другими вещами, которые не меняют существующий код. Это было бы то, что я бы посоветовал, если бы вы пригласили нового парня попытаться минимизировать влияние на текущую рабочую нагрузку.

JB King
источник
2

Дата уже прошла, но для тех, кто читает это позже.

Главное, что нужно учитывать, это то, что клиент в этой ситуации может потерять гораздо больше, чем вы. Они уже потратили много денег, и у них есть ключевое событие, которое может сделать или сломать их бизнес. У вас уже есть свои деньги, и потеря одного клиента не должна сломать ваш бизнес. Если это так, то у вас есть другие серьезные бизнес-проблемы помимо ужасного управления проектами.

Лучше всего договориться о важном подмножестве функций, а затем работать сверхурочно, чтобы сделать это. Если вы не можете заставить меньшее подмножество случиться или не хотите работать сверхурочно в такой ситуации, вам, вероятно, не следует заниматься бизнесом. Это может означать приостановку работы других клиентов, однако я предполагаю, что ваши другие клиенты не заплатили за 3 человека лет, поэтому разместите свои ресурсы там, где есть деньги.

Если они не хотят договариваться о снижении объема, то вы можете потерпеть неудачу.

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

Как уже отмечалось, рекрутинг требует времени. Мой опыт показывает, что это занимает минимум месяца. Затем добавьте тренировку, и ваше время истекло.

Я надеюсь, что это сработало для вас.

Дэвид Бартон
источник