La empresa de TI promedio tiene requisitos, un historial de rastreadores de tareas, fuentes (quizás incluso con comentarios en el código), instrucciones para casos típicos, importantes y complejos en producción, una descripción de los procesos de negocio (desde la incorporación hasta “cómo irse de vacaciones”). ”) , contactos, claves de acceso, listas de personas y proyectos, descripciones de áreas de responsabilidad y un montón de otros conocimientos que probablemente nos olvidamos y que se pueden almacenar en los lugares más increíbles.
Conocimiento =/= documentación. Esto no se puede explicar, hay que recordarlo.
Cómo asegurarse de que quienes necesitan saber algo de esto entiendan dónde y cómo encontrarlo, y que todos los que necesitan estar al tanto de cosas y acuerdos individuales puedan conocer de manera instantánea y precisa los cambios en ellos.
En el episodio final del podcast “Team Lead Will Call”, los chicos de Skyeng hablaron sobre gestión del conocimiento con Igor. Tsupko es una persona del comité del programa KnowledgeConf y el “director de lo desconocido” en Flant.
La grabación completa está disponible como , y a continuación hemos recopilado algunos consejos interesantes y enlaces a materiales útiles que se mencionaron en el audio o ampliamos la información del mismo. Sería fantástico si también compartieras los trucos y trucos de tu equipo en los comentarios.
Primer truco: ya no necesitas saber en qué sistema buscar
“Tomé nuestras fuentes de conocimiento y realicé una búsqueda general de ellas: una única ventana con un sistema de filtrado para reducir el área de búsqueda. Sí, al mismo tiempo, aún es necesario controlar su calidad, reponer la base de conocimientos y combatir la duplicación y la información errónea.
Una hoja de papel para encontrar eso es todo.
Pero alrededor del 60% de los ingenieros de Flant ya utilizan esta búsqueda al menos 1 o 2 veces al día y, por lo general, encuentran respuestas en la primera o segunda posición. Y como prueba de concepto está la indexación de documentos de Google: todos los documentos, carpetas, unidades de furgoneta, etc.; todo esto también se incorpora fácilmente a la búsqueda interna".
Segundo truco: cómo no perderse cosas de importancia crítica en varios chats
"Si trabajas en un equipo distribuido, entonces probablemente una parte importante de tu día la pases en Slack, y en cuyo caso estás acostumbrado a hacer algo como esto: "@myteam, ayuda/mira/ingresa el correcto... ”.” Pero hay un problema con la abundancia de información, y se puede omitir una mención aparte entre otros mensajes.
En Skyeng nos ayuda un bot a través del cual puedes escribir un mensaje y etiquetar cualquier número de personas o grupos. Lo usamos en casos en los que es realmente importante que la gente lea o reaccione: se pinchará sin cesar hasta que presiones el botón "Leí"; no podrás omitirlo ni ignorarlo".
Pregunta a responder: ¿qué hacer con la documentación?
“Muchos conocimientos provienen de los técnicos, pero no todo el mundo sabe cómo describirlos bien.
Después de todo, no tienes ningún compilador o linter que te diga si lo estás haciendo bien o no y, a menudo, el resultado que tenemos es un texto incomprensible, mal formateado y incompleto. Por supuesto, debes hacerlo normalmente, no porque alguien haya venido y haya dicho "es necesario"; lo haces bien por ti mismo: en uno o dos meses lo leerás y lo entenderás. Y otra persona, al abrir un documento, no lo cerrará inmediatamente para siempre, al darse cuenta de que es inútil.
Parte del podcast dedicado a la pregunta “¿Cuántas personas se necesitan para escribir una buena documentación o hacer una demostración normal”
Pero la pregunta sigue siendo: ¿cuánto tiempo dedicar a esto y cómo hacerlo de manera eficiente?
Y si hay una respuesta honesta aquí: a menos que los empresarios participen y a menos que experimenten empíricamente el impacto de una buena documentación, existe el riesgo de que el esfuerzo produzca pocos beneficios. Esta es más una historia sobre el cambio de cultura.
Por lo demás, la experiencia y la tutoría te salvarán. Los análogos de la programación en pares, el seguimiento del progreso y las revisiones de código pueden ser adecuados aquí: muestran las mejores prácticas, hurgan en los errores y, al final, son aburridos”.
Bono: "Está bien, se lo diré de esta manera, lo entenderán"
La pregunta "cuánto tiempo dedicar a esto y en qué nivel hacerlo" es importante no sólo en el marco de la documentación, sino en general para la transferencia de cualquier conocimiento. La demostración también es un gran ejemplo de cómo compartir información. Pero hay matices: por ejemplo, cómo asegurarse de que ocupen el mínimo de tiempo.
Canal de intercambio de conocimientos entre desarrollo: informes internos, libros útiles, artículos, etc. El extracto estructurado también se almacena en Notion.
En parte, estos problemas pueden resolverse mediante la práctica de informes internos. Una vez a la semana, en un momento menos ocupado, se toman entre 40 y 60 minutos y los chicos hacen un reportaje en vídeo para los compañeros de diferentes proyectos. Equipo frontend del producto clave - Vimbox - sobre su kit de interfaz de usuario, que puede tener como tema cualquier otro proyecto. El equipo de desarrollo de marketing habló sobre una biblioteca para rastrear y registrar solicitudes, lo que inmediatamente atrajo el interés de varios otros proyectos. El equipo del proyecto Matemáticas compartió su experiencia al cambiar de REST API a GraphQL. El equipo de lecciones grupales está pensando en compartir cómo fueron los primeros en cambiar a PHP 7.4. Etcétera.
La lista se mantiene desde mayo de 2018 y tiene más de 120 entradas.
Todas las reuniones se inician a través de Google Meet corporativo, se graban y en un plazo de 1.5 horas aparecen en una carpeta en un disco compartido de Google, y los enlaces a las grabaciones se duplican en el mismo Slack. Es decir, no es necesario que venga si hay una emergencia, pero mírelo más tarde a velocidad 20; por lo general, el informe en sí dura hasta XNUMX minutos y la discusión, cómo resulta. Pero no pasamos de la hora)
PS ¿Qué funcionó y qué no funcionó para usted?
Enlaces de interés:
- Rodion Nagornov de Kaspersky Lab sobre y por qué esto no es documentación (gracias al canal de Igor por el enlace , hay muchos más como ese).
- Igor Tsupko de Flant sobre eso en mi empresa
- Alexey Kataev de Skyeng (brechas de conocimiento en tecnologías y áreas específicas) en un equipo distribuido.
- Sergey Goncharuk de Flant sobre la transmisión de información - , si encuentra un problema en un equipo distribuido.
Fuente: habr.com