Come incoraggiare il cliente a eseguire alcuni test di controllo di qualità interni?

they have none of the obsessive neurosis attention to detail of "real" developers

Prefazione : il tipo di linguaggio che hai usato qui è in genere una bandiera rossa per me. Quando sento gente parlare di "veri" sviluppatori o del (solo e solo) "giusto" modo di fare le cose, comincio a pensare a tunnel visionned sviluppatori di cult-cargo .

Ora, non sto dicendo che sei decisamente uno di questi sviluppatori (non ho prove sufficienti per affermarlo), ma se lo sei, allora potresti trarre vantaggio da questa risposta.

risposta

Sembra che tu e il tuo cliente stiate ottimizzando per cose diverse. È un fatto sfortunato nell'ingegneria del software che spesso le esigenze del business e i desideri degli sviluppatori non si allineano necessariamente.

Gli sviluppatori di software sono spesso persone appassionate che si concentrano sul miglioramento. A loro piace migliorare le prestazioni del software, il processo di sviluppo, i processi aziendali, i metodi di comunicazione, ecc. Ed è grandioso. Concentrarsi su queste cose è ciò che separa gli artigiani e le artigiane dagli incalliti keypusher.

Ma il tuo cliente non è un artigiano del software. Il tuo cliente è un business con una serie di priorità completamente diversa. E, a volte, quelle priorità sembrano ridicole per noi artigiani del software ... ma è solo perché stiamo ottimizzando per cose diverse.

Gli affari spesso desiderano ottimizzare per cose come il rilascio anticipato sul mercato e il risparmio sui costi a breve termine. In tal modo potrebbero dover sacrificare cose come QA, User Experience, risparmi sui costi a lungo termine e altre cose che fanno scalpore gli sviluppatori.

È una cosa brutta? Beh, non necessariamente. Non posso parlare per tutte le aziende, ma nella mia esperienza i miei clienti fanno queste cose per aumentare il proprio ROI (ritorno sull'investimento). Fare cose come il QA, il raffinamento di UX e la pianificazione a lungo termine offrono loro un ROI più basso. Ancora peggio, molte aziende hanno strutture di investimento che premiano solo le vincite a breve termine rispetto a approcci sostenibili e vincite a lungo termine.

Quindi, mentre potresti provare a vendere l'idea del QA al tuo cliente, potresti perdere tempo e sforzare il tuo rapporto con loro. Nel migliore dei casi avrai qualcuno desideroso di provare le tue idee (improbabile). Nel peggiore dei casi dovrai convincere l'intera azienda a rielaborare le sue strutture di incentivi in modo che gli investimenti a lungo termine come il QA vengano premiati. In entrambi i casi, le probabilità di successo sono basse.

La domanda interessante è quando ti viene pagato, non se il tuo cliente esegue un test per conto proprio.

• se vieni pagato in base al tuo tempo, nessun problema.
• se vieni pagato in anticipo, nessun problema.
• se vieni pagato quando il client dichiara il progetto "fatto", grosso problema.

Il problema è come puoi sapere quando il client accetta il software e ti pagherà. Questo chiaramente non funziona quando il cliente modifica continuamente il progetto con nuove richieste vagamente definite. Se questo significa che il giorno di paga è sempre differito - e diventa più improbabile da ogni richiesta - questo diventa insostenibile per te.

Un contratto fisso che specifica accuratamente tutte le caratteristiche e definisce in quali condizioni il cliente accetterà queste caratteristiche è chiaramente molto spiacevolmente severo, ma consente di pianificare il progetto in anticipo (anche il prossimo progetto). Garantisce inoltre che otterrai i tuoi soldi per il software che hai consegnato, se è all'altezza delle specifiche. In tale scenario, l'unica responsabilità di un cliente è durante la fase di definizione del contratto e alla fine per testing di accettazione .

Tale test di accettazione effettuato da un cliente è separato da altre forme di test:

• unit test
• test di integrazione del sistema
• test di usabilità
• carica i test
• test preliminari

Per quanto possibile, anticiperai i test di accettazione ed eseguirai tu stesso prima di fornire la funzionalità per evitare qualsiasi imbarazzo. A parte i test di accettazione (che misurano solo adempimento del contratto , non qualità del software ), tutta la garanzia della qualità è sotto la tua responsabilità. In particolare, il tuo cliente non ha necessariamente una mentalità QA, il background tecnico necessario o l'obbligo contrattuale di fare QA. Inoltre, trovo che l'outsourcing della caccia ai bug al cliente sia poco professionale.

Questo non vuol dire che gli errori non si verifichino. Supponendo che tu abbia una relazione basata su un progetto per il tuo cliente, ti conviene stabilire una linea di demarcazione tra la disponibilità di soluzioni rapide e rapidamente, e spiegare che hanno accettato la versione corrente come sufficiente per le loro esigenze: grandi cambiamenti richiedono un nuovo contratto. Se hai un contratto di assistenza in corso, dovrai ovviamente rispettare il livello di servizio concordato.

In un ambiente agile, rispondere alle esigenze dei clienti è più importante che attenersi alla lettera del contratto, ma vorrai comunque essere pagato. Pertanto, molte metodologie di progetto orientate all'agile stimano la stretta interazione con il cliente, al punto che il cliente potrebbe diventare parte del team. Potresti quindi sempre parlare con questo "product owner" per chiarire tutti i punti necessari. Poiché l'ordine di acquisto ha l'autorità di concederti il tempo di lavorare su qualsiasi funzione che ritengono utile, questo può funzionare anche a partire da esigenze vaghe dei clienti. Se non hai una comunicazione così stretta, dovrai seguire un approccio più formale.

• Quando apprendi delle nuove esigenze dei clienti, collabora con il cliente per tradurle in base ai requisiti. Questo aiuta il cliente a ottenere ciò che realmente desidera.
• I requisiti sono oggettivamente misurabili - sono soddisfatti o meno. Questo salva il client dalle mezze soluzioni che funzionano solo in modo

• Tutte le richieste dei clienti devono essere fornite in forma scritta in modo da poterle fatturare. Questo li protegge dall'essere fatturati per cose su cui hai semplicemente voglia di lavorare - come riscrivere l'intera interfaccia quando chiedi che un pulsante sia allineato in modo diverso.

  Molte comunicazioni possono essere fatte di persona o per telefono, ma alla fine ti servirà un pezzo di carta per documentare che il cliente desidera che tu lavori su questi requisiti. In casi semplici, potrebbe essere sufficiente ricapitolare una telefonata e inviare loro un'email per verificare cosa ti hanno chiesto di fare.

Le segnalazioni di errori sono sempre difficili. Se i tuoi clienti sono sviluppatori che dovrebbero aiutarti, in quanto possono capire le tue esigenze: avere passaggi chiari da riprodurre. Un modo semplice per ottenere informazioni approfondite è abilitare la registrazione nel software distribuito. A patto che i problemi relativi alla privacy dei dati possano essere risolti, richiedendo che ogni segnalazione di bug contenga il log corrente non solo garantisce alcune comunicazioni scritte, ma anche quello che l'utente ha effettivamente fatto (in contrasto con quello che pensavano stessero tentando di fare) .

Il modo per incoraggiare la comunicazione dei bug è incoraggiare una comunicazione frequente e granulare delle funzionalità. Se istruisci un'azienda che può chiedere qualsiasi cosa con zero cerimonie, userà questa caratteristica anche per i bug minori. Abbandona il passaggio al flusso di lavoro del tuo cliente a meno che queste modifiche non facilitino la vita.

Portare il tuo cliente a fare test interni è difficile, ma far sì che riportino bug non è così difficile come sembra. Il modo per ottenere più feedback è quello di ridurre l'attrito dell'utente ... anche se questo significa trasferire un po 'di quell'attrito a te stesso.

1. Usa strumenti più semplici, anche se questi strumenti sono inadeguati e inappropriati. Ad esempio, BaseCamp è un bug tracker piuttosto orribile (perché è destinato alla gestione dei progetti), ma le persone sono effettivamente disposte a usarlo.

2. Poiché i bug tracker che stavamo usando non supportavano il copia-incolla dell'immagine, in realtà ho scritto un programma banale che copia l'immagine degli appunti corrente su disco (come un Guid), quindi copia il Guid negli Appunti. Dopo una formazione minima, un utente può allegare le immagini degli appunti ai problemi semplicemente premendo la schermata di stampa, facendo clic su un pulsante e quindi incollando la finestra di selezione dei file dello strumento di invio dei bug.

Uno screenshot (eventualmente modificato in MS Paint con annotazioni) e 1-2 frasi è sufficiente per individuare la maggior parte delle funzionalità / bug.

Entrambi i suggerimenti sono mirati ai punti di attrito che I hanno sperimentato, e entrambi questi suggerimenti hanno aumentato il reporting di un fattore maggiore di 10. Tuttavia, dovrai indirizzare i tuoi punti di attrito.

Semplifica i test per il tuo cliente, ma rendi davvero difficile per il tuo cliente utilizzare qualsiasi nuova funzionalità in una versione non testata in produzione. Questo può essere ottenuto come segue:

Ogni volta che fornisci una nuova funzionalità, la implementi prima in una "versione beta", chiaramente contrassegnata con un segno "non destinato alla produzione". Rendi disponibile questa versione beta al client per il test. Fornisci anche l'ultima "versione di produzione" che dovrà utilizzare per la produzione reale (senza le nuove funzionalità, ma con le ultime correzioni di bug), e ti rifiuti di trasferire le nuove funzionalità beta nella versione di produzione fino a quando non ottieni un feedback che qualcuno a il lato client ha almeno provato per primo.

Se il client inizia a utilizzare la versione beta sui suoi dati di produzione reali sebbene mostri sempre un messaggio "Non destinato alla produzione" ogni volta che avvia il programma, allora non puoi aiutarlo, ma almeno hai chiarito che ogni volta perde il lavoro di produzione perché ha usato la beta per scopi errati che è chiaramente colpa sua. Se il cliente non apprende da questo, potresti considerare di disabilitare la capacità del tuo client di utilizzare la "beta" in produzione disattivando alcune funzioni cruciali come il salvataggio dei risultati su disco nella "beta", se necessario.

Fornire una "beta" separata ti costringerà a stabilire il controllo della versione / gestione della configurazione, in modo da poter gestire un ramo di produzione e un ramo beta testati parallelamente senza problemi. Ma dal momento che stai lavorando con Github, immagino che tu già usi qualcosa come GIT, il che rende questo tipo di gestione molto semplice.