¿Por qué compartir conocimiento puede convertirse en un problema de SQA (aseguramiento de calidad de software)? No descubrimos nada nuevo cuando decimos que el mercado laboral a nivel mundial está experimentando cambios significativos. Están apareciendo nuevas tendencias que han transformado las relaciones laborales y la propia concepción que tienen los trabajadores sobre el modo que tienen de aportar valor a las organizaciones. 

Ya no existe, o en muy pocas ocasiones se ve, el trabajador que pasa toda su vida laboral en la misma empresa. Del mismo modo que cada vez existe menos la empresa que se une a un proveedor de por vida. Todo esto se ve favorecido también por el modelo de licitación, que incentiva a cambiar de proveedor en busca de reducciones de coste. 

Y aquí es donde “compartir conocimiento” se convierte en un problema o, al menos, en una traba.  Las empresas disponen de especialistas con conocimiento, pero en muchas ocasiones el servicio lo presta un tercero en el que van rotando los empleados y, por tanto, se convierte en un reto compartir el conocimiento con los muchos que están de paso.  

La rotación de empleados: un problema serio para los equipos de SQA 

Cabe decir que la rotación de la que estamos hablando y la dificultad en la compartición de conocimiento no es un problema específico de los equipos de SQA, pero sí que está suponiendo un problema en estos equipos de aseguramiento de calidad de software. 

A medida que la práctica de DevOps continúa acelerando el pulso de la innovación, sus participantes se ven obligados a pivotar de acuerdo con este nuevo cambio que se extiende por la industria de TI.

Y con los que pivotan, se va una buena parte del conocimiento que hace un equipo eficiente. Y aquí es donde muchas empresas no consiguen optimizar el tiempo, ya que hay que formar a los nuevos integrantes del puesto, y en el proceso, además de tiempo como ya hemos dicho, se destruye también conocimiento. 

En el caso concreto de los equipos de aseguramiento de calidad de software (SQA) hay al menos dos causas de rotación: las individuales y las colectivas. Las primeras hacen referencia a personas que buscan un cambio en su carrera, por ejemplo. Y las colectivas, se refieren a empresas que cambian a su proveedor de servicios de SQA. Naturalmente estas últimas tienen un impacto enorme en la empresa, que se intenta mitigar con periodos de transición de un equipo a otro. 

Del conocimiento tácito al explícito 

Hay un tipo de conocimiento, el tácito, personal, no documentado, referente a habilidades que son difíciles de explicar o transferir a otros a través del lenguaje, que nos diferencia y nos hace especiales. Es difícil de copiar por competidores y ofrece, en ese sentido, ventaja competitiva. Pero es difícil de compartir. El conocimiento explícito, por el contrario, es aquel que está documentado o codificado y es transferible. 

Una de las formas más efectivas de protegerse de la rotación de personas dentro de la empresa es convertir el conocimiento tácito en conocimiento explícito, de forma que la persona que se acaba de incorporar al equipo alcance rápidamente la eficiencia deseada en su trabajo. 

icaria TDM facilita la compartición del conocimiento

¿Y qué puede hacer icaria TDM para evitar la pérdida de conocimiento que provoca la rotación de personas en los equipos de QA? Como hemos comentado la solución a la problemática que hemos ido exponiendo a lo largo del artículo no es otra que el paso, como hemos explicado antes, del conocimiento tácito al conocimiento explícito. 

Y hay diferentes funcionalidades que facilitan la transferencia del conocimiento y a continuación vamos a explicar dos de ellas: los arquetipos de datos y los dominios funcionales de datos, ya que ambos cumplen nuestros principios de diseño: registrar, conservar y compartir el conocimiento. 

1.  Arquetipos de datos (también conocidos como perfiles de datos)

Una de las fuentes inagotables de confusión y errores en QA es la falta de una definición compartida de los diferentes perfiles de datos que consumen los casos de prueba. A alto nivel, todo el mundo entiende qué es un "Cliente residencial potencial de la oferta X". Los problemas empiezan cuando hay que escribir queries para encontrar uno o crearlo manualmente para hacer pruebas.   

En icaria TDM puedes crear un catálogo de condiciones sobre tu arquitectura de datos de negocio, de forma sencilla, sin escribir queries. Después, puedes seleccionar el arquetipo que necesitas seleccionando las condiciones que lo definen. 

El arquetipo se encargará por sí mismo de encontrar ejemplos de ese arquetipo en las bases de datos que le indiques: producción y entornos no productivos. 

2. Dominios funcionales de datos 

Saber cómo se representa la información en los múltiples modelos de datos de una organización no es una tarea sencilla y, frecuentemente, es un conocimiento fragmentado, que impide explotar de forma eficiente los datos disponibles, ya sea para usarlos en pruebas de software o en otros procesos. 

Los árboles de segmentación de icaria TDM describen tan bien los dominios funcionales de datos y las relaciones entre ellos (aunque pertenezcan a distintas aplicaciones o distintas tecnologías) que icaria STUDIO se convierte en el punto centralizado de conocimiento del modelo de datos de negocio de la organización. 

Si quieres saber más sobre esto no dudes en ponerte en contacto con nosotros. En icaria Technology estaremos encantados de ayudarte.