Membro della squadra mancante? Colla tra produttori di dati e consumatori di dati

Penso sia appropriato avere qualcuno che abbia una visione di ciò che ogni team sta facendo e può identificare potenziali problemi, opportunità, lavoro ridondante e così via e formulare raccomandazioni per migliorare le cose. Sarebbe la responsabilità di quella persona, dal punto di vista tecnico, per determinare se ciò su cui i diversi gruppi stanno lavorando può adattarsi bene e risolvere i problemi aziendali. Non dovrebbe (necessariamente) essere la responsabilità di quella persona di decidere se i problemi da risolvere sono quelli giusti, però. Chiama quella persona come ufficiale tecnico, architetto, ingegnere principale o altro.

Non penso che tu voglia un terzo "gruppo di interfaccia", che avrebbe essenzialmente la responsabilità di mostrare se gli altri due gruppi stavano facendo un lavoro compatibile, ma probabilmente non avrebbero l'autorità di apportare modifiche a ciò che ciascun gruppo era fino a. Perché ora hai tre problemi: le due interfacce ufficiali che nasceranno tra il primo e il secondo terzo gruppo e quella non ufficiale che si pone per aggirare la burocrazia inerente alla comunicazione tra i primi tre gruppi.

Stai facendo una domanda molto specifica basata su un progetto molto specifico e impostato, ma in realtà punta a una risposta generica che si applica a tutti i progetti:

It's whoever it's agreed to be by the people involved.

Non esiste una struttura del team giusta, anche per una situazione specifica. Dipenderà dalle persone coinvolte, dalle loro competenze, dal tempo in cui possono impegnarsi, dal business e così via e così via.

Il che significa che l'unico approccio che puoi fare è assicurarti che quando crei un progetto le responsabilità siano concordate all'interno del team e che, come in questo caso, se ti perdi qualcosa, viene raccolto e assegnato al più presto come è stato identificato.

La prima cosa da provare sarebbe quella di convincere le due squadre a discuterne e concordare qualcosa. Idealmente lo farebbero e lo porterebbero al PM e diranno "questo è ciò che pensiamo" e lui o lei direbbero "fantastico".

Se ciò non accade (ad esempio perché non sono d'accordo), allora devi portarlo al PM e / o chiunque abbia stabilito che tu abbia questi due gruppi. Presumibilmente questa decisione è stata presa sulla base di alcuni criteri o di altri e questo di solito sarà un buon punto di partenza.

Ma non c'è nulla di autorevole che ti dirà come dovrebbe funzionare questa situazione, certamente non un gruppo di persone su Internet che non capisce nulla delle sottigliezze della situazione e non hanno nulla in ballo ...

Per come la vedo io dividi un progetto più grande in due blocchi. L'unica cosa sensata per dividere i progetti sono moduli. I moduli hanno un'interfaccia e un'implementazione. Un modulo è buono, se l'interfaccia è chiara e non perde informazioni sull'implementazione. Il modo in cui sembra ora, il "team di produttori" non ha creato un modulo, solo un set inutilizzabile di strumenti.

OTOH non puoi aspettarti che il loro modulo fornisca dati in una struttura perfettamente adatta per ogni scenario. Le esigenze dei tuoi clienti potrebbero cambiare e in realtà non dovrebbero influire sul loro lavoro.

A seconda di quanto lavoro occorre fare per trasformare un output del modulo produttore ben progettato in un input del modulo consumer appropriato, allora potrebbe essere necessario creare un altro modulo, la cui interfaccia dipende dalle proprie esigenze e l'implementazione di chi dipende dall'interfaccia del modulo del produttore (e ovviamente una sua interfaccia). Se l'interfaccia del produttore è buona e le esigenze del consumatore sono le meno ragionevoli, l'implementazione di tale modulo è banale ed è qualcosa che puoi chiedere al team del produttore, supponendo che questo abbia davvero un vantaggio organizzativo.

Questo non suona molto come un problema di programmazione. Piuttosto sembra più un problema di lavoro di squadra / affari / gestione.

Se i due gruppi avevano già la mentalità di essere nella stessa squadra, lavorando insieme per far funzionare l'azienda, questo problema potrebbe aver già risolto se stesso. Per lo meno, potrebbero portare qualsiasi vincolo di tempo / personale ai rialzi appropriati. Quindi, potrebbe essere presa una decisione appropriata, con tutti e 3 i gruppi che lavorano con lo stesso obiettivo: ecco un problema che deve essere risolto affinché la nostra attività possa avere successo.

Sembra che tu abbia a che fare con una situazione in cui nessuna squadra vuole eseguire il lavoro. Generalmente questo è un brutto segno per la salute dell'azienda.

I dati sono i consumatori degli utenti per i quali i produttori di dati stanno producendo strumenti? In questo caso, ciò di cui hanno bisogno è il requisito, non quello che preferiresti fare.