/ desarrollo de software

¿Qué es el bus factor en desarrollo de software?

Imagina por un momento que un autobús escolar atropella a la persona (o personas) que más experiencia y commits tiene en tu proyecto de software. Date un minuto para pensarlo:

  • ¿Cómo afectaría a tu empresa/proyecto?
  • ¿Cómo y quién continuaría el proyecto?
  • ¿Cuanto tiempo tardarían en volver a la rapidez en cambios o mantenimiento?

Básicamente el bus factor es cuantas personas tienen el conocimiento para seguir creando tu producto. Por obvias razones, mientras menos personas, peor para ti en un hipotético caso de atropeyamiento, renuncia o vacaciones largas.

¿Todos los equipos tienen bus factor?

Sí, si hay héroes. Te explico un poco. El héroe desarrollador es aquel que todo lo sabe y que siempre tiene la respuesta a nivel de negocio y a nivel técnico. Esto es un problema para todo el equipo, pues no crece a su máximo potencial porque no toma acción a requerimientos o problemas críticos.

También es un problema para nuestro héroe, porque vive en una zona donde todo lo que sucede es por él, lo que puede llevar al confort y al egocentrismo, evitando que el mismo pueda llegar también a su máximo potencial debido a que el siempre tiene "la" solución.

¿Cómo aumento el bus factor?

Aquí te escribo algunos tips y acciones que a mi me han ayudado para aumentar este factor:

Crea una cultura de documentación

Para muchos desarrolladores esto puede ser aburrido o engorroso, pero es parte del proceso de desarrollo e incrementa la velocidad del equipo, ya que a cualquier duda puedes visitar la documentación. Activar una wiki en tu repositorio de código o escribiendo mejores historias de usuario son actividades que ayudan con este punto.

Realiza pair programming con regularidad

El o los desarrolladores héroes deben realizar sesiones de pair programming en algunos requerimientos. Esto facilita que el conocimiento de negocio y de buenas prácticas fluya. Por lo que a mayores sesiones, el desarrollador "novato" empezará a conocer el núcleo de la solución, logrando independencia para nuevos requerimientos. Sí este nuevo desarrollador, realiza pair programming con otro... bueno, tu sabes lo que pasa.

Todos somos héroes humildes

Siguiendo el punto anterior. Cuando todos tienen el mismo conocimiento todos pueden resolver o crear soluciones acordes al proyecto. Esto crea fortalezas en todo el equipo (a nivel psicológico y técnico) dando como resultado capacidad de reacción ante requerimientos o bugs críticos.

Capacitación de tu producto ó solución

Esto es algo que suelo comentar bastante. Tus desarrolladores, si o si, necesitan conocer y saber usar tu producto o solución. Te pongo un ejemplo, si vendes software para restaurantes: muéstrale como crear una comanda, como activar o desactivar platillos, o como reservar mesas. Esto ayudará a tener más contexto de la aplicación que desarrollará y empezará a hablar el mismo lenguaje que tú.

Ahí te lo dejo, un post para desarrollo de equipos técnicos. Espero te ayude a crear una cultura de aprendizaje y un crecimiento en tu equipo de desarrollo. ¡Recuerda! un autobús acecha en la esquina.

Eduardo Montalvo

Eduardo Montalvo

Programador con intereses en machine learning, clean code, arquitecturas de software y formación de equipos técnicos.

Read More