Зменшення повернення додаткових розробників


10

Чи є термін для опису моменту, коли додавання більшої кількості розробників до програмного проекту забезпечить зменшення прибутку?

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


2
Я вважаю, що ця точка називається "Зараз". Якщо серйозно, то ви повинні показати їм графік, в якому відображається момент, коли додається один / п’ять / десять нових розробників та вплив, який він має на часовий графік проекту (враховуючи втрату продуктивності через наставництво членів, нові члени помилок та переробку тощо). )
Oded

14
"Дев'ять жінок, які народили дитину за один місяць", є поширеною аналогією, яка використовується для пояснення питання управління ресурсами та часовою шкалою.
dasblinkenlight

2
@dasblinkenlight - "Але що робити, якщо жінки працюють у зміну?" (типова нетехнічна відповідь управління).
jfrankcarr

6
but senior management tends to view it as aggressively negativeПорядок денний вищого керівництва у вашому випадку, ймовірно, дворазовий: зменшити дані про завершення проекту будь-якими можливими способами та контролювати розробників. Будь-який погляд, який суперечить їх заздалегідь задуманим уявленням, буде розглядатися як негативний, і залежно від того, наскільки агресивно ви намагаєтесь "переконати" їх в іншому, буде позначати вас лише як "не гравця команди" Напр. Керівництво виступає за того, хто не може контролюватися.
maple_shaft

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

Відповіді:


7

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


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

@MarkJ Добре. Напевно, я не обов'язково шукаю зменшення або негативне повернення за правилом. Я просто шукаю точку, щоб керівник проекту / керівника проекту сказав "ні" більше ресурсів. На жаль, це не завжди ріжеться і сушиться.
smp7d

6

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


1
"Мій приятель з гольфу, який також керує ІТ-консалтинговою компанією, каже, що у нього є два програміста" чорного пояса ", які зараз доступні. Вони обоє мають ступінь магістра з інформатики. , правда? Можливо, ви дізнаєтесь щось про те, як краще запланувати час ".
jfrankcarr

1
@kevincline - "Я бачу, що ти не гравець команди. Я доручаю тобі підтримувати наш 14-річний додаток VB6. Ось копія" Хто перемістив мій сир? ", щоб ти прочитав."
jfrankcarr

3
"Я бачу, що ти не гравець команди".: У мене був і цей коментар. Моєю відповіддю було порівняння з футболом: хороша команда не намагається забитися на 5 квадратних метрів, але намагається зайняти все поле, щоб кожен гравець був більш ефективним; і гравці часто віддають м'яч вперед-назад за потребою. Робота в команді означає, що члени команди координують свою діяльність, але працюють над незалежними ділянками проекту, що не перетинаються. Якщо це можливо, можна додати більше розробників та підвищити продуктивність.
Джорджо

1
@kevin cline: Можливо, це причина, чому з часом стає марним додавати нових розробників до команди. Ймовірно, слід припинити додавати нових розробників, якщо не вдасться знайти область, яка є абсолютно незалежною від решти проекту.
Джорджіо

2
Ставлення команди, розмір проекту, наскільки хороша ситуація, досвід нових членів, сучасний стан вимог тощо - це всі важливі фактори, які слід враховувати тут ...
NoChance

4

Приречений на повторення

Бідний Фред Брукс - це як Кассандра з Ілліаду Гомера . Якщо ви читаєте книгу про те, що фільм "Троя" з'явився, саме вона не піклувалася про (троянського) коня. Вона точно прогнозує майбутнє, але ніхто не вірить їй, поки не відбудеться прогноз, і вони переконалися в цьому самі.

Не боротися з управлінням / пасивним опором чи ретельним наймом?

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

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

Контроль тягаря інтеграції нових найм

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

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

Найкращі та найгірші призначення нових наймань

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

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

Дотримання гармонії в команді, встановлення майбутніх очікувань

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


1

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

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

0

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

Використовуючи наш веб-сайт, ви визнаєте, що прочитали та зрозуміли наші Політику щодо файлів cookie та Політику конфіденційності.
Licensed under cc by-sa 3.0 with attribution required.