ruolo Analista aziendale nel processo di sviluppo

No, non è accettabile pulire il loro lavoro.
Ci sono una serie di ragioni sul perché.

1) v2.0 ha avuto un ciclo di sviluppo che era 1/3 del ciclo originale e il periodo di convalida del rapporto è stato ridotto dal 50% del ciclo a meno del 30% del ciclo.
Va bene contrattare un ciclo di sviluppo, ma a meno che la quantità di rapporti non sia significativamente inferiore, la finestra di convalida dovrebbe essere rimasta proporzionata. Poiché i report erano significativamente più complessi, non sarebbe irragionevole aspettarsi una convalida continua dei report durante l'intero ciclo di sviluppo.

2) Prendendo le cose nelle tue mani, hai rotto la catena di comando e non sei riuscito a notificare la gestione in modo tempestivo dei problemi significativi del rapporto. Tali problemi di prestazioni e requisiti rappresentavano rischi per il rispetto del programma, ed è una cosa che il team di gestione ha il diritto di essere consapevole. Mentre pensi di sapere cosa sarebbe stato fatto per risolvere la questione, non lo sai per certo dato che non è stata una tua decisione. Il ruolo della direzione è quello di valutare i pro / contro di un percorso rispetto all'altro e di accettare la responsabilità delle conseguenze. Hai cortocircuitato quel processo presumendo la risposta e ipotizzando che ciò a cui stava lavorando la squadra onshore fosse una priorità più alta. Per quanto ne sappia, potrebbe esserci stato qualcuno con la capacità di risolvere il problema o una soluzione diversa potrebbe essere stata trovata.

3) Hai anche rotto la tua area di responsabilità. Normalmente, questo non è un problema nel mio libro in quanto sono a favore di tutti che contribuiscono dove possono e crescono le loro capacità. Tuttavia, probabilmente non sei la persona più competente per risolvere la questione. Accettandolo senza informare gli altri, hai negato l'opportunità di risolvere il problema più rapidamente. È possibile che il team offshore abbia potuto risolvere rapidamente i problemi una volta che ne erano stati informati. Cosa ti avrebbe detto il team di onshore se non fosse stato in vacanza e sapesse cosa stavi facendo?

Complicare tutto questo è la tensione invalicabile tra i team onshore e offshore. Inavvertitamente hai camminato dritto in un vespaio di problemi politici.

La cosa giusta sarebbe stata informare immediatamente la tua gestione del problema e quindi offerta di cui conoscevi SQL e sarebbe felice di affrontare la sfida. Questo mette un'altra opzione sul piatto per risolvere la questione, ma consente comunque alla direzione di scegliere l'approccio migliore per risolvere il problema.

È sempre opportuno correggere ciò che è rotto e fare in modo che le cose funzionino il più vicino possibile alla specifica il più vicino possibile alla scadenza.

È anche opportuno documentare tutto ciò che dovevi correggere per far funzionare le cose. È importante sapere se le tue risorse offshore stanno fornendo un codice accettabile che si adatta alle tue specifiche. Se non lo sono, è opportuno inviare loro la documentazione delle differenze tra le vostre specifiche (in particolare re: performance) e dimostrare che quello che hanno consegnato NON era quello che è nelle specifiche. Questo può essere usato dai tuoi manager per negoziare il lavoro futuro o per limitare ciò che paghi per quello che hai ottenuto.

Quando molte persone sono coinvolte in un'attività, i ruoli devono essere chiaramente definiti e le misure devono essere stabilite. Se il codice che ottieni è negativo, devi dire che non ha rispettato gli standard prestazionali previsti. Se non vengono impostati standard di rendimento, è possibile indicare che può essere migliorato, ma non penso che dovresti modificarlo da solo. Personalmente, non accetterei che qualcuno cambi il mio codice senza prima discuterlo con me.

Quando diverse organizzazioni sono coinvolte, i confini non devono essere superati senza un'attenta considerazione, perché le persone (e soprattutto i manager) non amano questo. Dopo tutto questo è ciò che i manager sono (o almeno una parte della ragione).

Questo non vuol dire che l'opportunità di miglioramento vada via, ma che la gestione decida l'approccio se non è già impostato.

È molto comune che i team offshore facciano cose strane da quelle che ritieni accettabili perché la natura dei contratti che queste aziende talvolta prendono e molte altre ragioni.

La regola numero uno dello sviluppo del software è di farlo funzionare, tutto il resto è secondario. Se stai scontando una scadenza e problemi hai bisogno di essere riparato ora. Avrai molto tempo dopo per analizzare il problema e capire chi non è riuscito a fare cosa o cosa ha bisogno di essere migliorato nel processo per il futuro. Se diventa un evento comune che devi risolvere costantemente i problemi che non dovresti, allora questo è un problema diverso e questo dimostra una mancanza di gestione che fa il loro lavoro per identificare e risolvere i problemi con il processo.