Come avviare un progetto di sviluppo quando ci sono troppi potenziali stakeholder

Ho appena assunto un nuovo lavoro in un college come (unico) sviluppatore di applicazioni Web.

Il college ha un numero di sistemi legacy disparati ma tutti piuttosto mal codificati. Principalmente costruiti in PHP, si occupano di cose come la frequenza, i risultati degli esami, i voti, ecc.

Il mio primo lavoro è quello di costruire un sistema che incorpori molti di questi dati, che attualmente si trova in vari database senza alcun tipo di API amichevole per estrarli (i sistemi esistenti sono codificati in PHP vanilla senza separazione dei dati e vista) con una nuova piattaforma per la registrazione di informazioni pastorali sugli studenti e le presenta ai tutor e al personale senior in modo utile in modo che possano reagire rapidamente ai problemi con gli studenti.

Nel nostro primo incontro, c'erano 18 persone! Non c'era nessun leader o voce chiara che rappresentasse la maggioranza. Nessun cliente identificabile . La riunione è passata da idee dettagliate sull'implementazione di funzionalità minori dei presidi della facoltà a discussioni sull'opportunità o meno di utilizzare fogli di calcolo Excel per l'inserimento di dati!

Come puoi immaginare, alla fine mi girava la testa. In realtà avevo molte buone idee ma non riuscivo a farle sentire. Questo è un ruolo molto nuovo per me, prima che facessi parte di un team di sviluppo in un'agenzia di marketing. Avevamo ruoli ben definiti: Project Manager, Cliente, Designer, Sviluppatore.

Vorrei sapere se alcuni sviluppatori o manager esperti possono darmi alcuni consigli su come posso montare i miei colleghi in qualcosa che assomiglia a un team di progetto. Agile è la strada da percorrere? Come ti approcceresti gestendo tutte le voci disparate? È chiaro che alcuni processi devono essere messi in atto molto rapidamente, non sono sicuro di cosa si tratti.

Non mi aspetterei qui alcun "processo di sviluppo agile" come soluzione al tuo attuale problema. La prima cosa per te dovrebbe essere: cancella la tua missione . Questo significa:

• chiarire quali sono le tue responsabilità
• chiarire quali sono le responsabilità delle altre parti interessate
• identificare chi è responsabile di ciascuno dei sistemi legacy
• se non esiste un client (ancora) per la tua applicazione web, trova qualcuno che lo userà in futuro e chiedi il permesso di incorporarlo come utente rappresentativo del tuo sistema (una persona con cui puoi discutere dei requisiti)
• se vi sono diverse parti interessate con obiettivi diversi, raccogliere i loro requisiti (ad esempio, intervistandoli uno a uno, non 18 persone complessivamente in una stanza). Scrivi i risultati in un elenco. Successivamente, inizia a definire le priorità.
• annota una roadmap (il quadro generale) e una piccola specifica per la versione 0.1 e fai in modo che il tuo capo e il cliente rappresentativo accettino formalmente
• EDIT: vedi il commento di GlenH7

Questo può richiedere del tempo, probabilmente non scriverai molto codice in questa fase del progetto. In una tale situazione, dovresti prima fare un po 'di "ingegneria dei requisiti". Ma inizia in piccolo, pensa in grande. Dopo aver sviluppato la tua prima versione, avrai qualcosa da mostrare, discutere nuovamente i requisiti con le parti interessate ecc.

Separare quelli che vogliono davvero che questo progetto funzioni dalla mandria.

A causa della grande politica, qualcuno ha messo insieme questo incontro con un elenco di partecipanti in cui l'appartenenza era determinata da chi sarebbe stato più turbato se non li avessi invitati. Succede. Questo obiettivo è stato raggiunto ma, come sviluppatore, hai scoperto che non era stato deciso nulla. A nessuno è stato assegnato cosa fare. Se sei fortunato, sono riusciti a programmare il prossimo incontro o Dio non voglia, hanno organizzato un incontro ricorrente il 3 ° martedì di ogni mese.

Successivamente arriverà la formazione di comitati, sottocomitati e task force. Questo è più bello, ma li troverai ugualmente inutili.

Alla fine, scoprirai a chi interessa davvero questo progetto. Chi vuole davvero avere il tempo di farlo bene. Spero che questa persona (e) abbia un supervisore che gli permetta il tempo di farlo e non solo di renderlo un altro elemento nella loro già lunga lista di cose da fare. Trova queste persone al più presto! Aiutali a gestire le aspettative del loro capo e ottenere un impegno concordato.

Ottieni qualcosa di fronte al maggior numero di persone nel gruppo originale che si preoccuperanno persino di tornare. Potrebbero essere tutte persone intelligenti e / o istruite, ma non leggeranno un sacco di specifiche. A loro piaceranno alcune cose, odieranno gli altri e ne vorranno di più. Non è male annotare suggerimenti, ma cerca di far seguire quella parte con un po 'di pelle nel gioco. Non promettere di fare tutto. Basta affrontare ciò che può essere fatto nel prossimo futuro.

Se finisci per avere a che fare con più di 5 persone su base regolare, è perché alcuni manager hanno coinvolto molte delle loro persone che non vogliono davvero essere lì.

Fornisci un elenco di idee che ritieni possano rafforzare / migliorare i sistemi esistenti in base alle tue osservazioni e ai loro "bisogni" e assicurarti di concentrarti su dove puoi ottenere guadagni visibili. Includi in quell'elenco ogni idea che ritieni possa essere utile, così come ogni suggerimento "ragionevole" straordinario dei non sviluppatori.

Crea un elenco di funzioni che "dovrebbero" essere incluse nei tuoi sforzi di sviluppo. Dai a ciascun membro il potere di "voto", magari sotto forma di "stelle appiccicose" e scopri cosa vuole veramente il tutto da ciascun membro mettendo le stelle accanto a ciò che pensano sia importante. Alcune persone potrebbero finire con più stelle se firmano l'assegno, hanno l'ultima parola, ecc. Dopodiché, spero che tu e tutti gli altri vedrete ciò che è importante per il tutto, e si spera che accetteranno la priorità, che quindi traduci in una tabella di marcia

1). Esamina il team : scopri ciò che ciascun membro considera importante / necessario / priorità assoluta

2). Ottieni subito qualcosa, non tentare di risolvere tutti i problemi contemporaneamente, ottenere la funzionalità "minima indispensabile" e farli approvare, quindi farli avanzare collettivamente in base al feedback degli utenti.

3). Usa il loro feedback e il feedback di altri utenti per guidare il processo di sviluppo

(Crea, valuta feedback, crea, valuta feedback) Risciacqua e ripeti.

Inoltre, potresti prendere in considerazione la possibilità di inserire "punti di sforzo" o ore stimate per il completamento .. ciò potrebbe anche aiutare a stabilire le priorità.

La tua prima sfida è identificare la necessità di questo progetto. Tieni un altro incontro con tutte quelle persone e chiedi loro di scrivere i problemi che devono essere risolti. Non lasciare che parlino dei molti modi in cui questo progetto sarà la soluzione. Costringili a identificare veramente i bisogni / problemi.

Un modo per farlo è quello di chiedere a ciascuno di loro individualmente di documentare quelle esigenze su note adesive - un'idea per appiccicosa. Quindi esegui un diagramma di affinità per aiutarli a raggruppare queste idee disparate in bisogni specifici. Infine, falli votare (voto multiplo ) in modo da poter vedere i bisogni più grandi.

Agile ci ricorda di affrontare prima la funzionalità che ha il maggior valore per il cliente. Inizia con il bisogno più grande e poi continua a suddividere l'oggetto fino a quando non avrai il primo piccolo pezzo che puoi effettivamente fare in un breve periodo di tempo.

BACIO - Fai un itinerario. Ringrazia tutti per essere venuti, esaminalo, fallo. Il tracciamento laterale rallenterà se lo affronti condividendo le loro preoccupazioni e chiedendo loro di rimanere DOPO la riunione. Prendi delle decisioni votando dove c'è controversia per essere più felici. La motivazione alla partecipazione a qualsiasi sistema è direttamente correlata alla credenza individuale nei suoi metodi.