En este post te voy a explicar que es el congitive load o carga cognitiva y como esta puede afectar el rendimiento de programadores individuales o equipos.
Todas las personas, independientemente de sus habilidades y capacidades, tenemos un límite físico en la capacidad de datos e información que podemos almacenar en nuestro cerebro, en determinado momento. Esto también aplica a los equipos de trabajo, por obvias razones.
Es muy difícil determinar el espacio disponible de memoria de trabajo que tiene una persona o un equipo para asignar, cuando estos reciben nuevas tareas. Cada tarea nueva que se realiza tiene un coste cognitivo, que frecuentemente no es tomado en cuenta al momento de asignar actividades. Esto no significa que el equipo no deba recibir nuevas actividades, más bien, estas actividades por sí mismas van a agregar un coste adicional y en teoría, podrían reducir los tiempos de respuesta del equipo. En resumen, entre más se abarque, menos efectividad habrá.
Costes ocultos.
Un equipo de trabajo que atiende más de un dominio, va a sufrir de falta de efectividad como mal crónico. Empezando por el hecho de que a más dominios que atender, se incrementan las posibilidades de tener Context Swicthing. Y también, el desgaste producido por dominar todos y cada unos de los sistemas que el equipo tiene que atender.
¿Cómo reducir la carga cognitiva?.
No es necesario que un equipo de trabajo tenga que saberlo todo, no me refiero únicamente a la lógica de negocio y al código mismo. Una aplicación moderna se compone de muchas más partes que solo código. Desde infraestructura, servidores, aplicaciones de terceros, testing, QA, migraciones, actualizaciones, etc. Muchas de esas partes, pueden ser delegadas, y en el mejor de los casos, automatizadas. Con esto podemos remover una parte de carga cognitiva del equipo.
También tenemos el problema del dominio, por dominio me refiero al aspecto específico del negocio que la aplicación busca solucionar. Los dominios y las aplicaciones crecen con el tiempo, poco a poco, y solamente te vas a dar cuenta de su exceso de tamaño hasta que los costes de mantenimiento y tiempos de respuesta se vean incrementados. Un sistema demasiado grande, debe ser divido, al menos en la parte organizacional. Por ejemplo: el sistema de la compañía tiene un módulo de facturación, donde se procesan las facturas de ventas, las de compras y las de nómina. El equipo de trabajo tiene problemas para corregir errores y enviar nueva funcionalidad. Una idea, podría ser dividir el equipo de trabajo en áreas especializadas, una para nómina, otra para compras, y otras para ventas. Aun cuando el sistema monolítico sea el mismo, la carga cognitiva que debe llevar cada equipo es solo 1/3.
Carga cognitiva y crecimiento de equipos.
La solución más común ante la falta de resultados por parte de un equipo de desarrollo es: incrementar el número de miembros de equipo. Los equipos, por sí mismos, tienen una limitación física. No se puede hacer crecer un equipo indefinidamente. El número máximo de miembros que debería tener un equipo fluctúa de 7 a 15 miembros, dependiendo de la organización y de la cultura empresarial. Un equipo muy grande, va a agregar más carga cognitiva a sus miembros.
Para el crecimiento de equipos, debes tener en cuenta los principios de WIP y el principio de única responsabilidad. Es preferible tener equipos pequeños, especializados en un dominio, que un equipo grande que abarque todos. Si llegado el momento, en tu organización necesitas incrementar el número de miembros, está bien, hazlo. Antes, evalúa los dominios de tus aplicaciones para ver cuál de ellos puede ser dividido en dos o tener un subdominio. La arquitectura de tus equipos, va a tener un impacto directo en la arquitectura de tus aplicaciones.
Conclusiones.
No hay una fórmula que puedas ocupar para saber cuándo tienes problemas con las cargas cognitivas. Los indicadores de productividad pueden sugerirte que es momento de hacer cambios en tu estructura organizacional. También, tener equipos y miembros especializados, no implica que estos no puedan ser incorporados en otros equipos o proyectos. Lo único que se busca con esto, es que la carga cognitiva que tiene un miembro del equipo sea la necesaria para atender el trabajo que le fue asignado. Esta carga puede cambiar en un futuro.
Referencias:
Photo by David Matos on Unsplash
- NVL in SQL Server - 2023-11-01
- ¿Que es Cake Build? - 2023-02-22
- #How to fix error: MSB4019: The imported project «Microsoft.Data.Tools.Schema.SqlTasks.targets» was not found - 2023-02-20