Le scadenze mancate sono comuni nei lavori di programmazione? [chiuso]

18

Era il mio lavoro come libero professionista in oDesk. Ho svolto diversi lavori in precedenza in un determinato momento, ma è stata la prima volta che ho perso la scadenza. È stato un lavoro molto lungo e ho fatto del mio meglio ma ho ancora perso la scadenza. Ora ho molta paura. Perché è colpa mia se ho perso la scadenza.

La mia domanda è: è una grande preoccupazione o le scadenze mancate sono comuni tra i lavori di programmazione, quindi non dovrei preoccuparmi troppo di questo?

freelancing deadlines

1

Dipende completamente dall'ambiente. Ad esempio, il mio ultimo lavoro è stato presso un'agenzia digitale che ha addebitato i clienti in base a stime. Se hai perso la scadenza, l'azienda ha perso denaro. Il mio attuale lavoro è così dinamico che non ci sono scadenze reali .. se la mia attenzione è richiesta altrove mi viene dato il tempo appropriato per dedicarvisi. Forse l'inclusione di questo nella tua domanda ti aiuterà con le risposte.

— Simon Whitehead,

possibile duplicato di Qual è il modo più efficace per comunicare potenziali ritardi nello sviluppo del software?

— moscerino il

3

le scadenze mancate sono comuni in tutti i lavori

— Steven A. Lowe,

2

Spero davvero che stiate comunicando con il cliente la scadenza mancata. Scadono le scadenze mancate, ma non dovrebbe essere inaspettato quando lo fa - dovresti essere in grado di vederlo arrivare e comunicarlo. Di solito rende più semplice che andare semplicemente "No, non ancora pronto".

— Bobson,

6

Fallo velocemente, fallo a buon mercato, fallo bene: scegline due.

— Reactgular,

45

Sì. Le scadenze mancate sono comuni nello sviluppo del software.

Molti liberi professionisti rispettano le scadenze incorrendo in debiti tecnici o nascondendo lo sporco sotto il tappeto.

Parafrasando The Mythical Man Month di Frederick Brooks :

Frederick Brooks, autore di The Mythical Man Month

Le scadenze vengono spesso perse perché i responsabili del progetto continuano a stimare le attività del software nello stesso modo in cui svolgono le attività di ingegneria civile, il che è un approccio imperfetto perché il software è un nuovo settore artigianale senza norme chiare. Questo è così vero che non è possibile revocare il "permesso" di un programmatore di codificare per negligenza, né si può fare causa a qualcuno per la programmazione senza titolo.
Lo sviluppo del software ha una complessità intrinseca che manca ad altre discipline. Un grande programma può avere più componenti di un'auto e questi componenti possono interagire in più modi diversi.
Il software è difficile da visualizzare, quindi vengono utilizzati diversi tipi di diagrammi per vedere diversi aspetti di un progetto e questi aspetti potrebbero non essere ortogonali. L'ingegneria civile, d'altra parte, ha schemi che consentono di vedere impianti idraulici, cablaggi ecc. Tutti nella stessa carta (o strati) in modo ortogonale.
Non è comune, dopo che un ponte o un edificio è stato costruito a metà, per il cliente modificare completamente l'ambito del progetto. Questo è spesso il caso di progetti software.
Lo stato dell'arte nello sviluppo del software non ha raggiunto il punto in cui i progetti software sono ripetibili e quasi privi di rischi. Anche le più grandi società di software come Microsoft possono non rispettare le scadenze di mesi o anni.
La maggior parte dei vaporware non è altro che progetti software che sono stati tagliati a causa di questo tipo di problemi.

In conclusione:

Stime errate e sottostima della complessità, a causa della natura artigianale del processo di sviluppo del software, fanno sì che rimanga una disciplina immatura.

— Tulains Córdova
fonte

11

+ Buona risposta, ma avendo avuto una certa esposizione all'ingegneria meccanica e civile, è divertente come i programmatori facciano facili paragoni con la costruzione di ponti e altre cose, quando non hanno la minima idea di come siano costruiti.

— Mike Dunlavey,

3

Sottoscriverei l'idea che il software sia un piano (in termini di piano in ingegneria, descrivendo ogni dettaglio del progetto). Nel caso dell'ingegneria, il tempo della costruzione fisica domina una così grande varianza nella pianificazione che non ha alcun ruolo. Tuttavia, poiché il software consiste solo in un piano ... "Lo stato dell'arte nello sviluppo del software non ha raggiunto il punto in cui i progetti software sono ripetibili e quasi privi di rischi" - in quei casi perché il progetto lo fa? Se qualcosa è ripetitivo e può essere automatizzato, non deve essere fatto più volte ma può essere fatto una volta e copiato.

— Maciej Piechotka,

2

@ user61852: mi hai frainteso. Il "piano" per l'ingegneria è come "fonte" per l'informatica - ovvero una descrizione dettagliata di ogni componente - ma una volta che lo abbiamo possiamo costruirlo (entrare makeo qualunque altra cosa). Ciò che è "piano" nell'informatica sarebbe un "piano di piano "in ingegneria. La differenza è che makenell'informatica ci vogliono al massimo poche ore mentre la scrittura del codice sorgente (compresi test e integrazione) richiede mesi mentre in ingegneria la pianificazione può richiedere mesi (incluso il calcolo strutturale) mentre la costruzione richiede anni, quindi la varianza della pianificazione ha un impatto minore su quest'ultimo.

— Maciej Piechotka,

1

@ user61852: per quanto riguarda la ripetitività, una cosa su cui i computer sono bravi è l'automazione. Supponiamo che tu debba creare un blog semplice: nel momento in cui avresti delle "stime" precise otterrai un wordpress (o qualsiasi altro sistema di blog) in modo da non doverlo fare (in caso di bridge hai ancora un ambiente diverso, quindi devi adattarti più attentamente poiché la roccia potrebbe essere diversa o potrebbe esserci un habitat per uccelli o potrebbe distruggere la vista) - i programmatori potrebbero essere più responsabili della creazione degli strumenti (il modello di ponte standard).

— Maciej Piechotka,

2

Bonus per la citazione del Mese uomo mitico; Frederick Brooks regge dopo tutti questi anni perché si concentra sulle persone e non sulla tecnologia.

— Michael Shopsin

3

Le scadenze perse non dovrebbero diventare una pratica comune se si desidera continuare a trovare lavoro.

Detto questo, in genere vuoi lasciarti un po 'di spazio in più nelle tue stime nel caso in cui succeda qualcosa (e succede sempre). Non è necessario rivelare che hai aggiunto in tempi supplementari, ma non renderlo irragionevole. Forse tra il 5 e il 10% del tempo totale? L'unico modo per scoprirlo è farlo alcune volte.

Per ottenere davvero buoni risultati, devi sapere quanto tempo ci vuole per codificare un certo tipo di widget ... per esempio, supponiamo che devi creare un widget di scorrimento infinito per il client X. Se ti ci vuole una settimana per distribuirlo in produzione senza errori, è possibile utilizzarlo come base per le stime di scorrimento infinite.

— TJ Trapp
fonte

2

Dò sempre il 20% di spazio quando faccio la stima. Il 5-10% è troppo piccolo. Immagino che dipenda da quanto sei distratto. Lo sviluppatore solista potrebbe non essere affatto distratto

— BЈовић

Sono uno sviluppatore solista e di solito prendo un margine del 10% per i miei progetti.

— Konsole,

Hmmm ... vedi Hofstadter's_law

— Philip,

1

Rispetto al 5-20%, penso che un margine del 100% sia migliore. Sul serio. Ti consente di esplorare le tue opzioni molto meglio. E rispondi a più domande su Stack Exchange.

— Acumenus,

Oh sì, è colpa dello sviluppatore quando un veterano project manager di 15 anni fa pressioni su un ingegnere informatico rookie di 1,5 anni per dargli una stima e poi aggiusta che sia ancora più aggressivo e si comporta come se lo sviluppatore stia rallentando quando il progetto è disossato . Non ho mai lavorato per un manager o un PM che potesse scrivere software e mi stai dicendo che le scadenze non dovrebbero diventare una pratica comune se vuoi continuare a trovare lavoro? Le scadenze perse sono endemiche perché la maggior parte dei PM sono letteralmente incompetenti nel loro lavoro. Il mio miglior manager non era ancora un ingegnere del software, conosceva solo i suoi limiti.

— battere il

3

Le scadenze mancanti non sono rare nello sviluppo del software. È quasi impossibile stimare con precisione la durata di un progetto software.

La professionalità è dimostrata da come la gestisci. Quando sai che perderai una scadenza, informa il tuo cliente il prima possibile in modo che possano pianificare di conseguenza.

— Philipp
fonte

2

È abbastanza comune, ma puoi migliorare. Potresti voler esaminare la stima usando qualcosa di astratto come i punti della storia e tenere traccia della tua velocità per calcolare le stime effettive. Questi concetti sono più comunemente associati alla mischia, ma possono essere utilizzati anche se non si fa la mischia.

La cosa sorprendente della velocità è che comprende tutte le cose immateriali come le interruzioni e la complessità inaspettata che gli sviluppatori hanno difficoltà a tenere in considerazione nelle loro stime. Tutte le probabilità si aggirano nel tempo. Con una media di oltre 10 settimane, le nostre stime di velocità sono state accurate entro circa il 5%. Tuttavia, quando stimiamo le stesse attività in ore, la stessa squadra identica sottostima costantemente del 30-50%.

— Karl Bielefeldt
fonte

1

La mia teoria (non dimostrata) è che gli umani si sono evoluti per sottovalutare i lavori complicati di due o tre a uno. Ogni volta che il Congresso chiede alla NASA qualcosa del genere: quanto costerà costruire una navetta o viaggiare sulla luna, torneranno entro una settimana con un numero. Dopo aver esaurito tutti i costi previsti scoprono che costerà tre volte di più.

Abbiamo scherzato negli anni '70: prendi qualsiasi stima del programmatore, raddoppia il numero, quindi spostalo nella successiva unità di tempo. Pertanto, se un programmatore dice che può essere fatto in due settimane, lo finirà in quattro mesi.

Se qualcuno ha ristrutturato una cucina, in genere pensano "Bene, lo farò tra due settimane". Lo finiscono circa sei settimane dopo.

— Meredith Poor
fonte

1

Cosa c'entra la NASA con la mia domanda?

1

Più precisamente, cosa c'entra l'evoluzione umana con la tua domanda? La NASA è un esempio chiaramente documentato nel registro pubblico di persone addestrate ed esperte che sottovalutano grandi progetti. In breve, la tua esperienza è "naturale".

— Meredith Poor,

Mentre sono d'accordo sul fatto che le stime della maggior parte delle persone sono almeno del doppio, ma la prossima unità di tempo ... hmmmm. Comunque, la NASA è molto brava a stimare compiti che già sanno come fare. Il problema è che le persone non sono molto brave a stimare i compiti quando non sanno cosa non sanno. Essendo che la NASA svolge un lavoro davvero pioneristico, non c'è da meravigliarsi che non sappiano molto di quello che stanno facendo fino a quando non iniziano a farlo. Pertanto, il motivo della sottovalutazione iniziale. Inoltre, alcune persone sono predisposte ad essere ottimiste e altre pessimiste. Non sono sicuro dell'evoluzione.

— Dunk