Siamo una piccola azienda di cui sono il principale sviluppatore, e abbiamo avuto riunioni e incontri con un potenziale stakeholder per una buona opportunità. Questo stakeholder ci sta aiutando direttamente a presentare una proposta a un gruppo di altri stakeholder per software di cui hanno un strong bisogno. Speriamo che se li vendiamo sulla nostra proposta (costituita da caratteristiche di altissimo livello e risultati generali), sponsorizzeranno il progetto e cresceranno organicamente da lì agli utenti di tutto il paese che vedranno quanto sia utile.
Il problema è che noi, in quanto sviluppo, siamo terribilmente impantanati come con progetti precedenti, manutenzione dei sistemi di produzione esistenti e funzionalità di cui abbiamo bisogno nel backlog. Così com'è, perché questo progetto potrebbe essere molto redditizio e non ci sono concorrenti seri, il management vuole agire FAST e ottenere le funzionalità più elementari il più rapidamente possibile, indipendentemente dal costo .
Questo non è realistico per noi senza crescere la nostra squadra, ma ci vuole troppo tempo. Stanno pensando di contrattare lo sviluppo del lavoro, ma voglio che io sia un analista di business e che abbia anche esperienza architettonica nel progetto. Quando terminano lo sviluppo di funzionalità importanti, anticipano che il mio team si assume la responsabilità della manutenzione, quindi il controllo architettonico è importante perché vogliamo che i deliverable siano mantenibili.
Sono d'accordo con questo ruolo, ma non mi sono abituato. In casa, in genere, non utilizziamo documenti con requisiti formalizzati e raccogliamo invece i requisiti di storie utente, casi d'uso, flussi di lavoro e accordi con i clienti. Siamo abituati a formulare storie di utenti, ma temo che non abbia senso fornire storie di utenti a una società esterna di appalto perché probabilmente avranno una propria gestione di progetto che potrebbe voler fare le cose a modo loro. Non vorrei imporre il nostro processo di gestione del progetto non familiare su di loro se lo trovano estraneo e li rallenta.
Penso che siano necessari requisiti aziendali formalizzati estremamente dettagliati perché vogliamo essere certi di avere le linee guida necessarie per creare software di qualità, ma non ho idea del tipo di impegno che questo comporterà da solo. Sono anche sicuro di quando iniziare. Niente è ancora ufficiale, ma ho il 90% delle informazioni che ritengo di aver bisogno dalle parti interessate. Non voglio finire con la direzione che mi informa che l'accordo è stato firmato, dobbiamo consegnarlo in 6 mesi e procurargli tutti i documenti dei requisiti entro la fine della settimana.
Sentendomi un po 'in testa qui, posso formulare storie di utenti o requisiti aziendali? Qualche altro suggerimento utile?