Un prodotto guidato dagli sviluppatori è una buona cosa?

Lavoro in un'azienda in cui l'amministratore delegato gestisce il team del prodotto, che simula le funzionalità e lascia cadere in grembo gli sviluppatori per poi implementare tali funzionalità. Esistono ovviamente alcune iterazioni, le opinioni degli sviluppatori sono rispettate. Ma mi chiedo quanto sia efficace questo processo.

Jason Calacanis ha appena scritto :

La dottrina di Zuckerberg: gli sviluppatori progettano prodotti con velocità e funzionalità notevolmente migliorate rispetto ai responsabili e ai progettisti del prodotto, superando potenziali errori e svantaggi.

...

Poi mi ha davvero colpito: le startup guidate dagli sviluppatori producono sempre prodotti più velocemente.

Questo è ovvio: il nostro personale non tecnico sta discutendo e dibattendo mentre Zuckerberg sta programmando il suo prossimo film. Ecco perché nessuno è stato in grado di tenere il passo con Facebook!

Mentre MySpacers ha discusso su come iterare il proprio prodotto, Facebook ha semplicemente provato cose.

Funziona davvero meglio in pratica?

I prodotti dovrebbero essere guidati dal cliente.

Se i tuoi clienti sono sviluppatori di software e utilizzi il tuo prodotto (cosa che dovresti, in ogni caso), suppongo che tu possa essere il tuo miglior cliente.

Ma come sviluppatore, la tua prospettiva è già compromessa da ciò che accade sotto il cofano. È necessario che il cliente ti dica che ciò che stai facendo con l'interfaccia utente o il flusso di lavoro dell'applicazione è sciocco e non ha alcun senso.

Come sviluppatore, devi conoscere le domande giuste da porre agli stakeholder in modo da poter combinare la tua esperienza con i loro desideri per produrre il miglior prodotto possibile.

Come sviluppatore, mi piacerebbe pensare che facciamo un lavoro migliore rispetto a manager e designer. Ma non penso che tu possa generalizzare.

Uno dei problemi con gli sviluppatori che eseguono la progettazione è che potrebbero non essere in contatto con le esigenze degli utenti finali e potrebbero non essere bravi a porre alle persone giuste le domande giuste. Un manager, e in particolare un buon designer, potrebbe essere più bravo a capirlo.

Tuttavia, penso che la cosa più convincente non siano le persone ma il modo in cui si avvicinano per affrontare il problema. L'approccio che funziona è scendere e implementare le cose, piuttosto che passare interminabili riunioni e abbattere alberi per trovare il design "ideale". È davvero la rivisitazione di Agile contro Waterfall.

(Dovrebbe essere chiaro che Facebook è un esempio di come NON fare anche le cose. Ad esempio, il loro approccio sprezzante ai problemi di privacy sta iniziando a metterli in difficoltà legali ...)

IMHO, direi che hai parzialmente ragione. Sembra ragionevole. Tuttavia, ciò potrebbe non essere applicabile a tutti i prodotti / software. Quindi, lo direi così. Un designer dovrebbe essere una persona con una vasta esperienza di sviluppo sotto la sua cintura E non solo: la persona dovrebbe ancora essere programmatore e non solo progettare.

Risposta breve: a volte.

Risposta lunga: lo sviluppo orientato al cliente funziona se sai chi sono i tuoi clienti e sanno cosa vogliono.

Lo sviluppo guidato dagli sviluppatori ha valore per le persone che non si rendono conto che lo troveranno ancora utile. In altre parole, a volte i clienti non possono sempre sapere cosa vogliono. I nuovi requisiti possono derivare da un'esperienza esistente di carenza di un prodotto esistente. Non c'erano clienti per Facebook, Zuckerberg ha creato un prodotto, una risposta prima della domanda. Ora stabilito, Facebook è influenzato dai suoi clienti, ma prima di essere creato e durante la creazione, era un'idea guidata dagli sviluppatori.

Lo sviluppo orientato al cliente è ideale per prodotti consolidati, forse maturi, che fanno soldi o nuove iterazioni del prodotto nello stesso mercato, dove ignorare i desideri del cliente sarebbe altamente dannoso per i flussi di reddito futuri.

Lo sviluppo guidato dagli sviluppatori è un'attività a margine, prototipazione, che rientra nell'arena del 20% di Google, in base alla quale i loro sviluppatori spendono il 20% del loro tempo di lavoro per i propri progetti.

Per progettare un buon prodotto, sono necessarie molte conoscenze sul dominio problematico. Un prodotto per il pubblico come Facebook può essere guidato dagli sviluppatori, perché risolve anche un problema che gli sviluppatori hanno: come connettersi e rimanere in contatto con gli amici, ecc. Lo stesso è ancora più vero per i prodotti destinati agli sviluppatori di software: gli sviluppatori sanno cosa un IDE dovrebbe fare e come.

Ma per molti altri domini problematici, gli sviluppatori spesso non ne sanno abbastanza. Anche con una visione generale e una certa esperienza, che spesso tendono a implementare fredde caratteristiche o funzioni che sono facili da implementare, ma non aggiungono molto valore per il cliente e rendono il prodotto più complesso. Questi sono casi in cui i prodotti dovrebbero essere guidati da esperti del dominio.

Penso che questo sia chiaramente l'approccio migliore a un prodotto orientato agli sviluppatori (come AWS o Visual Studio), ma non sono sicuro che sia chiaramente l'approccio migliore in generale. Voglio dire, di solito vedo accadere le cose al contrario: gli sviluppatori sono in giro a discutere l'approccio migliore mentre le persone non tecniche prendono rapidamente decisioni. Personalmente, sono propenso a dire che la risposta corretta è da qualche parte nel mezzo. Dovrebbe esserci un product manager con la capacità di impostare un'ampia direzione che gli sviluppatori quindi implementano.

Nella maggior parte dei casi, il software guidato dagli sviluppatori potrebbe essere migliore del software gestito dal gestore. Il gestore vede il massimo valore nelle funzioni (per lo più funzioni di moda) che si adattano bene a un annuncio o possono essere utilizzate in un discorso. Gli sviluppatori vedono valori diversi: prestazioni, minori bug, design snello, manutenibilità. Ciò porta quasi quasi a un software migliore.

Ma il migliore sarebbe un software guidato dall'utente. Gli utenti sanno davvero di cosa hanno bisogno, cosa li aiuta a fare il loro vero lavoro. Sarebbe l'ideale.

Cosa succede se produci prodotti più velocemente che nessuno vuole usare?

Concentrarsi su un singolo attributo (funzionalità, time to market, prezzo, qualità, ecc.) Può avere senso per un certo momento. Ad esempio, Apple ha fatto precipitare l'iPhone e l'iPad fuori dalla porta. La qualità ha sofferto un po ', ma era abbastanza importante essere i primi.

Penso che ti faccia male, se ti concentri su un aspetto solo a lungo termine.

NO, a meno che non risolva un problema del mondo reale

• I programmatori di solito amano risolvere i problemi, a volte a problemi che non esistono ancora :)
• I programmatori di solito fanno una terribile GUI, perché è un pensiero secondario
• La maggior parte dei problemi degli utenti non sono gli stessi dei problemi del programmatore .
• Pertanto, il prodotto programmato sarà di solito buono per altri programmatori, ma non così buono per gli utenti.

Anche una nota sul face-book:

Il successo dei face-book non ha nulla a che fare con i suoi meriti tecnici, è più un'idea piggy back che è appena diventata molto grande e piena di neve. Face-book e altri accadono solo una volta in una "Google Blue Moon".

Tuttavia:

• Se un programmatore ha un vero problema "utente", che non è un problema del programmatore. Quindi è probabile che sia un'ottima cosa. Se lo stakeholder è anche lo sviluppatore che in relazione al problema è una situazione ideale per una grande soluzione di prodotto.

(Oh cavolo ... dove ho appena letto qualcosa del tipo "Ho una grande idea! Tutto ciò di cui ho bisogno è uno sviluppatore." Era tra una settimana penso. Comunque ...)

Le grandi idee sono una decina. L'implementazione della cosa è ciò che conta. Se lo sviluppatore è quello con la grande idea, può semplicemente implementarlo.