2009-07-16 13 views
8

Lavoro per una grande azienda che sta attraversando una fusione. Stiamo lavorando a diversi progetti che coinvolgono e non coinvolgono la fusione. Un problema che sto notando è che molti gruppi di sviluppatori sono molto frammentati, anche se per lo più supportano molti progetti diversi all'interno del loro ambito di attività, e anche i database su cui lavoriamo sembrano riflettere questo. Non sono molto fiducioso nell'accuratezza di gran parte dei dati a causa di ciò.Sviluppo per un costante cambiamento in un ambiente aziendale?

Esistono modelli o standard che hanno avuto successo nella gestione di questi tipi di ambienti in evoluzione? Quali sono i modi migliori per comunicare tali modifiche agli utenti? Ci sono modi per creare ridondanze, quindi se viene proposta una modifica su una parte della produzione, essa viene comunicata su e giù per la pipeline?

Edit: rendendo questo wiki comunità a causa della sua soggettività

risposta

2

Risorse dedicate per supervisione, migrazione e creazione del processo.

Abbiamo attraversato fusioni e acquisizioni, quindi abbiamo acquistato altre società e stiamo integrandole nel nostro "processo". Cito il processo qui perché, a mio parere, non ne abbiamo ancora parlare.

Dove ci riusciremo, penso che abbiamo risorse dedicate per creare un processo che funzioni e che sia aziendale.Scrum va tutto bene, ma non si applica necessariamente ai cicli di fatturazione e marketing dell'azienda, tuttavia sarebbe utile per i nostri sviluppatori, R & D e per i team di implementazione (magari anche per creare una singola squadra tra tutte e tre!). Quindi, come facciamo a elaborare i migliori processi e le pratiche per ciascuno di lavorare in modo efficiente nelle loro aree di competenza, mantenendo tutto legato insieme?

La nostra bacchetta magica qui è che abbiamo qualcuno dedicato a questo compito, guarda come è ora, guarda ciò che è necessario e disegna i piani per arrivarci e poi li esegue. Lavorerà con i reparti, con IT e chiunque sia tenuto a farlo. Soprattutto, ha la leadership e il sostegno delle grandi teste per dargli la giusta leva per far rotolare i grossi massi pesanti (sono sicuro che tu li abbia, qualsiasi azienda abbastanza grande alla fine dà una bella sedia comoda a chiunque abbia ha superato la soglia di Peters). Una volta definito il processo, arriva il compito di elaborare il processo in modo appropriato e di migrare tutti i dati da tutti i diversi sistemi adottati ad-hoc da ciascun team - aziende prima della definizione.

Per fare tutto questo mentre devi svolgere gli altri tuoi compiti è impossibile, so che quasi sono stato licenziato cercando di fare proprio questo (scavalcato uno su molti di loro massi), è il motivo per cui hai bisogno di risorse dedicate a questo interno strutturazione. Se non lo hai ancora nella tua compagnia, farei di me il mio primo campo di battaglia.

Per fare un'analogia, quello che abbiamo qui è uno Chef d'orchestra che sa cos'è un processo e che ha i pantaloni per farlo. Non possono essere persone di tipo CE * sono troppo occupati per questo, ma qualcuno non è nel percorso critico di alcun progetto. In questo modo rimane obiettivo e può fare un passo indietro e guardare il quadro generale senza essere costantemente risucchiato nello zoo. Trovo che qualcuno con un background di sviluppo che abbia esperienza in paradigmi di processo sia agili che formali sia il più adatto per questo lavoro. Il processo di sviluppo è molto probabilmente il più difficile da inchiodare e andare avanti, se può farlo, il resto dovrebbe essere facile, almeno sulla carta.

Da quando abbiamo ottenuto questo qui i cambiamenti arrivano, viene lentamente ma arriva e finora è un dio che invia ogni volta. Ogni cambiamento apportato mette in luce come il resto sia inefficiente e gli dia più munizioni per farlo. In questo modo trovo più facile vivere con le inefficienze sapendo che qualcuno ci sta lavorando e alla fine saranno sdoganate.

Ti auguro buona fortuna, non è impossibile ma è definitivamente fattibile.

1

La vostra grande azienda suona come ogni altro. Quante di queste caratteristiche si applicano a te?

  1. eco-sistema eterogeneo di server, sistemi operativi, sistemi, lingue, database, ecc
  2. duplicazione dei sistemi (ad esempio, entrambe le aziende alla fusione dei sistemi che fanno la stessa cosa in modi leggermente diversi) .
  3. Molti database ridondanti; nessuna fonte di verità.
  4. Dati condivisi da più applicazioni.
  5. Un sacco di complessità e dipendenza che rende difficile testare il codice.
  6. Un sacco di complessità causata da sforzi "pratici" per aggirare i limiti.

Non credo che il buon senso o la professionalità o la magia stiano comunicando cambiamenti su e giù per la produzione.

+0

Sì, si applicano tutti. Trovo difficile vivere con questo come uno stato attuale accettabile. – mandroid

0

Un pensiero è avere un gruppo di persone che supervisiona i progetti per assicurarsi che siano in linea con il business. Ci vuole un po 'di leadership per impedire che le cose diventino un disastro ferroviario.

Conosco in Scrum il concetto di Scrum of Scrums. Fondamentalmente, un rappresentante di ogni squadra si incontra ogni giorno (o meno spesso in alcuni casi) per raccontare ciò che il team ha fatto, su cosa stanno lavorando oggi e discutere degli ostacoli (che potrebbero essere le altre squadre).

Inoltre, le pratiche agili in generale risolvono esattamente il problema in quanto anticipano il cambiamento.

Quindi, se la gestione non sta mantenendo le cose in carreggiata, ci sarà una buona comunicazione e una leadership da dentro.