Uno de los grandes desafíos en el desarrollo de un producto software es conseguir que el conocimiento y las experiencias adquiridas en el transcurso de su vida no se diluyan (incluso se pierdan) durante el proceso de traspaso.
Siempre es conveniente tener en mente la posibilidad de un traspaso, incluso cuando no se ha previsto, ya que hay muy diversos motivos que pueden acontecer, como por ejemplo: disolución del equipo, reemplazar a miembros, fin de la fase de desarrollo y entrega del proveedor al cliente, adquisición por otra empresa, etc.
El proceso de transferencia del conocimiento suele ser costoso, sobre todo cuando se trabaja con un proveedor de software externo (una consultora o software factory); en muchos casos motivado por la dejadez de la dirección del proyecto, que puede mantener en segundo plano las funciones específicas para la futura transferencia de conocimiento, centrando el esfuerzo en la salida del producto. En estos casos el proveedor aprovecha para tomar decisiones y acaparar el conocimiento del negocio, que luego difícilmente es capaz de transmitir.
Desde el punto de vista del desarrollo de software veo dos puntos claves para conseguir el traspaso de conocimiendo, independientemente de si se hace un traspaso completo (cambia todo el equipo) o parcial (cambia algún miembro del equipo):
- Transferencia de conocimiento tecnológico y/o técnico.
- Transferencia de conocimiento funcional (negocio).
Transferencia de conocimiento tecnológico y/o técnico
Se pudiera partir con la premisa de que la capacitación técnica del equipo que va a recibir (o heredar) el software es igual que la del equipo que lo ha desarrollado. Aunque este sea el caso, siempre es conveniente propiciar encuentros entre equipos para mejorar la comprensión de qué motivó cierta decisión, o porqué se implementó de tal o cual forma. Además es muy útil comentar los puntos de mejora del software, para que el equipo nuevo se haga a la idea de lo que va a recibir.
Si la capacidad técnica del nuevo equipo no es la adecuada para recibir el software (desconocimiento de frameworks, lenguajes de programación, arquitectura, etc.) es obligatoria la formación del nuevo equipo, bien previa al traspaso, bien durante el propio traspaso. Se debe asumir este handicap a la hora de valorar los tiempos necesarios para que el equipo nuevo pueda desempeñar su función al 100%.
Aunque las reuniones personales son muy enriquecedoras, en este aspecto siempre apuesto por usar herramientas objetivas, que valoren la calidad del software, la estabilidad y demás parámetros interesantes sin entrar en opiniones. Por eso veo fundamental llevar un control de este tipo de métricas a lo largo del desarrollo del proyecto, pero también antes de un traspaso. ¿Qué quiero decir con esto? que el equipo heredero debe conocer la deuda técnica acumulada del software. Para eso tenemos que conocer las posibles vulnerabilidades, la arquitectura, el entorno de desarrollo y ejecución, los procesos de testing, puesta en producción, calidad del código, etc. Y esa información debería estar documentada detalladamente.
Se debería dejar claro cuando se comienza el desarrollo, que el producto a desarrollar es altamente susceptible de ser transferido a otro equipo (de dentro o fuera de la organización), y que siempre se van a tener en cuenta las medidas y parámetros oportunos para su traspaso en las mejores condiciones. Por ese motivo es muy interesante recordar al equipo que desarrollen para los demás. Entendiendo por desarrollar software no solo escribir código.
Transferencia de conocimiento funcional
La gran olvidada. Es frecuente menospreciar el valor del conocimiento funcional, las reglas de negocio que dan vida al software y que son la verdadera justificación por la que se comenzó su desarrollo.
El problema que intenta solventar, las necesidades a cubrir, y las motivaciones que han llevado a plantear una solución software. En este aspecto el equipo original siempre lleva ventaja al nuevo, y se debe de minimizar esta brecha de conocimiento.
En el caso de tener un cliente final, es casi obligación el mantenerlo informado de los cambios en el equipo que motiven una transferencia de conocimiento, y que él mismo valide que el conocimiento funcional no se diluye en el traspaso, manteniendo siempre la calidad y corrección de la información transferida.
Es fundamental mantener una documentación útil y bien estructurada de todo el conocimiento funcional, así como la importancia o prioridad de las funcionalidades. No es suficiente con que la información esté en la cabeza de una persona, hay que plasmarla, hacerla accesible y útil para todo el equipo.
¿Qué suele ocurrir?
No existe documentación funcional. Si existe está desactualizada o no validada, son documentos poco útiles. Se confía en que el código fuente sea la bola de cristal donde descubrir las funcionalidades. Todo esto supone un desgaste y el consumo de un tiempo poco deseable.
En ciertos casos de proyectos de cierta emberagadura es recomendable hacer uso de mapas de conocimiento, son una herramientas excelentes para determinar dónde se encuentra el conocimiento y sus características.
Ante este escenario, la gestión del traspaso de conocimiento requiere que los directores velen por sostener una comunicación efectiva con y entre los equipos de trabajo, definir los roles y responsabilidades, mantener la documentación actualizada, velar por la calidad del desarrollo y definición escrupulosa de las pruebas de validación. De otra forma el traspaso será de deuda, no de conocimiento.
Comentarios