A empresa media de TI ten requisitos, un historial de rastreadores de tarefas, fontes (quizais incluso con comentarios no código), instrucións para casos típicos, importantes e complexos en produción, unha descrición dos procesos comerciais (desde a incorporación ata "como ir de vacacións". ”) , contactos, claves de acceso, listas de persoas e proxectos, descricións de áreas de responsabilidade, e un montón de coñecementos que probablemente nos esquecemos e que se poden gardar nos lugares máis sorprendentes.
Coñecemento =/= documentación. Isto non se pode explicar, hai que lembralo
Como asegurarse de que aqueles que precisan saber algo disto entendan onde e como atopalo, e todos os que precisan coñecer cousas e acordos individuais poden coñecer de forma instantánea e precisa os cambios neles.
No episodio final do podcast "Team Lead Will Call", os rapaces de Skyeng falaron sobre a xestión do coñecemento con Igor Tsupko é unha persoa no comité do programa KnowledgeConf e o "director do descoñecido" en Flant.
A gravación completa está dispoñible como , e a continuación recollemos algúns consellos interesantes e ligazóns a materiais útiles que se mencionaron no audio ou ampliamos a información do mesmo. Sería xenial que tamén compartas os trucos e trucos do teu equipo nos comentarios.
Primeiro truco: xa non necesitas saber en que sistema buscar
“Tomei as nosas fontes de coñecemento e fixen unha busca xeral delas: unha única fiestra cun sistema de filtrado para reducir a área de busca. Si, ao mesmo tempo, aínda cómpre supervisar a súa calidade, repoñer a base de coñecemento e combater a duplicación e a información errónea.
Un anaco de papel para descubrir iso é todo
Pero xa, preto do 60% dos enxeñeiros de Flant usan esta busca polo menos 1-2 veces ao día, e normalmente atopan respostas na primeira ou segunda posición. E en forma de proba de concepto está a indexación dos documentos de Google: todos os doxs, cartafoles, unidades de furgoneta, etc., todo isto tamén se introduce facilmente na busca interna.
Segundo truco: como non perderse cousas de importancia crítica nun grupo de chats
"Se traballas nun equipo distribuído, probablemente unha parte importante do teu día pases en Slack, e nese caso estás afeito a facer algo así: "@meuequipo, axuda/mira/ introduce o correcto... ”.” Pero hai un problema coa abundancia de información, e pódese perder unha mención separada entre outras mensaxes.
En Skyeng axúdanos un bot a través do cal podes escribir unha mensaxe e etiquetar calquera número de persoas ou grupos. Usámolo nos casos nos que é realmente importante que a xente lea ou reaccione: pisará sen parar ata que premes o botón "Leo"; non poderás ignoralo nin ignoralo".
Pregunta a responder: que facer coa documentación?
“Moito coñecemento provén dos técnicos, pero non todos saben describilo ben.
Despois de todo, non tes ningún compilador ou linter que che diga se o estás facendo ben ou non, e moitas veces a saída que temos é un texto incomprensible, mal formato e incompleto. Por suposto, cómpre facelo normalmente, non porque alguén viñese e dixese "é necesario": faino ben por ti mesmo: nun ou dous meses lerás e entenderás. E outra persoa, ao abrir un documento, non o pechará inmediatamente para sempre, ao entender que é inútil.
Parte do podcast dedicado á pregunta "Cantas persoas se necesitan para escribir unha boa documentación ou facer unha demostración normal"
Pero a pregunta segue sendo: canto tempo destinar a isto e como facelo de forma eficiente?
E se hai unha resposta honesta aquí: a menos que os empresarios estean implicados, e a menos que experimenten empíricamente o impacto dunha boa documentación, existe o risco de que o esforzo dea pouco rendemento. Esta é máis unha historia sobre o cambio de cultura.
Polo demais, a experiencia e a titoría aforrarache. Os análogos da programación por parellas, o seguimento do progreso e as revisións de código poden ser axeitados aquí, mostrando as mellores prácticas, detectando erros e aburrindo ao final.
Bonificación: "Está ben, voulles dicir deste xeito, eles entenderán"
A pregunta "canto tempo dedicar a isto e a que nivel facelo" é importante non só no marco da documentación, senón en xeral para a transferencia de calquera coñecemento. A demostración tamén é un excelente exemplo de compartir información. Pero hai matices: por exemplo, como asegurarse de que ocupen un tempo mínimo.
Canle de intercambio de coñecemento entre o desenvolvemento: informes internos, libros útiles, artigos, etc. O extracto estruturado tamén se almacena en Notion.
En parte, estes problemas pódense resolver coa práctica de informes internos. Unha vez á semana, lévanse entre 40 e 60 minutos nun momento menos ocupado, e os mozos fan un informe en vídeo para os compañeiros de diferentes proxectos. Equipo de frontend do produto clave - Vimbox - sobre o teu kit de IU, que pode ser temático para calquera outro proxecto. O equipo de desenvolvemento de mercadotecnia falou dunha biblioteca para o rastrexo e rexistro de solicitudes, o que inmediatamente atraeu o interese de varios outros proxectos. O equipo do proxecto de Matemáticas compartiu a súa experiencia de cambiar da API REST a GraphQL. O equipo de clases grupais está pensando en compartir como foron os primeiros en cambiar a PHP 7.4. Etcétera.
A lista mantense desde maio de 2018 e ten máis de 120 entradas
Todas as reunións inícianse a través de Google Meet corporativo, grávanse e nun prazo de 1.5 horas aparecen nun cartafol dunha unidade de Google compartida, e as ligazóns ás gravacións duplícanse no mesmo Slack. É dicir, non tes que vir se hai unha emerxencia, pero mira máis tarde a velocidade 20; normalmente o informe en si dura ata XNUMX minutos e a discusión, como resulta. Pero non imos máis alá da hora)
PS Que funcionou e que non funcionou para ti?
Ligazóns útiles:
- Rodion Nagornov de Kaspersky Lab sobre e por que isto non é documentación (grazas á canle de Igor pola ligazón , hai moito máis como iso).
- Igor Tsupko de Flant sobre iso na miña compañía
- Alexey Kataev de Skyeng (lagoas de coñecemento en tecnoloxías e áreas específicas) nun equipo distribuído.
- Sergey Goncharuk de Flant sobre transmitir información - , se atopa un problema nun equipo distribuído.
Fonte: www.habr.com