Come posso difendere Ruby on Rails dall'opinione tecnica dei clienti?

Penso che tu commetta un errore nell'assumere che la scelta della tecnologia sia una decisione puramente tecnica.

Il cliente sembra essere preoccupato per le implicazioni commerciali della scelta di una particolare tecnologia. Detto questo, è necessario presentare un caso che affronti le sue preoccupazioni aziendali almeno tanto quanto le vostre opinioni sulla tecnologia.

• I datori di lavoro devono reclutare da una particolare area geografica e alcune aree hanno comunità particolarmente attive attorno a particolari stack tecnologici. Se stai iniziando un'attività nel Pacifico nordoccidentale degli Stati Uniti, ad esempio, ci sarebbe una strong propensione verso uno stack Microsoft semplicemente perché Microsoft è molto influente nell'area, quindi la maggior parte degli sviluppatori che vorresti assumere sarebbe avere esperienza con quello stack. Altre regioni geografiche hanno profili molto diversi.
  Parla con il tuo cliente e capisci perché e come ha formato la sua opinione. Forse ha letto che la comunità PHP locale è particolarmente attiva o che il college locale insegna molto PHP e nessun Ruby. Forse ha uno sviluppatore affidabile che può chiamare per l'emergenza occasionale che è un professionista PHP e un neofita di Ruby. Ovviamente, è anche possibile che utilizzi metriche scadenti come il numero di annunci di lavoro o di curriculum che menzionano varie parole chiave.
• I datori di lavoro devono preoccuparsi della sostenibilità a lungo termine degli stack tecnologici. Anni fa, ad esempio, molte aziende investivano molto tempo e sforzi per creare app PowerBuilder (e altri linguaggi di quel genere). PowerBuilder spesso rendeva molto facile creare una linea di app aziendali e gli sviluppatori, al momento, erano spesso abbastanza innamorati di esso. Sfortunatamente, la comunità di PowerBuilder ha più o meno fatto collasso lasciando le aziende in una situazione in cui avevano un sacco di codice esistente in una lingua che nessuno voleva davvero usare dove avevano difficoltà a ottenere sviluppatori competenti per mantenere il codice esistente e progetti costosi e dispendiosi in termini di tempo per migrare quelle app ad altri stack tecnologici. I meriti tecnici relativi di PowerBuilder erano contro Java o C ++ o C # o qualsiasi altra migrazione a quel punto; è stata una spirale mortale perché gli sviluppatori non volevano rimanere bloccati in un linguaggio che le aziende volevano emigrare e le aziende hanno visto la mancanza di sviluppatori come un segno che dovrebbero raddoppiare i loro sforzi di migrazione per garantire che avessero la capacità di fare sviluppo del business necessario.
  Linguaggi relativamente di nicchia come Ruby hanno il potenziale per creare questo tipo di problemi legacy per le aziende che non possono prevedere se la lingua si esaurirà in pochi anni quando le persone passeranno alla moda prossima o se ha un reale potere di resistenza . Si può certamente mitigare questo sottolineando che Ruby non dipende da una società o organizzazione, quindi nessuno può decidere che non sia più un prodotto strategico per l'azienda. Se il tuo cliente è stato bruciato in passato con applicazioni sviluppate in lingue che sono diventate problemi di business, dovrai dimostrare che Ruby è più simile a Linux e altre tecnologie open source che prosperano senza una società che le supporta rispetto alle lingue che hanno si spense nel corso degli anni.
• I datori di lavoro vogliono coerenza nell'ambiente, quindi scegliere una lingua per un progetto costringe a scegliere per molti altri. Anche se Ruby è tecnicamente ideale per il progetto che stai pubblicando, devi spiegare perché è appropriato per ogni altra applicazione che questo cliente avrà bisogno di sviluppare o spiegare quale mix di tecnologie tu credi sia appropriato (es. Ruby per X, qualcos'altro per te). Affrontare tecnologie eterogenee, tuttavia, si traduce inevitabilmente in un costo aggiuntivo per il business.

Per cominciare, puoi indirizzare il tuo cliente qui per dare un'occhiata all'ecosistema che esiste attorno a Rails. Puoi anche indicare le startup di successo come LivingSocial, Shopify, 37signals, ecc. Che hanno costruito le loro attività con Ruby e Rails.

Puoi menzionare che le grandi aziende come AT & T, SAP e Symantec stanno usando anche Rails (erano molto impegnate a reclutare su RailsConf l'anno scorso).

Puoi sottolineare che un business di traduzione ha molto da guadagnare usando un linguaggio / framework che rende il supporto Unicode e i18n relativamente indolore.

In definitiva, penso che tu abbia bisogno di vendere l'idea che essere in grado di usare Rails è una caratteristica premium che ottiene assumendoti: "Ovviamente tutti quelli altri usano PHP. Ma hai l'opportunità di avere uno moderno stack che alimenta la tua applicazione. "

Alla fine della giornata, deve anche essere chiaro che ciò che sta acquistando alla fine è la tua abilità e competenza; se fosse così competente sulle tecnologie web server-side, non avrebbe bisogno di te. La lingua e il framework sono decisioni di implementazione, non requisiti.

P.S. Non parlare di Twitter. Stiamo ancora cercando di annullare le cattive Rails PR prese da questo.

Spiegherei che è fondamentalmente una scelta "Coca-Cola" e "Pepsi". Entrambi sono ampiamente accettati, entrambi hanno persone che combatteranno e moriranno per ciascuna, e sono entrambi perfettamente adeguati. Indica i motivi per cui preferisci RoR.

Sta parlando di persone, stai parlando di un linguaggio e di una struttura. Non sentirà alcunché che sia puramente tecnico, quindi dovresti concentrarti su ciò che le persone stanno facendo con la lingua . Puoi parlare di persone-potere sotto Rails, come è più facile per una persona fare più di una persona PHP, più veloce (se questo è ciò che credi). Puoi chiedere se la prevalenza dei piloti Honda significa che è un'auto migliore di una Rolls Royce, che si vede raramente. Puoi parlare di ciò che la comunità è effettivamente composta, se ci sono troppi cuochi nella zuppa del modulo (gemme vs moduli, ecc.), Se tutti hanno la sindrome NIH e così via.

In ogni caso, deve essere in termini di persone perché vuole sapere che può sostituirti. Aiutalo a saperlo, perché (probabilmente) non vorrà comunque andarsene. La tua "decisione esperta" non ha assolutamente rilevanza quando dà molto meno attenzione a ciò che sa una determinata persona. Vuole solo che ci siano "più persone" che conoscono la stessa cosa.

Alla fine della giornata, non c'è da vergognarsi nel chiamare il suo bluff. "Bene, vai con PHP, buona fortuna!"

Fai notare che il pubblico di PHP ha più membri perché è la barriera più bassa per entrare e dura da più tempo. Assicurati di sottolineare che le comunità più piccole hanno percentuali più elevate di programmatori che valgono la pena assumere, PHP può avere 10.000 bravi programmatori rispetto ai 5.000 programmatori di rotaie, ma i programmatori PHP sono nascosti in un blocco di 100.000 rispetto ai 20.000 per i programmatori di rotaie. (Questi numeri sono truccati, ma il punto è superato.) Quindi devi spiegare che la community in realtà non ha preferenze tra PHP e Rails.

Non puoi utilizzare motivi tecnici su una persona non tecnica, non puoi spiegare perché l'iPhone è inferiore ad altri smartphone a qualcuno che sa solo come sono i telefoni. Hai bisogno di ragioni che capiscono.

Il tuo cliente ti ha assunto, quindi presumibilmente si fida della tua esperienza. Spiega che diversi professionisti potrebbero preferire strumenti diversi e il tuo strumento preferito sembra essere il RoR. Fai notare la presenza della comunità e l'accettazione della comunità che esiste per il RoR e le aziende di successo come 37signals che lo usano, per rimuovere la sua preoccupazione che tu stia raccomandando una tecnologia arcana che nessuno, ma tu conosci. Fai notare che sarai più produttivo usando gli strumenti che preferisci (riducendo così i suoi costi e migliorando le sue modifiche al successo) e che se tu o lui hai mai bisogno di trovare più esperti di RoR non sarà difficile. Se è più tecnico, potresti indicare come RoR può avere successo nelle attività di cui ha bisogno rispetto a non meno della sua soluzione preferita.

Evita di ripetere FUD e generalmente denigrare PHP - se non sei un esperto di PHP, c'è un'alta probabilità che tu dica qualcosa che non è accurato, sbagliato o molto controverso, e se il tuo cliente impara che hai sbagliato su quello potrebbe danneggiare la tua credibilità con lui in altri aspetti.

Il tuo capo ha un punto. PHP è molto più popolare di RoR che accoda a diversi siti che si sforzano di tenere traccia di tali cose. Ad esempio, vedi link e link & gt ;. Penso che sarebbe sciocco ignorare i fatti.

Ti suggerisco di riconoscere che ha un punto e ricordargli che anche RoR ha un strong seguito. Non sarebbe male avere pochi link a siti popolari creati con RoR che puoi mostrargli.

Dopotutto, sta davvero cercando la sua assicurazione che sta prendendo le giuste decisioni aziendali e vuole che le prove lo confermino. Come dice il vecchio proverbio "Nessuno ha mai avuto frecce con le frecce per raccomandare Microsoft". Lo stesso vale per PHP nello sviluppo web. Dagli fatti concreti e evita le opinioni. Andrà bene.

Traduci le tue convinzioni in termini economici quantificabili (se possibile / valido). Il fatto che la sua attività sia specifica della traduzione suggerisce che RoR (o qualsiasi lingua con supporto multilingue nativo) è tecnicamente superiore a PHP - ma questo deve essere compensato con i costi degli sviluppatori e del provisioning dei server associati a quelli rispettive piattaforme. È probabile che la loro attività duri più a lungo del tuo rapporto, vorranno rassicurazione sul fatto che stanno gettando le giuste basi.

IME, ammettere i contro (e anche i pro) della tua strategia è più convincente di qualsiasi altra forma di evangelizzazione - suggerisce che sei più interessato a risolvere il problema loro che usare il tuo martello preferito.

Il tuo cliente potrebbe avere un punto valido. Domanda e offerta influenzano i prezzi. Se la fornitura di sviluppatori con una particolare competenza nell'area geografica dei clienti è bassa, il prezzo per la manutenzione del software che richiede quel set di abilità più raro potrebbe aumentare più nel tempo rispetto a se il software fosse stato sviluppato utilizzando un linguaggio più popolare per il quale esisteva un numero significativamente maggiore pool locale di sviluppatori esperti. Quindi il problema potrebbe anche essere una gestione a lungo termine dei costi.

Quando ho un cliente che desidera utilizzare uno strumento particolare perché è "standard di settore", ha un "consenso" o è "ciò che tutti usano", faccio notare che tutti questi termini sono codice per " media del settore. " Cioè, cosa sta facendo la maggior parte delle altre persone nella zona. L'azienda "media" fallisce. Scegli i tuoi strumenti in base ai requisiti del lavoro, non a quello che fanno gli altri. Ci sono meno programmatori RoR non importa se al sistema non serve tanto armeggiare quando è finito.

Sicuramente questa è una decisione commerciale per entrambi .

Per te le domande sono:

• Quanto mi costerà implementare i requisiti dei miei clienti utilizzando Ruby on Rails?
• Quanto mi costerà implementarli in PHP?
• Quale valore attribuisco all'utilizzo del mio ambiente preferito?

Per il tuo cliente, la domanda è

• Quanto vale il valore percepito di PHP rispetto a Ruby on Rails?

Se fornisci ai tuoi clienti un'offerta con un Prezzo per l'implementazione utilizzando Ruby on Rails e un Prezzo per l'impiantazione separato utilizzando PHP , entrambi basati sulle risposte al tuo proprie domande, allora il cliente può fare il proprio giudizio su se il costo aggiuntivo ora vale un risparmio futuro possibile.

Questo non è diverso da loro che decidono se devono dare il contratto a te, o ad un altro sviluppatore che lo implementerebbe usando PHP come richiesto.

La migliore analogia del mondo reale che riesco a trovare è "Comprerei una Ford piuttosto che una BMW solo perché la quota di mercato di BMW è inferiore?"

In definitiva, i programmatori PHP sono la metà del costo dei programmatori di Rails, e tu cosa ne pensi se trovi un lavoro migliore domani? Il tuo capo sarebbe totalmente fregato e affannato per trovare uno sviluppatore di Rails, e ciò richiede tempo e denaro dal momento che gli sviluppatori di Rails scarseggiano.

L'unica ragione per cui il tuo capo sarebbe d'accordo è se ti sembra che ti renderebbe più felice e che, permettendo di prendere le decisioni che desideri, sarebbe più felice lavorare per lui, e quindi essere più produttivo.