Será casualidad, será moda, pero en estas semanas 4 personas me han puesto el ejemplo de la paternidad como problema a la hora de revisar el trabajo de compañeros…
Hay algo que necesitas, necesito, necesitamos, entender. Cuando alguien crea algo, tú creas algo, yo creo algo, y ese algo puede ser desde una clase Java, a un power point, un Test, o un plan de Marketing o lo que sea, quien, o quienes, lo crea genera con ese algo que ha creado un sentimiento de propiedad, que creo que se entiende mejor si le llamamos sentimiento… de paternidad.
Esto es por lo general, que siempre hay casos, y raros por ahí, pero es lo más común o… es lo que yo más me he encontrado.
Aunque alguien cree algo en el trabajo, bajo en ámbito de una empresa, aunque ese ente abstracto llamado empresa entienda que esa creación le pertenece, porque esa persona que lo creó trabaja para esa empresa, independientemente de esto, el creador siempre sentirá la creación como suya, como su hijo, o su hija, con sentimiento paternidad.
Entonces, al igual que si de un hijo fuese, al padre que ha creado ese algo no le gustará (y aquí hay grados) que le digan que su hijo es feo, que no es muy listo, que no tiene sentido para la humanidad, que habría que cambiarle esto, lo otro, que “yo lo hubiera hecho mejor”, etc.
Todo esto se manifiesta especialmente cuando la necesidad del trabajo en equipo lleva a que el trabajo de uno, o unos pocos, tiene que ser revisado, matizado o evolucionado por otros, véanse las “peer reviews” y similares.
Algo relacionado con esto ya hablamos en Enfoques “sin ego” y que si en tu equipo existe la cultura de otro vea el trabajo que has hecho y en En tu equipo, ¿Cualquiera puede tocar el software o sólo aquel quien lo desarrolló? La Propiedad Colectiva del Código (Collective Code Ownership)
Como te citaba más extendidamente en uno de los post anteriores, hasta el propio Yourdon, hace nada menos que 40 y algo años, en el 1975, ya le dedicaba un artículo a lo que él llamaba enfoques de trabajo en equipo “sin egos”, véase en nuestro contexto… enfoques que buscan reducir el sentimiento de paternidad de lo creado o de permitir la crítica sobre los hijos para su mejora.
Los antiguamente llamados “walkthrough”, las más modernas “peer reviews”, las revisiones en grupo, las pair review, hasta los Mob Programming o la práctica de la “Propiedad Colectiva del Código” (Collective Code Ownership) de Extreme Programming (a la que ya le dediqué un post) necesitan de ese enfoque de relajación del sentimiento de paternidad con el trabajo desarrollado.
Pero claro, los instintos son los instintos, y hasta el de paternidad con el trabajo desarrollado puede considerarse un instinto, hasta el punto de que ya decía Yourdon en el 75 que las revisiones del trabajo de uno, por parte de otros, pueden ser llegar a consideradas “algo inaudito”, y al que incluso llegaron a decirle que leer el código, o el trabajo, de otro es como “leer su correo personal.
Primera vez que me tocó hacer una gestión Ágil en una empresa... año 2001. Desde entonces he trabajado en, o para, más de 90. Y he formado a más de 2000 alumnos.
También soy profe de la Universidad Rey Juan Carlos.
- Más allá del Management 3.0: 12 prácticas (de muchas) que no están en M 3.0 - 25 enero, 2024
- Más allá del Management 3.0: Otros muchos patrones para equipos Ágiles - 18 enero, 2024
- Años 30, Ohio (EE.UU.) y el Agile Product Management - 11 enero, 2024
Mi punto de vista es muy parecido.
De ahí, que estemos aún en «artesanía del software», y no «ingeniería del software».
Porque esto no pasa en otras ingenierías (obra pública, industriales, navales, aeronáuticos, etc), ¿no?