Ogni problema contiene la sua soluzione
come dovrebbe pensare un ingegnere (II)
Stiamo operando nel mondo reale, il progettista interviene su situazioni esistenti vincolate da diverse restrizioni ed in questi ambiti deve sapersi muovere per ottenere il risultato richiesto. Risolvere un problema significa rappresentarlo in modo che sia evidente la sua soluzione.
Cioè a dire: ogni problema presenta nelle sue conclusioni quello che era implicito nelle sue premesse. Avete tutto sotto gli occhi, dovete saper vedere come stanno le cose e capire come invece potrebbero stare.
Se vi eravate distratti a proposito dei sistemi formali è il momento di andare a riprenderli e se credete che non ci sia disciplina in questa orgia di potere vi strasbagliate.
Questo è quello che dovreste saper fare per affrontare un progetto (secondo Herbert Simon):
Valutare l’esistente, per prima cosa; cioè ottimizzare le alternative fisse: quello che c’è già lo riorganizzo, stabilisco delle marginalità, una scala di preferenze su una base statistica ovvero logico-matematica. Per farlo ho bisogno degli strumenti che mi consentano di dedurre la migliore fra queste alternative esistenti. Sono strumenti di calcolo, brutali e pertanto schifosamente sinceri e spesso faticosi da capire e da far capire ma per fortuna ben noti: li avrete sentiti chiamare Ricerca Operativa.
Non vi sfugga che in queste valutazioni state osservando quello che già c’è, che poi è il problema (non la soluzione, il problema); non ci avete ancora messo un grammo di vostra inventiva ma iniziate qui: dovete cercare le alternative (possibili ma ancora inesistenti) all’esistente e analizzare le differenze fra quello che c’è e quello che dovrebbe essere.
Nell’ambito del possibile potreste andare avanti per l’eternità e questo non è accettabile perché siete ingegneri, non filosofi, le cose che vi si chiede di fare devono funzionare per qualcosa o qualcuno che ne ha bisogno il prima possibile.
Qui è la fase eminentemente iterativa in cui si generano soluzioni che vengono controllate e modificate e diventano soluzioni nuove che vengono controllate e modificate e diventano soluzioni nuove che insomma avete capito.
Perciò dovete decidere fino a quanto siete disposti ad indagare, ovvero quando potete dirvi soddisfatti della soluzione e passare oltre. Non c’è regola fissa e dipende da voi, dal problema e dal cliente (inteso indifferentemente come chi paga o chi usa).
Per procedere è necessario capire che cosa merita di essere ulteriormente indagato e quali e quante risorse potete usare (la soluzione trovata è soddisfacente, che cosa faccio per migliorare ulteriormente? Perfeziono quello che ho o cerco altri comparti da migliorare? E quante volte posso, devo, mi conviene farlo?)
Vi ricordate che il meglio è nemico del bene? Ecco, vale sempre.
E vale sempre la sovrapposizione degli effetti anzi, meglio: la loro composizione. Quindi ogni volta che aggiornate qualcosa agite a cascata sul vostro sistema; da qui la necessità di organizzare la struttura del progetto per gestire queste variazioni evitando reazioni caotiche.
Ecco perché se su facebook o linkedin leggo di nuovo un creativo che dice “per provare a immaginare come ridisegnare [aggiungere qui una cosa a piacere]” non rispondo di me.
