Condivisione della conoscenza aziendale?

Disponiamo di un ampio sito di Sharepoint interno e di un sito di supporto rivolto ai clienti, che richiede molti documenti dal sito di Sharepoint interno. Ciò riguarda meno i dettagli di implementazione e molto altro sul supporto, ma siccome lavoro ampiamente in una capacità di supporto, abbiamo bisogno di accedere a molte informazioni implementative e quindi finiamo per essere i driver per il team di ingegneri per documentare cosa stanno facendo e perché. Un sistema di tracciamento dei bug dettagliato è anche prezioso per seguire come i problemi sono stati risolti.

Nella nostra azienda, in parte perché abbiamo uno sviluppo diffuso in un paio di località, molte discussioni sulle nuove funzionalità e problemi di supporto finiscono per accadere via email. Piuttosto che cercare di cambiare questo, l'approccio più semplice è un sistema di archiviazione della posta elettronica che renda le discussioni ricercabili e rintracciabili - in modo efficace un approccio di tipo newsgroup. Siamo in grado di farlo attraverso Sharepoint, anche se bisogna essere consapevoli dei limiti delle dimensioni dell'elenco, anche se crescerà a milioni di elementi che non è possibile fare molto in termini di classificazione di elenchi molto grandi o modifica di viste su di essi senza si schianta drammaticamente.

StackOverFlow per aziende come spiegato nell'articolo che hai menzionato?

IMHO è una pessima idea .

Rafforzerà la competizione invece di collaborazione .

Hai bisogno della collaborazione tra divisione e dipartimento, senza aumentare la concorrenza.

Immagina anche che l'impatto estremamente negativo di essere svalutato dal tuo collega (di fronte agli altri) possa avere sulla tua salute psichica.

Non mescolare tutto.

Tuttavia, un'idea molto più uservoice.com in cui i dipendenti possono postare idee (anonimamente) e altri dipendenti che li inviano (anche in modo anomalo) avranno un impatto positivo. Alcuni anni fa ho sviluppato una piattaforma di questo tipo per un grande istituto bancario e ha aiutato i dirigenti a identificare cosa migliorare in via prioritaria.

Mi piace molto anche l'idea del wiki, ma hai ragione-è difficile convincere le persone a contribuire. E senza contributi, nessuno lo userà davvero perché non ha abbastanza informazioni. Esiste comunque un "punto critico" in cui, se si riuscisse a far pubblicare le persone (magari attraverso un processo aziendale richiesto), a un certo punto il wiki si sposterà come se fosse un grande archivio di informazioni.

La paia di programmazione è un ottimo modo per diffondere la conoscenza tacita.

Il problema con la conoscenza tacita è che può praticamente non essere scritto o insegnato, ma solo sperimentato. La programmazione accoppiata (in particolare l'accoppiamento promiscuo) lo fornisce.

La conoscenza che è importante per l'azienda dovrebbe far parte del progetto stesso, sotto forma di codice ben scritto, commenti di alto livello sull'architettura e documentazione eccezionale sugli obiettivi del progetto e su come vengono realizzati con la tecnologia .

Non potrei non essere più in disaccordo con le conclusioni dell'autore collegato. Incoraggiare l'acquisizione di conoscenza scoraggiando la collaborazione del team? Ci dispiace, ma non è così che funziona. È la collaborazione stessa che produce la ricchezza della conoscenza, non sequestrando gli ingegneri nei cubicoli.

La mia azienda ha alcuni forum di discussione interni. Sono usati molto di rado. Per la maggior parte, la conoscenza che abbiamo è troppo generica (domande / argomenti di tecnologia generale che sono discussi altrettanto bene in Internet) o troppo specifica (si applica solo alla nostra applicazione e non ad altri team applicativi nella stessa azienda). È positivo in quanto offre un posto dove le persone possono dire come faccio a realizzare xyz qui, ma non è molto familiare.