Transversalidad del conocimiento

Hola amigos quisiera establecer un tema respecto del cómo, desde del punto de vista de la gestión, es posible asegurar transversalidad en el conocimiento de los proyectos, buscando no quedar parados por el integrante que falta.

Nuestros equipos en el día a día ejecutan proyectos de software y en algunos casos, al enfermarse alguien o cualquier inconveniente similar los standups, retrospectivas de release u otras se quedan cortos respecto a esto.

Uds. conocen algunas actividades complementarias que busquen idealmente minimizar este tipo de situaciones?

Para minimizar el problema de que alguien se ausenta y el proyecto corre peligro (de que falte gente que sepa acerca de temas específicos del mismo) se puede hacer lo siguiente:

  • Pair Programming: dos personas siempre trabajan en un mismo aspecto del proyecto al mismo tiempo
  • Brown Bags: sesiones de transferencia de conocimiento, sencillas, cortas, a la hora de almuerzo
  • Metáfora: todo el equipo tiene acceso a información que explica de qué se trata el proyecto, y ésta información está explicada de tal forma que se puede seguir un hilo conductor que cuenta la historia de qué es lo que estamos haciendo y por qué lo estamos haciendo

Aunque suene contraintuitivo, tener parejas trabajando ayuda a evitar tener dependencia en personas específicas. Claro que tiene sus costos.

1 me gusta

Hola Germán:
Pair programming me complica al menos de manera permanente dado que el proyecto es de largo aliento y como tal, es “vivo” si fuera un producto me sería un tanto más sencillo pero de momento respecto de la dinámica del proyecto me es imposible sustentarlo para mantener el proyecto rentable.

En términos de negocio el equipo completo sabe de que se trata (apuntando a metáfora), pero tú bien sabes es que otra cosa es a la hora de meterse al método mismo a nivel de código.

Brown bags no lo conocía, buscaré más info y veré si puede aplicar (en primera instancia si me suena bueno)

Saludos y gracias.f

Hola @Cristian_Bravo, en los equipos que participo, usamos algunas reglas para mitigar la centralización de conocimiento:

  1. Los correos se envían con copia a todo el equipo (Creamos un grupo en Outlook).
  2. No enviar archivos adjuntos, todos los archivos son almacenados en la nube y solo se envía el link.
  3. Buenas practicas de codificación, el código habla por si mismo, los métodos no tiene mas de 10 lineas, se limita el uso de IF, entre otras reglas.
  4. Todo desarrollo tiene su documentación, casos de pruebas, historias de usuario y diseños etc.
  5. Si o si, se realiza refinamiento de historias de usuario, esto con el fin de tener mayor claridad a nivel grupal de lo que se debe desarrollar y tener tiempo antes del planning para aclarar dudas.
  6. Si hay un especialista de negocio en el equipo, este se encarga de capacitar a 2 backup.

Espero te sirvan algunas de esas ideas.
Saludos.

Hola gracias por tu post.

Todo lo que mencionas lo hacemos acá también, pero finalmente es paliativo al problema. Creo que lo único que evita realmente el problema es el punto 6, al menos en mi caso.

Saludos y gracias!

Este es un problema más común de lo que parece.

Las soluciones que comenta @taichi2000 , las comparto, especialmente Pair Programing, pero indicas que choca con tu rentabilidad. Te invito a darle una mirada más a fondo, ya que el Pair Programming aumenta la productividad (y debiera aumentar en algo la rentabilidad, si está ligada de alguna forma al tiempo de entrega o a la calidad)

Ten en cuenta que muchas de las prácticas ágiles son contra-intuitivas, es decir, requieren un “salto de fe” para implementarlas, ya que todo el adoctrinamiento tradicional te dice que no hay forma en que puedan funcionar, cuando la la mayoría de los reportes de quienes las practican, indica que son efectivas o muy efectivas.

La inversión es el punto que quizás te preocupe, tiene un tiempo de inicio en el cual vas a ver un declive de productividad y probablemente más problemas que soluciones, pero eso sucede con cualquier cambio de procedimiento que valga la pena.

Hola David.

Efectivamente choca con la rentabildad incluso con el flujo, toda vez que el esquema de entregas e hitos ya viene definido en un marco propuesto. Si “me como” la curva inicial no podré cumplir con el plan en entregas e hitos y si bien siguiendo tu teoría a la larga recuperaré, no veo probable

Quizás en un proyecto más abierto podría aplicar, para flexibilidar la dinámica de entregas vs flujo.

En ese caso, puedes solo reducir los síntomas, pero el problema va a reaparecer.

Revisa este artículo publicado por @darsenov Una experiencia con un equipo trabajando de manera ágil que resume los argumentos y da un par de guias, especialmente sobre la práctica del swarming, que con el tiempo, puede llevarte a hacer un cambio más profundo.

@Cristian_Bravo Bueno, si tu proyecto tiene

  • Precio fijo
  • Alcance fijo
  • Tiempo fijo
  • Equipo fijo

Veo poco margen de maniobra ahí. Ojo que no puse la Calidad del proyecto como un factor, ya que considero que la Calidad debe ser intransable.

Implícitamente creo que todos nos estamos refiriendo aquí a proyectos que tienen un cierto grado de incertidumbre, en cuanto a:

  • Características del proyecto
  • Regulación de leyes
  • Problema no conocido (al menos en parte)
  • Solución no conocida (al menos en parte)

Para minimizar el Bus Factor, es decir, a cuánta gente del equipo la debería chocar un autobús para que el proyecto se declare como un fracaso, sugeriría empezar de a poco a crear conciencia en el equipo de la necesidad de convertirse en un equipo de alto rendimiento, y con eso me refiero a adoptar los valores e implementar las prácticas de Extreme Programming.

El camino puede parecer largo, lo bueno es que es simple comenzar: dando el primer paso.

No es tan así, pero si tengo un marco. Lo fijo de las variables que expones se variabiliza en cuanto afectas al otro moviéndolas, dado que en el mundo real si aumento el equipo aumenta el precio, me sigues?

Agradezco los tips de todos.