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

Il mio cliente, un imprenditore di traduzioni, mi ha appena detto che ha letto di Ruby on Rails e mi ha detto che " ci sono più ragazzi PHP in giro " e " sembra che la comunità lo preferisca ". Che cosa diresti, come ingegnere informatico e libero professionista, al cliente per raggiungere questi obiettivi:

• Vendere
• Fagli capire che la tecnologia è la mia decisione da esperto e che Rails è buono o migliore di PHP (+ qualunque sia il framework) per questo particolare progetto.

AGGIORNAMENTO: Grazie a tutti per i suggerimenti! Domani ho un altro incontro con lui, vediamo come va, aggiornerò di nuovo :)

AGGIORNAMENTO 2: Alla fine gli ho detto di leggere questa discussione e il risultato è stato fantastico: mi ha dato il progetto e inizieremo ora. Grazie a tutti per l'aiuto, avete birra gratis a carico mio se vedremo un giorno :)

A proposito: ho imparato la lezione: sii il più trasparente possibile, perché se credi in te stesso e nel tuo lavoro, non c'è dubbio che sia abbastanza compromettente da batterti.

Saluti

Penso che tu faccia un errore nel ritenere 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 commerciali almeno tanto quanto le tue opinioni tecnologiche.

• I datori di lavoro devono reclutare da una particolare area geografica e alcune aree hanno comunità particolarmente attive attorno a particolari pile tecnologiche. Se stai avviando un'attività nel Pacifico nord-occidentale degli Stati Uniti, ad esempio, ci sarebbe un forte pregiudizio verso uno stack Microsoft semplicemente perché Microsoft è molto influente nell'area, quindi la maggior parte degli sviluppatori che vorresti assumere sarebbero avere esperienza con quello stack. Altre regioni geografiche hanno profili molto diversi.
  Parla con il tuo cliente e scopri 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 niente Ruby. Forse ha uno sviluppatore fidato che può chiamare per l'emergenza occasionale che è un professionista PHP e un neofita Ruby. Naturalmente, è anche possibile che stia utilizzando metriche scadenti come il numero di annunci di lavoro o riprende che menzionano varie parole chiave.
• I datori di lavoro devono preoccuparsi della sostenibilità a lungo termine delle pile tecnologiche. Anni fa, ad esempio, molte aziende hanno investito molto tempo e fatica nella costruzione di app PowerBuilder (e altre lingue di quel genere). PowerBuilder spesso rendeva molto semplice la creazione di una linea di app aziendali e gli sviluppatori a quel tempo ne erano spesso piuttosto innamorati. Sfortunatamente, la comunità di PowerBuilder è più o meno crollata 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 che richiedevano tempo per migrare quelle app su altri stack tecnologici. I meriti tecnici relativi di PowerBuilder erano vs. Java o C ++ o C # o qualunque cosa essi migrassero a quel punto;
  Lingue relativamente di nicchia come Ruby hanno assolutamente il potenziale per creare questo tipo di problemi ereditari per le aziende che non sono in grado di prevedere se la lingua si esaurirà in pochi anni quando le persone passeranno alla moda successiva o se ha un vero potere di resistenza . Puoi certamente mitigarlo sottolineando che Ruby non dipende da un'azienda o organizzazione, quindi nessuno può decidere che non è più un prodotto strategico per l'azienda. Se il tuo cliente è stato bruciato in passato con applicazioni sviluppate in linguaggi che sono diventati mal di testa, dovrai dimostrare che Ruby è più simile a Linux e ad altre tecnologie open source che prosperano senza una società che le supporta rispetto alle lingue che hanno estinto nel corso degli anni.
• I datori di lavoro desiderano coerenza nell'ambiente, quindi la scelta della lingua per un progetto impone una scelta per molti altri. Anche se Ruby è tecnicamente ideale per il progetto che stai lanciando, devi spiegare perché è appropriato per ogni altra applicazione che questo cliente avrà bisogno di sviluppare o spiegare quale mix di tecnologie ritieni appropriate (es. Ruby per X, qualcos'altro per te). Trattare con tecnologie eterogenee, tuttavia, si traduce inevitabilmente in costi aggiuntivi per l'azienda.

Per cominciare, puoi indirizzare il tuo cliente qui per uno sguardo all'ecosistema che esiste intorno 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 anche grandi aziende come AT&T, SAP e Symantec stanno usando Rails (lo scorso anno hanno reclutato molto in RailsConf).

Puoi sottolineare che un'azienda di traduzioni ha molto da guadagnare utilizzando un linguaggio / framework che rende il supporto Unicode e i18n relativamente indolore.

In definitiva, penso che tu debba vendere l'idea che essere in grado di usare Rails è una caratteristica premium che assume assumendoti: "Naturalmente tutti quegli altri ragazzi stanno usando PHP. Ma hai l'opportunità di avere uno stack moderno che alimenta la tua applicazione ".

Alla fine, deve anche essere chiaro che ciò che sta alla fine acquistando è la tua abilità e competenza; se fosse così ben informato sulle tecnologie web lato server, non avrebbe bisogno di te. La lingua e il quadro sono decisioni di attuazione, non requisiti.

PS Non menzionare Twitter. Stiamo ancora cercando di annullare le cattive PR Rails da questo.

Spiegherei che è fondamentalmente una scelta "Coke" vs. "Pepsi". Entrambi sono ampiamente accettati, entrambi hanno persone che combatteranno e moriranno per ciascuno, ed entrambi sono perfettamente adeguati. Indica i motivi per cui preferisci il RoR.

Sta parlando di persone, stai parlando di una lingua e un quadro. Non sentirà ragioni puramente tecniche, quindi dovresti concentrarti su ciò che le persone stanno facendo con la lingua . Puoi parlare del potere delle persone sotto Rails, di come è più facile per una persona fare più di una persona PHP, più velocemente (se questo è ciò in cui credi). Puoi chiedere se la prevalenza dei conducenti Honda significa che è un'auto migliore di una Rolls Royce, che è raramente vista. Puoi parlare di ciò che la comunità è effettivamente composta, se ci sono troppi cuochi nella zuppa del modulo (gemme contro moduli, ecc.), Se tutti hanno la sindrome NIH e così via.

Indipendentemente da ciò, deve essere in termini di persone perché vuole sapere che può sostituirti. Aiutalo a saperlo, perché (probabilmente) non vorrà comunque allontanarsi. La tua "decisione di un esperto" non ha assolutamente importanza quando dà molta meno attenzione a ciò che una determinata persona conosce. Vuole solo che ci siano "più persone" che conoscono la stessa cosa.

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

Fai notare che la folla di PHP ha più membri perché è la barriera più bassa all'ingresso ed è rimasta in giro più a lungo. Assicurati di sottolineare che le comunità più piccole hanno percentuali più elevate di programmatori che vale la pena assumere, PHP può avere 10.000 buoni programmatori rispetto ai 5.000 programmatori di rotaie, ma i programmatori PHP sono nascosti in un blocco di 100.000 rispetto ai 20.000 dei programmatori di rotaie. (Questi numeri sono inventati, ma ottiene il punto.) Quindi devi spiegare che la community in realtà non ha una preferenza tra PHP e Rails.

Non puoi usare 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 per capire.

Il tuo cliente ti ha assunto, quindi presumibilmente si fida della tua competenza. Spiega che professionisti diversi potrebbero preferire strumenti diversi e il tuo strumento preferito sembra essere RoR. Sottolinea la presenza della comunità e l'accettazione della comunità che esiste per RoR e aziende di successo come 37signals che la usano, per rimuovere la sua preoccupazione che stai raccomandando una tecnologia arcana che nessuno tranne te conosce. Fai notare che sarai più produttivo utilizzando gli strumenti che preferisci (riducendo così i suoi costi e migliorando le sue modifiche in caso di successo) e che se tu o lui dovessi mai trovare più esperti RoR non sarà difficile da fare. Se è più tecnico, puoi sottolineare come RoR può avere successo nelle attività di cui ha bisogno rispetto alla sua soluzione preferita.

Evita di ripetere FUD e in genere denigrare PHP: se non sei un esperto di PHP, c'è un'alta probabilità che dirai qualcosa che non è accurato, sbagliato o altamente controverso, e se il tuo cliente scopre che hai torto che potrebbe ferire la tua credibilità con lui in altri aspetti.

Il tuo capo ha ragione. PHP è molto più popolare della codifica RoR in diversi siti che si sforzano di tenere traccia di tali cose. Ad esempio, vedere http://lang-index.sourceforge.net e http://www.tiobe.com/index.php/content/paperinfo/tpci/index.html >. Penso che sarebbe sciocco ignorare i fatti.

Ti suggerisco di riconoscere che ha un punto e poi ricordargli che anche RoR ha un forte seguito. Non sarebbe male avere alcuni link a siti popolari costruiti con RoR che puoi mostrargli.

Dopotutto, sta davvero cercando la tua certezza che sta prendendo la giusta decisione commerciale e vuole che le prove lo confermino. Come dice il vecchio proverbio "Nessuno ha mai avuto frecce sparate contro di loro per aver raccomandato Microsoft." Lo stesso vale per PHP nello sviluppo web. Dagli fatti concreti e evita le opinioni. Farai bene.

Traduci le tue convinzioni in termini economici quantificabili (se possibile / validi). Il fatto che la sua attività sia specifica per la 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 alle rispettive piattaforme. La loro attività probabilmente durerà più a lungo della tua relazione, vorranno rassicurare che stanno gettando le basi giuste.

IME, ammettere i contro (così come i pro) della tua strategia è più convincente di qualsiasi quantità di evangelizzazione - suggerisce che sei più interessato a risolvere il loro problema che usare il tuo martello preferito.

Il tuo cliente potrebbe avere un punto valido. L'offerta e la domanda influiscono sui prezzi. Se l'offerta di sviluppatori con una particolare competenza nell'area geografica dei clienti è bassa, il prezzo per la manutenzione del software che richiede un set di competenze più raro potrebbe aumentare più nel tempo rispetto a se il software fosse sviluppato utilizzando un linguaggio più popolare per il quale esisteva un numero significativamente maggiore pool locale di sviluppatori esperti. Quindi il problema potrebbe essere anche quello della gestione del rischio a lungo termine.

Quando ho un cliente che desidera utilizzare uno strumento particolare perché è "standard del settore", ha un "consenso" o è "ciò che tutti usano", faccio notare loro che tutti questi termini sono un codice per "media del settore". " Cioè, ciò che la maggior parte delle altre persone nell'area sta facendo. Il business "medio" fallisce. Scegli i tuoi strumenti in base ai requisiti del lavoro, non a quello che fanno gli altri. La presenza di un numero inferiore di programmatori RoR non importa se il sistema non ha bisogno di armeggiare tanto quando ha finito.

Sicuramente questa è una decisione commerciale per entrambi .

Per te le domande sono:

• Quanto mi costerà implementare i requisiti dei miei clienti usando 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 valgono per me i benefici percepiti di PHP su Ruby on Rails?

Se fornisci al tuo cliente un preventivo con un prezzo per l'implementazione utilizzando Ruby on Rails e un altro prezzo per l'implementazione tramite PHP , entrambi basati sulle risposte alle tue domande, il tuo cliente può esprimere il proprio giudizio in merito al fatto che il costo ora vale possibili risparmi futuri.

Questo non è diverso dal fatto che prendano una decisione sul fatto che dovrebbero dare il contratto a te o ad un altro sviluppatore che lo implementerebbe usando PHP come richiesto.

La migliore analogia del mondo reale che posso inventare è "Comprerebbe una Ford piuttosto che una BMW solo perché la quota di mercato della BMW è inferiore?".

In definitiva, i programmatori PHP sono la metà del costo dei programmatori Rails, e cosa faresti se trovassi un lavoro migliore domani? Il tuo capo sarebbe totalmente fregato e si affannasse per trovare uno sviluppatore di Rails, e questo richiede tempo e denaro poiché gli sviluppatori di Rails sono scarsi.

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