Cosa succede se non riesci a risolvere un problema? [chiuso]

Sono a un anno dalla laurea e non vedo davvero l'ora di risolvere problemi pratici. Soprattutto quelli non banali che richiedono un po 'di ricerca e molta riflessione.

Ma allo stesso tempo, questa è anche la mia più grande paura: affrontare un problema che non sono in grado di risolvere, non importa quanto ci provi. E con la pressione di consegnare il codice su scadenze imminenti proprio dietro l'angolo, sembra un po 'spaventoso quando lo si visualizza dai campi da gioco sicuri su uni (dove la cosa peggiore che può accadere è che devi ripetere un corso o un esame).

Quindi, per coloro che sono stati nel settore per un periodo di tempo più lungo, cosa accadrebbe se ti venisse detto di risolvere un problema che non potevi? È successo e, in tal caso, cosa è successo? Lo hanno semplicemente lasciato cadere e hanno detto "Oh bene, immagino che possiamo accontentarci di qualcos'altro"? Ci sono state conseguenze? Sei stato rimproverato o addirittura licenziato?

Prima di tutto, la tua paura è molto sana e normale. Ecco le mie riflessioni dopo circa 15 anni nel settore del software.
Ecco alcune domande da porsi:

1. Non si capisce il problema?
2. Sai che il problema è irrisolvibile (entro i limiti di tempo / budget)?
3. Non sai come risolvere il problema?
4. Il tuo cliente / capo chiede l'impossibile.
5. Ne vale la pena? (ROI)
6. È un problema REALE ?

1) Prima di tutto, assicurati di aver capito il problema. Non esistono domande stupide. Capisci cosa ti chiede il tuo cliente / capo rispetto a ciò di cui hanno bisogno?

2) Questo accadrà. "Costruiscimi un ponte entro domani" . Assicurati di sapere per certo che un problema è irrisolvibile nei tuoi limiti. Il tuo cliente / capo potrebbe essere flessibile in termini di tempo / budget e questi possono essere modificati per darti più tempo / budget.

3) Se il problema è comprensibile e i vincoli sono ragionevoli, e c'è una tecnologia che può risolverlo, ma semplicemente non ne sai abbastanza ... questo è ciò StackOverflowche serve a Internet. Assicurati di fare prima la tua ricerca. Prova a porre domande esplicite con risposte quantificabili. Chiedi ai tuoi colleghi. Fai una sessione di progettazione.

4) Questa è una variante della risposta numero 2. Sembra che il tuo cliente / capo stia chiedendo l'impossibile. Fare qualche ricerca. Non dire mai che il problema è irrisolvibile, a meno che tu non sappia esattamente perché e puoi chiarire.

5) ROI sta per Return On Investment. Questo si riferisce a un investimento nel tempo. Il tuo tempo!. Il problema è abbastanza importante da risolvere per garantire la quantità di tempo necessaria per ricercare e risolvere il problema. Discutilo con il tuo cliente / capo

6) È un vero problema. I clienti, spesso volte, capiscono quello che vogliono, ma non capiscono necessariamente di cosa hanno bisogno. Cerca di capire di cosa ha realmente bisogno il tuo cliente / capo e discuterne con loro.

Spero che queste linee guida ti possano aiutare.

Due cose da ricordare se sei bloccato con un problema apparentemente irrisolvibile:

• Fai sapere agli altri che sei bloccato il prima possibile. Li aiuterà a regolare la stima in tempo prima che sia troppo tardi.

• Se vedi un modo per risolvere un problema non funziona: lascialo cadere prima di perdere troppo tempo. Chiedi aiuto o prova un approccio diverso. Non si tratta di dimostrarti duro e intelligente, si tratta di fare le cose.

Vado a StackOverflow ;)

Ma scherzando a parte, non temere l'ignoto. Tutta la tua carriera dovrà affrontare l'ignoto, perché se lo hai già risolto, la prossima volta non sarà un problema.

Dovrò rispondere con una semplice risposta: chiedo aiuto. Proprio come gli altri a volte mi chiedono aiuto quando sono bloccati nel tentativo di trovare una soluzione per qualcosa.

Modifica: dovrei menzionare che trovo spesso la soluzione semplicemente descrivendo il problema a un collega, o talvolta anche quando inizio a pubblicare una domanda su siti come StackOverflow.

Guarda da diverse angolazioni

L'ho incontrato molte volte, di solito quello che succede è:

• Hai un problema, inizialmente hai un'idea nella tua mente su come risolverlo.
• Quando si tratta di implementare effettivamente la soluzione, si scopre che non funziona (probabilmente a causa del modello debole del problema reale).
• Dopo aver lottato per risolvere il problema, sia che si tratti di ulteriori ricerche o di chiedere ad altri. Niente di tutto ciò funziona, la pura frustrazione!

Finalmente opti per quello che non volevi fare ->

"The Dirty Hack"

Funziona, ma ti senti sporco ...

Di solito, ottengo qualcuno più intelligente di me per risolverlo. Lo fa ed è il mio capo. Mi sento stupido. Andiamo avanti.

Dipende dal motivo per cui non sei in grado ...

• logicamente impossibile: discuterne con chi ha scritto i requisiti, forse c'è un malinteso. Esempio: a un certo punto, la specifica dice che l'applicazione deve apparire nativa su tutte le piattaforme (Windows / Linux / Mac) e, in un altro posto, afferma che il programma deve apparire esattamente identico su tutte le piattaforme

• tecnicamente impossibile: rivaluta gli strumenti con cui stai lavorando, forse non sono appropriati. Discuti il ​​problema con i tuoi colleghi e il project manager. Esempio: requisiti hard realtime in un ambiente in cui la garbage collection può interrompere l'esecuzione per un tempo indeterminato

• prestazioni insufficienti: forse stai usando l'algoritmo sbagliato, o forse il problema è troppo difficile (ad esempio NP-hard) e i requisiti non ne tengono conto. Rivaluta l'algoritmo che stai utilizzando, forse c'è un modo più veloce. Discuti il ​​problema con i tuoi colleghi e il project manager. Considera di passare a un euristico abbastanza buono invece di un risultato perfetto. Esempio: ottimizzazione del percorso con dozzine o persino centinaia di nodi

• semplicemente non sai come farlo: chiedi ai tuoi colleghi, chiedi a StackOverflow, cerca in Internet. Contatta il supporto dello strumento / lib che stai utilizzando. Discutilo con il project manager.

• dovrebbe funzionare, ma non funziona e non hai idea del perché: rifattorizza il programma per renderlo più testabile. Considerare le condizioni di gara, sono spesso la ragione di bug difficili da trovare. Chiedi aiuto ai colleghi, quattro occhi ne vedono più di due. Controlla su Internet la presenza di bug noti negli strumenti / librerie che stai utilizzando.

Penso che altre persone sottolineino bene come affrontarlo in modo professionale. Vorrei dire come affrontare il sentimento personale come la frustrazione, la paura.

In conclusione, sarai FINE anche se non risolvi i problemi in modo tempestivo. La vita va a vanti.

A volte, il programma verrebbe spinto. Il progetto avrebbe successo o fallito. Potresti essere licenziato e avere un ottimo lavoro. Non lo sai mai.

Non fraintendetemi. Non significa che sia OK lasciare che il problema sia lì. Tutto quello che possiamo fare è fare del mio meglio e lasciarlo andare.

A volte, penso che la frustrazione, la paura di non risolvere il problema sia la mia vita come sviluppatore medio.

Non sono sicuro di dire che non potrei risolvere un problema, ma ci sono stati casi in cui ho rinunciato a provare a risolvere un problema. Dopo aver impiegato molte ore nel cercare di correggere un bug o implementare alcune funzionalità che non ho idea di come farlo, potrei dire a qualcuno del mio team, team leader o manager, "Sono bloccato su questo. Cosa vuoi che faccia? " in modo che sappiano dove sono. Potrebbero dire "Continua, pensiamo che lo otterrai" o "Passa a qualcos'altro che non è così importante" o poche altre cose e poi saprò cosa dovrei fare.

Ho avuto dei bug che non ho risolto e alcune funzionalità che non sono state completate, certo. Mentre posso provare a fare qualcosa, non tutto è in mio potere per risolvere in un tempo ragionevole. Un punto chiave in questo è avere una comunicazione in modo che i tuoi superiori sappiano dove ti trovi.

Detto questo, ho avuto un paio di volte in cui mi sono imbattuto in alcune circostanze piuttosto speciali:

1. Mentre lavoravo in una grande banca canadese a Toronto, mi sarebbe stato chiesto di fare tutti i tipi di cose che non sapevo fare quando mi è stato assegnato l'incarico. Ad esempio, mi è stato chiesto di provare questo metodo per proteggere i laptop in cui i tasti "Esc" e "Invio" sono stati scambiati all'avvio e con la giusta sequenza di tasti il ​​laptop sarebbe di nuovo utilizzabile che sembrava bizzarro da provare a capire fuori, "Funzionerebbe? Come faccio a sapere che sarebbe o non andrebbe bene con gli utenti?" C'erano altre attività che non avevo l'hardware o altre risorse per farlo. Allo stesso tempo, è stato piuttosto istruttivo in quanto ciò mi ha dato molte cose da notare su qualsiasi situazione lavorativa futura per prevenire problemi. Cose come garantire quando sono pagato, come viene monitorato il mio tempo,

2. Mentre lavoravo presso un fornitore di servizi applicativi a Calgary, mi è stato dato questo progetto di provare a creare una copia di un altro sito Web all'interno della nostra applicazione interna che abbiamo venduto come servizio. Un punto chiave qui è che non mi è stata data una linea temporale o suggerimenti su quale parte fare prima, solo ricerche generali e un mese dopo mi è stata chiesta una demo proprio mentre stavo avendo una brutta reazione ad alcuni farmaci antidolorifici. Quella reazione è durata una settimana in cui mi sono tolto improvvisamente dal lavoro e poi la settimana successiva sono andato a un evento Microsoft che è stato un po 'l'ultima goccia quando sono stato licenziato il giorno successivo. Qualcosa da notare qui è come ho avuto un rapporto piuttosto povero con il mio capo poiché ogni volta che si avvicinava alla mia zona il mio pensiero immediato era: "Ora che cosa c'è che non va?"

Come altri hanno già detto, la comunicazione è fondamentale: far sapere alle persone (chi sarà colpito) quando sei bloccato: il tuo capo, i membri del team, i clienti, ecc.

Un collaboratore acuto una volta mi ha instillato che il successo ha radici in due cose:

1. Le relazioni
2. aspettative

Avere una buona relazione, suppongo, è una funzione di una buona comunicazione e di anticipare le aspettative.

Seguo il principio Polya:

"Se c'è un problema che non puoi risolvere, allora c'è un problema più semplice che non puoi risolvere: trovalo."

George Polya

Il bello del principio è che a un certo punto ci sarà un problema abbastanza piccolo e che sarai in grado di risolvere il che, si spera se hai fatto le cose nel modo giusto, ti consentirà di avviare una soluzione al problema originale. Questo principio non mi ha ancora deluso.

Le risposte " cercare aiuto " sono decisamente corrette. È altamente improbabile che tu sia la prima persona ad aver mai incontrato un problema particolare.

Ma come esperimento, se non ci fosse aiuto? E se dovessi risolvere il problema da solo? La più importante capacità di problem solving è la capacità di identificare e contestare i propri presupposti . Se riesci a elencare i tuoi presupposti su un problema uno a uno ed eliminarli a turno, alla fine ti imbatterai nell'assunto errato e di conseguenza si apriranno nuove possibilità per una soluzione.

(A proposito, questo è anche l'approccio migliore quando non riesci a vedere una risposta a un problema che ottieni durante un colloquio di lavoro. Elenca verbalmente i tuoi presupposti e determina quale è sbagliato e quindi attacca nuovamente il problema. Quasi tutte le "domande trabocchetto" si basano su presupposti naturali ma difettosi).

Chiedere aiuto è davvero la risposta migliore, ma ecco un po 'di più che può essere utile.

Quindi, per coloro che sono stati nel settore per un periodo di tempo più lungo, cosa accadrebbe se ti venisse detto di risolvere un problema che non potevi? È successo e, in tal caso, cosa è successo? Lo hanno semplicemente lasciato cadere e hanno detto "Oh bene, immagino che possiamo accontentarci di qualcos'altro"? Ci sono state conseguenze? Sei stato rimproverato o addirittura licenziato?

Sì, mi è successo, e no, non sono mai stato rimproverato o licenziato per questo, perché ...

Nel settore, si tratta di risolvere i problemi in tempo e nel rispetto del budget, e i manager decenti capiscono che non è sempre possibile.

Quello che succede davvero è che il tuo manager dice "Mi piacerebbe che tu facessi X, cosa pensi che ci vorrà?" E puoi dare molte risposte. I buoni includono:

• Ho fatto qualcosa di molto simile a questo, quindi penso che ci vorranno tre settimane e testare l'hardware per un valore di $ 3.000.
• Ho qualcosa in genere simile a questo. Quindi lasciami riflettere e torna da te oggi pomeriggio.
• Non ho mai fatto niente del genere. Quindi lasciami fare una ricerca e torna da te domani.
• Nessuno al mondo lo ha mai fatto. Se vuoi esaminarlo, ci vorranno due settimane per fare abbastanza sperimentazione per fare una stima.

È compito del manager decidere se e come procedere. Se decidono di procedere, è tuo compito rispettare le tue stime o far sapere al manager se c'è un impedimento. Fintanto che lo fai, in un'azienda ragionevole non ci saranno conseguenze negative.

Naturalmente, ci sono anche aziende irragionevoli che non ti danno il tempo o le risorse per svolgere il tuo lavoro. Ho lavorato su alcuni di questi e a tutti sono stati consegnati problemi che non potevano essere risolti nei limiti della società. Uno di loro ha licenziato circa il 98% del personale addetto alla programmazione in otto mesi, e questa è stata certamente una conseguenza, ma non è stato indirizzato personalmente a me, e continuo a considerare il mio capo e il suo capo da lì come buoni amici.

Esistono molti tipi diversi di problemi su cui verrai sconcertato e molti hanno modi diversi di gestirli.

Un tipo di problema è l'implementazione di qualcosa che non hai mai visto prima come una strana API audio o qualcosa del genere. In questo caso, chiedo sul SO, sul serio.

Un altro è un problema molto grande da risolvere. Questo tipo di problema può essere affrontato in modo iterativo. Ti dicono "Implementa Humongous". Lo guardi e scrivi quanti più passaggi puoi capire. Quindi si scompongono i passaggi complicati in passaggi più piccoli. Quando sei costretto a pensare a piccoli passi, diventano più chiari. In caso di difficoltà tecniche, provare un'implementazione di prova e chiedere qui se necessario.

Uno dei problemi più fastidiosi sono le richieste mal specificate. Vogliono solo una cosa che fa "x" e non ti dicono come dovrebbe essere fatto. Per questi un buon approccio è il prototipo di un'interfaccia (in genere una GUI) e consentire a qualcuno di giocarci.

Quindi ci sono vincoli di tempo che non possono essere rispettati. Ciò comporta spesso la modifica delle aspettative e la consegna di prototipi funzionali.

In genere troverai la strada attraverso le cose in un modo o nell'altro. È spaventoso, ma una volta che ci sei dentro puoi praticamente trovare sempre un modo.

La tua scommessa migliore potrebbe essere semplicemente dipingere le parole "Don't Panic" all'esterno del tuo laptop. E non dimenticare il tuo asciugamano.

La mia sequenza di risoluzione dei problemi (ogni spet successivo viene eseguito solo se il precedente non ha funzionato):

1. Prova a google
2. Chiedi a qualcuno
3. Cerca SO direttamente (ignorando Google)
4. Pensare
5. Fumo (== testa chiara)
6. Fai una domanda su SO
7. Aspetta fino al mattino (== cancella ancora di più)
8. Usa quell'hack sporco e stai male con me stesso :(

I cattivi problemi vengono risolti nei passaggi 5-6.

I problemi veramente cattivi di solito hanno bisogno di un po 'di tempo (il passaggio 7 è LA soluzione alla maggior parte dei problemi "sembra che non posso fare nulla"). E intendo dire: passare a un'altra attività per il resto della giornata e provare a risolvere il problema per prima cosa al mattino. Questo fa miracoli.

E solo allora arriva il passaggio 8.

Non ho sentito parlare di nulla di simile. Prima di tutto non ti viene mai dato un problema che non può essere risolto affatto. Il problema potrebbe essere difficile e potrebbe richiedere del tempo per risolverlo. Quando ti viene dato un problema, dovrai dire che è il tempo che richiederò. Se nella tua ricerca pensi che questo problema non possa davvero essere risolto, devi alzare una bandiera e dire al tuo manager che questo problema richiederà un po 'più di tempo o è davvero difficile da risolvere. Riguarda il programma. Se prometti qualcosa e non sarai in grado di consegnare, allora è un problema. Ma se continui a dire il tuo stato e le tue preoccupazioni, è responsabilità del manager occuparsene. Dovrebbe reindirizzarti alla persona corretta che può aiutare o adattare il programma.

C'è qualche grande consiglio qui! Il mio valore di due centesimi è; Non lasciarti sopraffare dal GRANDE problema, non dimenticare che la parte eccitante e stimolante della risoluzione di un problema è la scomposizione in una serie di sotto-problemi gestibili e, cosa più importante, comprensibile, che a sua volta si rompono ancora e ancora in più piccoli sotto-problemi. Ogni buon programmatore lo farà di solito minuto per minuto mentre sta creando codice (usando funzioni, metodi, sotto-routine ecc. Per aiutare a ridurre la complessità complessiva di una sezione di codice) e questa metodologia si applica in genere a qualsiasi GRANDE problema affrontare nella vita (non solo al lavoro).

Dipende da quale sia il problema specifico, ovviamente. Ma la risposta può essere una delle seguenti:

1. Trova una soluzione alternativa / sostituzione
2. Acquista una soluzione commerciale che approssima ciò che desideri
3. Non mollare e continuare a lavorarci finché è necessario fino a quando non ci riesci .

Il numero 3 potrebbe richiedere una pausa dal problema e rivederlo settimane o mesi dopo. Questo aiuta spesso.

Nella mia esperienza, a volte c'è un problema che non puoi risolvere, almeno nella restrizione temporale. Quindi, in cerca di aiuto il più presto possibile, dopo qualche sforzo risolutivo hai fallito .

Ricorda la regola empirica: osserva sempre il motivo per cui il capo ti assume. Fai tutto ciò che pensi di poter fare per il miglior risultato di lavoro, e talvolta è un rapporto di fallimento precoce (molto meglio di un ritardo).

In breve, se pensi di trovare la soluzione, sentiti libero di provare, ma dai al tuo capo una stima del rischio e del costo del tempo. È il loro problema adesso.

Se i progetti da cento milioni di dollari possono fallire anche con persone esperte, non dovresti preoccuparti del tuo fallimento poiché sei ancora uno studente. Ho avuto un problema su cui lavorare e ho scoperto che se è qualcosa su cui rimani bloccato, devi registrare ogni tentativo fatto per risolverlo.

Questo aiuta:

1. Prova dei tentativi fatti per risolvere un problema.
2. La registrazione di questo tipo di errore è importante, quindi si impara da esso e non lo si fa più qualche giorno dopo pensando che funzionerà.

La mia esperienza è che un nuovo laureato non viene gettato nel profondo. Invece, probabilmente farai parte di un team che include anche sviluppatori esperti.

Il mio consiglio sarebbe: farne uso. Quando non sei sicuro di come affrontare un problema o se vuoi sapere se la tua soluzione sta andando nella giusta direzione, discuterne con loro. E se senti di essere bloccato da qualche parte, prendi uno dei ragazzi esperti e spiega il tuo problema e chiedi aiuto.

Molto spesso, solo spiegare il tuo problema rivelerà una soluzione e spiegare la tua soluzione potrebbe anche rivelare difetti in essa.

Spesso ciò accade perché non hai definito il problema in modo corretto e accurato. Forse stai cercando di risolvere una soluzione preconcetta anziché il problema stesso.

Il problema è solo ciò che osservi, non quello che immagini.

"La mia macchina insanguinata non si avvia" è un problema. "La batteria è scarica." è una soluzione preconcetta al problema di avviamento dell'auto. Anche testare la batteria non dimostra che sia l'unica causa del problema. A meno che tu non abbia effettivamente ricaricato o sostituito la batteria e avviato correttamente la macchina, non hai prove che la batteria sia la causa del problema.

Semplifica e continua a semplificare. Dividilo in piccole parti. Se non riesci a risolvere quelle parti, distruggile. Ti sentirai meglio. Quindi scomporlo in diverse piccole parti. Ognuna di quelle parti deve essere un fenomeno osservabile.