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ì?