4 de julio de 2024
Las áreas tecnológicas son un eje central de información y documentación que obligatoriamente debe trascender al resto de la compañía de forma automática para conseguir la sincronización entre todas las personas con el mínimo esfuerzo. (Flujos de Negocio, Estructuras de Atribuciones, Demostraciones Funcionales…).
Cuando no existe un proceso estandarizado que favorezca la redacción y transmisión de la información transversal, se genera un entorno de: preguntas repetitivas, dudas y consultas alrededor del mismo conocimiento que convierten en ineficientes a los equipos.
Por no hablar de la dependencia a nivel compañía de que solo escasos empleados conozca como funciona una determinada arquitectura, proceso ó ese fichero batch que mágicamente llega a nuestro partner de integración todas las semanas.
Hay distintos comportamientos corporativos que denotan la misma problemática:
Si algo he aprendido con el paso del tiempo, es que no hay nada más óptimo que la información única centralizada, El dato único que dirían algunos vendedores de lechugas. Es por ello que tras analizar distintas soluciones, decidí probar con el sistema de Handbook.
El término Handbook puede asociarse a distintos elementos, es por ello que primero de todo hay que indicar qué es un Handbook a los términos de esta prueba:
Repositorio central de información en el que se encuentran los manuales, estándares y procedimientos de la compañía.
No limitamos la información a los Handbook de empleados donde sólo se incluye información de onboarding, cultura y legal, sino que aprovechamos para, además de incluir esta información mencionada, añadir los procedimientos operativos.
A continuación, se definen las características que debe tener este repositorio para asegurar el correcto funcionamiento:
Información del propietario y colaboradores
Toda página debe tener unos responsables. Son las personas que se encargan de que su apartado asignado se mantenga siempre actualizado y las que se encargan de validar en última instancia cualquier cambio en los mismos. Normalmente son las personas a las que acudir en cualquier duda sobre el contenido.
Control de versiones
Los apartados son vivos, cambian con el tiempo al igual que la compañía. Por lo tanto debe existir un histórico de cambios que indiquen su última fecha de actualización así como la variación que ha sufrido en cada momento.
Enlaces entre apartados
Siempre se evita duplicar la misma información en dos apartados distintos (DRY). Dado que muchos procesos dependen de otros, debe existir la posibilidad de navegar entre apartados.
Sistema de comentarios
Los debates sobre los cambios existen sobre la misma información y no en canales separados. De esta forma siempre mantenemos una trazabilidad de por qué se tomaron las distintas decisiones.
Migrable
Este repositorio contiene gran cantidad de información específica de la compañía, así que evita el vendor lock-in.
Sistema de permisos
No todo el mundo puede editar el contenido a su discreción y también hay ciertos apartados que deben de ser, por seguridad, visibles por ciertos roles de la compañía.
A pesar de esta característica, siempre hay que buscar que la información sea lo más transparente posible y vista por el mayor número de personas para aportar el máximo contexto.
La estructura de la información, como la compañía es viva y podrá cambiar con el tiempo, por lo que tampoco esperes tener la estructura perfecta desde el inicio y no te preocupes por ello.
La primera pregunta que nos hacemos cuando empezamos es cómo estructurar los apartados de información del más alto nivel. Cada organización se distribuye de forma distinta, en función de su tamaño, cultura y producto a ofrecer.
La recomendación es agruparlo en zonas funcionales, es decir, establecer un primer nivel general donde exista la información genérica de la compañía (Misión, Valores, Objetivos…) y un segundo nivel en función del área donde impacta dicha información (Personal, Tecnología, Producto, Marketing, Financiero…). Haz uso de cuantos niveles jerárquicos te sean necesarios.
En nuestro caso establecimos la siguiente estructura (Se ponen unas páginas de ejemplo):
Estructura de ejemplo
- General
Esto puede construir en una gran variedad de herramientas, depende de qué stack utilicéis actualmente para incluso aprovechar alguna licencia que utilicéis. Por ejemplo, nosotros aprovechamos que ya utilizábamos Notion como base de conocimiento técnica para incluirlo en dicho sitio.
Recuerda que cada compañía tiene su idiosincrasia, la estructura que le funcione a una compañía no asegura que funcione en la tuya, y por ello debes mantener la mentalidad de amoldarlo a lo que a vuestra compañía le funcione.
Las herramientas y frameworks de trabajo no se aplican con sólo configurarlas. Es como decir:
Somos Agile porque utilizamos Jira.
Cometí el error en los inicios de redactar y migrar toda una serie de procedimientos, manuales, guías de cultura, de diseño, de tecnología sin prestar atención en cómo hacía parte al equipo de la construcción y evolución del Handbook.
Me encontré con páginas y páginas de información a la que nadie acudía y obviamente no se aplicaban en el día a día.Sólo hay un ingrediente que, si no existe, nunca funcionará este sistema: Todo el equipo debe ser partícipe de la evolución y el mantenimiento del Handbook, y esto pasa por hacerles ver el beneficio que puede conllevar.
