2009-09-02 6 views
6

Al momento, sono estremamente frustrato perché stavo sviluppando un meccanismo interessante per ottimizzare un sistema di calcolo riducendo il numero di calcoli da circa mezzo milione a poche migliaia. Ci è voluto un sacco di tempo per esaminare e analizzare i dati, scrivere le cose, fare alcuni test e, in generale, fare solo il mio lavoro. Poi abbiamo avuto una riunione di progetto. Ho spiegato cosa volevo fare, quanto tempo ci sarebbe voluto e quanto avrebbe potuto migliorare il progetto e persino rendere possibile la creazione di nuove funzionalità. Poi è stato deciso che era troppo tempo per fare tutto questo prima della prossima scadenza. (Una scadenza che dovrebbe essere prorogata se mi fosse stato permesso di continuare.) Un rapido brainstorm ha chiarito che è possibile utilizzare un semplice work-around che potrebbe ritardare l'ottimizzazione per qualche altro mese.Come gestire un progetto quando è congelato/ritardato per un tempo indefinito

Bene, difficile!

Okay ... Ho appena scritto la frustrazione. Ora la domanda ... ora ho tutto questo disegno nella mia testa. Gran parte di esso sono solo schemi e fogli di carta con testo scritto a mano, alcune stampe e anche alcune domande qui a SO. Queste idee saranno congelate per un po ', ma dovrò ricordarle nuovamente in futuro. Posso ottenere un giorno, forse due per ripulire gli appunti e iniziare a documentare le cose.

Quindi ho bisogno di consigli su come ricordare meglio il mio progetto, ad es. 4 mesi da ora. O forse anche tra un anno ... Quale sarebbe il più importante da scrivere? O documento? (Considerando il poco tempo che ho ...) Qualche suggerimento?

Perché? Altrimenti mi sentirò frustrato ancora tra quattro mesi. :-)

+1

Sto votando per chiudere questa domanda come off-topic perché non si tratta di programmazione. –

+0

Prima di tutto, questa domanda ha 6 anni. In secondo luogo, riguarda la gestione dei progetti, che è una parte importante della programmazione! Ogni programmatore deve fare i conti con situazioni come queste in cui un progetto viene messo nel congelatore per mesi prima che venga ripreso. –

+0

Ok, eccoci di nuovo .. Si prega di dare un'occhiata a questa risposta - https://meta.stackoverflow.com/a/343841/1000551. La tua domanda non è una domanda di codice e non è esclusiva dello sviluppo del software. Immagina di essere una specie di scienziato (ad es.fisica) e ti trovi nella stessa situazione. –

risposta

3

Dipende da ciò che funziona per te e da come ti piace imparare. Mi piace usare diagrammi, quindi nella situazione in cui ho progettato un algoritmo interessante (anche se complesso come questo!) Faccio quanto segue:

1) Disegna l'algoritmo su carta o scrivilo .

2) Aggiungere annotazioni per rendere completo sensato.

3) Descrivi l'algoritmo a qualcun altro solo da ciò che hai disegnato. Questo ti impedisce di riempire gli spazi vuoti dalla tua conoscenza dell'algoritmo.

4) Se vi sono lacune nella descrizione, aggiungere ulteriori dettagli man mano che si procede, in modo che il documento diventi un registro completo della descrizione.

5) Metti via il disegno per una settimana e verifica se ha ancora senso. A questo punto dovrebbe essere abbastanza familiare da aggiungere dettagli mancanti.

Se sarà abbastanza chiaro tra un anno - o se vorrete anche usarlo - resta da vedere.

Spero che questo aiuti!

+0

Buon consiglio! Ho già trascorso due mesi su questo progetto, prima per capire il problema del dominio, quindi per analizzare tutti i dati richiesti, quindi per elaborare un algoritmo corretto. Se il progetto dovesse continuare, scriverei anche la documentazione in questo momento, ma anche con un leggero codice. E avrei più tempo per la documentazione. Ora, la principale frustrazione è che tutto si trova per lo più nella mia testa, con solo un giorno per ottenerlo in un documento ... Odio semplicemente affrettare le cose ... –

7

Nella mia esperienza, i vecchi disegni sembrano sempre vecchi quando rispolverati. Nei prossimi mesi il codice esistente cambierà, i requisiti cambieranno e cambierai come programmatore. Forse dovresti scrivere una breve spiegazione e supporre che dovrai comunque rielaborarla completamente in futuro.

Non essere frustrato con progetti specifici, concentrare le tue energie sul miglioramento come sviluppatore. E porta questa esperienza con te.

1

Un documento dettagliato sui requisiti che descrive tutti gli ingressi e le uscite è probabilmente uno dei modi migliori per iniziare. Se è un design di codice davvero unico, il metacode potrebbe essere un buon passo. vale a dire.

[Meta Object] 

    [Return String(string param1, string param2)] 

     Return param1 + " " + param2 

    [Return Integer(integer param1, integer param2, integer param3)] 

     Return (param1 + param3)/param2 

[End Meta Object] 

Far sembrare qualcosa di simile alla lingua w/o test o qualsiasi cosa, basta avere il LOGC teorica su carta (notepad) in questo modo si dispone di una scheda di primavera, quando/se mai a tornare ad esso ... quindi documentare le luci del giorno fuori di esso.

+0

Invece di metacode, tendo a creare un XSD con XmlSpy. Offre una buona panoramica grafica ed è molto veloce da creare, se hai esperienza con i fogli di stile. –

2

In termini di frustrazione, in genere prova a visualizzare un progetto come un viaggio piuttosto che una destinazione.

Se avete prestato attenzione avrete ottenuto un sacco fuori dal progetto fino ad oggi - le cose che hai imparato sulla tecnologia e il business, moduli creati di codice è possibile riutilizzare, avrete costruito rapporti con membri del team o utenti, commesso errori che non farai di nuovo e così via. Potrebbe aiutarti personalmente a scrivere un elenco di ciò che sai ora che non lo avevi all'inizio del progetto.

In definitiva, la società potrebbe non aver implementato il progetto, ma gran parte del beneficio che ti viene fornito come persona e sviluppatore è ancora lì. Infatti, spesso si impara di più su progetti che vanno male e in aziende che non sono eccezionali rispetto a quando le cose funzionano come un sogno.

Come per il resto della vita, più soddisfazione si ottiene dalle cose giorno per giorno, e meno ci si concentra solo sui risultati del tendone, più felice sarà.

Non sto dicendo che il recapito di progetti non è buono - è ovviamente il motivo per cui codifichiamo - ma non è interamente sotto il nostro controllo, quindi devi essere realistico ed equilibrato su quanto ti lasci influenzare.

(L'obbligo a qualcosa di Joel e Jeff ha scritto: http://www.codinghorror.com/blog/archives/001297.html)

1

Se avete trovato la soluzione una volta, le probabilità sono alte scoprirete soluzione anche 4 mesi su tutta la linea per lo stesso problema. Ciò che non devi assolutamente perdere è il vero problema.

È necessario ridurre a icona tutti i problemi di ottimizzazione che costituiscono il problema, ovvero i problemi oi problemi effettivi. È necessario mantenere ordinatamente note di questi problemi.

Ora, la prossima volta [diciamo 4 mesi sulla linea] quando si desidera tornare di nuovo a questo. Hai solo bisogno di leggere i problemi dei tuoi appunti e il tuo cervello inizierà a lavorare nella direzione corretta come in precedenza.

Per migliorare ulteriormente, è possibile provare a passare attraverso le note del problema una volta al mese o due. Questo allenerà il tuo cervello verso la soluzione, come farai ogni volta con la soluzione proprio come hai fatto per la prima volta.

Inoltre, se riesci a ridurre il problema o la preoccupazione che ti ha motivato abbastanza a lottare per la soluzione, sarebbe fantastico.

Problemi correlati