Lo sviluppatore/fornitore non può dire di no al cliente

Che titolo inutile è questo: certo che il cliente deve dire la sua... è lui che tira fuori il denaro? Ci mancherebbe solo che non avesse potere decisionale!

Ecco, non è proprio per il fatto che il cliente detta i requisiti il problema.
Il problema è che il cliente (a seconda dei casi) può soffrire di manie di grandezza e voler decidere dell'applicativo sviluppato, anche i nomi delle tabelle.

Ma il problema sta qui?
No, non sta neanche qui il problema.
Il problema è il buco nero che il cliente ha nel cervello... scusate mi sono lasciato andare. Il problema è quando il cliente chiede, propone e insiste che delle incoerenze inconsistenti siano "volontariamente" messe nel software.

Per esempio a noi fu chiesto che fossero levati tutti i controlli sui dati che a ragione avevamo messo. Quando facemmo presente (in modo molto convincente) al cliente che così facendo avremmo permesso l'introduzione di errori che difficilmente avremmo sanato, lui ha glissato dicendo che si prendeva la responsabilità ( ah ah ah, questa è un ossimoro per un dirigente della pubblica amministrazione: nessuno si prende mai la responsabilità!!! era un mero scherzo verbale ) e che "avanti tutta"!

Inutile dire che il sistema ebbe un tracollo, la parte di business intelligence rilevò dati dell'anno 1 dopo Cristo, che alcune fatture erano pari al debito pubblico italiano e così via.
Ma chiedere di fare un software con un bug evidente è una cosa: lo sfacelo è visibile da tutti, ma magari anche i fornitori ci godono perchè verranno pagati per risolvere bug (sempre che questi siano risolvibili...); mentre fantasticare sulle interfacce è un'altra ed è una tentazione molto più subdola per il dirigente di turno.

"Possiamo fare una barra laterale attraverso la quale uno sceglie la sua casella?".
Tu che sei un analista funzionale capisci che ormai il cliente parla per analogia di cose già viste. Ti chiedi se pensa all'interfaccia di Gmail o di Outlook, ma tanto sai che non puoi farlo.
L'interfaccia deve avere una coerenza interna, le leggi dell'usabilità sono poche e semplici e se il resto dell'applicativo non ha quella logica, buttarla in quella singola funzionalità impedisce all'utente finale di capire come usarla!

Ma no, a lui piace la barra laterale, e allora "l'ha chiesto il cliente".
Si convince il povero sviluppatore a strappare a morsi pezzi di infrastruttura, accroccare una grafica improbabile e mettere su due procedure che facciano il minimo sindacale per mostrare quella INUTILE BARRA LATERALE!!!

Ma dove è finita la professionalità del programmatore?

E'come se quando mi venisse l'idraulico in casa, io sono quindi il cliente, al momento di smontare la tazza del bagno io gli intimassi di usare il cacciavite da orologiaio, perchè a me piacciono i lavori di fino anzichè lo strumento che sta usando lui.
Secondo voi l'idraulico come reagirebbe?
Perchè il programmatore è trattato peggio di così?

Technical manager buono e Technical manager cattivo

Come nei migliori film, nei migliori progetti per la pubblica amministrazione si gioca al Technical manager buono e Technical manager cattivo.

Dico si gioca perchè a differenza degli Stati Uniti, in Italia non esistono rigide gerarchie di skill ma ognuno si improvvisa quello che può, come può.

Un giorno ti svegli e sei il Project Manager, o il Team Leader, oppure ti capita di dover cambiare il berretto, di sviluppare e/o parlare con il cliente. Il tutto come alla Corrida: "dilettanti allo sbaraglio".

Ma non voglio distruggere come al solito, oggi voglio costruire!
Vorrei volare da sviluppatore nel mondo rosa confetto in cui le cose vanno come vorrei e parlarvi del Technical manager perfetto (ne ho conosciuti)!

Il Technical manager dovrebbe non solo coordinare un team di sviluppo ma anche relazionarsi con il management e capire o trasmettere correttamente i tempi e i costi.

• Capisce di tecnologia a differenza del Project Manager che potenzialmente dovrebbe sapere gestire lo sviluppo di un progetto  software come un cantiere edile

• Se le cose vanno male è lui che ci rimette, non gli sviluppatori (lui ha sbagliato i calcoli, lui al più si siede e sviluppa il software nel week end se gli è richiesto o dopo l'orario di lavoro).

• Si prende la responsabilità e (se è magnanimo) ridistribuisce gli onori (in fondo il software non lo ha sviluppato lui). 

• Combatte fianco a fianco del gruppo di sviluppo per riportare il management sulla retta via e far capire (più che semplicemente comunicare) quali sono i tempi reali che ci si può aspettare per fare qualcosa.

• Sa dire di no: se una cosa la si può fare in due settimane, non scende a una settimana; piuttosto dice che non si può fare.

• Delude il management che vende l'anima al cliente salvo poi sentirsi dire che le richieste non sono realizzabili

Se ci penso bene, un buon technical manager altro non è che un buon padre di famiglia!