Vai al contenuto

Project Overview Statement

In questo POS viene riassunto quanto detto negli scoping meetings.

Scoping meetings:


Problema/Opportunità

si vuole creare un videogioco di tipo rogue like, rpg e building che permetta al team di accumulare esperienza nel settore, motivo per il quale tutto il prodotto si concentra sull'essere semplice e veloce nella produzione.

Goal

Creare un videogioco con caratteristiche rogue like, rpg e building che permetta di far accumulare esperienza al team nel settore videoludico, lanciare il primo prodotto nel mercato e fornire una base economica minimale per l'apertura dell'azienda.

Obiettivi

  1. pubblicazione del prodotto software entro l'inizio del nuovo anno (2026)
  2. business value:
    1. Tangibile: Accesso a una fonte di entrate dirette tramite le vendite su Steam
    2. Intangibile: Validazione della capacità del team di rispettare tempistiche e rilasciare un prodotto completo
    3. Intangibile: Aumento della visibilità e credibilità del team come sviluppatori
  3. success criteria (IR): entrata nel mercato
  4. caratteristiche action rpg, rogue-like e building del videogioco
  5. business value:
    1. Tangibile: Incremento del potenziale commerciale del gioco grazie all'attrattiva per nicchie di mercato specifiche
    2. Intangibile: Differenziazione del prodotto e riconoscibilità del brand del team
    3. Intangibile: Aumento del coinvolgimento e della soddisfazione del giocatore, che può riflettersi in maggiori vendite e recensioni positive
  6. success criteria (IS):
    1. presenza di almeno 4 classi diverse giocabili
    2. la mappa delle zone varia di volta in volta
    3. presenza di oggetti piazzabili nel mondo virtuale del gioco
  7. acquisizione di esperienza da parte del team per quanto riguarda la game industry
  8. business value:
    1. Intangibile: Sviluppo di competenze tecniche avanzate in strumenti come Unity e Blender
    2. Intangibile: Creazione di una rete professionale utile per futuri progetti (collaborazioni, finanziamenti, assunzioni)
    3. Intangibile: Capacità di affrontare future produzioni con maggiore efficienza e autonomia
  9. success criteria (IR-AC-IS):
    1. network con colleghi dello stesso settore (almeno altre 3 aziende conosciute con le quali si è stabilito un rapporto)
    2. marketing del prodotto (intraprendere almeno 3 strategie di pubblicizzazione differenti)
    3. dev-skill specifiche dei tool di sviluppo quali Unity e Blender (conoscere a fondo le funzionalità principali e essere a conoscenza di quelle più avanzate)
  10. arrivare ad un guadagno minimo che saldi le spese annue della partita IVA
  11. business value:
    1. Tangibile: Copertura dei costi fissi di esercizio (almeno 3600€ di ricavi), garantendo la sostenibilità economica di base
    2. Intangibile: Prova di un interesse reale del mercato per il prodotto del team
    3. Tangibile: Accesso a promozioni su Steam e future campagne con leva su un primo successo
  12. success criteria(IR): avere un'entrata pari, almeno, a 3600€

Assunzioni

  • Steam non incrementa in modo considerevole la trattenuta sui guadagni
  • Il team lavora in modo disomogeneo, c'è chi dedica più ore, chi meno, per il fatto che non è ancora fonte di reddito
  • Il team è composto da persone che conoscono e sono appassionate al mondo dei videogiochi in qualità di clienti

Rischi

L'analisi dei rischi si può è stata eseguita in questo file.

Ostacoli

  • è obbligatorio avere una partita IVA per pubblicare prodotti su Steam
  • alcune persone del team hanno altre attività quali università o lavoro che impediscono la partecipazione continuata
  • aderire alle policy di Steam

Appendici

Durante gli scoping meeting è stata condotta un'analisi finanziaria a sostegno del progetto insieme allo studio di fattibilità. Esse possono essere reperite qui.

Scelta del PMLC

Analizzando RBS e POS il team è giunto alla conclusione che il Project Management Life Cycle che più si adatta a questo progetto è: Iterativo.

La scelta è dovuta ai seguenti fattori:

  • Obiettivi noti e stabili, ma requisiti instabili o incompleti.
  • Necessità di apprendere mentre si implementa, approfondendo la conoscenza delle necessità degli stakeholders (prima di tutto quelle relative al team come stakeholder).