Complicato o complesso ?

Mi è servito un sondaggio tra colleghi e clienti per decidere di scrivere con l’obiettivo di chiarire la differenza tra complicato e complesso, che nel linguaggio comune vengono utilizzati in modo pressoché intercambiabile.

Ho scoperto con sorpresa che il linguaggio che utilizzo normalmente non è affatto chiaro agli altri, ma immediatamente mi sono sorpreso di essermi sorpreso.
Quindi cerco di chiarire i termini, per poi parlare delle implicazioni.
Con COMPLICATO definiamo un problema o una situazione che siamo in grado di descrivere compiutamente, di cui siamo in grado di definire una strategia e un piano per affrontarlo, dei tempi e delle milestones per arrivare a un risultato che siamo in grado di descrivere.
Con COMPLESSO definiamo invece una situazione in cui non siamo in grado di definire una serie di milestones precise, dei tempi precisi e un risultato preciso da raggiungere.
Sono definizioni un po’ grossolane rispetto a quanto si può prendere dalla letteratura, ma secondo me rendono bene l’idea.
Uso alcuni esempi tipici per tradurre in pratica:
COMPLICATO: montare un mobile dell’IKEA, mandare un razzo sulla luna, smontare e rimontare un orologio, costruire una barca.
La complicazione può venire la vastità del compito e dagli skill molteplici che sono necessari, ma se della situazione conosco cosa so fare e cosa non so fare,sono comunque in grado di descrivere i passi certi per arrivare a una risoluzione.
COMPLESSO: crescere bene un figlio, fare un piano strategico -che funzioni-, gestire un gruppo di persone, fare un progetto software grosso che non ho mai fatto prima, gestire una azienda -o l’IT di una azienda-.
Cioè se esiste una ricetta, pur con molti ingredienti e con molti step, se anche non ho alcuni degli ingredienti e non so fare alcuni step, posso comunque procurarmi ciò che manca ed essere pressoché sicuro del risultato. E si tratta di situazioni complicate.
E’ abbastanza chiaro che tutte le volte in cui sono coinvolte persone non come “ingranaggi di un orologio”, cioè esecutori di procedure, ma come elementi portanti di una attività che ha interconnessioni ed evoluzioni nel tempo, siamo di fronte a problemi complessi.
I sistemi complicati sono predicibili. Li possiamo prendere, separare nelle parti, capire le interazioni, e riprodurre. A meno di errori di esecuzione sono in grado di ripetere l’evento.
Per i sistemi complessi non è così. Per quanti figli io possa avere non ne usciranno mai due uguali, per quante aziende abbia gestito non potrò mai garantire che fare le cose che ho fatto in una farà funzionare la prossima. I sistemi complessi sono in larga parte impredicibili, e quando li sollecito con una azione non so con certezza cosa aspettarmi (a meno che non sia un peccatore cronico di “overconfidence”).
L’incertezza è sovrana, averlo fatto bene una volta non dà garanzie per la prossima, non ho garanzie di successo. Molte volte non riesco nemmeno a definire esattamente cosa sia il successo.
Per riassumere:
Sistemi complicati (come costruire una barca)
Le formule sono critiche e necessarie
Riuscire una volta garantisce che anche la prossima riuscirà
Servono livelli di esperienza adeguati nei diversi campi coinvolti
Ci sono molte similitudini (se non uguaglianza) tra le ripetizioni
Ci sono alti livelli di certezza sul risultato
Sistemi complessi (come crescere un figlio o gestire un gruppo di persone)
Le formule hanno una applicazione limitata
Riuscire una volta dà esperienza ma non garantisce il risultato ripetibile
L’esperienza è necessaria ma non sufficiente
Ogni persona o gruppo è unico (e cambia nel tempo) nelle caratteristiche, e le relazioni sono fondamentali
Ci sono bassi livelli di certezza sui risultati
Una prima conclusione che si può trarre è che lo stile con cui si affrontano situazioni complicate e complesse non può essere lo stesso.
Mentre per le prime ho una relazione diretta tra causa ed effetto, cosa che mi permette uno stile di  monitoraggio e gestione consolidato e abbastanza ripetitivo, per le seconde le indicazioni devono servire a capire i trend e i modelli di comportamento del “sistema” per giurarlo nella direzione giusta tenendo conto che una azione provocherà sicuramente reazioni che non sono in grado di predire con certezza.
Prossimamente cercherò di illustrare gli stili più appropriati per affrontare situazioni complicate e complesse, sempre cercando di essere molto pratico.

Comments (1)

I perché sulle architetture

Questo post nasce da uno spunto (un video) che mi richiama i frequenti dibattiti a cui partecipo nelle aziende che frequento.

I dibattiti, le riunioni, le chiacchiere informali a cui mi riferisco riguardano la necessità, le motivazioni, i vantaggi di avere un Gruppo Architetture formalizzato e operante, cosa fa e come lo fa, che ruolo deve avere, che relazioni con gli altri gruppi deve avere, che potere deve avere e a chi deve fare capo, se si deve occupare solo di IT o anche d’altro, …. e tutto ciò che si può collegare a questo tema.

Le situazioni e il tenore degli argomenti varia moltissimo da azienda a azienda, e in alcune occasioni i ragionamenti sfociano in autentica gazzarra ideologica; dipende molto dai partecipanti e dalla cultura e mentalità dell’azienda e degli individui. Quasi mai se ne esce sereni e migliori, perché il dibattito ristagna quasi sempre su domande di questo tipo, in modo dipendente da situazione e maturità dell’azienda:

  • che cosa è e perché serve avere un gruppo architetture?
  • perché delle architetture non basta che se ne occupino i progetti (NDR come si è sempre fatto, cioè non occupandosene quasi mai se non a livello di tecnologie da scegliere)?
  • ma perché ci deve essere qualcuno a cui raccontare cosa fa un progetto “al suo interno”?
  • ma gli architetti si devono occupare solo della parte IT o anche della organizzazione (cioè del modo in cui si svolgono le attività – nell’IT e/o anche fuori-)?
  • il modello architetturale SOA è meglio di un modello a Silos e perché?

Tutte queste domande sono lecite e al tempo stesso le risposte, quali esse siano, sono indimostrabili matematicamente quindi insoddisfacenti per chi è prevenuto. Ed è la quasi totalità dei casi.

La constatazione pratica è che chi non vuole convincersi di un cambiamento per sue valide ragioni individuali ha tutte le possibilità di giustificare il suo atteggiamento, e nessun argomento, se non dimostrabile matematicamente, lo convincerà per il solo fatto che non vuole essere convinto.

Lo spunto che mi ha fatto decidere di scrivere è un video che ha scatenato un dibattito tra la tribù che sostiene che l’Enterprise Architecture è una disciplina a livello aziendale e quella che sostiene che è una disciplina IT e a quella parte deve rimanere limitata.

Questo video mi piace perché è efficace per tutti quelli che non hanno dimestichezza con la globalità di un IT e non hanno presente la “complessità emergente” che negli anni sta caratterizzano i Sistemi Informativi. Spesso questo connubio porta alla sottovalutazione dell’impatto di un singolo progetto sul tutto, visto che la prospettiva da cui il progetto guarda le cose è individuale, ma il video sottolinea bene l’importanza di collegare una decisione al tutto e non solo al singolo obiettivo.

Ci sono però altri aspetti che non condivido affatto:

  • il video ha un titolo errato, in quanto quella di cui si parla non è come il titolo farebbe pensare Enterprise Architecture bensì IT Architecture
  • viene trattato solo un aspetto, la riduzione o la non generazione di inutile complessità, che non è certo la sola ragione per cui l’architettura deve esistere: quindi rischia di essere riduttivo e deviante

Al di là di questi “difetti” lo considero uno strumento di consapevolezza utili in qualche caso, quindi meritevole di essere diffuso.

Eccolo.

 

Leave a Comment

links for 2011-09-23

Leave a Comment

links for 2011-09-22

Leave a Comment

links for 2011-09-20

Leave a Comment

links for 2011-09-19

Leave a Comment

links for 2011-09-16

Leave a Comment

Older Posts »