El origen: PDCA

También conocido como ciclo de Deming por su autor Edward Deming, el PDCA ( por sus siglas en inglés para plan-do-check-act) es un ciclo de mejora continua que consta de cuatro pasos construido sobre la idea orignal de Walter Shewhart.

El ciclo de dinámica iterativa y continua es utilizado por las organizaciones con objetivos variados tales como: mejora de productos/servicios, optimización de costos, gestión de la calidad, innovación, creatividad (revisate mi post sobre design thinking) entre otros. Por lo general si analizas en profundidad los procesos estándar encontrarás varias similitudes que te indicaran que se han inspirados por el PDCA principalmente por esto es que lo considero como el origen.

El PDCA consta como te comentaba antes de cuatro etapas:

Plan (planificar): con la planificación se estudian las oportunidades de mejora y se organizan las acciones que se van a realizar para su implementación fijándose los objetivos de mejora.

Do (ejecutar): Se ejecuta el plan estrategico diseñado con la planificación; es en definitiva la intervención que hacemos para implementar la mejora.

Check (verificar/validar): Se trata del periodo de prueba una vez ejecutada la mejora, con el cual tomamos medidas para conocer como se comportan las intervenciones que hemos realizado durante la ejecución.

Act (corregir): Analizamos los datos obtenidos con las mediciones realizadas durante la fase de verificación buscando conocer si las intervenciones han dado los resultados esperados. Si los han dado entonces la intervención se plasma en el estándar y de lo contrario podremos actuar para corregirlo. Tras ello volvemos a la fase Plan para continuar con el proceso de forma cíclica hasta terminar es decir alcanzar los objetivos planteados.

Vinculado originalmente a la mejora continua de procesos, como te comentaba hay varias formas de implementar el proceso PDCA. Es un tema que esta muy procesado por lo que puedes encontrar diferentes y muy buenas fuentes para continuar profundizando el tema o en su defecto puedes hacerme llegar tus dudas y las contestaré. 

Sobre la construcción del software

Uno de los aspectos tal vez más importante al encarar un proyecto de software es definir como lo vamos a construir; aunque no lo parezca es un aspecto que esta muy influenciado por la naturaleza del proyecto y también por el tipo de organización que somos.

Considerando lo anterior, las opciones más elementales que tenemos para encarar el proyecto de software desde el punto de vista de la construcción (también conocidos como ciclos de vida) son las siguientes:

• Cascada: Hay distintas visiones en cuanto a las etapas que se cubren con este ciclo pero la característica que lo distingue es que ninguna etapa comienza hasta que no termine la anterior.
• Espiral: Es como una mezcla entre el ciclo en cascada y el desarrollo rápido de aplicaciones con la característica que lo distingue es el foco en la gestión del riesgo 
• Iterativo/Incremental: Este ciclo de vida propone ejecutar el proceso en varios ciclos repetitivos (con todas las etapas) como si fueran mini-cascadas que con cada nueva iteración la característica es que el producto ira creciendo en capacidad y alcance.
• Ágil: Se basan en las características de los procesos iterativos/incrementales para dar más agilidad al proceso, mas concentrados en las personas y el feedback temprano que en los procesos y la planificación.

Por supuesto que los anteriores no son las únicas opciones pero si las básicas, aquellas que reúnen las principales diferencias sobre las que se construyen el resto de las estrategias. Claro es que tu mismo puedes especificar tu propio proceso de desarrollo o ciclo de vida solo tienes que considerar que estos ciclos deben:

• Definir todas las etapas/actividades que se deben ejecutar
• Facilitar el seguimiento y la gestión de todo el ciclo
• Permite un marco de trabajo sobre el cual ejecutar el proceso

No hay una solución ideal para todos los proyectos, antes de empezar debes analizar el tipo de recursos que dispones, la cultura de la organización, el tipo de proyecto, características de los requisitos, limitaciones de tiempo, presupuesto y el tipo de alcance con todo ello sobre la mesa elegir el ciclo de vida que más se ajuste. De todas formas esto no te asegurará el éxito pero marcará el camino hacia él.

¿Que es eso del Valor Ganado?

El método del valor ganado, es una técnica de control de proyectos desde el punto de vista financiero y del rendimiento de los plazos aceptada por la comunidad de la ingeniería de software y en particular de la gestión de proyectos. El organismo que regula estas prácticas es el PMI (Project Management Institute).

Seguramente si no la has visto implementada alguna vez, al menos habrás leído sobre ello. La dificultad que tiene el método son la cantidad de fórmulas que lo componen y que muchos las aplican sin entenderlas completamente.

En mi experiencia una vez que entiendes los conceptos que están detrás la aplicación mejora, por lo tanto voy a explicarlo de una forma más coloquial:

Imagínate que tu proyecto es que pintar 4 paredes, tenes previsto pintar 1 por día, según tu previsión el valor monetario de cada pared es de $2. Con estas condiciones tu presupuesto para el proyecto es de $8 a "generar" en 4 días.

No olvides que esta técnica es una medida financiera de avance, por lo tanto es un valor monetario acumulativo que se relaciona con el tiempo utilizado. 

BAC o presupuesto al final del proyecto: es el valor monetario que esperas obtener al final del proyecto; es decir cuando hayas terminado de pintar habrás generado $8 de trabajo. Esto es independiente de lo que hayas gastado y el tiempo transcurrido porque esta pesado en términos de trabajo realizado. Sobre el rendimiento hablaremos en otro post. 

EV o Valor Ganado: Digamos que al pasar cada día si has cumplido tu objetivo habrás generado (o ganado) el valor monetario correspondiente al periodo transcurrido, que en el ejemplo equivale a $2 cada día. Entonces cuando hayas pintado 3 paredes y si todo salio como esperabas en 3 días habrás ganado $6. 

PV o Valor Planeado: Es aquello que tienes previsto, entonces si proyectas tu avance en términos de valor monetario estarás hablando del valor planificado (planeado) esto quiere decir por ejemplo que si aun no has comenzado pero tienes previsto avanzar según lo planificado al 3 día esperarás haber generado un valor equivalente a $6.

AC o Costo Actual: Debes entender que el valor monetario del trabajo que has realizado (alias valor ganado) esta medido en unidades de trabajo que no es lo mismo que el gasto; puede ser que hayas previsto gastar $1 por pared pero realmente haber gastado $2 por cada pared entonces si haz hecho 2 paredes en dos días habrás ganado $2 en trabajo por cumplir con los objetivos según lo planificado pero tu costo será de $4.

ETC o Estimado para completar el proyecto:  Este concepto esta vinculado con el ritmo de avance que lleves; como vimos antes no es lo mismo el valor ganado por el trabajo que lo que gastas para conseguirlo entonces si avanzas más rápido o te retrasas afectarás la inversión que debes hacer para terminar el trabajo. Es ideal que el ETC se mantenga igual al PV al final del proyecto. Digamos que si has pintado 1 pared y quedan 3 por pintar y todo ha ido bien tu ETC será de $6.

EAC o Estimado al final del proyecto: Es el costo con el que tienes previsto terminar el proyecto; es decir la cantidad de dinero que esperas haber gastado al terminar de pintar las 4 paredes luego de pasados los 4 días. Es ideal que el EAC se mantenga igual al BAC. Digamos que si has pintado 1 pared a un costo de $2 y quedan 3 por pintar también por $2 cada una tu EAC será de $6

Por ahora esto será todo, sin embargo es solo el inicio; esta técnica trae algunos indices que te servirán como métrica para evaluar tu rendimiento en términos de costos y uso del cronograma. A estos los trataremos en un nuevo post, por ahora intentemos automatizar los conceptos inherentes a la técnica.

Como diseñar mis procesos?

Al momento de diseñar nuestros procesos debemos tener claro que lo que estamos buscando es: hacer explicitas las tareas que se deben realizar, como se relacionan, cuales son las entradas, las salidas necesarias y si quienes son los interesados que deben participar en él.

Definitivamente no entramos en el mundo de los procesos solo por urgencia o necesidad, lo hacemos porque queremos obtener información de nuestra forma de trabajo y así poder analizarnos y mejorar para poder hacerlo cada vez mejor. La tendencia es hacia la eficiencia y la eficacia.

Seguramente lo tienes claro, pero conocer las actividades acota el trabajo y las responsabilidades por lo tanto facilitará la obtención de datos y posteriores medidas. Por lo tanto tendrás control. Recuerda que lo que no se puede medir, no se puede controlar.

Siguiendo con el razonamiento, si adicionas a lo dicho antes el conocer las entradas y salidas te asegurarás de producir únicamente aquello que agregue valor a tus operaciones. Y los roles estrictamente necesarios para llevarlo adelante.

Ok, los procesos son buenos lo entendimos, ahora ¿como diseño mis procesos a medida? La idea es apoyarte en alguna de estas dos técnicas:

ETVX por Entry Task Validation eXit

Esta técnica te dice que diseñes tu proceso enumerando las entradas, las tareas que realizarás, quienes deben validar los productos del trabajo y cuales serán las salidas.

SIPOC por Supplier - Input - Process - Output - Customer

Esta otra técnica te indica que diseñes tu proceso considerando tus proveedores, las entradas, las tareas que realizarás, sus salidas y quienes serán los clientes.

Cuando vayas a diseñar el proceso, o las tareas de cada actividad e incluso sus entradas o salidas, debes hacerlo pensado en que sea útil. Busca maximizar el valor agregado de cada elemento que introduces. Recuerda:

"Todo lo que diseñes debe rondar los  5 +/- 2 niveles"

Esta eurística te ayudará a tener un criterio acerca de que tan grande o pesado es tu proceso. Por otra parte intenta diseñar pensando en que cada salida que produzcas será una entrada para una próxima etapa del proceso, esto te ayudará a producir únicamente aquello que agregue valor.

Claramente no debes ir a por el proceso perfecto con la primera versión, porque todo es mejorable y aprenderás mucho de la experiencia y el uso del proceso definido. Lo interesante que ahora tendrás apoyo empírico que te va a dar un conocimiento que antes no tenias. Como puedes suponer al tener mediciones empíricas sobre como haces las cosas, puedes mejorar tu escala de control y tomar mejores decisiones que te mejoren tu funcionamiento.

Gestión del conocimiento

Como mencionan diferentes autores tales como A. Del Moral y compañía [1]. En su libro Gestión del conocimiento y con lo cual coincido absolutamente, desde la más remota antigüedad el progreso de la humanidad ha estado estrechamente relacionado al desarrollo de los conocimientos y su capacidad, no solo de generarlos, sino también de almacenarlos y distribuirlos, ya que estas dos últimas actividades son fundamentales para que los conocimientos del hombre se incrementen. 

Continuando con esta línea de pensamiento, seguramente desde épocas inmemoriales los conocimientos han sido gestionados de forma implícita a partir de que la gente comenzó a pensar más seriamente acerca de su trabajo. Al respecto, es de suponer que ya desde los primeros hombres sobre la Tierra sea notoria una preocupación al respecto de las habilidades y experiencia de sus compañeros. Como también, es de suponer, se preocuparían por averiguar las mejores y más exitosas prácticas a fin de mejorarlas y asegurar la viabilidad del grupo a largo plazo.

También desde épocas remotas los pueblos más sabios han asegurado la sucesión apoyada en la transferencia en profundidad de los conocimientos a la generación siguiente. Si nos centramos en aquellos conocimientos abstractos, es sabido que el hombre ha estado involucrado estrechamente con los procesos de transferencia de conocimientos y la creación y aplicación de los mismos desde hace miles de años.

Sin embargo, la gestión del conocimiento de forma sistemática, como la entendemos actualmente, no llegó a ser explicita hasta hace aproximadamente dos décadas e incluso al día de hoy es un concepto que no es comúnmente compartido entre los directivos, en las instituciones.

A partir de esta primera aproximación a la gestión del conocimiento durante el desarrollo de este documento habremos de presentar diferentes aspectos, los cuales están relacionados con la historia y crónicas de la gestión del conocimiento, la definición y las fases que contempla el proceso de la gestión del conocimiento.

Definiciones y fases

Al contemplar la diferente bibliografía que hay disponible sobre la GC lo primero que se observa es la gran cantidad de descripciones que hay para ello. En ningún caso, se ofrece de momento una definición formal de lo que en realidad implica la GC. En este artículo para expresar la definición de este concepto, tomaremos el análisis y la propia definición propuesta por A. Del Moral y compañía [1] en su libro Gestión del Conocimiento, que fuera también recogida por L. F. Paradela en su tesis doctoral [2].

La gestión del conocimiento consiste en poner a disposición del conjunto de miembros de una institución, de un modo ordenado, practico y eficaz, además de los conocimientos explícitos, la totalidad de conocimientos particulares de cada uno de los miembros de dicha organización que puedan ser útiles para el más inteligente y mejor funcionamiento de dicha institución y el máximo desarrollo y crecimiento de esta.

Podemos ver a la gestión de conocimiento como un proceso en función de: 

1) Integrar la información 

2) Extraer sentido de información incompleta

3) Renovar la información

Desde una perspectiva sistemática de la gestión del conocimiento, esta comprende 4 áreas de énfasis siguientes:

1) Monitorizar y facilitar las actividades relacionadas con los  conocimientos

2) Crear y mantener infraestructura de conocimiento

3) Renovar, organizar y transferir conocimientos.

4) Potenciar, usándolos, los activos de conocimientos para darse cuenta de su valor.

A partir de estas cuestiones A. del Moral [1]. Propone el entender por gestión del conocimiento al conjunto de principios, métodos, técnicas, herramientas, métricas y tecnologías que permiten obtener los conocimientos precisos, para quienes los necesitan, del modo adecuado, en el tiempo oportuno de la forma más eficiente y sencilla, con el fin de conseguir una actuación institucional lo más inteligente posible.

A continuación profundizaremos en las diferentes fases del proceso de la gestión del conocimiento a partir de un marco típico que es el de O’Donell (1997),  de acuerdo con lo expuesto por A. del Moral [1]. El marco propuesto propone un proceso cíclico compuesto por las siguientes fases:

1) Crear: esta fase es la responsable de la creación de los cocimientos que se van a gestionar, independientemente de los métodos utilizados.

2) Identificar: determina la existencia de conocimientos útiles para la institución en general y el problema en curso en especial, a partir de los conocimientos creados en la fase anterior

3) Adquirir: a partir de esta fase una vez identificadas las fuentes de los conocimientos así como los evaluados favorablemente, se trata de adquirirlos y recopilarlos de una forma útil para los propósitos de la GC. 

4) Organizar y preservar: una vez adquiridos los conocimientos, estos hay que organizarlos para después desarrollarlos y preservarlos para que no se pierdan.

5) Diseminar y compartir: aquí se proporcionan los mecanismos para diseminar y compartir todos los conocimientos entre todos los miembros de la institución e incluso entre los miembros de otras instituciones 

6) Adaptar: en esta fase se pretende que los conocimientos diseminados para compartirlos, estén en tal forma, que se adapten a las necesidades y forma de usarlos de los interesados en ellos, facilitándoles las cosas. Quienes vayan a utilizar los conocimientos casi siempre tendrán que personalizarlos para asegurar su adecuación, actualidad y exactitud.

7) Aplicar y usar: los conocimientos que no se utilizan o son inútiles, pueden provocar auténticas catástrofes, hasta el punto que es más conveniente no utilizar ninguno de los conocimientos disponibles antes de utilizar uno obsoleto, no hay que olvidar que los conocimientos conciernen a nivel pragmático, de uso de la información y la no utilización lo atrofia o lo estropea.

Referencias

[1] A. del Moral, J. Pazos, E Rodríguez, A. Rodríguez-Patón y S. Suarez, Gestión del Conocimiento. España: Parainfo S. A. 2007, cap. 1.

[2] L. F. Paradela, “Una Metodología para la Gestión del Conocimiento (Tesis).” Ph. D. Tesis, Escuela de ingeniería, Universidad Ort Uruguay, Montevideo, Uruguay. 2001 pp. 1–17.

DEUDA TÉCNICA .... ¿what?

Imagina que tienes una funcionalidad que necesitas agregar a uno de tus sistemas. Para ello hay inicialmente dos formas de hacerlo, una es rápida de implementar pero algo confusa (es decir, es seguro que esta opción te dará mucho trabajo mejorarlo en un futuro). La otra es hacerlo a partir de un diseño “limpio”, pero esta opción llevará más tiempo y esfuerzo de implementar.

Deuda técnica es una excelente metáfora ideada por Ward Cunningham para ayudarnos a pensar en este problema.

“Shipping first time code is like going into debt. A little debt speeds development so long as it is paid back promptly with a rewrite. Objects make the cost of this transaction tolerable. The danger occurs when the debt is not repaid. Every minute spent on not-quite-right code counts as interest on that debt. Entire engineering organizations can be brought to a stand-still under the debt load of an unconsolidated implementation, object- oriented or otherwise.”

En esta metáfora, hacerlo de la forma rápida y confusa nos generaría una deuda técnica, con una mecánica similar a la deuda financiera. Al igual que una deuda financiera, la deuda técnica involucra el pago de intereses, que se configuran en forma de esfuerzo extra que tendríamos que realizar en un futuro a causa de haber elegido la opción de un diseño rápido y confuso. Y un principal que representa por el costo de eliminar la deuda técnica de forma definitiva.

Por lo tanto, podríamos optar por continuar pagando intereses u optar por pagar el principal a través de la aplicación de técnicas que nos lleven de un diseño rápido y confuso a uno mejor. A pesar del costo que nos trae el pago del principal, ganaremos a futuro al reducir el pago de intereses. 

La idea no es eliminar toda la deuda técnica, sino concentrarse en aquellos casos donde el monto de interés que evitaríamos con la solución justifica el costo que tiene el pago del principal. De acuerdo con esto hay casos donde optar por un enfoque rápido y confuso puede ser razonable. Por ejemplo, al igual que una empresa incurre en deudas para tomar ventaja en una oportunidad de mercado los desarrolladores podrían considerar incurrir en una deuda técnica para alcanzar un hito importante para los objetivos del proyecto. 

La metáfora se vuelve interesante porque generalmente las organizaciones productoras de software dejan que sus deudas técnicas se salgan de control y esto hace que pasen la mayor parte del esfuerzo futuro del desarrollo pagando intereses paralizantes. El tema es también que a diferencia de la deuda financiera, la deuda técnica no cuenta con una moneda que nos permita medirla de forma efectiva. Los pagos de interés por ejemplo deberían medirse en términos de la productividad del equipo, pero como medir la productividad es un tema complejo y pese a nuestros esfuerzos tal vez no consigamos medirla con exactitud, no podremos evaluar el efecto real de nuestra deuda técnica.

En resumen esta metáfora si bien es un concepto que no es nuevo, ejemplifica un problema que continua siendo interesante para los investigadores actuales. Distintos autores han tomado esta metáfora y la han extendido a diferentes áreas de la ingeniería de software particularmente a la vertical de calidad imagino que se debe a que es el área más difícil de evaluar cuantitativamente 

Análisis Causal de Defectos

Propósito

El propósito del análisis causal de defectos (DCA) es identificar las causas raíz de los defectos (además de otros problemas) y tomar las acciones correctivas necesarias para prevenir que estos no vuelvan a ocurrir.

Contexto

El DCA no es una tarea sencilla para las organizaciones pero es fundamental puesto que su aplicación mejora la calidad y la productividad a partir de la prevención de la introducción de defectos en un producto.

Normalmente confiar en la detección de defectos luego de que ya han sido introducidos no es rentable. Se ha visto que es más efectivo prevenir la introducción de defectos a partir del desarrollo de actividades de análisis causal en cada etapa del proyecto. Puesto que la calidad del producto es inherente a la calidad del proceso que lo produce.

Las actividades de DCA también son un buen instrumento para la comunicación entre proyectos; puesto que soluciones a defectos del proyecto actual pueden haber sido encontradas en otros proyectos (de similares características) o incluso en etapas tempranas del propio proyecto.

El DCA no tiene por qué estar únicamente relacionado a defectos en el software; sino que puede ser utilizado en otro tipo de problemas no relacionados con los defectos tal vez relacionados con la efectividad en el uso de los costos (CPI) o en el uso del calendario (SPI). Lo único que hace falta es un proceso bien definido.

Seguramente haga falta establecer algún sistema de medición que nos permitan analizar el efecto de las causas; sino también la efectividad de las etapas del proceso en términos de indicadores que nos sean de interés.

Etapas del proceso

1. Determinar las causas de los defectos
1. Elegir la información para analizar
2. Analizar las causas
2. Erradicar las causas de los defectos
1. Implementar las acciones correctivas
2. Evaluar el efecto de los cambios
3. Colectar información

Determinar la causa de los defectos

La idea de esta etapa es asegurarse que sistemáticamente se analizan y se determinan las causas de los defectos (u otros problemas). Lo importante es identificar la causa Raíz, que es esa causa que si es erradicada los defectos relacionados disminuyen o bien desaparecen.

Elegir la información para analizar

En esta parte del proceso lo que debemos hacer es colectar toda la información de los defectos (o problemas) que nos sean de interés. Esta información puede prevenir desde diferentes fuentes como por ejemplo:

• Fuentes de defectos: reportes del cliente, reportes de usuarios, reportes de testing (mantis), reportes de revisión por pares.
• Fuentes de problemas: problemas de la gestión, problemas del proceso, indicadores de performance (CPI, SPI, EV), tiempos de respuesta, uso de los recursos

(Las listas no son completas, solo a modo de ejemplo)

Luego deberemos elegir cuales de todos los defectos (o problemas) vamos a tratar en detalle. Esto es fundamental para el proceso puesto que cualquier pequeño estimulo que hagamos por mejorar puede tener un gran impacto pero lo cierto es que abarcar mucho puede hacernos perder efectividad, entonces es mejor ir priorizando y atacando los defectos agrupados por: el impacto que tengan, la frecuencia de ocurrencia, índice de costos, índice de tiempos, entre otras similitudes.

Hay varias herramientas que se pueden usar para visualizar mejor esta agrupación y poder ponderar la selección, pero (según los estudios) la más utilizada es el análisis de Pareto (coloquialmente proporción 80/20).

Cuando se aplica a productos de software y en particular a defectos esta “regla” de proporciones se interpreta de la siguiente forma: “El 20% de los tipos de defectos son la causa del 80% de los defectos” con lo cual esta interpretación nos da una heurística para la ponderación de las causas de defectos (problemas) a analizar.

Ejemplo de gráfico para análisis de Pareto

Con lo que finalmente la salida de esta etapa del proceso es una lista ponderada, priorizada de defectos (o problemas) e incluso grupos de defectos (agrupadas por alguna dimensión de particular interés) que nos servirá de entrada para realizar el análisis de causa raíz.

Analizar las causas

El objetivo de esta etapa del proceso es realizar el análisis de causa raíz para los defectos/problemas seleccionados y proponer las acciones correctivas para erradicarlos.

El DCA es llevado a cabo normalmente en reuniones en con aquellos interesados que conocen o entienden mejor los defectos que hemos seleccionados para analizar. Estas reuniones se pueden realizar en cualquier momento; lo importante es que se realicen de forma sistemática.

Durante esta reunión lo que se hace es analizar detalladamente los defectos (problemas/tipos/grupos) que hayamos identificado en la etapa anterior del proceso para hallar la causa raíz.

Como para visualizar y profundizar el análisis de los defectos hay varias herramientas (puedo proveer un artículo que he publicado con una revisión sistemática sobre este tema si es necesario profundizar) pero las más utilizadas por las organizaciones son: el diagrama de Ishikawa (fishbone) y la técnica de los “5 ¿por qué?”.

El diagrama de Ishikawa (o de espina de pez) nos permitirá enfocarnos en un defecto a la vez y graficar de forma visual las posibles causas; mientras que la técnica de los “5 ¿por qué?” nos obligará a ir más profundamente sobre las causas acercándonos con mayor certeza a la posible causa raíz del defecto que estemos analizando.

Tras haber finalizado el análisis de cada uno de los defectos en cuestión, nos resta listar todas las causas identificadas (puesto que puede haber más de una causa en común), proponer y documentar acciones correctivas que nos ayuden a prevenir que vuelvan a ocurrir.

Ejemplo de diagrama de Ishikawa (fishbone)

Algunos ejemplos, las acciones correctivas pueden tener impacto en: el proceso, nuevos entrenamientos, cambios en herramientas, desarrollo de nuevas herramientas o métodos, mejoras en las comunicaciones o productos de trabajo.

Habitualmente de las acciones correctivas se documenta: Evento que la origina, descripción del problema, descripción del defecto, autor, etapa del proceso en la que se da el evento, etapa en la que fue identificado, descripción detallada de la acción propuesta (en pasos si fuera necesario).

Con lo cual el típico producto de trabajo de esta etapa es una lista de todas las acciones correctivas identificadas.

Erradicar las causas de los defectos

Básicamente el objetivo de esta etapa del proceso es realizar las acciones para institucionalizar las propuestas de mejora que faciliten que las causas de los defectos analizados sean erradicadas y así estos no vuelvan a ocurrir.

Implementar las acciones correctivas

Seguramente de la etapa previa hayan surgido varias y diferentes acciones correctivas y tal vez no todas (al menos a priori) puedan ser implementables o sea dudoso sí efectivamente su implementación agregará valor, por lo que primero habrá que analizarlas y priorizar su implementación.

Cuando se haya seleccionado una acción correctiva hay que generar los instrumentos para liderar su institucionalización, esto se hace a través de los action ítems (quién, cuándo, dónde y cómo) y así constituir una propuesta de mejora para la organización.

¡Ejecutar! Y finalmente identificar cuáles de las propuestas de mejora deben ser debidamente documentadas y en todo caso elevadas para ser incluidas en el conjunto de procesos estándar de la organización.

Por lo tanto los productos típicos de trabajo de esta fase son: la lista de acciones correctivas seleccionadas para su implementación y las correspondientes propuestas de mejora.

Evaluar el efecto de los cambios

Aquí la idea es poder medir, tomando medidas y calculando métricas el impacto de los cambios en el proceso/proyecto que ha sido modificado tras la puesta en práctica de las propuestas de mejora.

Esto necesitará de la definición de métricas (y las medidas adecuadas a estas) que nos permitan conocer si ha sido o no una mejora exitosa.

Hay alguna métricas comunes para defectos específicamente que se pueden utilizar; pero la mejor opción suele ser el utilizar un modelo de guía para la definición de métricas como Goal – Question – Metric (GQM) de V. Basili que es el mecanismo que más se ha industrializado y así definir las métricas especialmente necesarias de acuerdo a las necesidades de información.

Con las métricas y medidas definidas establecer una línea base de medición sobre la cual contrastar tras haber aplicado la mejora al proceso. Lo que necesitará también de la institucionalización de un proceso de medición.

Por lo que el producto típico de trabajo de esta actividad son las medidas de rendimiento previas y posteriores a la instrumentación de la mejora; además del análisis correspondiente.

Colectar información

La información recolectada, procesada y analizada durante el proceso de DCA debe ser administrada para que pueda ser compartida con el resto de la organización a los efectos de institucionalizar la mejora como conocimiento organizacional. Uno de los instrumentos que se puede utilizar como medio de comunicación de dicha información son las lecciones aprendidas.

Los registros, correspondan o no a las lecciones aprendidas, son los principales productos de trabajo de esta actividad.

Causalidad: Causas, Efectos y Relaciones

Para poder entender cómo se analizan las causas de los defectos a partir de un proceso de DCA hay que entender previamente algunos conceptos importantes y como estos se relacionan entre sí por lo que a continuación intentaré explicarlos:

El análisis causal se enfoca en comprender las relaciones causa-efecto (es decir un sistema causal). Un sistema causal es un conjunto de causas (eventos y condiciones) que interactúan, produciendo efectos (consecuencias) reconocibles. El análisis causal es la investigación sistemática de sistemas causales para identificar las acciones que los influencian, usualmente con el objetivo de minimizar consecuencias indeseables.

El DCA representa la aplicación de actividades de análisis causal a un tipo de problema en particular: defectos introducidos en activos de los procesos de una organización productora de software. El DCA busca comprender las relaciones entre los defectos introducidos durante el ciclo de vida del software y sus causas, de forma de minimizar futuras consecuencias indeseables.

De lo anterior se puede apreciar que el DCA opera a partir de tres conceptos elementales: Causa, Defecto y la Relación entre estos.

Defecto

No hay una única definición para esto, y muchas veces se habla indiferentemente de falta, defecto, error dependiendo del momento en que ha sido identificado. El PMI los define como una imperfección o deficiencia en un componente de un proyecto, que hace que dicho componente no cumpla con sus requisitos o especificaciones y deba ser reparado o reemplazado.

Causa

Desde la perspectiva de los sistemas causales, el término Causa responde a aquellos eventos y condiciones que contribuyen con la ocurrencia de un problema. Un problema es una situación particular que genera consecuencias indeseables.

Mientras que una Causa desde una perspectiva de la ingeniería de software, responde a una variable que cuando es invocada bajo determinada configuración siempre se va a manifestar el efecto que esta provoca.

Relación

Una relación es una conexión lógica o natural, que resulta de la interacción y/o dependencia entre un conjunto de eventos y condiciones. Y en particular se dice que una relación es causal cuando se conoce completamente el fenómeno de influencia, de forma que se puede afirmar que la variación del efecto se da siempre a través de los componentes que lo causan y sólo éstos.

Como determinar la causalidad

De todo esto hay bastante para detallar (puedo proveer un capítulo de mi tesis de maestría donde esta detallado con mayor profundidad), pero básicamente el problema es que no es un trabajo fácil comprobar de forma determinista que entre dos eventos existe una relación causal. Pero hay tres las condiciones esenciales para poder intuir la existencia de causalidad:

1. Debe existir al menos una relación de asociación o de correlación entre la causa y el efecto establecidos en la hipótesis.
2. La causa debe preceder temporalmente al efecto.
3. Debe ser posible identificar el mecanismo que vincula la supuesta causa-efecto.

Design Thinking

Según lo veo Design Thinking no es un concepto nuevo, nace en EE.UU. en la década de los 60. Actualmente hay varias versiones, nosotros tomaremos la versión de 4 pasos:

• (1) Definir el problema
• (2) Crear y considerar muchas opciones
• (3) Refinamiento de las opciones seleccionadas
• (4) Escoger al ganador y ejecutar

Con la definición (1) nos centramos en especificar y caracterizar el problema. Con la creación (2) generamos múltiples ideas que den una solución al problema definido.  Durante el refinamiento (3) lo que buscamos es consolidar las diferentes visiones de las ideas generadas en algo que unifique las visiones y verificarlo con “personas reales”.  Con la última etapa hacemos un prototipo para la idea aprobada (4).

Lo interesante es que por lo general se implementa con equipos multidisciplinarios, lo cual nos da distintos puntos de vista que favorecen la innovación. Por supuesto que como cualquier metodología tiene su ritmo, es recomendable trabajar en iteraciones cortas de no más de 5 días, y no temer a volver sobre los pasos anteriores durante cada iteración.

Tiene la ventaja de que se generan muchas ideas, tal vez no todas apliquen al problema específico que estamos intentando resolver pero sin embargo todas las ideas tienen valor, y se recomienda que sean administradas. Podemos considerarlas como productos colaterales.

En resumen es una metodología con foco en el producto y la innovación desde la perspectiva del diseño. Nos brinda un marco para generar ideas creativas de forma estructurada e independiente de los individuos que participen del proceso.