Problem Solving

PROBLEM SOLVINGMAD2

Luca Naso - Catania, 15 Gennaio 2015

AGENDA

1. Problem solving?

2. Strategie e strumenti

[break]

3. Un esempio concreto

PROBLEM SOLVING?COS’È E COME FUNZIONA

A LIFELONG CHALLENGE

L’arte di risolvere problemi è la sfida di tutta una vita

• Di certo non basteranno 4 ore di lezione ad apprenderla … e neanche 400

• Necessita di tanta esperienza

A LIFELONG CHALLENGE

Scopo della lezione di oggi è di indicarvi la via per massimizzare la vostra esperienza

Insieme di tecniche utilizzate per risolvere problemi non banali

Che tipo di problemi?

• problemi di natura tecnica in ambito lavorativo, riguardanti ad esempio i processi aziendali.

• problemi di natura relazionale e/o emozionale, in ambito sia lavorativo che non.

COSA E’ IL PROBLEM SOLVING?

I “PROBLEMI”

I “problemi” per i quali si cerca una soluzione sono di solito complessi, riguardano più eventi e coinvolgono diverse persone.

I “PROBLEMI”

Spesso la soluzione si ottiene lavorando di gruppo.

COMPETENZA TRASVERSALE

Il problem solving è una competenza trasversale che si applica ai più disparati ambiti (così come il

Sviluppa/richiede capacità di giudizio e di analisi.

pensiero critico, la creatività e la gestione costruttiva dei sentimenti).

STRATEGIE STANDARD

Con il tempo sono state sviluppate delle strategie codificate per la risoluzione dei problemi.

Si tratta di una insieme di istruzioni da seguire per arrivare alla soluzione del problema.

PERCHÉ SVILUPPARE DELLE STRATEGIE STANDARD?

L’obiettivo è risolvere i problemi…

in maniera:

1. Efficace (non vogliamo che il problema torni)

2. Efficiente (vogliamo farlo ad un costo minimo)

Una strategia standard è la raccolta di tante esperienze perfezionate nel tempo.

BENEFICI

Avere delle precise tecniche di problem solving consente alle aziende di:

• ottimizzare i loro processi (essere più competitive)

• rispondere alle emergenze in tempi più brevi e con soluzioni più efficaci

di quanto non si farebbe lasciando tutto all’iniziativa dei singoli (e del momento).

ATTIVI E SUBITO

ATTIVI E SUBITO

• ATTIVI: Non è l’applicazione teorica, ma richiede un ruolo intellettualmente attivo, che porta alla creazione di qualcosa.

• SUBITO: Non è la pianificazione di una risoluzione futura, ma prevede che sia già in atto.

COME FUNZIONA

Esistono varie tecniche, solitamente divise in fasi e seguono lo schema tipico dell’approccio scientifico.

Tutte le tecniche passano attraverso tre macro-aree:

1. identificazione e definizione del problema

2. suddivisione del problema nelle sue parti critiche

3. individuazione ed applicazione di una soluzione

COME NON FUNZIONA

Quando ci si trova di fronte alla necessità di risolvere un problema è facile avere alcuni atteggiamenti estremamente controproducenti.

Vediamone due.

SALTARE ALLE CONCLUSIONICOME NON FUNZIONA

SALTARE ALLE CONCLUSIONI

1. Saltare direttamente alla conclusione, perché si pensa di aver intuito una soluzione

COME NON FUNZIONA

ACCUSARECOME NON FUNZIONA

ACCUSARE

2. Andare alla ricerca di un colpevole (chi ha creato il problema) e fare accuse.

COME NON FUNZIONA



Tutti iniziano ad accusare



Poi si risponde alle accuse



Qualcuno porterà il peso della colpa



A meno che non facciate una faccina così sarà difficile lavorare bene

Questi atteggiamenti si traducono quasi sempre in una perdita di tempo e risorse.

Spesso ci si ritrova al punto di partenza oppure è necessario fare più volte lo stesso lavoro.

E’ anche al fine di evitare questi errori che sono state sviluppate delle strategie precise di problem solving.

SPRECO DI RISORSECOME NON FUNZIONA

REPETITA IUVANT

In nessuna fase si va mai alla ricerca di colpevoli, ma sempre e solo di soluzioni.

La ricerca della soluzione, non deve spingere a saltare o accorciare le fasi della strategia che si sta mettendo in atto.

Altrimenti si perdono i benefici della strategia stessa, ad esempio si rischia di sottovalutare il problema, o la soluzione che si vuole applicare potrebbe non essere la migliore.

STRATEGIE E STRUMENTI[1]

PANORAMICA

PSS PROBLEM SOLVING STRATEGICO

1. Definire il problema

2. Concordare l’obiettivo

3. Individuare e valutare eventuali soluzioni già tentate (e fallite!)

4. Come si potrebbe peggiorare la situazione?

5. Quale sarebbe lo scenario una volta risolto il problema al 100%?

6. Piccoli passi a ritroso: partire dalla fine e procedere a ritroso fino alla partenza

7. Iterare: risolvere un piccolo problema alla volta, e se serve modificare la direzione ad ogni passo.

Usato in campo manageriale

FARE - FOCALIZZARE ANALIZZARE RISOLVERE ESEGUIRE

1. Focalizzare: Capire e definire in dettaglio il problema

2. Analizzare: Definizione degli elementi critici, Quantificare i fattori rilevanti con dei valori di riferimento

3. Risolvere: Generare delle possibili soluzioni, scegliere la soluzione da implementare, sviluppare un piano

4. Eseguire: Realizzare il piano, quantificare i progressi

PDCA PLAN DO CHECK ACT

1. Pianifica: analizzare la situazione, cercare le cause, definire gli obiettivi, le soluzioni ed i compiti

2. Prova: applicare il piano su piccola scala

3. Verifica: verificare che le prove danno i risultati attesi. Se no, tornare al punto 1

4. Agisci: mettere in produzione il piano che ha superato la verifica

Considerare l’opzione di inserire una verifica su scala intermedia (tra il punto 3 e 4).

DMAIC – DEFINE MEASURE ANALYZE IMPROVE CONTROL

risorse necessarie. Realizzare una roadmap


1. Definire i processi critici, gli obiettivi da raggiungere, le risorse necessarie. Realizzare una roadmap


2. Elaborare un piano per misurare l’efficacia dei processi, dopo averli suddivisi in piccole parti





3. Analisi dei dati raccolti al punto 2, per trovare relazioni tra le variabili, ed identificare punti sui quali intervenire


4. Sulla base dell’analisi al punto 3 creare ed implementare una soluzione che possa migliorare i processi





5. Dopo aver ottimizzato il processo creare un sistema di controllo per mantenere il livello di qualità raggiunto


4. Sulla base dell’analisi al punto 3 creare ed implementare una soluzione che possa migliorare i processi



STRUMENTIPANORAMICA

DIAGRAMMI

• Diagrammi Causa-Effetto

• Diagrammi di Flusso

• Checklists

• Diagramma di Pareto

• Diagrammi di controllo

• Scatter diagrams

DIAGRAMMI DI FLUSSO

• Visualizzare il processo

• Trovare i difetti

• Capire le relazioni

ANALISI DI PARETO

Solo pochi fattori vitali (20%)

sono responsabili della gran parte dei problemi (80%)

5W2H

Redigere un documento per individuare le principali cause del problema.

Il documento viene creato rispondendo a 7 domande.

5W2H

5W: Who? What? Where? When? Why?

2H: How? How many?

5W2H+

5W2H+

BRAINSTORMING

Riunione dove si dà libero spazio alle idee

BRAINSTORMING

Nessuna idea può essere rifiutata o respinta. Il focus non è sulla critica ma sull’estensione delle idee.

Senza timore di essere giudicato ciascuno si esprime più liberamente e può diventare fonte di ispirazione per gli altri (associazione delle idee).

1. Ciascuno scrive un’idea, il gruppo vota ogni idea, le prime vengono discusse (in sottogruppi).

2. Ciascuno scrive un’idea, la passa alla persona accanto, aggiunge qualcosa all’idea che ha ricevuto.

3. Strumenti informatici possono ottimizzare i tempi ed assicurare l’anonimato.

COME FUNZIONA - 3 ESEMPIBRAINSTORMING

DIAGRAMMA CAUSA-EFFETTO

Diagramma a lisca di pesce per descrivere un processo/fenomeno/problema.

La testa del pesce è il problema, a seguire le varie cause. Ogni causa può avere altri rami del diagramma.

Tutte le cause vanno suddivise gerarchicamente.

DIAGRAMMA CAUSA-EFFETTO

ANALISI DI ISHIKAWADIAGRAMMA CAUSA-EFFETTO

Per identificare tutte le cause si utilizza il brainstorming.

Il diagramma causa-effetto a lisca di pesce viene anche detto “diagramma di Ishikawa” perché è parte integrante dell’analisi di Ishikawa,

in cui, oltre alle cause, va definita anche l’azione correttiva più opportuna.

UN ESEMPIO CONCRETO[2]

PROBLEM SOLVING FOR DEVELOPERS

IL PROBLEMA

Data la propria data di nascita e la data corrente, calcolare la propria età in giorni. Includere gli anni bisestili. Assumere che la data di nascita e la data

corrente siano date valide e che non ci siano viaggi nel tempo.

Esempio: se la data di nascita è 1 gennaio 1950 e la data di oggi è 2 gennaio 1950, l’età è di 1 giorno.

1. LA PRIMA COSA DA FARE

Come iniziereste voi?

a. Inizio a scrivere le prime righe di codice

b. Mi assicuro di aver ben capito il problema

c. Penso ad un algoritmo che possa risolvere il problema

Risposta giusta: b


Uno dei modi per capire il problema è quello di identificare input ed output

Input: tutti quei valori che possono essere accettati in ingresso

Output: tutti quei valori che vengono richiesti perché il problema si consideri risolto

Logicamente la soluzione al problema sarà una procedura che a partire da input validi restituisca degli output corretti


Nel nostro caso:

Input = una coppia di date (infinite)

Output = un numero intero, la distanza in giorni tra le due date (1 solo)

Possiamo accettare tutte le coppie di date come input? No, la prima data deve essere antecedente la seconda data

Defensive Programming: all’interno del nostro codice verifichiamo che gli input sono corretti, se non lo sono interrompiamo l’esecuzione e restituiamo un messaggio di errore chiaro

2. COME RISOLVERE IL PROBLEMA?

Siamo adesso pronti a risolvere il problema. Come procediamo?

a. Iniziamo a scrivere il codice

b. Studiamo alcuni esempi (a mano)

c. Cercare una soluzione sul web

Risposta giusta: b, e anche c

2. COME RISOLVERE IL PROBLEMA?

E’ importante capire la relazione che c’è tra gli input e gli output. A prima vista non si colgono tutti i casi

Scegliere alcuni input, e calcolare a mano l’output corretto.

Ad esempio: due date uguali, output 0; due date una dopo l’altra, output 1; due date a distanza di 1 anno, output 365; due date errate, output err msg; …

3. E’ ARRIVATO IL MOMENTO DI SCRIVERE CODICE?

La nostra conoscenza e padronanza del problema aumenta. Siamo adesso pronti a scrivere il codice?

a. Si

b. No, dobbiamo scegliere il linguaggio adatto

c. No, dobbiamo cercare una soluzione

Risposta giusta: c

3. E’ ARRIVATO IL MOMENTO DI SCRIVERE CODICE?Consideriamo come un umano risolverebbe il problema

Ad esempio, input: da 2013,1,24 a 2013,6,29

1. prendere un calendario

2. cercare la data di inizio

3. segnare i giorni che restano nel mese di partenza (7)

4. segnare i giorni dei mesi completi (feb 28, mar 31, apr 30, mag 31)

5. segnare i giorni parziali dell’ultimo mese (29)

6. sommare tutti i valori segnati (—>156)

3. E’ ARRIVATO IL MOMENTO DI SCRIVERE CODICE?

Traduciamo in pseudo-codice questa soluzione:

Usiamo indice 1 per la prima data, e indice 2 per la seconda data

days = # days left in month1 month1 += 1 while month1 < month2: days += # days in month1 month1 += 1 days += day2

4. POSSIAMO IMPLEMENTARE LA SOLUZIONE?

Adesso abbiamo una soluzione che funziona, possiamo implementarla in un codice?

a. Si, funziona alla grande

b. Si, non è perfetta ma è un buon inizio

c. No, prima dobbiamo analizzare altri casi

d. No, dobbiamo trovare una soluzione più semplice

Risposta giusta: d


In questa procedura ci sono troppi casi non gestiti:

1. Le due date sono in anni diversi

2. Le due date sono nello stesso mese

3. La seconda data è in un mese precedente della prima data, ma in un anno successivo

4. Non c’è traccia degli anni bisestili


ATTENZIONE

di sicuro questa procedura può essere modificata in modo tale da gestire tutti i casi citati

Questo però richiederebbe la definizione di molti casi speciali

i casi speciali sono l’anticamera preferita dei bug!


Come trovare una soluzione più semplice?

Gli umani odiano fare compiti ripetitivi, quindi cercano di ridurre le azioni. I computer invece no: è meglio fare tante azioni semplici che poche complesse (si riduce la probabilità di sbagliare, ed è più facile da capire)

Allora perché bisogna passare da questa fase? Perché ci aiuta a capire meglio il problema, e ad individuare le criticità


Procedura semplice e meccanica (e noiosa):

1. prendere un calendario

2. cercare la data di inizio

3. contare i giorni uno per uno fino alla data finale (156)

Pseudo-codice: days = 0 while date1 before date2: days +=1 date1 advance to next day

5. CON COSA INIZIAMO?

Adesso siamo pronti a scrivere il codice. Cosa scriviamo per prima?

a. daysBetweenDates

b. nextDay

c. isLeapYear

d. daysInMonth

Risposta giusta: b, anche c

5. CON COSA INIZIAMO?

Input: data Output: la data del giorno successivo

Non implementiamo la versione completa e definitiva, ma solo una prima versione semplificata, dove assumiamo che ogni mese abbia 30 giorni

Dopo averla scritta la testiamo su alcuni casi d’esempio

BUONE NOTIZIE: STIAMO FACENDO PROGRESSI!FARE PROGRESSI = SCRIVERE PICCOLI PEZZI DI CODICE, TESTARLI, E SAPERE COSA FANNO.

6. COSA SCRIVIAMO DOPO?

Abbiamo scritto la prima procedura, qual è il prossimo passo?

a. Perfezioniamo la procedura appena scritta, nextDay

b. Realizziamo una nuova procedura, daysBetweenDates, cioè la procedura generale

Risposta giusta: b


L’approccio giusto e’ quello di fare tanti piccoli passi in una certa direzione, anche se non sono tutti perfetti.

Questo serve per capire se siamo nella direzione giusta, e per scrivere codice in maniera efficiente (= evitare di scrivere cose che non servono, o di scriverle male).


daysBetweenDates ci permetterà di avere una stima dell’output finale.

Non avremo il valore preciso, pero’ ci aiuta a definire i punti cruciali dell’intera soluzione.

In questo caso ci serve una procedura intermedia, dateIsBefore(date1,date2), per sapere se una data è prima di un’altra.

7. LA PARTE “DIFFICILE”

Adesso dobbiamo gestire le parti problematiche: i mesi non sono tutti di 30 giorni, ed alcuni anni sono bisestili.

La strategia che abbiamo seguito ci ha permesso di fare notevoli progressi, affrontando solo task facili.

Abbiamo isolato gli elementi più difficili senza pero’ creare casi speciali.


Per avere la soluzione corretta però prima o poi va affrontata anche la parte difficile.

La cosa importante è affrontare la parte difficile solo quando si è sicuri che abbia senso farlo, e solo quando si hanno le idee più chiare su come farlo (nell’economia dell’intero codice).


Come concludere in 3 fasi (8 passi):

1. (1) creare una “dummy” daysInMonth, che restituisce sempre 30 (2) modificare nextDay per usare daysInMonth (3) test (stessi risultati di prima).

2. (4) modificare daysInMonth, in modo che sia sempre corretta, tranne che per gli anni bisestili (5) test (i risultati sono corretti per tutte le date che non contengono anni bisestili).

3. (6) creare isLeapYear (7) test isLeapYear (8) finalizzare l’intero codice e testare.

CORE DELLA STRATEGIA DI CODING

Core: Scrivere piccoli pezzi di codice e testarli mano a mano che si scrivono.

Altrimenti:

• Non solo il codice finale avrà molti più bug, ma sarà anche difficile trovarli

• L’azione di debug sarà complessa ed anche il mantenimento del codice sarà più lungo e difficoltoso

GUIDA AL PROBLEM SOLVING: 5 PASSI 2 NOTE

Nota 1: don’t panic!

1. Quali sono gli input?

2. Quali sono gli output?

3. Analizzare alcuni esempi a mano

4. Identificare una soluzione meccanica semplice

5. Sviluppare il codice in modo incrementale, testando ogni passo

Nota 2: Non ottimizzare il codice prematuramente

AGENDA

1. Problem solving?

Cos’è, come funziona e come NON funziona

2. Strategie e strumenti

Panoramica sulle tecniche ed i tools più interessanti

3. Un esempio concreto

Codice per calcolare la distanza in giorni

ADESSO TOCCA A VOI

Per gli sviluppatori: provate a risolvere sul serio il problema della data.

Per i designer: provate a trovare un vostro esempio concreto simile a questo.

Quando vi trovate di fronte ad un problema, d’ora in poi razionalizzate la vostra reazione.

REFERENCES

[1] wikipedia: it.wikipedia.org/wiki/Problem_solving

[2] udacity course: intro to computer science: www.udacity.com/course/cs101

Contacts:

email: [email protected]

Linkedin: Luca Naso it.linkedin.com/in/lucanaso

https://it.wikipedia.org/wiki/Problem_solving

https://www.udacity.com/course/cs101

mailto:[email protected]?subject=%5BSlideShare%5D%20Problem%20Solving%20-

http://it.linkedin.com/in/lucanaso

Small Business & Entrepreneurship

Problem Solving