miércoles, 27 de diciembre de 2017

Un modelo conceptual básico para apoyar la implantación de métodos ágiles

Antes de presentar nuestro modelo conceptual comentaré lo que en mayor medida me ha motivado a escribir este post: el uso indiscriminado del término "Proyecto" :-).

En el PMBOK un proyecto se define como: “A project is a temporary endeavor undertaken to create a unique product, service, or result. The temporary nature of projects indicates that a project has a definite beginning and end. ...". Sin embargo, en la mayoría de empresas (y herramientas) se usa el término "Proyecto" casi como sinónimo de "Trabajo", incluso sin existir un inicio y fin predeterminados, o cuando el resultado no es algo claramente nuevo (como es el caso de trabajos de mejora y mantenimiento en general). Más allá de cuestiones de terminología, lo realmente importante es que muchas veces esta denominación marca la estrategia con la que se aborda el trabajo. Por ejemplo, y siendo exagerado, poco sentido tiene el imponer una planificación con Sprints rígidos, entregas pre-establecidas, cálculos de esfuerzo y de capacidad requerida, etc., solo porque el trabajo que se realizará se denomina "Proyecto de mantenimiento de 2018", y siendo que se trata solo de un acuerdo de mantenimiento para un producto software que acabamos de entregar a un cliente. Obviamente dicha estrategia es errónea básicamente porque al alcance a priori es desconocido, no se sabe qué mejoras o correcciones se solicitarán durante el período de realización del trabajo.

Este uso indiscriminado del término Proyecto probablemente está detrás de la confusión que delatan afirmaciones tales como; "para algunos proyectos usamos Kanban y para otros Scrum", "usábamos Scrum pero hemos decidido pasarnos a Kanban". Probablemente la cuestión de fondo es que en ciertos contextos no es conveniente usar Sprints (una de las prácticas de Scrum), o al menos no usarlos con una interpretación rígida (ignorando que los Sprint podrían ser "flexibles" en contenido y/o en duración). Lo lamentable son las decisiones tomadas a nivel de método, es decir, cuando se usa uno u otro de forma exclusiva. La mejor opción es usar las prácticas sugeridas por los métodos, no necesariamente todas, combinándolas, adaptando su intensidad, teniendo cuidado de no hacer interpretaciones radicales. Para no extenderme en esto recomiendo echar un vistazo a los siguientes posts:
Obviamente, no se trata de prescindir del concepto y término "Proyecto", sino de usarlo como un elemento más de la estrategia establecida para abordar un determinado contexto de trabajo. Es decir, asociarlo a trabajos que tienen comprometidas fechas de inicio y fin, donde el alcance está previsto (aunque luego pueda haber ciertos cambios), ya que en esta situación es útil incluir mecanismos de planificación y seguimientos acordes con la rigidez de dicho compromiso.

Cuando me refiero a "trabajo" puede tratarse de un esfuerzo no solo asociado a un producto, podría ser de un servicio prestado. En el resto de este post usaré el término "producto" pero lo comentado también sería aplicable a "servicio".

Una de las características del enfoque ágil es destacar el valor del resultado del trabajo y cómo es percibido por el cliente/usuario. Esto ha cambiado el foco hacia el producto, el éxito ya no es solo una cuestión de cumplir con alcance-plazos-costos (Proyecto). Un producto exitoso se continuará desarrollando y mejorando siempre y cuando se vea reforzado por el valor que aporta a sus cliente/usuarios.

Así pues, un producto podría tener asociados varios proyectos a lo largo de su existencia. Por ejemplo: el proyecto que desarrolla el producto, un proyecto que mejora sustancialmente el producto original, un proyecto de integración con otros productos, etc. Sin embargo, en paralelo a dichos posibles proyectos, un producto podría requerir cierto trabajo de soporte y mantenimiento más continuo (que también hay que gestionar), no enmarcado en esos proyectos.

Además, el contexto de un producto puede cambiar a lo largo de su existencia. Un producto software antes de su primera entrega genera trabajo relativo a su desarrollo, lanzamiento y puesta en marcha, pero a partir de su primera entrega requiera además de mantenimiento y soporte para los usuarios.

Un modelo conceptual para organizar y abordar el trabajo con un enfoque ágil


He tenido la oportunidad de conocer el contexto de trabajo de muchas empresas. Gracias a esta experiencia y con el afán de establecer unas pautas de implantación y metodológicas asociadas a métodos ágiles hemos ido refinando un modelo conceptual, asociado a nuestro enfoque metodológico TUNE-UP Process.


La Unidad de Trabajo (UT) representa a un ítem de trabajo a un cierto nivel de granularidad (también podría llamarse Historia de Usuario o simplemente Ítem). Por ejemplo, en desarrollo de software una UT podría ser un nuevo requisito, una mejora de un requisito ya implementado o una corrección de fallo.

Cada UT desde su creación hasta su término sigue un flujo de trabajo (workflow), que corresponde a una secuencia de Actividades (pudiendo existir actividades realizadas de forma alternativa o en paralelo). Los workflows determinan los Tableros kanban que se utilizarán, en los cuales las actividades del workflow corresponden de izquierda a derecha con las actividades del Tablero kanban. En principio cada Tablero kanban mostrará las UT que siguen ese flujo de trabajo, pero podrían mezclarse (integrarse) varios flujos de trabajo en un mismo Tablero kanban, especialmente si comparten actividades. Para el diseño de workflows y tableros kanban recomiendo leer: "Workflows flexibles. Parte I y Parte II" y "Tableros kanban. Parte I y Parte II".

Una Línea de Trabajo es el contenedor más global de UT. Podríamos NO reconocer Líneas de Trabajo (es decir, tener solo un contenedor para todo el trabajo) pero hay varios factores que hacen conveniente establecer diferentes Líneas de Trabajo, entre ellos:
  • Planificación y seguimiento del trabajo. Trabajos que normalmente tienen distintos calendarios de compromisos o acuerdos de ritmos de entrega.
  • Equipos de trabajo. Trabajos asignados diferentes equipos de trabajo.
  • Distribución de capacidad de los equipos. Trabajos que en un período de tiempo compiten por asignación de capacidad.
Así pues, una Línea de Trabajo normalmente tiende a estar asociada a un producto o servicio y a un equipo de trabajo (pudiendo un equipo ser responsable de varias Líneas de Trabajo). Además, si la naturaleza del trabajo asociado a una Línea de Trabajo es diversa, la Línea de Trabajo puede tener asociados varios Workflows, para que a cada UT se le aplique un workflow con las actividades que le sean más adecuadas.

Toda Línea de Trabajo tiene un Backlog. El Backlog es el contenedor de las UT que NO se están contenidas en un Sprint, es decir, las UT están en el Backlog o están en algún Sprint. Cuando se decide NO trabajar con Sprints, conceptualmente todas las UT están en el Backlog, allí se priorizarían e irían terminándose. Cuando se trabaja con Sprints, en el Backlog a las UT se les aplica un trabajo de "preparación", y al pasar a un Sprint se les aplica el trabajo asociado a su "ejecución". Por ejemplo, actividades típicas de "preparación" en el Backlog son: Priorizar, Definir/Analizar/Especificar, Validar, Estimar, etc. Actividades típicas de "ejecución" en un Sprint son: Programar/Implementar, Probar, Integrar, Desplegar, etc.  Así pues, el Backlog y los Sprint en el tablero kanban se corresponden con grupos de columnas; las del Backlog en la parte izquierda del tablero y las de Sprint en la parte derecha. Si se decide NO trabajar con Sprints en una Línea de Trabajo todas las actividades, tanto de preparación como de ejecución se realizan en el Backlog.

Cuando se adquiere un compromiso de entrega (fechas de inicio y fin) es recomendable enmarcar todas las UT del compromiso (el alcance) en un Proyecto asociado a la Línea de Trabajo. Este compromiso requiere tener en alguna medida establecido un alcance y costos, es decir, estamos en una situación de trabajo "planificable". Usualmente el desarrollo de la primera entrega de un producto es por definición un Proyecto. Sin embargo, a partir de dicha entrega, si no vuelven a existir compromisos alcance-plazos-costos, podría continuarse el trabajo asociado al producto sin tener asociado un Proyecto.

A continuación se responden varias cuestiones claves respecto de la combinación de los elementos del modelo conceptual propuesto. Es importante destacar que estas cuestiones deben evaluarse para cada Línea de Trabajo; uno de los errores más frecuentes es ignorar la diversidad del trabajo e imponer la misma estrategia para todo el trabajo y/o no reconocer diferentes Líneas de Trabajo, cada una con sus necesidades.

¿Tiene sentido usar un Tablero kanban si también se usan Sprints?

Se usen o no Sprints, siempre es recomendable utilizar un tablero kanban para visualizar el estado de preparación y ejecución de las UT

¿Cuándo conviene usar Sprints en una Línea de Trabajo?

Los Sprints son importantes para ayudar a gestionar el desarrollo incremental a corto plazo. Sin embargo, en situaciones NO planificables (cuando el alcance no se conoce totalmente de antemano o suele variar significativamente) no es sensato imponer una disciplina de Sprint rígidos en contenido y/o duración, dado que cualquier previsión probablemente se verá muy afectada por cambios durante  el Sprint. En el caso extremo, cuando gran parte del esfuerzo de planificar Sprints se pierde por los continuos cambios, podría prescindirse de usar Sprints y trabajar solo con un Backlog priorizado.

¿Tiene sentido usar Proyecto y Sprints en una Línea de Trabajo? 

Tanto Proyecto como Sprint son contenedores temporales de trabajo, y lo natural es que el alcance de dicho trabajo esté previsto antes de comenzar a trabajar en ello. Por otra parte, se recomienda que los Sprints NO tengan una duración de más de 4 semanas pues su objetivo es darnos una retroalimentación a corto plazo del avance del trabajo. Sin embargo, un Proyecto no tiene dicha  restricción de duración. Así pues, sí que puede ser útil usar Proyecto y Sprints, por ejemplo, para un Proyecto de 6 meses se podrían establecer 8 Sprints de 3 semanas cada uno. Las UT del Proyecto estarán priorizadas en el Backlog y se irán incluyendo en los sucesivos Sprints hasta finalizar el Proyecto. Al finalizar el Proyecto podrían quedar algunas UT en el Backlog (ya quitadas del alcance del Proyecto), podría tratarse de algunas UT originales, o de nuevas UT que se hayan generado durante el Proyecto. Esta es una de las razones del por qué es importante separar el concepto de Proyecto del concepto de Línea de Trabajo; aunque el Proyecto finalice, el producto seguirá existiendo y tendrá trabajo asociado que habrá que abordar posteriormente (en el marco, o no, de otros Proyectos).

No tiene sentido usar Sprints si la duración del Sprint es igual a la del Proyecto. Por ejemplo, si el proyecto es de 2 semanas y se establece que se hará solo un Sprint de dos semanas, en este caso el Sprint no aportaría nada respecto de la planificación y seguimiento del trabajo. Puede que tampoco tenga mucho sentido tener Sprints muy pequeños, cuando el Proyecto sea de muy corta duración. Por ejemplo, un Proyecto de 3 semanas dividido en 3 Sprints de una semana. Hay que evaluar los "costos de transacción", es decir, el esfuerzo asociado a arrancar un Sprint y a terminarlo (siguiendo todos los protocolos asociados).

¿Cómo empezar a organizar el trabajo de forma ágil?

Recorriendo los elementos del modelo conceptual propuesto debería hacerse las siguientes actividadess (no necesariamente en el orden presentado):

  • Identificar las Líneas de Trabajo. Para comenzar se podría considerar que cada producto o servicio es una Línea de Trabajo, cada una de ellas con el nombre de dicho producto o servicio, por ejemplo, si tenemos el producto ACME, establecemos la Línea de Trabajo ACME. Si se diera el caso (ahora o más adelante) que el producto ACME tuviese trabajo de desarrollo, mantenimiento y soporte, podría ser conveniente tener más de una Línea de Trabajo asociada al mismo producto, en este ejemplo, las Líneas de Trabajo: ACME Desarrollo, ACME Mantenimiento, y ACME Soporte. La división o agrupación de Líneas de Trabajo puede variar de acuerdo con las necesidades, lo importante es que en un momento dado las Líneas de Trabajo sean cómodas y efectivas para la gestión del trabajo asociado.
  • Asignar los colaboradores (el equipos) responsables de cada Línea de Trabajo.
  • Definir los Tableros kanban que necesita cada Línea de Trabajo según la actividades que se deben realizar sobre sus UT. Los Tableros kanban podrían reutilizarse entre diferentes Líneas de Trabajo. Además, una Línea de Trabajo puede utilizar varios Tableros kanban, según lo requieran sus UT.
  • Para cada Línea de Trabajo decidir si se trabajará con Sprints y cuáles serán sus características. Esto lo comento en detalle en el post  Sprints, "welcome to the real world"
  • Establecer Proyectos cuando sea necesario. Normalmente un Proyecto se asocia a una Línea de Trabajo, pero podría darse el caso que en un mismo Proyecto se vean involucradas varias Líneas de Trabajo.

El modelo conceptual propuesto sirve de infraestructura para organizar el trabajo de forma ágil. Sin embargo, hay que destacar que un enfoque ágil no consiste solo en utilizar conceptos ágiles. El mayor desafío es aplicar prácticas ágiles (hábitos de trabajo), y para esto es fundamental establecer un roadmap para ir incorporando dichos hábitos ágiles en el trabajo diario del equipo. Ver nuestra colección de prácticás ágiles en Agile Roadmap.

Para finalizar, y volviendo a la motivación original de este post; el abuso del término Proyecto, en mi opinión este abuso se ve fomentado además por herramientas (como en JIRA o Target Process) con deficiencias conceptuales importantes. Si a todo se le llama Proyecto, cuando un proyecto termina ¿te ves obligado a crear otro proyecto con el trabajo restante o nuevo que surge y que está asociado al mismo producto? ¿le cambias nombre y fechas al proyecto terminado?. Cuando se solapa para un mismo producto el desarrollo de nuevas funcionalidades con el mantenimiento continuo (de respuesta rápida y con urgencias) ¿se enmarca todo este trabajo en un mismo proyecto?. En esta temática, te recomiendo leer: Gestión ágil de productos. Líneas de trabajo en un producto a partir de su primera entrega.



Patricio Letelier

www.tuneupprocess.com 

miércoles, 13 de diciembre de 2017

Retrabajo, Refactoring y Fallos ... ¿cuál es su relación?

Retrabajo es el esfuerzo adicional necesario para corregir defectos en un producto. El Retrabajo tiene connotación negativa pues si se evitasen los defectos no se tendría que hacer dicho esfuerzo adicional, pero como veremos no todo el Retrabajo debería considerarse negativo.

Antes de seguir quiero indicar la terminología que usaré en cuanto a defectos, fallos y errores. En el post "Fallos - Defectos - Errores y su gestión en un contexto ágil" se ofrecen unas definiciones al respecto, que resumen en lo siguiente: los errores son cometidos por las personas participantes en el desarrollo de un producto, estos errores generan defectos que quedan incluidos en el producto (especificaciones o código), estos defectos en algún momento se manifestarán, cuando se detecte el fallo provocado por el defecto, y finalmente, la corrección del fallo es la eliminación del defecto. Los defectos pueden generarse en cualquier actividad (por ejemplo, al especificar requisitos, diseñar, programar, probar, etc.). Es muy difícil conseguir productos con cero defectos, pero es posible evitar en gran medida los defectos si se dispone de los mecanismos preventivos adecuados.

El Retrabajo conlleva la repetición parcial o total de algún trabajo que se suponía estaba finalizado. Pero hay que destacar que las mejoras en requisitos ya implementados y/o el desarrollo incremental NO deberían considerarse Retrabajo. Aunque se trata de trabajo asociado a resultados ya obtenidos de un trabajo previo y finalizado, se están añadiendo aspectos no existentes en los requisitos ya implementados. Lectura recomendada: "Flecos" de implementación y gestión ágil de proyectos.

El Refactoring sí que es una forma de Retrabajo, pero ojo!, también es considerada una buena práctica en el enfoque ágil. Hay que aclarar que el Refactoring "bueno", el planteado por Extreme Programming (XP), implica intentar mejorar de la organización del código continuamente. Cada vez que se va a cambiar alguna pieza de código existe la oportunidad para mejorarlo. Sin embargo, muchos equipos interpretan el Refactoring como concentrarse puntualmente en hacer mejoras de arquitectura del código puntualmente, especialmente cuando una parte del código está teniendo serios problemas de mantenimiento. Para este Refactoring "bueno" no deberían crearse ítems específicos, sino que este trabajo debería abordarse como parte del trabajo de programación de cualquier cambio en el producto. En un enfoque ágil el Refactoring es muy importante ya que este enfoque apuesta radicalmente por el desarrollo incremental, es decir, una misma pieza de código tiene alta probabilidad de ser cambiada una y otra vez durante el desarrollo del producto. El Refactoring continuo contribuye a evitar que la arquitectura del código se degrade con los cambios. Así pues, este Refactoring "bueno" y su Retrabajo asociado deberían ser asumibles en un enfoque ágil, pues favorecen la estrategia global de desarrollo de este enfoque.

Por otra parte, hay trabajos que tienden a considerarse como Refactoring, tales como una mejora del rendimiento de la aplicación o una remodelación de la interfaz de usuario. La definición estándar de Rafactoring es "cambiar el código sin que esto conlleve cambios en los requisitos ya implementados", es decir, es un trabajo cuyo resultado no es visible para el usuario. Según esto, los dos ejemplos anteriores (mejora de rendimiento y remodelación de la interfaz) son cambios constatables por el usuario, con lo cual no deberían considerarse Refactoring.

Volviendo al tema del Retrabajo, ¿cuál es el Retrabajo verdaderamente negativo y qué supervisión deberíamos hacer sobre él?. Existen dos situaciones de Retrabajo que deberían ser vigiladas:
  1. Fallos detectados en el uso del producto (en una versión ya publicada). Se deben crear ítems para corregir estos fallos, y estos ítems competirán con los otros ítems del Backlog hasta que alcancen la prioridad para ser implementados (un fallo podría no ser severo y tener menos prioridad que otros ítems). Además de la imagen negativa para los usuarios en cuanto a calidad del producto y sus consecuencias, el esfuerzo dedicado a estos ítems de corrección de fallo restará capacidad al equipo para desarrollar mejoras o nuevos requisitos.
  2. Fallos detectados durante el proceso de desarrollo de una entrega. Cada vez que en el flujo de trabajo se debe volver a realizar a una actividad supuestamente finalizada se incurre en Retrabajo. Por ejemplo, cuando el programador demanda una corrección dirigida a la actividad (previa) de "Especificar Requisitos" porque algún ítem tiene defectos en su especificación, o cuando el tester al probar un cambio en el producto detecta algún fallo en la implementación de dicho cambio y solicita a programador que vuelva a programar para corregirlo. Sin embargo, no debería considerarse Retrabajo que el mismo programador detecte algún fallo en su trabajo mientras lo está realizando ya que esa detección ocurre en el ámbito de su actividad no finalizada (además, sería difícil  distinguir en una misma actividad cual parte del esfuerzo se refiere a defectos detectados y corregidos dentro de la misma actividad). Así pues, una forma sencilla de identificar Retrabajo dentro del proceso de desarrollo es observando cuándo en un ítem se vuelve a repetir una actividad ya finalizada. Por ejemplo, si un ítem está en la actividad "Pruebas de Aceptación" y debido a fallos detectados vuelve abrirse la actividad "Programar". De esta forma, podemos decir que el esfuerzo invertido en la actividad "Programar", después de la primera vez que se dio por finalizada, es tiempo de Retrabajo en dicha actividad. Pero nuevamente, hay tener en cuenta una situación en la que este Retrabajo no tendría un sentido negativo, es más, podría ser algo positivo. Supongamos que se está implementando un ítem ítem grande, complejo y/o con mucha incertidumbre asociada a su "qué y cómo", y que se descartaron las alternativas asociadas a particionarlo (convertirlo en ítems más pequeños) o desarrollarlo incrementalmente (desarrollar primero una pequeña parte y mantener el resto del ítem pendiente en el Backlog), es decir, el ítem se va a implementar como un todo, y se decide iterar Análisis-Diseño-Implementación-Pruebas para ir intencionalmente desarrollándolo en refinamientos sucesivos y asumiendo posibles "pasos en falso". En este caso es probable que se realicen dichas actividades con bastante paralelismo y/o vuelta atrás, con lo cual no deberíamos penalizar esta estrategia, puntual para un ítem, por el Retrabajo natural que se registrará. 
Según lo anterior, ¿qué métricas deberíamos manejar para poder evaluar el rendimiento de nuestro proceso de desarrollo respecto del Retrabajo?. El esfuerzo invertido en la corrección de defectos sería la métricas esencial, y en segunda instancia, el número de correcciones de defectos (teniendo en cuenta que la diversidad de los defectos y de su corrección hacen que sean muy dispares en esfuerzo uno de otros).

A continuación ilustraré cómo en nuestra metodología y herramienta TUNE-UP Process ofrecemos  información para la supervisión del Retrabajo. Comenzaremos con lo relativo a fallos detectados en el uso del producto.

Capacidad invertida por tipo de ítem (Nuevos requisitos, Mejoras en requisitos ya implementados y Correcciones de fallos). Esta información se muestra por cada Sprint.


En la gráfica anterior cada barra representa el esfuerzo invertido en un Sprint. Los colores corresponden a la proporción del esfuerzo del Sprint invertido en cada tipos de ítem (verde: Nuevos requisitos, amarillo; Mejoras y rojo: correcciones de fallos). 

Número de ítems por tipo en cada Sprint. En esta gráfica se representa también como una barra cada Sprint, pero los colores ahora corresponden a la proporción del número de ítems de cada tipo respecto del total de ítems en el Sprint (usando el mismo código de colores de la gráfica anterior).


Para apoyar la interpretación de estas gráficas también es conveniente conocer la duración de cada Sprint (si el equipo y su disponibilidad se mantiene, a mayor duración del Sprint, mayor capacidad de trabajo). La siguiente gráfica muestra la duración de los Sprints asociados a las anteriores gráficas. Como se observa, en este caso los Sprints son "flexibles" en cuando a duración (en general, lo recomendable es mantener cierta regularidad en la duración de los Sprints, pero puede que en un contexto determinado sea más conveniente usar Sprints flexibles. Ver "Sprints, "welcome to the real world" ...").


Algunos otros datos que podrían ser interesantes para un estudio más profundo, especialmente desde una perspectiva de calidad son:
  • Distinguir los fallos según su severidad. 
  • Conocer las áreas del producto en las cuáles se están generando más fallos y retrabajo.
  • Poder identificar el ítem previo o el Sprint donde se introduce cada defecto.
  • Conocer el tiempo transcurrido desde que se detecta un fallo hasta que se publica una versión donde ese fallo está corregido.
Ahora veremos cómo podemos supervisar el Retrabajo asociado a fallos detectados dentro del proceso de desarrollo.

Retrabajo registrado en cada ítem de trabajo. En la siguiente gráfica se muestra el tiempo invertido en la actividad "Programar" para cada uno de los ítems de un Sprint. Además, para cada ítem se destaca en color rojo la proporción de esfuerzo que corresponde a Retrabajo.


¿Cuánto debería ser la proporción admisible de Retrabajo en un ítem?. Dependerá del contexto y también como indiqué antes hay que tener cuidado al evaluar el Retrabajo, pues puede ser intencional, es decir, cuando la estrategia que elegimos para abordar un ítem genera de forma natural cierto Retrabajo. Sin embargo, lo importante de la gráfica anterior y de su interpretación es poder identificar comparativamente que ítems han generado más Retrabajo y estudiarlos para concluir si es justificable o si deben/pueden tomarse medidas preventivas para reducirlo.

Seguimiento de un ítem con indicación de vueltas atrás. Si accedemos a cualquiera de los ítems con Retrabajo podremos ver en su seguimiento (la historia del ítem) información adicional asociada a dicho Retrabajo. Por ejemplo, en la siguiente imagen podemos ver que hay dos vueltas atrás (marcadas con la flecha roja), es decir, se repitieron dichas dos actividades y los tiempos invertidos de esas repeticiones has sido contabilizados como tiempo de Retrabajo.


Finalmente, es muy importante tener presente que la interpretación de esta información y las posibles acciones que se puedan derivar deben tomarse con prudencia. No es recomendable correlacionar  penalizaciones/premios para el equipo basándose directamente en estadísticas de Retrabajo o Fallos. Como he señalado existen bastantes situaciones particulares en las cuales el Retrabajo no debería considerarse negativo. Además, los fallos exigen mayor discriminación en cuanto a severidad, tiempo que se requiere para corregirlos, etc. Acciones mal orientadas podrían perjudicar el espíritu de equipo cuando conllevan la culpabilización de las personas involucradas. Por contraparte, y como sabemos, las estadísticas se pueden manipular :-), sería fácil mejorar los datos, por ejemplo, no registrando esfuerzo en las actividades que se están supervisando, registrando esfuerzo de forma que no figure como Retrabajo, clasificando incorrectamente los fallos, o no poniendo la severidad que les corresponde.



Patricio Letelier

www.tuneupprocess.com