Siamo un piccolo team di software (per quanto riguarda i programmatori) e abbiamo un team di venditori dall'altra parte del mondo che programma per noi. Possediamo il prodotto e semplicemente dettiamo loro alcune delle attività su cui lavorare. Sono uno dei programmatori principali e anche il project manager di questo particolare progetto, quindi sono un requisito di programmazione e di realizzazione, oltre a delinearli.
Ho difficoltà a comunicare con i venditori esattamente cosa ci si aspetta da loro. Lasciatemi dire che siamo abbastanza nuovi in questo e non ho molta esperienza nel guidare una squadra di venditori, specialmente quando è difficile comunicare verbalmente in inglese, e lavorano durante la mia notte e poi vengo codice che hanno spinto mentre stavo dormendo. Il problema è che finisco per passare un sacco della mia giornata a controllare cosa hanno fatto e a correggere bug e casi a cui non pensavano. Non sono pensatori, fanno esattamente quello che dico loro, e niente più o meno. Il più delle volte, mi sento come se fosse più facile farlo da solo.
La mia domanda è: come può comunicare la maggior parte dei team? In questo momento abbiamo riunioni telefoniche settimanali e le invio via e-mail ogni notte i progressi che ho fatto, così come quello che ci si aspetta da loro. Quando penso "come comunicare con altri programmatori" la risposta sembra essere UML. Questo è quello che è. Sicuramente ho molta familiarità con UML, l'ho imparato a scuola, ma non l'ho mai usato sul posto di lavoro. Non è qualcosa che facciamo, in realtà i requisiti per un compito sono in testa al mio manager. Posso inserirli in un foglio di calcolo o in un diagramma di flusso, ma mai in un diagramma ufficiale.
UML è in realtà utilizzato da team come questo? In tutta la realtà, mi sembra di aver imparato tanto a scuola che nessuno lo fa davvero. Se sì, quali diagrammi sono i più utili / usati? Dalla mia conoscenza, in questo progetto in cui stiamo rinnovando qualcosa che esiste già nel sistema da cima a fondo, sento che il seguente sarebbe un buon approccio:
- Crea un diagramma ER veloce contenente le entità aggiunte / aggiornate / utilizzate nel progetto.
- Crea un modello di caso d'uso dettagliato , definendo chiaramente e numerando ogni caso d'uso.
- Crea un diagramma di sequenza per i casi d'uso complessi (così come i loro flussi alternativi) per mostrare esattamente cosa ci si aspetta da ogni passaggio.
Credo che questo sarebbe un buon inizio. Al giorno d'oggi non realizziamo un buon lavoro nel catturare i requisiti, iniziamo a iniziare la codifica basandoci su qualcosa che abbiamo redatto su una lavagna bianca. Ovviamente anche questo deve cambiare, per evitare di ottenere una settimana in un progetto e rendersi conto che abbiamo dimenticato qualcosa.
Quali sono i tuoi suggerimenti / esperienza? Sfortunatamente siamo un po 'ciechi e non abbiamo mai visto nessuno abbastanza esperto in queste situazioni. Voglio che il progetto sia un successo, ma non posso continuare a fare errori (comprensibilmente) ai fornitori perché presumo che conoscano X o Y. Come posso utilizzarli in modo più efficace?