Quanto dovrebbero gli sviluppatori interagire con i clienti? [chiuso]

Personalmente non avrei lavorato in nessun posto che non avessi l'opportunità di contattare direttamente il cliente. Cercare di risolvere un problema con i requisiti quando si devono attraversare strati di PM e BA è doloroso e il messaggio non arriva mai chiaramente. Desidero questo accesso per migliorare il prodotto in modo che rifletta effettivamente le esigenze dei clienti e non l'interpretazione di tali esigenze da parte di qualcuno che non conosce le domande giuste da porre.

Potrebbe essere rilevante nella mia risposta che io faccia lavoro su ETL di database e spesso una conversazione di 5-10 minuti con la persona IT del cliente può risolvere un problema di vecchia data con le importazioni o le esportazioni. A volte il personale IT deve parlare con il personale IT. Questo è particolarmente vero se si tratta di un'importazione delta o di uno che va in due modi. Devo capire la struttura del database e le esigenze, nonché le esigenze del mio database. Direttamente parlando è l'unico modo per ottenere queste informazioni.

Tuttavia, non desidero che al client vengano regolarmente dati email e telefono, poiché alcuni di loro chiameranno direttamente quando non dovrebbero. Ho solo bisogno di parlare con loro quando c'è un problema che non possiamo risolvere in nessun altro modo. E devi essere in grado di impostare i limiti in modo che non provino a sfruttare l'accesso per ottenere lavoro da te per il quale non stanno pagando. Faccio sempre riferimento a nuove richieste al di fuori dei limiti del problema che dovremmo discutere con le vendite.

Anche se parlo direttamente con il cliente, raramente, se non mai, vedo un'ulteriore opportunità di vendita, il mio cervello non funziona in questo modo.

Credo che ci debbano essere alcuni punti fissi di contatto con il cliente. Nella gestione tradizionale del progetto, questa persona è il project manager. In Scrum, chiameresti questa persona il Product Owner. In Extreme Programming, è il rappresentante del cliente. Nota che in Scrum e XP, nulla dice che questa persona deve provenire dall'organizzazione del cliente, ma deve solo ricevere la voce del cliente quando arriva il momento di prendere decisioni.

Per me, la più grande preoccupazione è il numero di percorsi di comunicazione . Il numero di percorsi di comunicazione nel team di progetto è definito come (N × (N-1)) / 2 dove N è il numero di persone nel team di progetto. Se tutti i membri del team hanno accesso alla comunicazione al cliente o al cliente, N aumenta del numero di contatti all'interno dell'organizzazione del cliente, aumentando notevolmente i percorsi di comunicazione. Diventa quasi impossibile sapere chi sa quali informazioni, chi ha detto cosa quando e mantenere tutte le comunicazioni organizzate.

La mia seconda preoccupazione principale per la comunicazione libera tra il team di sviluppo e il cliente è tenere traccia di chi sta dicendo cosa in termini dell'attuale stato di salute e stato del progetto, delle stime di riunione in base a pianificazione e budget e così via. Avere un punto di contatto primario garantisce che tutti al di fuori dell'organizzazione di sviluppo sappiano esattamente cosa sta succedendo al livello appropriato di granularità e garantisce che ogni membro del team disponga di tutto ciò di cui ha bisogno per eseguire i compiti assegnati a loro.

My manager, and old-school mainframe guy, contends that developers should never ever have ANY client contact. That all interaction with the client should be mitigated by a Project Management layer. He asserts that this allows a coder the focus they need in order to CODE, and protects the business's relationship with the client from the autism-spectrum tendencies of Joe Average Code Monkey.

Sono d'accordo con il tuo manager, per la maggior parte. I tuoi sviluppatori sono lì per lo sviluppo e i tuoi tester sono lì per testare. Ciò significa che uno dei tuoi sviluppatori non può essere un contatto con il cliente, un proprietario del prodotto o un rappresentante del cliente? Assolutamente no. In effetti, potrebbe essere utile avere qualcuno con un background tecnico coinvolto nell'interagire con il cliente, specialmente quando si tratta di ingegneria dei requisiti, discussioni di fattibilità e pianificazione (dopo tutto, gli ingegneri sono i migliori nella pianificazione delle attività di ingegneria). / p>

Affermare che il tuo cliente ha bisogno di essere protetto dai tuoi sviluppatori è sbagliato, e forse anche offensivo. I tuoi ingegneri dovrebbero avere le conoscenze e le competenze necessarie per interagire con i clienti (e tutte le parti interessate a un progetto). È solo che non dovrebbero essere tutti chiamati a farlo.

His boss, the owner of the company, told him this morning that every single person in the company needs to think of themselves as an extension of the sales department, and needs to be listening all the time for upsell opportunities. To this end, he thinks clients ought to have more or less full access to developers directly, in part so that devs have the opportunity to hear sales opportunities.

Il proprietario è assolutamente sbagliato. Le persone senza formazione commerciale o di marketing o formazione non dovrebbero fare il lavoro di quei dipartimenti. Potrebbero essere necessari gli ingegneri per interagire con le vendite e il marketing? Assolutamente si. Ma non è il loro lavoro vendere software, è il loro lavoro costruire un software che soddisfi i requisiti delle parti interessate. Se tutti i tuoi sviluppatori sono impegnati a vendere e commercializzare il software, chi lo sta progettando, costruendo e testandolo?

Posso essere d'accordo in una misura in cui non sono completamente protetto dal cliente, ma gli sviluppatori non dovrebbero essere il chiaro di luna come il dannato personale di vendita.

Uno sviluppatore è proprio questo, qualcuno come sviluppa il prodotto finale. Incontrare il cliente un paio di volte è una buona cosa in quanto consente alle due parti di eliminare qualsiasi potenziale problema derivante dallo sviluppo di particolari elementi. Il cliente sarebbe in grado di esprimere direttamente ciò che desidera e gli sviluppatori potrebbero esprimere ciò che è possibile in un intervallo di tempo.

Dove questo può andare storto è un contatto costante. Immagina che il tuo cliente sia il tipo di persona che cambia idea ogni altro giorno. Ora immagina che il cliente invii email al team di sviluppo a giorni alterni con il loro cambiamento di piani e in che modo ciò potrebbe provocare lo sviluppo del prodotto. Costringere il cliente a passare attraverso più "canali appropriati" per discutere dei cambiamenti nel prodotto consente agli sviluppatori di concentrarsi sulla finitura del prodotto e modificare solo le cose se ne sorge la necessità.

La mia sensazione è che gli sviluppatori non debbano interagire direttamente con i clienti, ma piuttosto attraverso la gestione quando ricevono lavoro o feedback o un reparto di supporto clienti quando ottengono problemi di supporto. Gli sviluppatori dovrebbero ottenere attività attuabili e non dovrebbero cercare di capire cosa desiderano / bisogno i clienti attraverso il contatto diretto (ad esempio corrispondenza e-mail). Questo dovrebbe essere lasciato alla direzione o ad altri reparti, come ad esempio un reparto vendite, in modo che possano gestire la direzione in cui il software sta andando e capire dove si adattano i desideri / le esigenze dei clienti.

Il tuo PM ha ragione. Una volta che il tuo cliente ha il Dev's Direct #, il Dev sarà sommerso da chiamate di supporto.

Il PM dovrebbe essere abbastanza tecnico da poter agire come una persona senza diventare un ostacolo.

Il seguente messaggio deve essere urlato dai tetti .. quindi ecco qui:

QUESTO È IL LAVORO DEL PM !!! ASSICURARSI CHE GLI SVILUPPATORI HANNO TUTTO QUELLO CHE DEVONO FARE QUI PER LAVORO, E PER ASSICURARE CHE POSSONO LAVORARE SENZA INTERRUZIONE COSTANTE! IL PM FUNZIONA PER I DEV !!! QUALSIASI PMS CHE PENSA I DISEGNI FUNZIONA PER LUI È SBAGLIATO E NON MANIPOLAGNA IL PROGETTO!

Penso che sia generalmente meglio avere un PM come buffer. Quando non c'è stato, ho notato quanto segue:

• lo sviluppatore viene travolto dalla forma non organizzata e non pensata che i requisiti arrivano quando sono direttamente dal client. I Good PM fanno una quantità incredibile di lavoro affinando le idee originali del cliente prima di consegnarlo allo sviluppo. Pochi sviluppatori hanno tempo per fare questo e in effetti costruiscono il prodotto.

• lo sviluppatore è offeso dal client, perché non è soddisfatto con alcuni componenti. Il cliente è offeso dallo sviluppatore perché lo sviluppatore sembra ignorare i propri bisogni. I PM forniscono un canale di comunicazione obiettivo tra le due parti che è meno probabile che si riscaldi sotto pressione.

Affinché le cose funzionino, tuttavia, devono essere presenti i seguenti fattori:

• Il project manager deve essere valido. Devono avere la capacità di essere un sacco da boxe per tutti. I clienti si sentono frustrati con gli sviluppatori, i tester diventano frustrati con gli analisti di business e gli sviluppatori si sentono frustrati con quasi tutti :). Il PM deve essere lì per ascoltare tutti i lati e cercare di mantenere tutti felici e produttivi.

• Gli sviluppatori devono essere disposti ad affrontare rigorose iterazioni di test. Dal momento che non ci sarà un contatto diretto con il cliente e nessun PM è perfetto nel trasmettere i requisiti, il cliente e i tester devono vedere quante più iterazioni possibili nel corso del processo, per verificare continuamente che lo sviluppatore stia interpretando correttamente le specifiche. IMHO, gli sviluppatori che amano sedersi sul loro codice fino alla fine del progetto, solo facendo domande sui requisiti, ma non rilasciando effettivamente i deliverable di frequente, non andranno bene con questo tipo di struttura. Non è colpa loro, ma penso che gli sviluppatori con questo tipo di stile abbiano davvero bisogno di interagire con il cliente più direttamente per creare un ciclo di feedback migliore.

Alcuni sviluppatori odiano la struttura del buffer PM, ma sono giunto ad amarlo. Avere qualcuno nel bel mezzo di un progetto che è responsabile per i requisiti è un vero toccasana. Chi altro sarebbe responsabile? Non ci si può aspettare che il cliente descriva ciò che vuole con i dettagli richiesti, e non si può comunque attribuire molta responsabilità alla persona con l'assegno. Lo sviluppatore potrebbe essere ritenuto responsabile, ma in genere ne ha già abbastanza sul piatto senza dover interpretare le ramificazioni criptiche dei BA. Un buon PM che respinge tutto il calore del client rende IMHO il compito di uno sviluppatore molto meno stressante.

Sembra che il tuo PM sia un fan del processo a cascata mentre sei più nel campo di sviluppo "agile".

Non sono sicuro che ci sia un lato giusto e uno sbagliato qui, ma mi piace decisamente il lato "agile". Parlo con gli utenti almeno una volta alla settimana, guarda cosa stanno facendo, ascolta i loro problemi. Se è qualcosa che il reparto servizi può gestire, glielo dirò, ma spesso vedo un problema di usabilità reale o una caratteristica mancante che probabilmente non mi avrebbe mai raggiunto se la comunicazione fosse passata attraverso più filtri di servizio / vendita / gestione del progetto.

Ho lavorato in aziende in cui gli sviluppatori erano protetti dai clienti. Il risultato è stato che gli sviluppatori hanno consegnato un software che soddisfaceva le lettere dei contratti, ma non era sempre utile. Peggio ancora, gli sviluppatori erano orgogliosi di cose che non avevano alcun valore commerciale. (Chi ha bisogno di una grande navigazione da tastiera su un sistema con touchscreen e senza tastiera? Chi ha bisogno di funzionalità di scripting, se gli utenti del software non hanno lo o in background o la necessità di utilizzare lo scripting?) Gli obiettivi impliciti e non scritti del team di sviluppo non sono mai stati "sincronizzati" con ciò di cui gli utenti avevano effettivamente bisogno. E a meno che i tuoi "sviluppatori" non siano solo delle scimmie di codice che non sono autorizzati a prendere decisioni, questo porta a un tempo sprecato per gli sviluppatori.

My manager, and old-school mainframe guy, contends that developers should never ever have ANY client contact. That all interaction with the client should be mitigated by a Project Management layer. He asserts that this allows a coder the focus they need in order to CODE, and protects the business's relationship with the client from the autism-spectrum tendencies of Joe Average Code Monkey. (My words, not his.)

Il fatto che egli detenga questa opinione non è perché è il mainframe della vecchia scuola, e i tuoi commenti sui tuoi colleghi programmatori mancano di rispetto a mio avviso.

Detto questo, ci sono varie scuole di pensiero in termini di gestione del servizio riguardo a chi dovrebbe occuparsi degli utenti / livelli aziendali e non dipendono necessariamente dalla cultura da cui proviene la tua gestione, ma ciò che era di moda l'ultima volta hai avuto consulenti d'affari.

La posizione del tuo proprietario è insostenibile perché quasi certamente causerà un serio screep del campo del progetto, più permetterai agli sviluppatori di vendere funzionalità agli utenti senza passare attraverso una sorta di processo di assegnazione delle priorità. Non sono davvero a favore. Quello di cui probabilmente hai bisogno è un po 'di livello - non necessariamente il project manager - ma come un account manager aziendale che puoi suggerire caratteristiche che possono essere vendute ai tuoi utenti o clienti se sono pratici, e qualcuno a cui puoi anche andare a se hai bisogno di input dagli utenti.

Il lead engineer dovrebbe tipicamente interagire con i clienti solo durante riunioni altamente tecniche (o le parti degli incontri che sono altamente tecniche); o, per le discussioni tecniche sulla roadmap. Per ingegnere capo, questo significa il miglior ingegnere del team, non l'ingegnere capo per progetti particolari.

Il PM non è sempre responsabile della conoscenza di tutti gli ultimi acronimi e decisioni architettoniche. Il PM (e il tuo manager) potrebbero rimanere indietro di una o più generazioni di tecnologia. È qui che l'ingegnere capo deve colmare il divario.

Ci sono ruoli nell'IT che dovrebbero essere utilizzati e rispettati. Ogni ruolo ha 0, 1 o più motivi di contatto con il cliente.

Il motivo del contatto deve essere definito dal PM.

I ruoli corretti come Analista dei sistemi, Analista dei requisiti e Analista aziendale devono essere assegnati ai membri del team competenti sotto la supervisione del PM.

L'interazione con il cliente non è un'abilità banale. Sia la Skill che la politica del progetto dovrebbero essere definite dal PM.

I plus che vuoi incoraggiare sono:

• Relazione positiva tra IT e azienda
• Fonte di requisiti singola o molto limitata
• Raccolta dei requisiti accurata

Cose che non vuoi che succedano:

• Fare promesse al cliente al di fuori del piano / della politica del progetto
• Rifiuta i requisiti del cliente che possono essere consegnati
• Perdere traccia di chi ha promesso cosa
• Requisiti di documentazione inadeguati
• Rendere l'IT come se non parlassero tra loro
• Rendere il cliente privo di fiducia nell'IT
• Troppe e-mail che vanno avanti e indietro senza integrazione

Quindi, per rispondere alla domanda, gli sviluppatori designati possono interagire con il cliente nei ruoli definiti dal PM e solo nelle istanze specificate dal PM (ad esempio prototipazione e test congiunto).

Spero di aver chiarito il mio punto di vista ...

Ho visto casi in cui uno sviluppatore ha interagito con un cliente e ha avuto risultati disastrosi. Dipende anche dalla personalità dello sviluppatore, alcuni possono essere gradevoli e pieni di tatto mentre altri possono guidare il cliente fino alle lacrime, dove i contratti vengono annullati di conseguenza.

Il PM / Project Owner è il raggio sul volante e se i cambiamenti si verificano senza la sua conoscenza si tradurrà in tempo, costi e oscillazioni del cigno.