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

Abbiamo creato un CRM per un cliente. Ora che la prima fase principale è terminata, e una seconda concordata, il cliente vorrebbe riprendere parte del lavoro, apportando lievi modifiche allo schema del database e ai processi aziendali nella prima fase mentre costruiamo la seconda .

Sono indeciso se questo sia del tutto pratico, ma supponendo che lo sia, vorrei alcuni suggerimenti su quali misure possono essere prese per renderlo del tutto praticabile. Ecco cosa ho finora:

• Fino ad ora, il cliente ha in gran parte visto il progetto dal punto di vista di un utente; chiaramente, dovrebbe svolgersi un seminario in due parti in cui lo presentiamo ai meccanismi interni:

  • in primo luogo, mostrando lo schema del database esistente e, a titolo esemplificativo, estendendolo,
  • quindi, mostrando un codice di esempio e scrivendo un nuovo processo aziendale per il miglioramento dello schema.
• Il codice attualmente risiede in un repository Subversion interno. Mentre potremmo installarne uno o uno pubblico sulla sua rete (a cui possiamo VPN), penso che un sistema distribuito funzionerebbe meglio. Mi sembra di essere l'unico a sentirsi così, tuttavia, in modo da poter usare alcuni buoni argomenti convincenti.

• Non sono sicuro di come imporre / garantire che venga eseguito il commit del codice eseguito in produzione. Sembra che "x abbia apportato un cambiamento critico e senza documenti proprio prima di andare in vacanza; ora stai cercando di capire questo bug che si sta verificando da quando" i disastri sono inevitabili. Idealmente, tutte le modifiche, prima della distribuzione, dovrebbero:

  • essere documentato in un sistema di localizzazione dei problemi,
  • si verificano prima in un ambiente di test separato e
  • passare test automatici.

  Purtroppo, dubito che prevarrà la disciplina per nessuno di questi.

Supponiamo che un'architettura plug-in o un progetto separato non siano opzioni praticabili, perché 1) il primo non esiste e 2) il secondo vieterebbe al client di guardare e eventualmente modificare il codice esistente, un'abilità che credo avrebbe insistere su.

Questa sarà la risposta meno gradita, ma tuttavia eccola qui!

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

Comprendi perché vogliono farlo: non è che hanno risorse di riserva, è solo per farsi sentire sotto controllo.

Quello che devi fare è il seguente:

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

2. Dovresti sempre tornare indietro con le opzioni sui pro / contro sugli approcci (e documentare bene queste riunioni) ma dovresti consentire loro di prendere alcune decisioni. Almeno cominceranno ad apprezzare che non sanno molto o assumeranno la proprietà di se stessi.

3. È possibile creare uno spazio separato, ad esempio i rami in modo che possano essere in grado di codificare ciò che vogliono, le cose devono essere debitamente testate prima di eseguire il commit o l'unione.

Mentre so che potrebbero verificarsi complicazioni, ogni problema è un'opportunità. Se tutto va bene, il tuo cliente otterrà effettivamente maggiore apprezzamento per le questioni interne e svilupperà una fiducia migliore perché sa (come) che hai fatto un buon lavoro!

PS: Per darti un'idea: io vengo dall'India; e conosco molti negozi IT in cui la direzione non ha davvero molti indizi. Di solito a loro non importa (nemmeno sentirsi felici) che il cliente metta risorse aggiuntive per assicurarsi che il progetto non vada nella spazzatura! Questo funziona alla grande per loro; vanno tutti con una mentalità "Qualunque cosa tu dica signore!". Non si tratta di sminuire il mio connazionale, ma di dimostrare che lo sviluppo congiunto non è una cattiva idea. Dopotutto, ciò che molti guru della gestione descrivono è "l' approccio prosumer " ai problemi aziendali.

Ahi ... Hai la giusta idea ma ho visto quanto può essere disordinato, ed entrambe le parti soffrono considerevolmente. Attualmente sto gestendo una simile domanda.

Scopri i veri motivi per cui il cliente ritiene necessario contribuire direttamente al progetto. È ora che vogliono che il progetto sia fatto più velocemente di quanto tu possa realisticamente realizzarlo? Vogliono già modifiche ma hanno paura di incorrere in costi aggiuntivi per apportare modifiche alle specifiche o richiedere funzionalità aggiuntive? Esiste una lotta politica nella loro organizzazione in cui le risorse di sviluppo interno desiderano un maggiore controllo e input nel progetto o sono alla ricerca di un lavoro intenso per gli sviluppatori interni? (quest'ultimo colpisce vicino a casa per me)

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

EDIT: Sfortunatamente 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à. Indipendentemente da ciò, assicurati che il loro sia UNO E UNICO RESPONSABILE DEL PROGETTO e PROPRIETARIO DEL PRODOTTO e che questa persona sia associata alla tua organizzazione / azienda. Questa persona deve avere la capacità di pianificare gli sprint, includere o rimuovere le storie degli utenti e assegnare attività alle risorse della tua azienda e dell'azienda del tuo cliente. Qualunque cosa accada, assicurati che le risorse di sviluppo della tua azienda non funzionino separatamente dalle risorse dei tuoi clienti e, cosa ancora più importante, NONconsentire agli sviluppatori della tua azienda di riferire ai loro project manager o proprietari di prodotti! O trarranno pieno vantaggio dal lavoro gratuito non coperto dal contratto o ti sottrarranno al tuo progetto. È una certezza.

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

Dal punto di vista della programmazione, chiederei ulteriori informazioni: è possibile implementare ciò che il client richiede utilizzando una sorta di sistema EAV definito dall'utente o con hook che possono essere aggiunti al sistema? Idealmente, vorrei mantenere il codice del cliente il più separato possibile dal tuo per vari motivi.

Qualcuno che di solito è nel ruolo del cliente qui interviene. Onestamente non avrei questo problema perché se andasse così lontano saresti nel mio controllo del codice sorgente, usando la mia configurazione CI e la mia configurazione QA per testare le cose. Questa sistemazione può essere piuttosto difficile da configurare: ricevo un sacco di respingimenti dai consulenti, soprattutto per far funzionare le cose. Sembra che il processo abbia delle interferenze con le ore fatturabili.

Penso che la tua prospettiva sia sinceramente un po '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, il negozio IT sul lato client ha una motivazione molto maggiore per assicurarsi che questo prodotto funzioni come progettato ed è facile da mantenere, gestire e supportare in futuro. Immergersi di nuovo per correggere i bug non è ore più fatturabili per noi a differenza della maggior parte dei consulenti. Inoltre, costruire cose per essere facilmente configurabili e fallire in modi prevedibili è molto più importante quando si possiede anche il lato operativo della medaglia. Potresti finire con un progetto di qualità superiore perché parte del personale di sviluppo non è vincolato da orari fatturabili.

Nella misura in cui come farlo funzionare, DCVS è sicuramente la strada da percorrere se può essere fatto accadere. Scegliere qualcosa di neutrale (bitbucket, github) può aiutare. Avere CI in atto è anche una manna dal cielo qui - è più difficile che le cose escano di colpo quando tutti sanno che è uscito di colpo durante l'ultimo commit. Se riesci a forzare l'implementazione delle cose tramite CI, cosa che in genere dobbiamo imporre ai fornitori, puoi davvero assicurarti che tutte le modifiche siano impegnate. Per quanto riguarda la formazione, hai preso in considerazione l'associazione con il cliente per alcuni giorni? Potrebbe essere un buon modo per stabilire i legami laterali di cui avrai bisogno. Nel complesso, la scommessa migliore è convincere tutti quelli che fanno parte della stessa squadra. Perché fanno parte della stessa squadra.

Sembra che questo sia un problema di gestione in quanto è un problema tecnico. Ho affrontato situazioni come questa in società di consulenza e software. Da un punto di vista generale "Quanto valore otterrà il cliente dal software?" e "Di quanti sforzi avrò bisogno per mantenerlo post-produzione?" questa è in realtà una buona situazione per te. Molti clienti insistono sul coinvolgimento delle persone. Ci vorrà molto lavoro però.

A partire dalla fine, avrai bisogno di una buona dichiarazione di lavoro . Questo elencherà ciò per cui sei agganciato e per cosa sono agganciati. Una matrice di ruoli e responsabilità è un documento meno legalistico che descrive chi possiede ciascun oggetto, chi è coinvolto e chi deve solo essere informato. Entrambi presuppongono che tu abbia una struttura di suddivisione del lavoro ben definita che elenchi a un livello basso (abbastanza basso da stimare) quale sia ciascuna attività.

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

Una volta definita chiaramente la proprietà, è tempo 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 utilizzando lo contrassegna, tanto meglio. Vuoi evitare che qualcuno ti blocchi qualcosa che va contro le decisioni architettoniche chiave prese in precedenza. Il concetto di 4 occhi (2 occhi aggiuntivi 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 a gestire i propri ambienti (non dare per scontato che siano bravi in ​​questo), tanto meglio.

Un altro paio di avvertenze ...

1. Non dare per scontato che il cliente abbia la stessa produttività del tuo team. (Otterrai sorprese al rialzo sulla conoscenza del dominio, sorprese al ribasso sulla velocità specifica del tuo software.)

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

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

4. Trascorri un sacco di tempo in formazione e co-localizzazione.

5. Ogni ora dedicata all'insegnamento del cliente per la risoluzione dei problemi farà risparmiare molti giorni in futuro.

6. Utilizza il client per lavorare all'interno della sua organizzazione interna e trova esperti in contenuti e domande sul dominio.

7. Utilizzare il cliente per vendere la propria organizzazione.

8. Per impostazione predefinita, coinvolgere i clienti nel processo di sviluppo ti costringerà a pensare come una società di servizi professionale. David Maister ha scritto il miglior libro sull'argomento. Anche se solo il 20% è pertinente 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 probabilmente i riferimenti futuri. Buona fortuna nel trarre il meglio da questa situazione!

Il tuo cliente dovrebbe assolutamente avere una panoramica di come tutto è impostato, avrebbe dovuto essere un requisito per la firma nella prima fase. Dovresti continuare a consentire al tuo cliente di modificare direttamente qualsiasi cosa, dovrebbe compilare una richiesta di modifica che viene inserita nel tuo sistema di tracciamento dei problemi e prioritaria con il resto del lavoro. Spetterà a te e al tuo cliente decidere quali richieste non rientrano nell'ambito del contratto. Come questo dovrebbe essere progettato in una sorta di flusso di lavoro / documento sulla gestione delle modifiche, se uno non esiste ti consiglio vivamente di crearne uno e convincere il tuo cliente a concordare che questo è il processo attraverso il quale può cambiare le cose e farlo entrare la scrittura. Altrimenti non c'è molto che tu possa fare se non pregare che nulla vada storto.