Nonostante i pochi uomini e mezzi…

Quelle volte che proprio non si può dire di no

Qualche giorno fa parlando di cromatismi, in relazione a progetti fullstack, spiegavo che in caso di mancanza delle minime risorse è opportuno che anche i manager sappiano dire di no. Anzi sarebbe nell’interesse dell’azienda saper valutare le contingenze; tuttavia ci sono due eccezioni importanti.

• Quando siete obbligati a farlo
• E quando un manager intende dare una prova

Il primo caso concerne obblighi contrattuali o scelte al più alto livello che impongono scelte rischiose come quella che, pur tentando, non si riesca a tenere fede all’obbligo. In generale è buona normai coinvolgere gli stakeholders nei processi di sviluppo proprio per prevenire ed eventualmente gestire queste situazioni senza arrivare agli estremi delle risoluzioni contrattuali.

Vedete capita un errore di valutazione su tempi e sforzo necessari per raggiungere il risultato, non dovrebbe ma succede, ed in questo caso ci si rimette compensando col maggior sforzo. Ma succede anche che circostanze avverse blocchino gli ingranaggi e che dall’altro lato vi facciano pressioni. Leadership aziendale, reputazione e lavoro rischiano una crisi ed il confronto diventa necessario, il punto di non ritorno sugli accordi precedenti è alla formale richiesta di risoluzione del contratto. Questa non è uno scherzo ed è uno dei (pochi) articoli del Codice civile, il 1453, che ricordo a memoria visto che da executive ho dovuto farlo attivare nei confronti di fornitori immotivatamente inadempienti. In ordine alla risoluzione per inadempimento la legge infatti dice testualmente:

“La risoluzione può essere domandata anche quando il giudizio è stato promosso per ottenere l’adempimento; ma non può più chiedersi l’adempimento quando è stata domandata la risoluzione. Dalla data della domanda di risoluzione l’inadempiente non può più adempiere la propria obbligazione.”

Può piuttosto essere l’occasione per un nuovo contratto nel caso in cui sia ripartito il rapporto commerciale, come ci si augura, ma non si potrebbe semplicemente tornare indietro; in punta di diritto sarebbe rischioso farlo facendo finta di niente perchè poi si rischia di passare dalla parte del torto. E credetemi succede anche questo.

La soluzione? Molto ma molto meglio la metodologia agile e coinvolgere regolarmente lo stakeholder di riferimento e gestire i problemi, incluso gli stop ai progetti.

Il secondo caso riguarda invece quel momento in cui il budget è scarso e il team è ridotto all’osso ma, come gruppo o come management, intendete usare la difficoltà come trampolino.

Perchè diciamolo: succede, anche se vorremmo tutti il migliore dei mondi possibili capita nell’esperienza del management di poter dover tirare fuori il meglio da poco. Anzi di voler fare tesoro dell’occasione per dimostrare capacità personali e del proprio, pur risicato, team.

Bisogna avere la certezza che un qualche risultato utile sia comunque raggiungibile: un azzardo danneggerebbe azienda e stakeholders, che pur vi hanno sfidato essendo coscenti delle condizioni di partenza e delle difficoltà. Ci avete pensato? Si, ok? Vi siete messi nei panni del team? Si? Avete previsto una contingenza ulteriore ad esempio se si ammala qualcuno?

A questo punto immagino che reputiate di avere i margini operativi per partire occorre concentrare gli sforzi su cose concrete ed utilizzare il poco che c’è a proprio vantaggio e nell’interesse dell’azienda. Faccio il tifo per voi ma permettetemi questi ultimi ed utili suggerimenti:

1. Innanzitutto la User Story, cioè i requisiti dal punto di vista dell’utilizzatore;
2. Assumere ogni scelta privilegiando esclusivamente ordine e razionalità;
3. Elaborate una forte Vision su questo;
4. Scegliete al più due colori base:
5. Procedete al Mockup :
6. Ricordate CRAP: contrasto, ripetizione, allineamento e prossimità;
7. Cercare il giusto contrasto anche nella scelta dei due colori;
8. Ripetete il punto 2, dico sul serio!
9. Per il testo non perdetevi ed usate gradazioni dal grigio al nero;
10. E soprattutto ricordate che “Less is More”;

Tutto questo riguarda la parte del frontend, delle interfacce dei progetti fullstack, invece discorso cambia con i progetti backend, dove un eventuale incompletezza non espone solo a problemi estetici od esperienziali ma può inficiare la sicurezza e l’efficienza dei sistemi. Ne parleremo diffusamente nei prossimi articoli.

Silvio Torre: