” Richiesta di funzionalità!!!”
È spesso il grido di battaglia che noi ingegneri del software usiamo per minimizzare l’urgenza del problema di un cliente. Dopo tutto, non c’è tempo per aggiungere nuove funzionalità quando osserviamo il registro di bug senza fine che ci affronta.
Per noi ingegneri del software, la differenza tra un bug e una richiesta di funzionalità è cristallina. Un bug è una discrepanza tra il modo in cui il codice funziona e come il nostro codice era destinato a funzionare. Una richiesta di funzionalità richiede un nuovo codice per soddisfare un caso che non può essere gestito dalla base di codice corrente.
Questo tipo di pensiero-processo ci porta sempre alla domanda più generale su come software come DoneDone dovrebbe essere usato. La tua organizzazione dovrebbe utilizzare un tipo di software per registrare i bug, un altro tipo di software per gestire le attività imminenti e un altro tipo di software per tenere traccia delle richieste di funzionalità?
Spendiamo molta energia mentale cercando di vagliare i problemi registrati da un cliente o da un cliente, cercando di determinare se gettiamo un problema nel secchio “bug” o nel secchio “richiesta di funzionalità”. Per il lavoro di consulenza, quando stiamo lavorando su un accordo predefinito su come il software dovrebbe comportarsi, questo ha senso. Le richieste di funzionalità potrebbero richiedere un costo aggiuntivo.
Ma, quando si tratta solo della pura pratica di creare un buon software, in particolare se stiamo lavorando sui nostri prodotti, quanto dovremmo preoccuparci di classificare un problema in questo modo?
Lasciamo che i tecnicismi (e la tecnologia) ostacolino la risoluzione dei problemi.
Robert Martin (alias Uncle Bob) parla molto del software. Egli considera il Web solo un meccanismo di consegna e niente di più. Non è l’esperienza dell’utente finale, e non è lo scopo del software. È semplicemente un piccolo dettaglio stupido. Tuttavia, quando noi programmatori programmiamo, l’architettura delle nostre applicazioni è troppo interamente influenzata dal fatto che si tratta di un’applicazione Web.
Allo stesso modo, cosa succede se consideriamo il termine che usiamo per “una cosa che deve essere fatta” per essere un dettaglio stupido?
Dal punto di vista della persona che registra quella “cosa”, le importa davvero che stia richiedendo una nuova funzionalità rispetto alla scoperta di un bug? Lei vuole solo il suo problema risolto da un altro essere umano, e preferibilmente, per sapere quando il suo problema potrebbe essere risolto.
Potresti essere in grado di vedere il tecnicismo più ovviamente se lasciamo il mondo del software. Quando l’idraulico arriva per riparare la doccia che perde, immagino che non ti importi dei dettagli. Se il soffione è stato installato in modo errato (bug) o se la guarnizione è rotta (bug) o se il nastro di teflon mancava da un tubo economico (feature), tutto ciò che ti interessa è quanto tempo ci vorrà per risolvere e quanto ti verrà addebitato.
Bug o richiesta? Entrambe le cose. E, non importa.
La scorsa settimana Siamo Mammut rilasciato Kin, uno strumento software HR per le piccole imprese. Kin ti dà un modo semplice per monitorare le richieste di tempo libero di ogni dipendente. Una cosa che Kin non fa in questo momento è distinguere i fine settimana e le vacanze dai giorni lavorativi. Quindi, se si voleva togliere una settimana intera durante il Ringraziamento, è necessario inserire manualmente la quantità di ore che si sta richiedendo off.
Il team ha già ricevuto alcune richieste per far sì che Kin esegua automaticamente questo tracciamento. In realtà, è nella coda di rilascio. Ma, quando è registrato, in qualunque posto sia connesso, il team Kin dovrebbe considerarlo un bug, una richiesta di funzionalità, un’attività o una cosa da fare?
Chiamando il mio zio interiore Bob, la mia risposta è semplice: non importa come classifichi la richiesta. E ‘ solo un dettaglio stupido.
Questo non vuol dire che non dovremmo classificarlo affatto. Il team Kin potrebbe taggare il problema in “richiesta di funzionalità” e lavorare per risolvere prima problemi più critici (come un utente con un problema di autorizzazione). Va bene e dandy, e un approccio valido.
Tuttavia, sarebbe un errore assumere automaticamente tutte le richieste di funzionalità di things-we-call sono meno urgenti di tutti i bug di things-we-call. Questo rende il dettaglio piuttosto piccolo di come classifichiamo il problema il fulcro per quando lo risolviamo. Non dovrebbe essere cosi’. Alla fine della giornata, tutte queste richieste sono semplicemente cose che hanno bisogno di risoluzione.
Lascia che la tecnicità sia il dettaglio stupido
A tal fine, l’etichetta che diamo a tutte queste richieste è in gran parte irrilevante. Ciò che conta di più è che qualcuno sta frequentando a loro e c’è un’idea generale di quando queste richieste saranno affrontate. Ciò che conta di più è che il 33% in più di utenti trarranno beneficio dall’oggetto A indirizzato rispetto all’elemento B. Indipendentemente dal tipo di oggetto A o B, l’elemento A è più prezioso da affrontare. Ecco fatto. Niente di più.
Così, la prossima volta che stai spendendo troppo tempo con le attività di categorizzazione, bug, richieste di funzionalità, e cose da fare, ricordatevi di dimenticare gli aspetti tecnici. Sono solo i dettagli stupidi.
Registrati per un account DoneDone in 30 secondi. Vuoi saperne di più da Ka Wai Cheung? Il nuovo libro di Ka Wai sul programmatore moderno, Il codice dello sviluppatore, è disponibile in eBook e stampa. Puoi seguirlo su Twitter @ developerscode.