Come implementare il cambiamento e nuovi strumenti in un piccolo team di sviluppo? [chiuso]

0

Mi è stato affidato il compito di produrre un piano per implementare una leggera modifica al lavoro dei nostri sviluppatori (ci sono otto di noi che lavorano in questa azienda). Il cambiamento interessa una piccola parte del nostro lavoro, ma introduce un nuovo strumento che gli sviluppatori non conoscono e un nuovo "passo".

Molto schematicamente la modifica è simile a questa

Prima della modifica:

  1. Scrivi materiale
  2. Fai la cosa X

Dopo la modifica:

  1. Scrivi materiale
  2. Utilizza lo strumento A
  3. Usa lo strumento B per fare la cosa X

Quello che ho fatto finora è che ho scritto la documentazione per l'uso dello strumento A e dello strumento B.

La mia domanda è cosa dovresti tenere a mente quando introduci nuovi strumenti / cambiamenti nello sviluppo in un piccolo team di sviluppo? Come assicuri che la trasmissione al nuovo modo di fare le cose sia agevole? Che tipo di risorse educative dovrebbero essere disponibili?

(Gli strumenti introdotti sono per il controllo della versione dello schema del database [quindi è solo quando apportiamo modifiche allo schema del database che è interessato dal nostro sviluppo], ma ho capito che era irrilevante per l'argomento)

    
posta 19.12.2013 - 10:59
fonte

3 risposte

2

Odio quando qualcuno introduce un nuovo strumento nella speranza di risolvere qualche problema senza in realtà discuterne con gli sviluppatori stessi. Quindi, prima di iniziare a implementare uno strumento di questo tipo o obbligarlo a utilizzarlo, assicurati che siano a conoscenza dei problemi che lo strumento sta tentando di risolvere e, ancora meglio, di essere d'accordo sul fatto che lo strumento sia il modo migliore per risolvere il problema.

Non c'è niente di peggio della gestione che aggiunge nuovi strumenti al processo di sviluppo e gli sviluppatori devono seguirlo in modo tale da uccidere metà della loro produttività e del morale.

    
risposta data 19.12.2013 - 11:36
fonte
1

Se vuoi essere sicuro che i tuoi colleghi seguiranno il nuovo processo, dovresti fare attenzione a diverse cose:

1) Crea una guida di tipo Quickstart di facile utilizzo (presumo che la tua documentazione sia sufficiente). Le immagini e il testo breve ma significativo dovrebbero indirizzare tutti nella giusta direzione.

2) Presenta il nuovo flusso di lavoro ai tuoi colleghi.

3) Puntali verso i benefici del nuovo flusso di lavoro. Se non ci sono benefici, potresti avere un problema e un sacco di lavoro in arrivo.

4) Assicurarsi che nessuno elimini il flusso di lavoro. Maggiore è il beneficio del nuovo processo, più semplice sarà.

    
risposta data 19.12.2013 - 11:22
fonte
0

Identifica il problema che questo strumento deve risolvere. Sembra ovvio, ma potresti non avere un consenso su quali siano i veri problemi con il tuo attuale modo di gestire le modifiche al database. Ci vuole troppo tempo? Gli errori sono fatti? È quasi impossibile il rollback? Scarsa documentazione?

Il team deve essere convinto che risolverà questi problemi senza una quantità sproporzionata di tempo e impegno.

Assicurati di avere un supporto gestionale e che ci siano modi per tenere traccia e avere contingenze per non utilizzare il sistema in modo corretto e regolare. Non puoi limitarti a pensare che lo useranno perché "gliel'avevamo detto".

Una volta avviato il processo di adozione e formazione, mantieni aggiornata la documentazione. Non penso che tu debba fare una raccolta esauriente di dati e studiare per vedere se funziona. Se la maggior parte dei tuoi sviluppatori è in grado di rispondere "sì" alla domanda, "pensi che questo strumento abbia semplificato la gestione del nostro database?" Probabilmente ha avuto successo. La percezione è la realtà.

    
risposta data 19.12.2013 - 11:28
fonte

Leggi altre domande sui tag