Differenza tra la pianificazione di un progetto e la pianificazione di un prodotto

Alcune differenze significative:

• Un progetto è generalmente limitato nel tempo . Di solito, un prodotto ha una durata di vita sconosciuta al momento dello sviluppo - la tua ipotesi dovrebbe essere quella in cui se si riesce ad avere un'attività in corso.
• Un progetto deve essere consegnato rispetto a un materiale da fornire specificato . Un prodotto deve offrire un'attività commerciale valida . Indovina quale è più difficile: -)
• È molto semplice esternalizzare un progetto. Lo sviluppo del prodotto in outsourcing è di solito una pessima idea (suggerimento: non dovresti esternalizzare la tua competenza di base!)
• Poiché i prodotti sono (di solito) mirati esternamente e destinati a ridimensionarli, la qualità tende a diventare più importante come fattore di successo.

Penso che le differenze elencate nella domanda in realtà non siano differenze intrinseche tra prodotti e progetti. Ad esempio, puoi immaginare di lanciare un prodotto con un set completo di funzionalità. Un progetto potrebbe avere una "base di utenti" ampia e definita. E sia i prodotti che i progetti potrebbero avere problemi con la schedulazione / scope creep: -)

Questo è mele e arance. Non c'è paragone come se uno fosse esclusivo dell'altro. Uno può e dovrebbe lavorare su progetti a vantaggio del prodotto.

Le qualità di costruzione di un prodotto si concentrano decisamente su 1 e 2, tuttavia 3 non è del tutto corretto. Semplicemente perché si tratta di un prodotto, non significa che lo scope creep sia più accettabile o meno pericoloso. Per determinare il lavoro del prodotto, è necessario adattare lo sviluppo di funzionalità realizzabili in uno o più progetti, in quanto è importante soddisfare le esigenze di pianificazione e mantenere i costi sotto controllo.

Il fatto è che il "prodotto software" è in parte un termine di marketing. Se ho un software funzionante di qualità ragionevole, posso pubblicarlo, pubblicizzarlo e tentare di venderlo a un numero di clienti.

Quando la progettazione del software entra in gioco è l'intelligente fusione di set di caratteristiche personalizzabili per una varietà disparata di clienti rende un prodotto software tale che la necessità di sviluppo personalizzato per ottenere un singolo cliente è ridotta al minimo possibile. Questo può essere straordinariamente difficile da fare.

Se la tua organizzazione sta usando la scusa che il lavoro sul prodotto rende lo scorrimento insensibile e le scadenze fluttuanti come accettabili, si limitano a scusarsi.

Durante la pianificazione di un progetto, è necessario considerare quanto segue:

1. Ambito di applicazione
2. Protagonisti
3. Risorse
4. Vincoli
5. Livello di qualità
6. Costo

Considerando che, la pianificazione di un prodotto richiede di prendere in considerazione quanto segue:

1. Caratteristiche generiche: componente essenziale del prodotto, i tratti senza i quali il prodotto non esiste.

2. Funzioni previste: caratteristiche che sono generalmente ipotizzate o previste dal cliente target

3. Funzioni aggiuntive: funzioni che aggiungono più forza e valore al prodotto

4. Potenziali caratteristiche: caratteristiche che hanno lo scopo di rendere il prodotto unico e distinto e quindi di contribuire alla fidelizzazione dei clienti.

Tutti e tre i tuoi punti possono essere applicati anche a un progetto. Può aiutare a visualizzare un esempio reale: sviluppare un sistema di fatturazione interno per una grande azienda (progetto) rispetto alla scrittura di un sistema di fatturazione da vendere in modo ampio (prodotto).

Alcune differenze:

1) Puoi accontentarti di "abbastanza buono" nel progetto. Il prodotto ha aspettative di qualità superiore.

2) Devi accompagnare molte più configurazioni hardware e software con un prodotto.

3) Gli utenti hanno maggiori probabilità di essere remoti su un prodotto. È più difficile, ma non impossibile, ottenere i dati di utilizzo.

4) Con un prodotto è più probabile che tu lasci l'integrazione a qualcun altro.

Ho lavorato per una piccola azienda di software durante il periodo in cui hanno rilasciato nuove versioni per gestire Y2K. Per me le maggiori differenze riguardano il controllo e la coerenza degli utenti e dei loro ambienti.

1. Le configurazioni del computer dell'utente saranno più consenzienti.
2. Gli utenti di solito hanno una formazione migliore (eccetto se il tuo mercato è un professionista IT) o hanno un dipartimento IT.
3. I lavori a contratto ti danno più accesso ai sistemi dell'utente nel caso in cui tu debba modificare un'installazione.
4. Il buy-in degli utenti può essere complicato in situazioni di contratto se ci sono combattimenti interni e politica in corso. Molti utenti non vogliono il cambiamento. Speriamo che un cliente che acquista software commerciale voglia davvero usarlo.

Non penso che le richieste di tempo siano così diverse perché qualcuno sta ancora pagando il tuo tempo e potrebbe perdere affari o produttività perché non hanno la tua app (non è per questo che la stanno comprando nel primo posto?). Se stai creando alcune app social gratuite e utilizzando denaro preso in prestito, gli investitori vogliono vedere un prodotto prima piuttosto che dopo.