Як я можу захистити Ruby on Rails від не технічної думки клієнтів?

Мій клієнт, власник фірми з перекладу, щойно сказав мені, що він читав про Ruby on Rails і сказав мені, що " там більше хлопців PHP " і " здається, громада віддає перевагу цьому ". Що б ви, як інженер програмного забезпечення та фрілансер, сказали замовнику для досягнення цих цілей:

• Продам
• Дайте йому зрозуміти, що технологія - це моє експертне рішення, і Rails настільки ж хороший або кращий, ніж PHP (+ будь-які рамки) для цього конкретного проекту.

ОНОВЛЕННЯ: Дякую всім за пропозиції! Завтра у мене ще одна зустріч з ним, давайте подивимось, як це відбувається, я ще раз оновлюся :)

ОНОВЛЕННЯ 2: Нарешті я сказав йому прочитати цю тему, і результат був фантастичним: Він дав мені проект, і ми зараз почнемо починати. Дякую всім за допомогу, у вас безкоштовно піво, якщо ми побачимось колись :)

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

з повагою

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

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

• Роботодавці повинні найняти з певної географічної області, а певні райони мають особливо активні громади навколо певних технологічних наборів. Наприклад, якщо ви починаєте бізнес на Тихоокеанському північно-західному напрямку США, буде сильний ухил до стеку Microsoft, просто тому, що Microsoft дуже впливає на цю сферу, тому більшість розробників, яких ви хочете найняти, є досвід роботи з цією стекою. Інші географічні регіони мають дуже різний профіль.
  Поговоріть зі своїм клієнтом і зрозумійте, чому і як він сформував свою думку. Можливо, він прочитав, що місцева спільнота PHP особливо активна або що місцевий коледж навчає багато PHP, а не Ruby. Можливо, у нього є надійний розробник, який він може зателефонувати за випадкових надзвичайних ситуацій, які є професіоналом PHP та неофітом Ruby. Звичайно, можливо також, що він використовує погані показники, такі як кількість оголошень про роботу або резюме, в яких згадуються різні ключові слова.
• Роботодавці повинні перейматися довгостроковою стійкістю технологічних наборів. Наприклад, багато років тому багато компаній інвестували багато часу та зусиль, будуючи додатки PowerBuilder (та інші мови цього жанру). PowerBuilder часто робив його дуже простим у створенні лінійки бізнес-додатків, і розробники в той час часто були дуже захоплені цим. На жаль, спільнота PowerBuilder більш-менш розпалася, залишаючи компанії в ситуації, коли у них було багато існуючого коду мовою, яку ніхто не хотів використовувати там, де їм було важко отримати компетентних розробників для підтримки існуючого коду та дорогих, трудомістких проектів щоб перемістити ці додатки до інших стеків технологій. Відносні технічні достоїнства PowerBuilder були порівняно з Java або C ++ або C # або з тим, що вони переходили до цього моменту;
  Відносно ніші мови, такі як Ruby, абсолютно мають потенціал створити подібні проблеми зі спадщиною для компаній, які не можуть передбачити, чи вийде мова через кілька років, коли люди перейдуть до наступної примхи або якщо вона має реальну стійкість . Ви, звичайно, можете пом'якшити це, зазначивши, що Ruby не залежить від однієї компанії чи організації, тому ніхто не може вирішити, що це вже не є стратегічним продуктом для компанії. Якщо ваш клієнт був спалений раніше, використовуючи програми, розроблені мовами, які стали головними болями у бізнесі, вам потрібно буде зробити так, що Ruby більше схожий на Linux та інші технології з відкритим кодом, які процвітали, не підтримуючи їх компанію, ніж мови, які мають вимерли з роками.
• Роботодавці хочуть послідовності в оточенні, тому вибір мови для одного проекту змушує вибір багатьох інших. Навіть якщо Ruby технічно ідеально підходить для проекту, який ви кепчуєте, ви повинні пояснити, чому це підходить для будь-якої іншої програми, якій цей клієнт потребує розробки, або пояснити, який поєднання технологій, на який ви вважаєте, підходить (наприклад, Ruby для X, щось інше) для Y). Однак робота з гетерогенними технологіями неминуче перетворюється на додаткові витрати для бізнесу.

Для початку ви можете направити свого клієнта сюди, щоб подивитися на екосистему, яка існує навколо Рейки. Ви також можете вказати на таких успішних стартапів, як LivingSocial, Shopify, 37signals тощо., Які створили свій бізнес за допомогою Ruby and Rails.

Ви можете згадати, що такі масивні підприємства, як AT&T, SAP та Symantec, також використовують Rails (вони в основному набиралися в RailsConf минулого року).

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

Зрештою, я думаю, що вам потрібно продати думку про те, що можливість використання Rails - це преміальна функція, яку він отримує, наймаючи вас: "Звичайно, всі інші хлопці використовують PHP. Але у вас є можливість мати сучасний стек, що живить ваш додаток . "

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

PS Не згадуйте Twitter. Ми все ще намагаємось скасувати поганий PR-рейл, який взяли з цього.

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

Він говорить про людей, ви говорите про мову та рамки. Він не буде чути жодних технічних причин, тому слід зосередитися на тому, що люди роблять з мовою . Ви можете поговорити про владу людей під Rails, про те, як одній людині легше робити швидше, ніж людині PHP, швидше (якщо в це ви вірите). Ви можете запитати, чи означає поширеність водіїв Honda це кращий автомобіль, ніж Rolls Royce, якого рідко можна побачити. Ви можете поговорити про те, з чого насправді складається спільнота, чи занадто багато кухарів у супі з модулями (дорогоцінні камені проти модулів тощо), чи є у всіх синдром НІХ тощо.

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

Зрештою, не соромно називати його блеф. "Добре, йдіть з PHP. Удачі!"

Зазначте, що натовп PHP має більше членів, оскільки його найнижчий бар'єр для входу є довший і довший. Не забудьте зазначити, що менші громади мають більший відсоток програмістів, яких варто найняти, PHP може мати 10 000 хороших програмістів порівняно з 5000 програмістами на рейках, але програмісти PHP приховані в блоці 100 000 порівняно з 20 000 для програмістів рейкових плат. (Ці цифри складаються, але це стає зрозумілим.) Тоді вам потрібно пояснити, що спільнота насправді не має переваги між PHP та Rails.

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

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

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

У вашого начальника є крапка. PHP набагато популярніший, ніж кодування RoR на кількох сайтах, які намагаються відстежувати такі речі. Наприклад, див. Http://lang-index.sourceforge.net та http://www.tiobe.com/index.php/content/paperinfo/tpci/index.html >. Я думаю, було б нерозумно ігнорувати факти.

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

Зрештою, він дійсно шукає вашої впевненості, що він приймає правильне бізнес-рішення і хоче, щоб докази підтвердили це. Як свідчить стара приказка: "Ніхто ніколи не стріляв по них за рекомендації Microsoft". Те саме стосується PHP у веб-розробці. Дайте йому ґрунтовні факти та ухиляйтесь від думок. Ви все зробите добре.

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

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

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

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

Звичайно, це ділове рішення для вас обох .

Для вас питання:

• Скільки буде коштувати мені виконання вимог моїх клієнтів за допомогою Ruby on Rails?
• Скільки буде коштувати мені впровадити їх у PHP?
• Яке значення я приділяю використанню вподобаного середовища?

Для вашого клієнта питання

• Скільки коштують мені сприйняті переваги PHP над Ruby on Rails?

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

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

Найкраща аналогія в реальному світі, яку я можу придумати, - це "Купував би Ford, а не BMW тільки тому, що частка ринку BMW менша?".

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

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