Чи допоможе новобранцям окремий підпроект від досвідчених розробників допомогти новачкам швидше нароститися?

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

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

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

=======

ОНОВЛЕННЯ

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

Ще одна помилка, яку я зробив (і про це мене попередив Алекс Д) - це те, що я намагався продати рефакторинг вище керівництву. Ви ніколи не продаєте рефакторинг, лише функції.

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

Подумав, я згоден, як і всі інші, що:

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

У мене таке відчуття, ти збираєшся це робити, де завгодно, так що ...

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

Що ви можете спробувати, це дати їм невеликі фрагменти / модулі / форми / класи вашого проекту, з якими потрібно працювати, а не над усім проектом.

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

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

Чи є у вас документація щодо заявки на зразок: UML, ER, Codd-Yourdon, що завгодно?

Щасти.

Моє запитання: чи допоможе такий підхід розробникам-новачкам легко адаптуватися до нового проекту?

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

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

• Купуйте або ліцензуйте існуючий продукт, а не намагатися створити свій власний. Вам справді потрібно винаходити колесо для оформлення каси?

• Як я вже говорив вище, наймайте людей, які мають досвід побудови потрібної системи.

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

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

• У вас чітко визначений процес розробки? База даних? Контроль версій? Процес перегляду коду? Посібник зі стилів? Поставте ці речі на місце.

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

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

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

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

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

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

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

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

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

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

У своєму коментарі до Алекса Д ви згадали: "Це не терміни, які ми дотримуємося, його демонстраційна здатність надавати нові функції". Тож перейдіть до стилю розробки, який виділяє функції в менші шматки та частіше. Запропонуйте новим членам команди протестувати нові функції, які допоможуть їм зрозуміти кодову базу.

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

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

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