Come condividere le conoscenze per la risoluzione dei problemi in un gruppo multiteam?

Ho lavorato per un'azienda startup in rapida crescita che passò da meno di 100 a più di 500 persone in due anni e mezzo, dove il problema della condivisione delle conoscenze divenne rapidamente un problema. La società ha costruito una strategia che ha funzionato abbastanza bene e ha incluso tre componenti chiave:

• Documentazione
• La standardizzazione
• Formazione interna

Ogni team era responsabile del rilascio della documentazione insieme agli aggiornamenti del proprio componente. Il rilascio del codice senza documentazione è stato considerato incompleto. La qualità della documentazione è stata valutata indipendentemente dal "target audience" (cioè l'altro team all'interno dell'azienda che ha utilizzato il componente). Errori o omissioni nella documentazione sono stati inseriti nel sistema di tracciamento dei bug e trattati come difetti di prima classe.

C'era anche bisogno di menzionare la documentazione quando si rispondevano alle domande e-mail sul componente. Se non si è in grado di individuare una parte della documentazione che risponde alla domanda, la politica si aspettava di scriverne una o modificare un documento esistente per rispondere alla domanda. Questa pratica ci ha aiutato a mantenere la nostra documentazione interna ad un livello rispettabile di qualità.

La società ha anche creato un comitato per gli standard di codifica, che si è riunito periodicamente e ha pubblicato aggiornamenti per gli standard di codifica a livello aziendale. Questi standard hanno prestato molta attenzione all'utilizzo delle librerie create in azienda e hanno predisposto un framework per l'implementazione di nuove librerie in modo coerente dal punto di vista architettonico.

Infine, ogni team era responsabile della pubblicazione di una serie di materiali per il corso di formazione per il resto dell'azienda. Anche i team leader delle squadre con ampia esposizione interna hanno corso corsi interni di addestramento una o due volte al trimestre, quindi se volevi allenarti su un componente interno, potresti impararlo direttamente dalla sorgente.

In definitiva, la condivisione delle conoscenze è un problema di processo, non un problema tecnico. La tecnologia può sicuramente aiutare, ma il processo rimane il mezzo principale per affrontare il problema.

"Vendere" il processo può essere difficile, specialmente per le parti interessate che dovranno fare più lavoro. Fortunatamente, la condivisione delle conoscenze ha un vantaggio significativo: aumenta la mobilità all'interno dell'azienda, il che è particolarmente utile quando l'azienda cresce rapidamente. Ciò significa che puoi essere promosso a un lead con un preavviso molto più breve o passare a un altro progetto che ti interessa di più.

Utilizziamo RedMine , che integra il monitoraggio dei problemi, i ticket, i wiki e altro in una buona applicazione web per la gestione dei progetti. Anche se ce ne sono altri del genere.

Come programmatori a volte cerchiamo erroneamente soluzioni tecniche a quello che fondamentalmente è un problema per le persone. Ci saranno sempre inefficienze in un grande gruppo. La migliore soluzione di cui sono a conoscenza è il buon vecchio stile "vite". Chiedo alla persona che ritengo più adatta rispondere a una domanda specifica. Se non conosce la risposta, mi rimanda al suo "guru" su quell'argomento, e così via. Non penso di aver mai avuto una catena più lunga di tre persone, e quasi sempre è uno o due. Se non hai idea di chi chiedere, invia un'email di gruppo.

Il wiki viene fornito come una sorta di FAQ. Quando qualcuno riceve la stessa domanda più volte, scrive un articolo wiki in modo che possa riferire le persone ad esso. Alla fine le persone inizieranno a cercare la wiki prima di fare una domanda, e le persone inizieranno a scrivere articoli wiki in previsione di domande frequenti. In un gruppo abbastanza grande, è probabile che qualcun altro abbia avuto la stessa domanda, o la tua domanda è abbastanza specifica da richiedere comunque aiuto individuale.

Un wiki può sicuramente essere utile, ma ci vuole tempo per scrivere articoli che saranno utili agli altri. Nella mia esperienza, ci sono due modi in cui il contenuto viene aggiunto:

1. Qualcuno con la conoscenza di un particolare modulo o funzione scrive alcuni contenuti che pensano possano essere utili agli altri.

   Spesso per lo sviluppatore o l'ingegnere di livello superiore è difficile trovare il tempo da dedicare alla documentazione scritta, e dato che molti non amano scrivere documentazione, potrebbero rimandare fino a quando non se ne dimenticheranno.

2. Qualcuno che ha richiesto aiuto o ha dovuto fare alcune ricerche serie per risolvere un problema, documenta come l'hanno risolto.

   Questo tipo di articolo può essere molto utile, in parte perché l'utente di un modulo potrebbe (anche se leggono alcuni documenti esistenti) ha identificato alcuni trucchi per il loro particolare caso d'uso. Possono anche funzionare molto bene come una sorta di guida per gli utenti futuri, anche se il caso d'uso non è esattamente lo stesso.

Sento che un datore di lavoro dovrebbe incoraggiare - e costruire in tempo per scrivere - entrambi i tipi di articoli, perché così facendo finisci per affidarti meno alla conoscenza di determinati individui.