Як мені зробити справу для дорогих програмістів?

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

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

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

Різниця полягає в тому, що досвідчені програмісти створюють менше помилок, а їхній код є стабільнішим і т. Д. Початківці програмісти витрачають багато часу на всіх (PM, клієнтів тощо). Але вони значно дешевші.

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

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

Я маю досвід з обох теорій, які перевіряються в реальному світі - насправді в одному проекті.

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

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

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

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

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

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

TL; DR Хороші програмісти - це угода. Важкий біт - це знайти їх та створити достатньо привабливе робоче середовище для їх збереження.

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

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

Нарешті, знайдіть зображення Червоного Адара , відомого пожежника, якого закликали у великій катастрофі після кількох невдалих спроб менш досвідчених хлопців. Його відома цитата:

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

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

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

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

Одне питання - що конкретно планує ваша компанія? Гаразд, вони наймуть дешевих молодших програмістів. Три роки минає, тепер що? Що вони роблять з розробником, який був з ними протягом цих трьох років? Вони просто ніколи не давали йому / їй підвищення? Тут є такі варіанти:

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

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

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

Однією з переваг, особливо, дуже хороших розробників є те, що я дивуюсь, що ніхто інший не згадав - це те, що вони можуть бути мультиплікативним фактором. Цілком може статися так, що молодший розробник та старший розробник витрачають однакову кількість часу, щоб скласти таблицю. Однак хороший розробник цього не зробить. Вони зроблять генератор таблиць, який скорочує час для створення всіх таблиць. Крім того / додатково, вони піднімуть стелю того, що можливо для всіх . Наприклад, розробники, які реалізували карту Google MapReduce, ймовірно, були надзвичайно кваліфікованими, але навіть якщо користувачі MapReduce, абсолютно не в змозі самостійно скласти широко розповсюджену версію свого алгоритму, тепер вони легко можуть з MapReduce. Часто ця динаміка менш кричуща. Наприклад, покращуються практики контролю над джерелами, тестування та розгортання всіх , але це може бути важче простежити за конкретною людиною.

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

Це не те / або ситуація.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Ваше друге питання щодо бюджету PM та Developer. Я б сказав, що розробник може обійтися без прем'єр-міністра, але ПМ не може обійтися без розробника. Спочатку відсортуйте свій двигун розробки, а потім отримайте прем'єр-міністра, щоб зняти адміністратора з своїх рук.

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

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

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

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

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

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