2014-10-16 10:39 GMT+02:00 Giuseppe Benfenati
<[email protected]
:
Salve a tutti,
stavo facendo una riflessione:
al di là della gestione del codice( che sia ruby o php), delle architetture
software, dei design pattern, spesso ci si scontra con il cliente che non
capisce e non percepisce la qualità del lavoro svolto.
Quindi capita che all’ultimo di chiedono una modifica che destabilizza
tutto il flusso, oppure pensa che per fare quella cosa si fà talmente
presto che, se gli chiedi qualcosa in più storce il naso.
Lavoro spesso a progetti con costo forfetario e non sempre si riesce a
farsi pagare tutte le ore impiegate.
E’ una cosa che capita solo a me (e quindoi devo cambiare lavoro) o è una
situazione frequente?
Avete individuato metodologie con le quali ci si difende da questi
problemi?
Been there, done that.
Per completezza aggiungo che questo discorso vale anche per i clienti.
Cliente: “spesso ci si scontra con il developer/team che non capisce e
non
percepisce le nostre problematiche”.
Da ambo le parti, se gli errori vengono commessi (dal developer e/o dal
cliente) in assenza di malizia (e ammetto di averne commessi, avoja), si
superano (magari con piccole ferite) e migliorano sia la professionalità
del developer che la qualità dei risultati del cliente.
La malizia, d’altro canto, è una stronza che che abbatte
sistematicamente
ogni percorso virtuoso e che cerca di restare incollata fino alla morte
lavorativa.
Ma sto divagando.
Proprio per i motivi della divagazione, mi sono auto-imposto di lavorare
solo con clienti che capiscono l’importanza dell’approccio ad
iterazioni.
Propongo di partire con un periodo (da 1 settimana a 1 mese) a costo
ribassato (~ 2/3 della tariffa “a regime”) , fatturando ad
ora/giornata/settimana, con la possibilità da ambo le parti di
sganciarsi
al termine di ogni iterazione. Generalmente adotto un approccio
Scrum-like.
Questo permette di creare un rapporto di fiducia tra cliente e
developer.
Il cliente può valutare la qualità del developer senza rischiare un
legame
troppo costoso e allo stesso tempo slega il developer da inutili
responsabilità.
Ccome il fatto di implementare specifiche che non sono ancora chiare
neanche allo stesso cliente e con un orizzonte temporale troppo lontano
(che io ho individuato essere di circa 2 settimane uomo).
Un rapporto lavorativo non ha senso in assenza di reciproca fiducia.
Se il progetto supera la fase di rodaggio significa che sia il cliente
che
il developer sono soddisfatti del rapporto e che il progetto è
effettivamente ad ampio respiro.
Il cliente è quindi consapevole della mia professionalità e posso quindi
ripristinare la mia tariffa “a regime”.
Il developer è consapevole sia di avere sufficiente autonomia tecnica
sia
di aver educato il cliente sulle ripercussioni dei cambi di contesto
generati dalle riprioritizzazioni in corsa delle attività e si fida che
tali riprioritizzazioni non sono capricci ma esigenze di business.
In passato, all’inizio di un nuovo rapporto lavorativo, davanti a
problematiche, ho dato il beneficio del dubbio.
Non conoscendo bene il contesto, non posso essere sicuro di come
risolvere
alcuni problemi o addirittura che essi siano effettivamente dei problemi
e
non invece solo delle circostanze alle quali sono semplicemente poco
abituato.
In seguito alla persistenza di questi problemi, provo a comunicare il
disagio.
Poi ci riprovo, cambiando lo stile.
Se i problemi persistono e mi tengono fuori dalla mia comfort zone,
ringrazio per tutto il pesce e saluto. 