Rifiutare di rilasciare software fino a quando non si crede che funzioni è un segno di competenza , non incompetenza. Ciò è particolarmente vero per il software mission-critical utilizzato per la cura del paziente. Passa il "e se fosse mia madre?" criterio o no?

Quasi tutto il software contiene difetti, anche cose di lunga durata e ampiamente distribuite. Un esempio ovvio è il recente difetto Heartbleed in OpenSSL. La misura della tua organizzazione ingegneristica non è l'assenza di difetti. È come li gestisci.

Questo è il tuo primo grande punto decisionale "vai / no-go" come nuovo PM e stai sostenendo il "no-go". Quello puzza. Il mio cuore sanguina per te (gioco di parole). Faccio software dal 1974 e ricordo ancora ogni volta che dovevo sostenere il "no-go". È uno dei compiti più difficili del settore. Ma è necessario. Quasi ogni famigerato disastro nel software può essere ricondotto a tale decisione presa male.

Non insegnano questo a scuola.

Ho alcuni suggerimenti concreti per le tue conversazioni con i tuoi clienti su questo argomento.

1. Utilizza la parola formale difetto anziché bug .

2. Spiega che il processo di test del software pre-rilascio ha rivelato alcuni difetti critici. Di 'al cliente quanti. Se te lo chiede, rivelare cosa sono.

3. Di 'che credi che il software non sia adatto per l'uso in produzione fino a quando quei difetti non saranno corretti. Spiegare le conseguenze dell'utilizzo del software senza correggere i difetti. Ad esempio, "il software a volte si arresta in modo anomalo", "in determinate circostanze il software indicherà un dosaggio del farmaco errato" o "il software potrebbe assegnare in modo errato input alla cartella del paziente sbagliato" o anche "Alcuni messaggi di errore non sono corretti , e gli utenti saranno confusi "Sii chiaro e dettagliato sui difetti e sulle loro conseguenze. La trasparenza è tutto.

4. Divulgare il piano e la pianificazione per correggere i difetti e ripetere il test .

5. Concludere dicendo: "Penso che dovremmo correggere questi difetti prima di andare in diretta, e tu sei il cliente. Cosa ne pensi?"

Invita il tuo collega che ha suggerito la scusa della "versione demo" debole a testimoniare queste conversazioni e a parteciparvi se appropriato.

Infine, sii molto felice che tu, e non il tuo cliente, abbia riscontrato questi difetti. L'individuazione dei problemi prima del cliente è un'altra misura della competenza.

Meglio dire che è la versione demo, perché è quello che serve solo per, se vuoi davvero perdere la fiducia del cliente, consegna il prodotto così com'è, lascia che il cliente scopra i bug nel modo più duro e mettere a rischio alcune vite. Ti dirò che sarebbe estremamente poco alla moda e se fossi negli Stati Uniti, esporresti il ​​tuo datore di lavoro a una causa importante se accadesse qualcosa di tragico e può essere fatto risalire al tuo prodotto.

Maggiore le aziende di software come Microsoft saltano regolarmente le date di spedizione. Microsoft probabilmente ha riacquistato molta credibilità nel corso degli anni per aver spedito prodotti affidabili in ritardo rispetto alla spedizione precedente di prodotti difettosi. Sono abbastanza sicuro che non sei l'unico PM anche nella tua azienda che ha dovuto affrontare questa situazione. Sì, leggi le risposte al tuo post ma consulta anche i PM più esperti su come hanno gestito una situazione del genere, perché potrebbe esserci una politica o una sorta di consenso in atto su come gestire una situazione del genere.

Non dovresti incolpare te stesso per il codice che si è rotto. Non hai scritto il codice in primo luogo. Invece, dovresti chiederti come questi bug sono sfuggiti agli sviluppatori. Sono stati test inadeguati? Gli sviluppatori sapevano dei bug ma non te l'hanno detto? In qualità di PM, sei totalmente dipendente dal fatto che gli sviluppatori siano sinceri con te. Ed essendo pienamente competente. Alla fine, dovrai andare in fondo a come si verificano questi fallimenti. Questo è il tuo lavoro.

Ti suggerisco di dire al cliente che hai qualche inconveniente con il software, che questi inconvenienti sono stati dell'ultimo minuto e che stai chiedendo ai tuoi dipendenti di risolverli, stai anche chiedendo loro di pulire accuratamente il software per qualsiasi altro problemi. Si potrebbe dire che stavamo pianificando la versione beta, ovvero pronta per il client del software, ma a causa di questi intoppi appena scoperti, la versione rimane alla versione alpha, cioè interna per ora. Il fatto è che alcuni bug compaiono solo quando l'intera app viene messa insieme o solo quando alcuni moduli interagiscono con altri. Fornisci loro una data di consegna rivista, ma avvisali che, sebbene tu sia sicuro che sarà soddisfatta, l'affidabilità del software viene prima di tutto.

È un evento sfortunato, ma avrebbe un rivestimento positivo se prendessi l'evento come un'opportunità per guadagnare e mantenere la fiducia del cliente essendo disponibile e non temendo di fornire cattive notizie e con la tua risolutezza , attenzione senza compromessi sull'affidabilità. E sì, se ti chiedono chi è responsabile di questo, devia la loro domanda dicendo qualcos'altro, come "Io sono il Primo Ministro. Sono responsabile. Mi assumo la responsabilità di tutta questa faccenda". Si spera che ti piaccia ancora di più per questo. In pratica, quello che vuoi comunicare loro è che qualcosa è andato storto ma il progetto rimane in buone mani.

Commento di follow-up di @JoeStrazzere "Puoi anche condividere l'elenco dei bug con il cliente e coinvolgerlo nella decisione sulla demo rispetto alla produzione. Alcuni bug hanno soluzioni alternative, altri no."

Non vedo come la storia della "versione demo" ti faccia sembrare migliore. In ogni caso, si aspettano che determinate funzionalità vengano fornite in un determinato momento e non la riceveranno.

Mettiti nei panni del cliente: come ti sentiresti se ti aspettassi un prodotto finito, e invece hai ottenuto "Oh, sì, è completamente finito, giusto in tempo! È solo la versione demo, quindi non puoi effettivamente usarla. Ma è finita!" Non saresti solo deluso, saresti sconcertato e arrabbiato. Ti sentiresti come se lo sviluppatore non capisse i requisiti o stesse cercando di darti la possibilità.

Ti rispetteranno di più se sarai onesto e diretto. Concentrati su ciò che deve essere fatto per completare il progetto e su come il cliente può aiutare.

Interagisci con il tuo cliente. Dì loro il vero stato del tuo software e lavora per correggere i bug. Therac-25 Accidents è un'ottima lezione da cui imparare.

Tali azioni ti farebbero risaltare e, cosa più importante, costruirebbero un rapporto di fiducia con il tuo cliente.

Sarei molto meno fiducioso in un prodotto software che mi è stato fornito come demo sulla scadenza di un project manager che mi ha detto in anticipo di aver trovato alcuni bug dell'ultimo minuto e che devono risolverli prima della spedizione. Le vite dipendono da questo software, non puoi permetterti di sbagliare.

In qualità di project manager è tuo dovere comunicare al cliente il problema, la soluzione proposta e il programma rivisto. Devi dirglielo ora, il prima possibile, non aspettare fino alla scadenza per dire loro che non stai consegnando in tempo.

Essere un project manager significa saper gestire le aspettative dei clienti e l'unico modo per farlo è dire loro la verità anche quando non è una notizia felice. Devi avere la capacità di affrontare le cattive notizie se vuoi continuare come project manager.

Ogni volta che ho visto un PM cercare di cavarsela senza mai dire la cattiva notizia e sperando che se ne vada (Gestione tramite pio desiderio) è stato licenziato perché la verità alla fine viene fuori ei clienti no come essere mentito.

Ricordo una volta in cui gli sviluppatori dissero al PM che la scadenza non era raggiungibile (e stavamo già facendo gli straordinari) e avremmo mancato la scadenza di almeno un mese. Ha aspettato per informare il cliente fino al giorno della scadenza e abbiamo perso un cliente multimilionario perché "Come hai potuto non sapere che ci sarebbero volute altre 4 settimane prima di oggi?" La verità era che lo sapevamo settimane prima del tempo, ma il Primo Ministro era un codardo e non glielo disse, quindi perse il cliente e il suo lavoro. Questo è ciò che probabilmente ti succederà se segui la storia "Demo".