Ingegneria del software - Sindrome del "progetto prezioso"? [duplicare]

Come Churchill ha notoriamente osservato, "la massima 'nulla ha bisogno ma la perfezione' può essere scritta in modo più breve: p-a-r-a-l-y-s-i-s" .

Devi interiorizzare l'idea che questo approccio non sia professionale.

Oppure, come ha detto Jamie Zawinski (in "Coders at Work", raccomandato da Joel Spolsky una volta ), "Alla fine della giornata, spedisci la cosa del cazzo! È fantastico riscrivere il tuo codice e renderlo più pulito e per la terza volta sarà davvero bello. Ma non è questo il punto non sei qui per scrivere codice, sei qui per spedire prodotti. "

E ciò contiene un'osservazione importante. Il lavoro di un programmatore non è scrivere codice! È per risolvere i problemi. Se un problema può essere risolto non scrivendo una riga di codice o cancellando il codice, tanto meglio.

Vedi il tuo lavoro come uno di un risolutore di problemi, che capita solo di essere un programmatore. Non viceversa. Uno spostamento delle priorità segue organicamente.

Soffro della stessa sindrome, ma ce la faccio con progetti di hobby, in cui non ho una scadenza e ho il mio piccolo mondo perfetto. (E sì, in genere finiscono paralizzati dal perfezionismo). Ma almeno grazie a ciò mi sto sfogando da tutti i compromessi marci che devo fare al lavoro, e tutti sono contenti:)

Quindi il mio consiglio sarebbe: cercare di scrivere programmi perfetti nel tuo tempo libero. Imparerai che stai inseguendo un miraggio e non ne vale la pena. Oppure potresti diventare dipendente dal brivido di inseguire questo miraggio, ma dal momento che è il tuo tempo libero, la tua reputazione professionale non sarà esposta al rischio, e non ti sentirai così affettuoso-affamato al tuo pragmatico, giorno per giorno lavoro. O forse imparerai davvero a scrivere programmi perfetti in tempo limitato. O il risultato è buono!

If you absolutely cannot work on a solo project then how do you explain it to your boss so that it doesn't seem like you're incompetent?

Mi dispiace dirlo, ma non sarebbe sembrare così. è una forma di incompetenza, fortunatamente una che può essere trattata abbastanza facilmente.

Una cosa che potrei suggerire dalla mia esperienza è di avere una chiara " definizione di fatto " per ogni attività su cui stai lavorando. Sebbene questo termine provenga principalmente dall'ambiente di mischia (vedere una descrizione qui ) potrebbe anche essere utile adottarlo quando si lavora da solo su un progetto.

L'idea principale è che tu definisca criteri chiari e misurabili che descrivono quando una determinata attività è completata. Ma l'importante è che funzioni anche al contrario: Non appena vengono raggiunti i criteri, l'attività viene considerata completata e non è necessario dedicare altro lavoro a questo compito specifico. Se pensi ancora di poter lucidare o ritoccare le cose un po 'di più, definisci un nuovo compito (magari con una priorità più bassa) e definisci esattamente cosa e come vuoi lucidarlo (sempre con chiari criteri di accettazione). Ma inizia questa nuova attività solo dopo aver terminato tutte le altre attività con una priorità più alta.

In questo modo puoi assicurarti di fare solo il lavoro che deve essere fatto per far funzionare il programma. Certo, questo potrebbe anche significare che il software non è ancora perfetto, ma non importa, almeno fa quello che dovrebbe, e miglioramenti possono essere fatti dopo.

Se il tuo progetto ha almeno un proprietario di un prodotto (o una persona con un ruolo equivalente) entrambi potresti sederti insieme e definire i DOD per ogni attività insieme.

How do you overcome it?

Vedo (cercando intenzionalmente) altre persone che commettono errori e stanno bene con questo. Questo attenua la mia paura degli errori.

If you absolutely cannot work on a solo project then how do you explain it to your boss so that it doesn't seem like you're incompetent?

Non so come appare dagli occhi del mio capo. Non posso leggere le menti degli altri. Se penso di sembrare incompetente, è solo la mia paura di apparire incompetente. E se sono davvero incompetente e provo a fingere di non esserlo, caccio comunque alla fine, quindi confesso meglio.

Non è chiaro dalla domanda se i progetti siano stati effettivamente rilasciati a un certo punto o se fossero stati abbandonati prima del primo rilascio.

In quest'ultimo caso è chiaro che è necessario un cambiamento di mentalità. Noi ingegneri vorremmo sempre perfezionare il nostro prodotto e sentirci a disagio quando dobbiamo rilasciare qualcosa che ha ancora molto da migliorare. Ma questo è esattamente ciò che deve essere fatto. Devi rilasciare presto e rilasciare spesso e accettare il fatto che la prima versione sarà dolorosamente pessima. Questo è l'unico modo per scrivere software di qualità che risolva effettivamente i problemi che i tuoi utenti non sono in grado di risolvere.

Potrebbe anche essere utile per te familiarizzare con il concetto di Prodotto minimo vitale e forse anche leggere il < a href="http://en.wikipedia.org/wiki/Lean_startup"> Lean Startup prenota da Eric Ries.