Ogni programmatore che costruisce prodotti software per vivere ha sperimentato o alla fine sperimenterà un bivio nel codice stradale. Possono essere soddisfatti per ora della funzionalità che hanno appena creato e passare all'attività successiva, riconoscendo che la funzionalità ha spazio per essere migliorata, oppure possono continuare a costruire per rendere una funzionalità migliore (e migliore) (e ooh e se potesse...).

Compromettere o non scendere a compromessi?

Per me, una persona che vuole finire i videogiochi al 100% e che sono cresciuta godendosi la fine dei miei pasti in modo da poter far parte del Clean Plate Club, il mio istinto di solito è di mantenere qualcosa fino a quando non è completamente finita, per il meglio delle mie capacità. Tuttavia, a volte i compromessi possono portare a risultati migliori. Tutti abbiamo poco tempo nella nostra vita (e spazio limitato nello stomaco, tranne quando siamo adolescenti) e spenderlo intenzionalmente è importante. Allo stesso modo, i clienti che pagano per la creazione o la manutenzione di un prodotto software avranno in genere fondi limitati disponibili a tale scopo, il che spesso equivale vagamente a un numero limitato di ore in cui possono pagarti per lavorare al loro progetto, e ogni cliente vorrà il massimo per il suo secchio. Vorranno massimizzare il valore del prodotto con i soldi che spendono per i tuoi sforzi di sviluppo.

Quindi, come programmatori, quando arriviamo a questi punti, dovremmo considerare un quadro più ampio rispetto a questa caratteristica e alla sua qualità/robustezza/facilità d'uso/flessibilità/ecc. Quali fattori dovresti considerare quando decidi dove scendere a compromessi?

1. Requisiti-Innanzitutto, esiste una serie di requisiti concordati o contrattuali per questa funzione? In tal caso, è meglio soddisfare tali requisiti al minimo (e in alcuni casi al massimo). Spesso è una buona pratica nello sviluppo del software ottenere l'approvazione del cliente (o feedback, modifiche, quindi approvazione) sui requisiti di una funzionalità quando vengono pianificati, prima che inizi il lavoro più costoso su quella funzionalità, in modo da evitare di dover fare supposizioni ciò potrebbe non essere corretto, il che potrebbe portare a dover rielaborare qualcosa costruito in modo diverso dalla visione di un cliente. Idealmente, questi accordi e piani possono essere ripetuti e riapprovati in modo da incorporare gli ultimi pivot che il cliente o l'architettura potrebbero richiedere. I documenti sui requisiti concordati tendono ad allineare le visioni di tutti per il prodotto per iscritto e garantire che le aspettative per il prodotto non siano obiettivi in ​​costante movimento. A seconda delle dimensioni del tuo team, potresti avere un analista aziendale per fare molto di questa raccolta e documentazione dei requisiti per l'approvazione del cliente, ma anche se non lo fai, quel processo può comunque essere molto utile.
2. Priorità : in che modo questa funzione si colloca tra le altre caratteristiche in termini di capacità di condurre o essere necessaria per il successo del prodotto o dell'azienda? Se è vicino alla cima dell'elenco, ti consigliamo di assicurarti che soddisfi molto bene ciascuno dei suoi scopi, visto da ogni prospettiva pertinente. In caso contrario, forse annotare le idee di miglioramento e inserirle in un backlog da considerare in futuro e passare all'implementazione o al miglioramento delle funzionalità più critiche per il successo.
3. Sforzo-Quanto tempo pensi ci vorrebbe per aggiungere i tuoi miglioramenti considerati e il valore vale lo sforzo/costo? Potresti avere tre miglioramenti separati che vorresti apportare, ma solo uno o due di questi fornirebbero un valore sufficiente per far valere il costo speso per lo sforzo necessario. In caso di dubbio, comunicare con il cliente (se necessario attraverso gli appositi canali); fai solo attenzione a non promettere troppo o formulare domande o affermazioni in modi che implicano che i miglioramenti aggiuntivi sarebbero gratuiti e assicurati che tutti coloro che hanno bisogno di conoscere le decisioni siano informati (metti le cose per iscritto dopo le riunioni verbali e condividi tali decisioni con gli interessati). È facile che questo tipo di incomprensioni o disaccordi su priorità o errori di comunicazione inaspriscano una relazione con il cliente altrimenti eccezionale,
4. Utilità : quanto sarebbe importante il tuo miglioramento considerato per il successo o la felicità degli utenti tipici della funzione? Possono farne a meno, o sarebbe importante o addirittura cruciale per loro? Gli utenti felici spesso portano a proprietari di prodotti felici. Questo tipo di punti di discussione in cui puoi essere un sostenitore degli utenti tipici del prodotto dovrebbero entrare in risonanza con il cliente quando una funzionalità viene pianificata o discussa.
5. Frequenza : se stai apportando una modifica che consentirebbe di eseguire un'attività utente popolare o comune in meno tempo, chi potrebbe trarre vantaggio da questo risparmio di tempo? Un minuto risparmiato, o anche pochi secondi risparmiati, moltiplicato per centinaia o migliaia di occorrenze o più, può fare regolarmente un'enorme differenza per le persone e le aziende che beneficiano del tempo risparmiato. D'altra parte, se la funzione non verrà utilizzata frequentemente, il valore di tale miglioramento potrebbe essere basso.
6. Prospettiva- Considera tutte le prospettive rilevanti (varie tipologie di utenti, varie entità clienti, vari partner, ecc.) e quale valore offrirebbe il miglioramento a ciascuna di tali entità. Mettersi nei panni degli altri per guardare le cose dal loro punto di vista è una qualità chiave di eccellenti programmatori ed è utile per aiutare a prendere questo tipo di decisioni.
7. MVP- Infine, in caso di dubbio, limita la tua implementazione alla funzionalità fondamentale di una funzionalità e documenta o archivia le idee per i miglioramenti da esaminare nelle future iterazioni del prodotto. Molto spesso è meglio ottenere un prodotto minimamente redditizio (MVP) nelle mani del cliente e degli utenti prima di creare campanelli e fischietti aggiuntivi, soprattutto quando è possibile applicare l'analisi degli utenti e ricevere feedback dagli utenti. Potresti essere sorpreso dal feedback e dall'utilizzo degli utenti; a volte tu o il tuo cliente potete considerare una funzionalità di vitale importanza che finisce per non essere quasi mai utilizzata dagli utenti o potete considerare una funzionalità insignificante che gli utenti trovano indispensabile. Il feedback degli utenti e le informazioni sull'utilizzo, soprattutto all'inizio dell'ascesa di un prodotto, sono spesso strumenti eccellenti per determinare dove concentrare gli sforzi in seguito.

-Tommy Elliott, responsabile del team di sviluppatori software presso AWH.