Numerosi ostacoli imprevisti che rovinano qualsiasi piano di progetto [chiuso]

Question

Numerosi ostacoli imprevisti che rovinano qualsiasi piano di progetto [chiuso]

#1 da (2 voti)
#2 da (2 voti)
#3 da (1 voti)

0

Sto lavorando come sviluppatore di software e sto lottando con questo problema più e più volte per quasi tredici anni. Sembra che non ci sia alcun modo per uscire dal seguente problema.

E succede anche con piccoli progetti.

Ad esempio, ho intenzione di scrivere un'estensione per Microsoft Visual Studio. Scarico materiale didattico, libro sull'argomento e tempo per l'apprendimento e lo sviluppo.

Tuttavia, durante lo sviluppo, sorgono molti problemi apparentemente banali, ad esempio:

Perché lo script si rifiuta di eliminare il file?
Perché Visual Studio non registra l'estensione?
(dopo due giorni) OK, lo registra, ma ora si è rotto. Come risolverlo?

ciascuno di questi "piccoli" ostacoli richiede solitamente 1-5 giorni per essere risolto e il progetto consuma diverse volte più ore uomo del previsto.

Forse succede solo perché sto lavorando su una piattaforma Microsoft e molti dei loro Framework e architetture sono un po 'confusi e mal documentati.

Mi piacerebbe che la maggior parte dei problemi si risolvesse trovando risposta in un libro o documentazione ufficiale (MSDN), ma l'unica risposta che di solito trovo è su qualche forum o blog personale su Google dopo aver cercato disperatamente qualsiasi informazione pertinente sull'argomento .

Hai le stesse difficoltà? Hai delle tecniche su come prevenire questi problemi?

Stavo pensando di moltiplicare semplicemente il tempo previsto per un determinato progetto di qualche fattore, ma questo non aiuta. Alcuni progetti vengono svolti rapidamente e alcuni impiegano mesi e il fattore guida qui sono questi piccoli "difetti" che richiedono ai programmatori intere settimane di risoluzione.

Devo ammettere che molti di questi ostacoli mi demoralizzano e mi drenano dalla concentrazione e dalla gioia del lavoro (a chi piace tornare al lavoro quando deve risolvere qualche stupido problema di registro o strano bug del framework invece di fare un lavoro creativo? )

Dopo che il progetto è finalmente finito, mi sento come morire da mille tagli.

project-management planning project-planning

posta Libor 18.10.2012 - 21:29

fonte

3 risposte

Leggi altre domande sui tag project-management planning project-planning

Come possono testare gli utenti accedere a un'app per iOS non pubblicata? Applicazione di Revamp [chiusa]

score 2 · Answer 1

Immagina di fare un lavoro creativo: creare un nuovo Boeing, più grande, più potente, ecc.

Un giorno, stai aspettando un camion che dovrebbe consegnare i bulloni per una parte dell'aereo, ma sembra che ci sia stato un errore umano, quindi invece di arrivare nella tua città, il camion è bloccato al centro del nulla e sarà in ritardo.
Un altro giorno, alcuni lavoratori molto importanti e molto esperti vengono investiti da un autobus. Per continuare il lavoro, devi trovare rapidamente un'altra persona con esperienza.
Scoprirai anche che il cablaggio spedito da diversi paesi è incompatibile. Dovresti ricablare gran parte dell'aeromobile e aspettarti ritardi importanti.
Quando l'aereo è finito, sembra che la coda stia sfregando la pista durante il decollo mentre non dovrebbe. Devi gestire questa situazione e spiegare ai tuoi clienti perché sei in ritardo di tre mesi a causa di ciò.

La casualità che hai con i progetti IT esiste ovunque. Questo è un rischio e non puoi evitarlo. Puoi ancora ridurlo :

Riutilizzando il codice scritto solo da sviluppatori esperti. Se prendi un pezzo di codice scritto da un programmatore sconosciuto, sottopagato, non puoi essere certo che sarà indolore usare. Potrebbe funzionare, potrebbe non funzionare.
Scegliendo le tecnologie che già conosci. Se avvii un'applicazione web e non usi mai Ruby ma hai dieci anni di esperienza in Python, non scegliere Ruby se devi evitare brutte sorprese. Non c'è niente di sbagliato nel provare qualcosa di nuovo per la prima volta, ma non farlo su un progetto business-critical con scadenze strette.
Chiedendo aiuto. Stack Overflow è per le persone che sono bloccate di fronte a un problema che alcuni altri sviluppatori potrebbero aver già sperimentato.

score 2 · Answer 2

... consumes several times more man-hours than planned.

Sembra che tu stia pianificando cose in cui tu o il tuo team non avete sufficiente esperienza o conoscenza per comprendere i potenziali punti dolenti. Questo è comune, e il modo migliore che ho visto per risolverlo o gestirlo è un Proof of Concept (POC).

Cioè, in un POC ti viene assegnata una quantità di tempo ben definita - diciamo 2-3 settimane - e ti viene chiesto di vedere cosa può essere fatto per risolvere un particolare problema o utilizzare una particolare tecnologia. Il risultato non è necessariamente il lavoro che hai svolto, ma un rapporto su come utilizzare la tecnologia, i punti deboli, le efficienze ottenute e ora la tua stima di quanto tempo occorrerebbe per sviluppare la soluzione.

Questa stima ha ancora una strong probabilità di sbagliare ... ma molto meno di quanto sarebbe stato altrimenti.

score 1 · Answer 3

Questo è un problema con la previsione dei tempi di sviluppo. Penso di aver letto da qualche parte un termine di fantasia per questa situazione, ma non riesco a ricordarlo ora.

La linea di fondo è, quando si prevede quanto tempo ci vorrà per un determinato progetto, se non si è già fatto un progetto simile prima, assicurarsi di non poter avere una previsione affidabile. Se lavorerai su una nuova piattaforma / lavorerai con un nuovo framework per la prima volta, ci saranno sempre dei problemi relativamente minori che ti riporteranno indietro per ore / giorni / settimane.

Ecco perché, almeno nel luogo in cui vivo, le persone che lavorano nell'industria del software non danno mai determinate stime e tendono ad esagerare molto.