Appaltare lo sviluppo di software; fornire storie di utenti o requisiti aziendali?

5

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?

    
posta maple_shaft 20.12.2011 - 13:46
fonte

3 risposte

1

I am afraid that doesn't make sense to deliver user stories to an outside contract company as they will likely have their own project managment who might want to do things their way

Sei il cliente e pagherai loro ... digli cosa otterranno. Inoltre, non penso che sia particolarmente importante in che formato vengono consegnati i requisiti, qualsiasi sviluppatore decente dovrebbe essere in grado di lavorare con entrambi.

Personalmente, penserei di ottenere un paio di singoli appaltatori / liberi professionisti piuttosto che una grande società di consulenza. Potresti finire con l'assumere le persone che la consulenza avrebbe assunto, sarà più economico e avrai una relazione più stretta con gli sviluppatori.

    
risposta data 20.12.2011 - 14:29
fonte
1

Invece di determinare come presenterai i tuoi requisiti, concentrati innanzitutto sulla ricerca di qualcuno che costruisca il sistema, preferibilmente nel costo e nella pianificazione accettabili per la tua organizzazione. Il processo dovrebbe iniziare con la creazione di una panoramica di alto livello che delinei gli obiettivi del progetto, il background e le motivazioni, i requisiti di alto livello, specifica esattamente cosa è in ambito e fuori ambito e i risultati richiesti. Nello stesso momento in cui ciò sta accadendo, sarebbe anche coinvolto il diritto a determinare la proprietà intellettuale, le NDA, qualsiasi tipo di conformità normativa richiesta dal subappaltatore e così via. Entrambi i documenti saranno messi a disposizione dei potenziali contraenti per fornire le informazioni necessarie per costruire una proposta che affronti la pianificazione, il budget, le risorse e anche alcuni rischi.

A questo punto, diventa una negoziazione. Potresti ottenere una serie di costi o programmi fuori linea per le tue aspettative, a quel punto potresti dover rivedere ciò che sei disposto a investire o ridurre le dimensioni e la portata del progetto. Potrebbero esserci altre domande da potenziali appaltatori a cui è necessario rispondere per fornire informazioni. C'è un periodo avanti e indietro qui per appianare alcuni dei dettagli necessari per portare a termine il progetto. Se non sei mai stato coinvolto in una negoziazione, ti consiglio vivamente i libri Arrivare a Sì: Contratto di negoziazione senza rinunciare a e Numero passato: negoziazione in situazioni difficili .

In base ai tuoi criteri, una volta selezionato un appaltatore, il livello di coinvolgimento dipende da ciò che viene negoziato. Personalmente ho visto tutto dall'appaltatore come una scatola nera che riceve i requisiti e, su base regolare, spedisce gli artefatti e i deliverable richiesti fuori dall'appaltatore come una scatola di vetro con un cliente che è sempre o abitualmente sul posto, attivamente coinvolto nel processo di sviluppo. E ci sono molte sfumature di grigio nel mezzo, con diversi livelli di coinvolgimento tra il cliente e l'appaltatore. In definitiva, ciò dipende dal contratto e dall'accordo tra il cliente (la tua organizzazione) e il costruttore.

Dato che hai accennato al fatto che la tua organizzazione riceverà il prodotto e proseguirà la manutenzione e lo sviluppo su di esso, passerei un po 'più di tempo a controllare i potenziali appaltatori sul loro processo di sviluppo e sulle pratiche di assicurazione della qualità. Cercherei anche di massimizzare la visibilità del processo e del prodotto per tutta la durata del contratto, in modo da poter individuare tempestivamente potenziali problemi e intraprendere azioni correttive. Pertanto, dovresti collaborare con la società appaltatrice per delineare i tuoi ruoli e responsabilità al progetto e le loro responsabilità nei confronti della tua organizzazione. Tuttavia, come ho detto, è una negoziazione, quindi potresti non ottenere il 100% di tutto ciò che vuoi.

Un'altra opzione potrebbe essere quella di assumere collaboratori interni temporanei, supponendo che tu abbia le risorse per farli funzionare. Avrebbero bisogno di una sorta di lead (che presumerei fossero voi), computer, server di creazione, un ambiente di incontro o collaborazione, spazio sulla scrivania e così via. La tua organizzazione dovrebbe anche passare il tempo a intervistare candidati e trovare persone che lavoreranno bene insieme e forse all'interno della tua organizzazione. Tuttavia, potrebbe anche portare a dipendenti a tempo pieno in futuro.

In questa situazione, puoi dettare il processo di sviluppo e avere un grande controllo su come sono fatte le cose. Ma hai anche i costi, ad esempio l'aggiunta di persone e infrastrutture da gestire. Potrebbe o meno essere più conveniente, ma potrebbe essere qualcosa da considerare, soprattutto se la tua azienda potrebbe essere in procinto di espandersi nel corso del progetto o alla sua conclusione - hai alcuni potenziali dipendenti futuri che lavorano con te.

    
risposta data 20.12.2011 - 14:26
fonte
1

Come imprenditore, ecco cosa penso:

Innanzitutto, conosci il tuo fornitore . Parla un po 'con lui, fallo parlare con i tuoi sviluppatori principali. Hanno bisogno di valutare il suo livello di abilità e il livello di intuizione. Non puoi semplicemente dare per scontato che a tutti gli appaltatori possano essere dati requisiti, storie o qualsiasi cosa tu abbia. Devi capire cosa possono fare da soli e cosa non possono.

Non dare troppo lavoro in una volta . L'appaltatore non ha familiarità con la tua azienda e il lavoro dovrebbe essere controllato su base bisettimanale o settimanale se possibile per accertarsi che vada nella direzione corretta.

Se questo è un progetto da zero, allora:

Dopo il primo incontro, chiedi all'appaltatore di sviluppare un prototipo molto minimale di ciò che ti aspetti. Dategli requisiti aziendali e non legarlo troppo. Vuoi vedere quanto può essere bravo l'appaltatore da solo. In questo modo, quando gli darai ulteriori istruzioni, non gli dirai cose che già conosce e che perdi tempo. Personalizza le tue istruzioni per l'individuo che deve eseguirle.

Se il progetto è un progetto esistente che richiede modifiche:

Spiega il progetto da una prospettiva di business. Mandagli il progetto, lasciagli sistemare le cose. Dategli un giorno o due con lui e organizza un incontro. Chiedi, spiega, comunica, mettiti comodo, costruisci un rapporto .

Rapport sarà molto più importante di qualsiasi insieme di requisiti del progetto. Alla fine della giornata, il tuo rapporto è quello che sta per convincere l'appaltatore a sistemare il progetto con breve preavviso, o fare il possibile per assicurarsi che sia fantastico. Una serie fredda di requisiti non ti darà questo.

Una volta che hai attraversato le fasi iniziali, aggancia il tuo appaltatore con un contatto di uno sviluppatore principale che sarà il suo referente per l'azienda. Se ha una domanda, può licenziarla. Dovrebbero incontrarsi settimanalmente. Trovo che Citrix Go-To Meeting sia la soluzione migliore per questo, la condivisione dello schermo è un must.

Ora che hai stabilito le comunicazioni, se vuoi implementare un po 'di agile o semplicemente distribuire elenchi di caratteristiche desiderate, non importa. Nessuna metodologia o sistema sostituirà mai le cose fondamentali che gli umani hanno bisogno e si aspettano.

Siamo prima gli umani, secondo gli sviluppatori.

Attenzione però, questo non significa che non inviare la documentazione. Faresti meglio a inviare la migliore documentazione e i requisiti di progetto che puoi raccogliere. Questo ragazzo è nuovo di zecca, e ora deve nuotare. Assicurati di gettare un salvagente.

Se decidi di utilizzare Agile, ti consiglio di tracker principale .

    
risposta data 21.12.2011 - 01:03
fonte

Leggi altre domande sui tag