Як менеджери вибирають мови програмування

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

Будучи самим програмістом, я ніколи не зміг цього зрозуміти.

Але зараз я думаю, що це так: мені щойно було відкриття, коли Джоел Спольський в подкасті сказав, що вони повинні використовувати QuickBooks, оскільки "це знає кожен бухгалтер у світі". Це вразило мене дуже схожим на "вибрав Java, тому що це знає кожен програміст у світі".

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

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

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

Дозвольте навести приклад: ПК. Джоель стверджує (правильно), що розробники повинні мати висококласні машини, оскільки час для розробників дорогий. У цьому він абсолютно правий. Але як ви це аргументуєте? Простий:

Приклад: я будую код приблизно 20 разів на день. Кожен раз це займає 3 хвилини. Якби у мене був швидкий ПК, я міг би створити його за 1,5 хвилини. Тож за додаткові 1000 доларів кожні два роки я можу отримати додаткові півгодини на день, що для програміста, який заробляє 100 тис. Доларів США (при витраті ще мінімум 50%), що становить приблизно 10 000 доларів на рік.

Але сперечатися з іншого боку - HR вирішує, що один розмір підходить всім, коли справа стосується політики та персональних комп'ютерів, тому працівник телефонного центру заробляє $ 25 тис., А програміст заробляє чотири рази, який чомусь повинен мати той самий ПК.

Технологічна платформа та мови матимуть чимало факторів, що входять до складу рішення:

• Стратегічні відносини з конкретними постачальниками. Якщо Ваша компанія є партнером Microsoft Gold (або як його зараз називають), то удачі отримати Java або Python;
• ІТ-відділ сперечається з певною конфігурацією, оскільки гроші на ПК виходять із їхнього бюджету;
• ІТ-рішення, що кожен повинен запускати Windows 2000, оскільки у них немає людей, які працюють під Linux;
• Які інші системи у компанії вже є (наприклад, якщо вони використовують Java для всього іншого, є сенс використовувати її для цього, навіть якщо самостійно це може бути не найкращим вибором);
• Відраза від ризику до різних платформ або мов просто через брак досвіду;
• Більше зацікавлений в тому, щоб сперечатися з ризиком з вищим керівництвом, ніж робити щасливим розробників;
• Деякі менеджери приймають рішення, які вони роблять, просто тому, що їм зв’язані руки;
• Бюджетні причини, хоча це може працювати і на вашу користь, оскільки це дозволяє утримувати дорогі бундогли з вашого будинку, як ПВХ, все, що виробляється Rational тощо;
• Неприязнь юридичного відділу до ліцензій з відкритим кодом;
• Не залучення технічного персоналу до планування та оцінки проектів;
• Ознайомлення з боку менеджера з певною платформою (технічні люди теж в цьому винні, але в обох випадках це не обов'язково погано - з багатьма інструментами, які можуть зробити цю роботу краще чорта, якого ви знаєте).
• Досвід технічного персоналу. Якщо вони всі з фону C #, навіщо вони використовувати Java, Python або Ruby?
• Багато інших причин

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

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

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

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

Як менеджери обирають мови програмування?

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

• Політичні
  • "Ніхто не звільнявся за покупку IBM" - безпечний вибір.
  • Генеральний директор почув, що Java крута - ажіотаж.
  • Головний архітектор любить .NET - проект для домашніх тварин.
  • Мова контролюється ворожим конкурентом - чому Google не покладається на C #.
• Економний
  • Витрати на ліцензування.
  • Вартість навчання розробників.
  • Кодові базові міграційні витрати.
• Соціальна
  • Вхід від команди.
  • Наявність навичок в будинку (потреби в навчанні, наступність).
  • Наявність навичок на ринку.
  • Загроза існуючому статусу кво в команді розробників.
  • Наявність достатньо великої спільноти практики.
• Технологічна
  • Підвищення продуктивності.
  • Поліпшення якості.
  • Можливість взаємодії з існуючою базою коду.
  • Дотримання стандартів.
  • Зрілість.
• Юридичні
  • Умови ліцензування.
  • Технологічний контроль (Хто володіє та контролює цю технологію? Яка майбутня стратегія ліцензування може бути?)
  • Відповідність законодавству та регуляторам.
• Екологічні
  • Існуюча інфраструктура компанії.
  • Існуючі навички в компанії.
  • Інтеграція із зовнішніми партнерами.
  • Рівень технологічної підтримки більш широкого середовища.

Тоді купу мов, що відповідають критеріям, можуть бути додатково оцінені за допомогою SWOT , аналізу вигоди та видатків тощо.

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

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

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

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

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

1. Поточна платформа вже не є адекватною.
2. Нова платформа обіцяє переваги, які значно переважають клопоту.

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

Менеджер А вирушає на літній відступ, де зустрічається з менеджером Б.

A: Отже, якою мовою ви користуєтесь у своїй компанії? В: О, ми використовуємо візуальні об'єкти CA, це робить безпілотники набагато продуктивнішими, ніж COBOL.

І ось так було прийнято рішення. Кінець справжньої історії.

Кожна платформа має хороші та погані сторони. .NET класний і потужний, але ви майже застрягли з серверами Windows. Рубі круто, але повільно. Було б важко знайти розробників для Haskell.

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

Виділяючи проблеми. Бізнес повинен відповідати за бізнес-рішення, а тех, хто відповідає за технічні рішення. Мені подобається термін «Прийнята відповідальність». Якщо я приймаю відповідальність, я також вимагаю зробити вибір, який стосується моєї області проблеми. Бізнес надає мені та моїм технічним колегам вимоги бізнесу, і ми відповідаємо однією або двома альтернативами того, як ми можемо прийняти на себе відповідальність. Це ніколи не повинно бути схожим на "ми зробимо це в Python або C #". Швидше;

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

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

Стати менеджером. (усмішка)

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

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

Це дуже залежить від особистості менеджера:

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

Інші довірятимуть лише те, що вони знають самі (наприклад, VB 6.0). Зробіть мову вибору легко зрозумілою для них ("ви знаєте, це так само, як і в старому доброму VB" - навіть якщо ви говорите про Haskell ...)

Але насправді більшість менеджерів не такі дурні, як ми любимо думати, і з ними можна міркувати. Тут важливо те, що ви розумієте їхню точку зору: їм зазвичай не цікаві конкретні технічні деталі, вони дбають про результати. Тому не кажіть їм, що .net або Java чи Delphi чи будь-що інше має цю приголомшливу особливість megacool. Скажіть їм, що (введіть свою мову тут) - хороший вибір, оскільки функція A дозволяє скоротити час розробки в такому проекті, або ця функція B створює менше помилок, а отже, скорочує час, необхідний для тестування. Просто переконайтесь, що ваш аргумент є надійним, не брешіть йому.

Іншими словами: ставитесь до нього як до розумної істоти (він, мабуть, є).

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

Вибір мови програмування часто є діловим рішенням. Клієнтів / користувачів це не хвилює. Ось коротка цитата (з http://www.ericsink.com/bos/Geeks_Rule.html ):

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

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

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

Так само, якщо ви говорите програмісту, якою мовою слід користуватися, то будьте послідовними, а також скажіть художнику, які розміри пензлів слід використовувати! АЛИ, альтернативно, просто залиште цей вибір людям, яким потрібно працювати з цим щодня і (як і більшість шедеврів) ночі!

Це різні поняття.

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

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

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

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

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

На мій досвід, це завжди залежало від:

1. Чи є у нас ресурси для використання мови?
2. Чи є у нас ресурси для підтримки мови?
3. Якщо у нас немає ресурсів для використання та підтримки мови, наскільки складно / дорого це отримати?
4. Яке "майбутнє" мови (чи буде вона довгий час і якась у використанні?)

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

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