Qual è il modo migliore per consentire a un cliente di contribuire a un progetto?

Questa sarà la risposta meno preferita - ma tuttavia eccola qui!

È rischioso (tanto quanto permettere a un principiante di guidare una macchina nuova di zecca) - ma non è una cattiva idea.

Understand why they want to do this: it is not that they have spare resources, it is only to make themselves feel under control.

Quello che devi fare è seguire:

1. Educa il tuo cliente: il software è più di un codice. Se vogliono partecipare, faccia in modo che prima esaminino aspetti architettonici, progetti e così via. Solleva le domande e mostra loro le implicazioni delle scelte che fanno un precedente.

2. Dovresti sempre tornare indietro con le opzioni sui pro / contro sugli approcci (e documentare bene questi incontri) ma dovresti consentire loro di prendere qualche decisione. Almeno inizieranno ad apprezzare che non ne sanno molto - o ne assumeranno la proprietà.

3. Puoi creare uno spazio separato, come i rami, in modo che possano essere in grado di codificare ciò che vogliono: le cose dovrebbero essere debitamente testate prima di commettere o unire.

Anche se so che potrebbero accadere complicazioni, ogni problema è un'opportunità. Se tutto va bene, il tuo cliente arriverà effettivamente ad apprezzare maggiormente le questioni interne e svilupperà una fiducia migliore perché sa (come) ha fatto un buon lavoro!

PS: per darti un'idea - vengo dall'India; e conosco moltissimi negozi IT in cui la direzione non ha molto indizio. Di solito non si preoccupano (nemmeno di sentirsi felici) che il cliente mette risorse aggiuntive per garantire che il progetto non vada in pattumiera! Questo funziona alla grande per loro; vanno tutti con una sola mentalità "Qualunque cosa tu dica, signore!". Questo non è per sminuire il mio stesso connazionale, ma mostrare che lo sviluppo congiunto non è una cattiva idea. Dopo tutto, sono molti i guru del management portray è " approccio Prosumer " ai problemi aziendali.

Ahi ... Hai l'idea giusta, ma ho visto quanto può essere disordinato e entrambe le parti soffrono in modo considerevole. Sto mantenendo una tale applicazione al momento.

Scopri i motivi reali perché il cliente ritiene necessario contribuire direttamente al progetto. È che ora vogliono il progetto fatto più velocemente di quanto tu possa realisticamente disattivare? Vogliono già delle modifiche ma hanno paura di incorrere in costi aggiuntivi da parte tua per aver apportato modifiche alle specifiche o richiesto funzionalità aggiuntive? C'è una lotta politica nella loro organizzazione in cui le risorse di sviluppo interno vogliono più controllo e input nel progetto o dove sono alla ricerca di un lavoro intenso per gli sviluppatori interni? (Quest'ultimo colpisce vicino a casa per me)

Scopri quali sono le loro vere motivazioni e affrontale se possibile. Il fatto che lo suggeriscano è un enorme segnale di avvertimento che i problemi stanno arrivando. Cerca di alleviare le loro reali preoccupazioni prima di accettare una cosa del genere, perché molto probabilmente ciò che accadrà è che controlleranno il progetto e ti elimineranno, o provocheranno un caos massiccio e un progetto fallito.

EDIT: Purtroppo quella nave ha navigato per te, ma non disperare ancora. Ci sono ancora cose che puoi fare per ridurre al minimo il dolore che arriverà. Non importa cosa, assicurati che il loro sia UNICO SOLO UN PROJECT MANAGER e PRODUCT OWNER e che questa persona sia associata alla tua organizzazione / azienda. Questa persona deve avere la capacità di pianificare sprint, includere o rimuovere storie di utenti e assegnare compiti alle risorse della propria azienda e dell'azienda del cliente. Qualunque cosa accada, assicurati che le risorse di sviluppo della tua azienda non funzionino separatamente dalle risorse dei tuoi clienti e, ancor più importante, NON consentire agli sviluppatori della tua azienda di segnalare ai loro project manager o proprietari di prodotti! Approfittano del lavoro gratuito non coperto dal contratto o ti snobbano dal tuo progetto. È una certezza.

Da un punto di vista legale, stai praticamente chiedendo "Qual è il modo migliore per guidare un asino bendato attraverso un campo minato?"

Da un punto di vista della programmazione, vorrei chiedere maggiori informazioni - è possibile implementare ciò che il cliente sta chiedendo usando una sorta di sistema EAV definito dall'utente o con ganci che possono essere aggiunti al sistema? Idealmente, vorrei mantenere il codice del cliente separato dal tuo come possibile per vari motivi.

Qualcuno che di solito si trova nel ruolo del cliente interpella. Onestamente non avrei questo problema perché se fosse arrivato così lontano saresti nel mio controllo sorgente, usando la mia configurazione CI e la mia configurazione QA per testare cose. Questa soluzione può essere piuttosto difficile da configurare - ottengo un sacco di respingimento da parte dei consulenti, in particolare per far funzionare le cose. Sembra che il processo abbia intereferenze con le ore fatturabili.

Penso che la tua prospettiva sia abbastanza sinceramente distorta. Innanzitutto, tieni presente che non è la tua base di codice, ma piuttosto la nostra base di codice. Il secondo è che, nella maggior parte dei casi, l'IT shop sul lato client ha una motivazione enormemente maggiore per assicurarsi che questo prodotto funzioni come progettato ed è facile da mantenere, gestire e supportare in futuro. Tornare indietro per correggere i bug è non più ore fatturabili per noi, a differenza della maggior parte dei consulenti. Inoltre, costruire cose facilmente configurabili e fallire in modi prevedibili è molto più importante quando si possiede anche il lato operativo della moneta. Potresti finire con un progetto di qualità superiore perché parte dello staff di sviluppo non è vincolata da ore fatturabili.

Per quanto riguarda il modo in cui farlo funzionare, DCVS è sicuramente la strada da percorrere se può essere fatto succedere. Scegliere qualcosa di neutro (bitbucket, github) può aiutare. Avere CI al suo posto è anche una manna dal cielo - più difficile che le cose vadano fuori di testa quando tutti sanno che è uscito fuori dall'ultimo impegno. Se riesci a forzare le cose a distribuire tramite CI - qualcosa che di solito dobbiamo imporre ai fornitori - puoi davvero assicurarti che tutte le modifiche siano state commesse. Per quanto riguarda la formazione, hai considerato l'accoppiamento con il cliente per alcuni giorni? Questo potrebbe essere un buon modo per stabilire i legami laterali di cui avrai bisogno. Nel complesso, la soluzione migliore è convincere tutti quelli che fanno parte della stessa squadra. Perché sono nella stessa squadra.

Sembra che questo sia un problema molto di gestione in quanto è un problema tecnico. Mi sono occupato di situazioni come questa in entrambe le società di consulenza e software. Da un totale "Quanto valore il cliente otterrà dal software?" e "Quanto impegno avrò bisogno per mantenerlo in post-produzione?" questa è in realtà una buona situazione per te. Molti clienti insistono sul coinvolgimento delle persone. Ci vorrà un sacco di lavoro però.

A partire dalla fine, avrai bisogno di una buona dichiarazione di lavoro . Questo elencherà per cosa sei agganciato e per cosa sono agganciato. Una matrice Ruoli e responsabilità è un documento meno legalistico che descrive chi possiede ogni oggetto, chi è coinvolto e chi ha solo bisogno di essere informato. Entrambi presuppongono che tu abbia una struttura di scomposizione del lavoro ben definita che elenca a un livello basso (abbastanza basso da stimare) ogni compito è

In termini di creazione, di solito è l'ordine inverso: Ambito (che hai già chiaramente) - > WBS (che potresti avere) - > Matrice ruoli e responsabilità - > SOW.

Una volta definita chiaramente la proprietà, è il momento di gestire il codice e gli ambienti. Sono abbastanza agnostico sugli strumenti di gestione del codice. Quello che dirò è che è fondamentale fare una revisione del codice per tutto ciò che viene fatto da qualcuno al di fuori del core team. Se lo strumento che stai usando lo segnala, tanto meglio. Volete evitare che qualcuno aggrappi qualcosa che vada contro le decisioni architettoniche chiave precedentemente fatte. Il concetto di 4 occhi (2 occhi supplementari che esaminano tutto) è la singola decisione tattica più importante che puoi prendere.

Anche gli ambienti sono dolorosi da gestire. Di solito ho sperimentato situazioni in cui "Facciamo il nostro lavoro sul nostro ambiente, quando abbiamo finito va al tuo" e sia il venditore che il cliente lottano. La tua situazione sembra più complessa. Consiglierei di provare a trovare un modo per farli lavorare nel tuo ambiente fino al termine del progetto. Se riesci a trovare un modo per addestrare il cliente nella gestione dei suoi ambienti (non dare per scontato che siano bravi in questo), allora tanto meglio.

Un paio di altri avvertimenti ...

1. Non presumere che il cliente abbia la stessa produttività del tuo team. (Avrai delle sorprese al rialzo sulla conoscenza del dominio, verso il basso sorprese sulla velocità specifica del tuo software.)

2. Non dare per scontato che il client conosca la tua metodologia.

3. Non dare per scontato che il cliente condivida il lavoro del tuo team. (Ho visto sorprese sia verso l'alto che verso il basso.)

4. Dedica molto tempo alla formazione e alla co-locazione.

5. Ogni ora trascorsa insegnando al client a risolvere i problemi salverà molti giorni in futuro.

6. Utilizza il client per lavorare attraverso la loro organizzazione interna e trovare esperti in contenuti e domini.

7. Utilizza il cliente per vendere il treno alla loro organizzazione.

8. Di default, coinvolgere i clienti nel tuo processo di sviluppo ti costringerà a pensare come una società di servizi professionale. David Maister ha scritto il migliore libro sull'argomento. Anche se solo il 20% è rilevante per te, vale la pena leggerlo.

Nonostante tutti questi avvertimenti, anche i clienti dei tuoi team possono fare miracoli per avvicinarti ai tuoi acquirenti. Questi client sono quelli che più probabilmente saranno riferimenti futuri. Buona fortuna per sfruttare al meglio questa situazione!

Il tuo cliente dovrebbe sicuramente avere una panoramica di come è stato impostato tutto, avrebbe dovuto essere un requisito per l'accesso nella prima fase. Dovresti tornare indietro e permettere al tuo cliente di modificare qualsiasi cosa direttamente, dovrebbe compilare una richiesta di modifica che viene inserita nel tuo sistema di tracciamento dei problemi e dare la priorità al resto del lavoro. Spetterà a te e al tuo cliente decidere quali richieste non rientrano nell'ambito del contratto. Come dovrebbe accadere ciò dovrebbe essere progettato in una sorta di flusso di lavoro / documento di gestione delle modifiche, se non ne esiste uno consiglio vivamente di crearne uno e di convincere il cliente a convenire che questo è il processo attraverso il quale può cambiare le cose, e ottenere questo in la scrittura. Altrimenti non c'è molto che puoi fare se non pregare che nulla vada storto.