In un recente post si sono aggiunti alcuni commenti con spunti interessanti e proprio stamattina ho letto un altro post di Luka molto interessante. Uno degli errori più macroscopici che si fanno solitamente durante lo sviluppo è quello di creare contrapposione tra dev e cliente. Tipicamente quando il cliente chiede una modifica, lo sviluppatore si sente frustrato e spesso accusa il cliente con frasi del tipo: “non sa mai cosa vuole”, “non è in grado di capire che cosi è meglio”, “debbo rifare tutto per colpa del cliente”, e potrei continuare ancora a lungo.
Questo conflitto spesso è determinato dal mancato contatto cliente / dev, che viene solitamente mediato da figure di “Analisti Marchettari”, ovvero persone che vanno dal Cliente non con lo scopo di raccogliere veramente requisiti e fare gli analisti, ma piuttosto per “Vendere” un prodotto. Qui spesso si cela il male perchè il ciclo di sviluppo adottato molto spesso è
1) andare dal cliente, cercare di capire alcune vaghe specifiche
2) vendere al cliente il proprio prodotto, convincendo il cliente che si è capito quello di cui ha bisogno
3) gettare le vaghe specifiche in una stanza con X sviluppatori
4) periodicamente aprire la porta di suddetta stanza e chiedere “è pronto?”.
5) quando si ha qualche cosa di più o meno funzionante lo si fa vedere al cliente
quindi in sostanza non si ha nessun processo, è come costruire una casa senza progetto, prendendo X persone e dando loro calce e mattoni.
Molto spesso inoltre le specifiche sono fumose e non sono corrette, principalmente perchè non le si è nemmeno cercate, ma le si è imposte al cliente stesso. Al termine il cliente ha un prodotto che non è quello che vuole e chiaramente inizia a chiedere cambiamenti creando quindi attrito con gli sviluppatori. La frustrazione maggiore è vedere il tempo perso ad implementare cose inutili.
Se non si ha il controllo sul processo, ovvero se siamo meramente le persone nella stanza, è comunque utile adottare un approccio più costruttivo, e come nel link citato da Luka invece di dire “It’s Them” preferiamo dire “It’s all of us”. Lo scopo è quello di cercare di coinvolgere il più possibile il cliente nel processo, con la maggiore trasparenza possibile, e soprattutto continuando per tutto il corso del progetto a cercare di elicitare i requisiti con il cliente stesso.
Cerchiamo quindi magari di convincere l’analista a parlare periodicamente con il cliente, facendo vedere il lavoro svolto fino a quel punto, e cercando strumenti che permettano di “aiutare” il cliente a capire cosa vuole (casi d’uso, mockup, prototipi, interviste).
Lo scopo finale è quello di soddisfare il cliente, per cui ogni richiesta di cambiamento è lecita. Se adottiamo questo modo di pensare, probabilmente ci si eviterebbero arrabbiature… d’altra parte “Il cliente ha sempre ragione”
Alk.