Los Magos de la Calidad con la Paradoja del Analista de Calidad: ¿Más Errores, Más Alegrías?"

Al dialogar con especialistas en calidad de software, como Analistas de Calidad, Analistas de Testing y Testers, se destaca su enfoque en la definición de casos de prueba, la ejecución de estos casos y la detección de errores en los productos.

Hace algún tiempo, planteé una pregunta a un grupo de 11 Analistas de Calidad: "¿Te sientes más satisfecho en tu trabajo al encontrar numerosos errores en las pruebas o cuando no los encuentras?"

Sin excepción, todos respondieron: "Cuando encuentro muchos errores". Este punto de vista refleja su objetivo de descubrir la mayor cantidad posible de fallos en los productos evaluados.

Sin embargo, este enfoque genera sentimientos opuestos en otros participantes del proyecto, como programadores, analistas funcionales, analistas técnicos, jefes de proyecto, gerentes de área y usuarios. Para ellos, la detección masiva de errores conlleva decepción, frustración y molestia, además del esfuerzo adicional por rehacer el trabajo, retrasos en la entrega, entre otros inconvenientes.

Es evidente que los Analistas de Calidad tienen una perspectiva diferente respecto al propósito del proyecto.

Si consideramos el objetivo del proyecto como la elaboración de un producto de calidad, el propósito del Analista de Calidad debería ser "no encontrar errores" o "asegurar la ausencia de errores en el producto", lo que les generaría satisfacción al cumplir su función.

No obstante, el problema radica en el momento en que se evalúa la calidad del producto: generalmente al final del proceso de fabricación. Muchos de los errores o defectos se originan a lo largo del proceso, desde el inicio con insumos deficientes, una ejecución deficiente de las actividades o especialistas con poco conocimiento y experiencia, lo cual impacta en la calidad del producto final.

Por ende, el enfoque del Analista de Calidad no debería limitarse a recibir un producto casi terminado para ejecutar pruebas y encontrar errores, sino centrarse en garantizar el cumplimiento de actividades y entregables con la calidad esperada. De esta manera, se previenen errores que podrían arrastrarse hasta el producto final.

Existen métodos adicionales para asegurar la calidad del producto a lo largo del proceso:

Identificar patrones de origen de errores en los entregables de cada fase del proceso y ajustar el proceso o asegurar su correcta ejecución.

Detectar patrones de comportamiento entre los colaboradores del proceso de fabricación para alinear y capacitar a fin de mejorar el cumplimiento de sus actividades.

Estas estrategias no solo mejoran la calidad en la fabricación del producto, sino que también elevan la calidad de los especialistas involucrados en el proyecto.

Los Magos de la Calidad ... algunos casos ...

En diferentes ocasiones nos cuesta revisar los entregables y los procesos que nuestros equipos de trabajo elaboran y ejecutan, pensamos que es engorroso y una pérdida de tiempo, siempre preferimos construir, desarrollar, crear cosas nuevas, en lugar de estar revisando y corrigiendo el trabajo de otras personas.

Alguna vez alguien me pregunto:  [[Para qué tanto control y metodología ...]], yo le respondí, "aun tenemos mucho por mejorar, porque aun perdemos mucho tiempo en retrabajos por los errores que detectamos en el producto.   Y porque esos retrabajos se realizaban a puertas de la entrega del producto, cuando ya no te quedaba mucho tiempo".

Si bien tenemos que corregir el producto antes de entregarlo, lo mejor es evitar generar estos errores en el momento que se elabora el producto.   Y se evita, ejecutando correctamente los procesos durante la elaboración.

Incluso el costo de la corrección del error es menor, en la medida que se detecte lo mas temprano posible.

Esta revisión que parece engorroso a lo largo del proceso de elaboración del producto, porque tenemos la idea de revisar todo el entregable o todo el documento para ver si no tiene ningún error.   No se trata de encontrar todos los errores, se trata de enfocarnos en la forma de trabajo del colaborador.    Es decir, asegurarnos que entienda el propósito de las actividades del proceso, de las políticas, de los artefactos, del producto final.   Si los comprende y los cumple, no debería existir problemas con los entregables y los productos.

Con este enfoque, donde nos aseguramos que se comprenda y se cumpla los procesos y entregables con calidad, la estrategia es revisar puntualmente una actividad o parte de una actividad, un entregable del proceso o parte de un entregable, con una frecuencia razonable y cubriendo la mayor cantidad de colaboradores del equipo, tipos de actividad o tipos de entregables.

En un ejemplo de desarrollo de software, sabemos que en la etapa de Análisis, necesitamos elaborar el Documento de Análisis, para ello, la revisión pueden realizarse de la siguiente manera:

Teniendo una política : "Todo avance de documento debe colocarse en el repositorio del proyecto", por lo que la revisión no implica reunirse con el Analista para revisar el documento, sino únicamente revisar el repositorio para buscar el documento de Análisis.  En caso no se encuentre se anotará una observación.   Por lo que esta actividad toma menos de un minuto.

En el caso de encontrarse el documento en el repositorio, el siguiente paso puede ser la revisión del cumplimiento del formato (en una primera instancia), sin necesidad de revisar (aun) la coherencia del contenido, si observamos que no cumple con el formato, o no completa el formato adecuadamente, también se anotará una observación.   Esto tomará menos de 5 minutos por documento.

En otro momento, se revisará la coherencia del contenido de un documento análisis, donde posiblemente, no se comprenda a cabalidad lo descrito.   O simplemente no sigue el formato previamente establecido que describe el flujo de una funcionalidad.   Ante ello, se registra una observación respecto a la deficiente descripción del contenido.  Posiblemente esto tomará aproximadamente 5 minutos por funcionalidad.

Estas observaciones permitirá al colaborador que elaboró el documento, buscar alinearse al procedimiento establecido para esta actividad, con lo cual se evitará arrastrar nuevos errores o incumplimientos posteriormente en otros documentos.   Asimismo, deberá corregir todos los documentos anteriores, no revisados.

De manera que se irán incluyendo nuevos temas de revisión a lo largo del proceso, sin necesidad la actividad o el entregable completo, sino mas bien, esto permitirá generar una cultura de calidad dentro del cumplimiento de los procesos, políticas y entregables del proyecto o servicio.

Los Magos de la Calidad con encantamientos y estrategias para potenciar proyectos y servicios

En el ámbito de los proyectos o servicios, nos enfrentamos a una serie de desafíos relacionados con la calidad, muchos de los cuales derivan del desempeño de los colaboradores. ¿Cómo podemos asegurarnos de que los colaboradores cumplirán con las expectativas del proyecto o servicio? Esta incertidumbre se agudiza cuando se trata de nuevos integrantes en el equipo. A pesar de las entrevistas y evaluaciones a los recién llegados, persiste la pregunta sobre cómo garantizarán el cumplimiento de las expectativas. Algunos incluso pueden pensar que cumplen con su tarea simplemente por hacerla a tiempo, sin considerar si lo entregado es útil para la siguiente fase o si los insumos recibidos están adecuadamente preparados.

Generalmente, se asume que cada colaborador cumplirá con su responsabilidad. Sin embargo, aunque se realice un seguimiento, este suele limitarse a la finalización de la actividad, sin asegurar que el entregable esté completo según lo especificado.

Así, los incumplimientos o errores se descubren en fases posteriores, cuando estos entregables se utilizan como insumos para actividades posteriores. Esta situación, bastante tardía, puede postergar el proyecto al requerir correcciones.

Los motivos de incumplimiento y errores pueden ser diversos:

- Desconocimiento del proceso operativo.

- Falta de comprensión del alcance.

- Ignorancia del nivel de calidad esperado.

- Bajo compromiso del colaborador.

- Insuficiente preparación técnica.

- Desconocimiento de los objetivos sobre su participación.

¿Cómo asegurarnos de que estos problemas no surjan o se minimicen durante el desarrollo del proceso?

El rol correspondiente debe inspeccionar el trabajo de cada colaborador, especialmente al inicio del proyecto cuando se está conociendo el mismo. A menudo se cree que debe esperar que se termine el entregable para revisar todo el contenido, lo cual requiere "mucho" tiempo. Pero el cambio necesario en los colaboradores no es tanto una revisión exhaustiva, sino un cambio cultural. Es crucial que comprendan que la mala calidad o los problemas en el servicio no son aceptables. Necesitan entender el proceso operativo, las políticas, el nivel de calidad esperado, el conocimiento técnico necesario y el propósito de su labor, para lograr cumplir con las expectativas.

Para lograrlo, solo se requieren revisiones puntuales y periódicas sobre el avance de la actividad, sin necesidad de que este terminado, verificando cualquier punto del proceso en el que se encuentra, cualquier política o nivel de calidad, sin necesidad de revisar todo.  Es esencial fomentar que los colaboradores estén comprometidos con entender y cumplir lo establecido. Además se evalúa el  nivel de conocimiento y experiencia técnica. Estas revisiones puntuales y breves de manera periódica, abarcando a la mayor cantidad de colaboradores en distintas etapas, permitirá alinearlos con los procesos y la calidad esperada, identificando deficiencias que corregirán y buscarán mejorar constantemente.

Asimismo, los colaboradores estarán más atento con cumplir con lo especificado en el proceso y las políticas, de manera que presentarán menos observaciones al momento de la revisión periódica.

A medida que se alineen y mejoren la calidad de su trabajo, el tiempo destinado a las revisiones disminuirá progresivamente.  Generando además, confianza entre los colaboradores del equipo.

¿Para qué tanto control y metodología?

Un día al término de la jornada laboral, antes de retirarme, un colaborador analista de testing, me pide una reunión, y entre diversos temas que conversamos resaltaron dos preocupaciones que tenía de los cambios que estabámos ejecutando.

La primera de ellas, "¿para qué tantos controles en el proceso?"

Para responder, recordé qué el colaborador tenía un negocio familiar, un restaurante.  Antes de responderle la pregunta, le formule una cuestión respecto a su negocio, "cuando tienes un cambio de turno de personal, y ellos salen con bolsas o maletines, ¿les revisan el contenido?", la respuesta fue afirmativa, entonces le hice una nueva pregunta, "¿por qué?", "porque en ocasiones se llevaban insumos, comidas o utensilios sin autorización".  Es decir, tuvo un problema y decidió aplicar un control para evitar que siga ocurriendo.   Adicionalmente los controles no siempre es por alguna ilegalidad que esté ocurriendo, sino simplemente para asegurar el cumplimiento de la actividad, así como, no se aplica en todos los casos sino a una muestra.   Y dependerá de la madurez del proceso y de las personas que la ejecutan, la necesidad de mantener el control.

La segunda pregunta, fue "¿para qué tanta metodología?", igualmente haciendo referencia a su negocio familiar, le pregunté, "¿cuál es el plato de bandera del restaurante?", "el lomo saltado", me respondió.  Adicionalmente le pregunté, "¿cuantos cheff tienen durante la semana? ", "tres cocineros", me respondió.  Le comenté que tenía mucha suerte, porque para tener tres cocineros, el sabor del lomo saltado era igual durante todos los días de la semana.  Y me comentó su secreto, "los platos tienen descrito un paso a paso que todos los cocineros lo deben seguir, para asegurar el sabor", entonces le dije, "esa es tu metodología".   La metodología te permite estandarizar la ejecución de las actividades, que permite en un primer momento asegurar el mismo producto en todo momento, con la misma calidad, característica, costos, etc., y adicionalmente te permite mejorar, optimizar y madurar el proceso y producto.

El temeroso y audaz colaborador que se atrevió (para bien...) a cuestionar los últimos cambios que veníamos aplicando, cambió en su perspectiva de cambios, logrando entender el propósito de las actividades.   Este cambio le permitió entender el resto de cambios, con lo que en el tiempo, asumió las responsabilidades de liderar el equipo de testing, luego la responsabilidad de calidad de los procesos, hasta el último reto asumido del equipo de desarrollo de software.

¿Pará qué tanto control y metodología?...

Comprar o desarrollar software

Muchas veces las empresas evalúan la posibilidad de desarrollar internamente o comprar un software que automatice cualquiera de los procesos de su negocio.

También hemos escuchado malas experiencias tanto en la compra de un software porque no se ajustaba a las necesidades del negocio; o malas experiencias en el desarrollo por el tiempo que tomó construirlo.

Antes que nada, considero que debemos tener claro que todo software estaba basado en un modelo de procesos o negocio. Por tanto, el software se adaptará a "mi proceso o mi negocio" en la medida que el modelo de "mi proceso o mi negocio" se asemeje en parte o gran parte del modelo de negocio o proceso sobre el cual se ha basado el software. Además todo proceso o negocio tiene un modelo definido, correcto o incorrecto, documentado o no, ordenado o no, pero al final es un modelo.

Para este evaluación sin considerar los factores económicos, políticos, culturales dentro de las empresas, únicamente nivel de modelo de negocio. Las pregunta que debemos hacernos son las siguientes, ¿tengo claro cual es el modelo de "mi proceso o mi negocio"?, si la respuesta es negativa, tendremos aterrizar todo el procesos involucrados o el negocio hasta conocer con claridad el modelo.

¿Considero que mi modelo es el adecuado para el soporte de mi negocio o mi proceso?, si la respuesta es afirmativa, iremos en busca de softwares cuyo modelo se asemeje al modelo de "mi proceso o mi negocio". Si la respuesta es negativa, tendríamos la oportunidad de buscar software cuyo modelo sea el adecuado para "mi proceso o mi negocio".

Cuando adquirimos un software más allá de obtener el paquete o la funcionalidad del software, obtenemos un modelo de procesos o un modelo de negocio para nuestra compañía, que se encuentra automatizada y que nos permitirá realizar nuestro trabajo de forma más productiva.

Es una errada decisión intentar adaptar el software adquirido con el modelo de "mi proceso o mi negocio" muy diferente a la del software, con ello estaríamos modificando el modelo de procesos o negocios del software adquirido.

Posiblemente no encontraremos un software cuyo modelo sea exactamente al modelo de "mi proceso o mi negocio", para ello, tendremos que considerar cuáles son las actividades o procesos críticos que deben estar automatizados y sobre el resto soportarlo manualmente o si los procesos o actividades no representan la parte crítica del modelo podemos realizar un desarrollo complementario al software. Que tan cerca al modelo de "mi proceso o mi negocio" debe estar el modelo del software para tomar la decisión de comprar, dependerá mas bien de que tan cuan crítica es la parte que no coincide con el modelo.

Si no encontramos un software cuyo modelo no se adapta al modelo de "mi proceso o negocio", la opción principal será desarrollar.

Adicionalmente, algunas consideraciones a tener en cuenta en una compra o desarrollo de software.

Ventajas de Desarrollar

• Se establece la funcionalidad del software acorde al modelo de procesos o de negocio de la compañía.

Desventajas de Desarrollar

• Demasiado tiempo para la implementación de la solución de software.
• Proceso de estabilización del software

Ventajas de Comprar

• Funcionalidad probada y estable
• Posibilidad de comprobar la calidad de la solución en implementaciones existentes.
• Menor costo total de implementación
• Menor tiempo de implementación

Desventajas de Comprar

• Funcionalidad cerrada, limitadas posibilidades de modificaciones, por riesgo a cambiar el modelo del Software.
• Normalmente adquisición sin código fuentes.
• Necesidad de recursos especializados en el software para el mantenimiento.

Organicémonos...

Muchas veces nos encontramos abrumados con la cantidad de requerimientos de sistemas que recibimos de nuestros usuarios, adicionales a la cantidad de problemas que nos reportan día a día, todo el equipo, toda el área de sistemas, esta abocada a atender las diferentes necesidades de nuestros usuarios, pero aún así, faltan manos para atenderlos todos. Finalmente, la situación conlleva a incumplimiento de fechas, postergación de la atención del requerimiento, insatisfacción del usuario, mala calidad del producto, estrés en el equipo de trabajo, etc.

En principio, debemos establecer una organización adecuada para la atención en el área de sistemas, si bien es obvio y la teoría lo dice, en la práctica, debido a nuestra desesperación, los roles en la organización no están definidos o no se cumplen. Tener claridad en cada uno de los servicios que el área de sistemas ofrece o es responsable, por ejemplo, soporte en la atención de incidentes tecnológicos de la compañía, atención de requerimientos de hardware y software, atención de requerimientos funcionales de las aplicaciones, desarrollo de proyectos tecnológicos, etc. Para cada uno de estos servicios tendremos definidos los procesos, perfiles, funciones y responsabilidades. Estos perfiles serán cubiertos por personas a quienes se les asignarán las funciones y responsabilidades para cumplir con la atención de los servicios del área. Debemos definir las responsabilidades para cada uno de los integrantes de nuestro equipo de trabajo, evitando que todos cubran todas las funciones o que todos realicen todas las tareas.

Ante la abrumadora cantidad de requerimientos, un punto muy importante, es establecer el procedimiento y las políticas de atención de cada uno de los servicios, donde se establece, quién debe solicitarlos, a través de que canal, como por ejemplo,

1. La atención de requerimientos, que corresponden a pedidos de nuevo hardware, software o funcionalidad adicional para las aplicaciones, en estos casos, debe ser solicitado o aprobado por el dueño del presupuesto del área solicitante, en vista que debe asumir el costo de la inversión o el gasto de la atención.
2. Para la atención de un requerimiento de funcionalidad adicional para una aplicación, deberá tener la aprobación del usuario dueño responsable de la aplicación, quien debe mantener el modelo conceptual definido para la aplicación, si no es así, cualquier persona solicitaría alguna funcionalidad sin los criterios del modelo conceptual.
3. Todos las solicitudes deben quedar registradas en una fuente de información o en todo caso a través de un solo canal de comunicación, o integrándolos, como Sistema de Mesa de Ayuda, a una cuenta de correo mesadeayuda@... o un número telefónico o anexo de la empresa que permita registrar la solicitud, eliminando cualquier pedido a través de un canal informal.
4. La solicitud debe ir acompañado de una prioridad o un orden de atención respecto a las solicitudes pendientes anteriormente ingresadas.
5. Toda atención completada debe tener la conformidad de la atención por parte del solicitante.

Para los servicios habrá un procedimiento de solicitud y atención que permitirá establecer el orden de los pasos a seguir, mientras que las políticas establecerán los principales requisitos para la atención.

Finalmente el registro centralizado permite no sólo tener la información en un sólo punto para hacer seguimiento a las atención, sino también permitirá explotar la información mediante estadísticas, para detectar y analizar los patrones de comportamiento, por ejemplo,

1. Incidentes por errores en las aplicaciones. Detectar patrones para priorizar la corrección del problema, en función al número de errores producidos y/o al impacto funcional del problema.
2. Requerimientos de hardware y software. Analizar compras periódicas para concentrarlos en compras por volumen.
3. Tiempos de atención de incidentes y requerimientos, que permitirá optimizar el número de personas para el área, así como definir el estándares de niveles de servicios para con el usuario cliente.
4. Estrategia de implementación de soluciones. La relación de los requerimientos de hardware y software priorizados, permitirá una adecuada planificación de la implementación y de inversión.

En resumen, organicémonos... de acuerdo a las funciones y responsabilidades por los servicios que brindamos, con ayuda de políticas y procedimientos, que son mejorados de acuerdo al análisis de estadísticas e indicadores, para identificar patrones y priorizar soluciones.

Un Momento para la Gestión...

En nuestros proyectos, somos buenos desarrolladores, conocemos diferentes técnicas de desarrollos, amplia base metodológica, estándares claros, estimaciones precisas, pero un defecto, muchas veces, nuestros planes de trabajo no consideran tiempos para la gestión, tiempo para controlar y hacer el seguimiento a los planes de trabajo, tiempo para administrar las actividades detalladas del plan de trabajo. Estos tiempos, también son parte del proyecto, son tareas del jefe de proyecto.

No tener estos tiempos considerados en el plan de trabajo, implica mayor esfuerzo para el jefe de proyecto para realizar sus tareas de desarrollo y las tareas de gestión (no considerados en el plan), con la finalidad de cumplir con las fechas comprometidas, o en todo caso, sinceraremos el plan de trabajo moviendo las fechas o ingresando un recurso adicional al proyecto.

Para evitarlo, es necesario e imprescindible, considerar los tiempos para la gestión, control y supervisión. A continuación un grupo de actividades que considero deben estar incluidos dentro de los tiempos de gestión, con estimados de tiempos, que dependen del tipo de proyecto, de las características de los perfiles del equipo de trabajo, y de las características del usuario:

1. Resolver dudas, consultas y/o coordinaciones diarias de cada uno de los participantes del equipo de trabajo. (0.50 horas por día por recurso)
2. Resolver dudas, consultas y/o coordinaciones diarias del cliente y/o usuarios. (1.00 hora por día)
3. Revisar los reportes de horas semanales de los participantes del equipo de trabajo.(0.10 horas por semana por recurso)
4. Actualizar semanalmente el plan de trabajo, registrar los avances, reestructurar las actividades y asignaciones de recursos. (0.40 horas por semana por recurso)
5. Elaborar reportes e informes de avances semanales, (0.50 hora por semana)
6. Reuniones semanales de reporte de avance con el cliente y/o usuarios. (1.00 horas por semana)
7. Reuniones semanales de reporte de avance con mi gerente supervisor. (1.00 horas por semana)

Para un ejemplo de proyecto con un equipo de cinco recursos podríamos necesitar 22.5 horas semanales del jefe de proyecto, insisto en que, de acuerdo a las características del proyecto, del equipo de trabajo y del usuario deben evaluarse las actividades de gestión, así como los estimados de tiempo de cada una de ellas. Pero en general, siempre necesitaremos de Un Momento para la Gestión...

Cuestiónalo y mejorará ...

"No sé, siempre lo hicieron de esta forma...", o "me dijeron que lo hiciera así..." son respuestas sorprendentes ante la pregunta de "¿porqué lo haces así?".

Si bien cada uno debe preocuparse por cumplir cabalmente las instrucciones encomendadas por el jefe responsable o por la empresa, también esperamos que cada uno contribuya con el aporte de mejoras.

Muchas veces no hacemos las mejoras a los productos y procesos porque pensamos que es responsabilidad de otras áreas u otras personas, pero, ¿se imaginan, quienes más que nosotros que realizamos la actividad, podemos conocerlo mejor como para realizar un aporte de mejora?.

No hacemos las mejoras porque creemos que nuestra obligación es sólo cumplir con la actividad o tarea, que mejor para nosotros cualquier mejora que optimice el tiempo, reduzca las actividades o simplemente mejora la calidad del producto bajo nuestra satisfacción de tener en nuestras manos algo de muy buena calidad.

O, no hacemos las mejoras porque no sabemos como empezar... ante esto sólo sugiero, para empezar, "Cuestiónalo y mejorará".

Estos cuestionamientos, como simplemente, ¿porqué no rojo en lugar del azul? o, tan complejo como ¿puede mi escarabajo VW volar?, presentarán muchas alternativas de cambio, posiblemente, varias de ellas sin ningún beneficio, ni mejora, económica, social, ambiental, estética, o como quieran llamarlo, pero algunas o simplemente una, podría ser alternativa favorable, que permita contribuir con la mejora en el producto o proceso.

No siempre necesitamos de especialistas externos para realizar las mejoras, generalmente somos nosotros mismos, los especialistas que trabajamos todos los días y a toda hora, con nuestros productos y procesos. Sólo tenemos que cuestionarlo para "romper el paradigma", donde las alternativas vendrán solas, que evaluadas podrán implementadas para mejorar nuestros productos y procesos.

Finalmente, estos cuestionamientos, que traerán alternativas, que generarán mejoras, harán en las personas y grupos de trabajo una forma de hacer las cosas, un hábito, con múltiples satisfacciones, personales y profesionales, productivas en tiempo, dinero, mejora en calidad, estética, etc. para esto, sólo, "Cuestiónalo y mejorará".

Control y seguimiento del proyecto ... un problema cultural

"No hay tiempo para realizar el control y seguimiento del proyecto", "no hay tiempo para elaborar los informes y reportes de avance", "no hay tiempo para reuniones de avance", son expresiones típicas y comunes por la que muchos de nosotros hemos pasado, hasta que nos convencimos que las cosas funcionan mejor con la gestión de proyectos.

Siempre he pensando que este problema común, es un problema cultural (cultura en la forma de trabajo) al cual nos es difícil adaptarnos (en un comienzo), lo tomamos como un trabajo engorroso que no tiene un beneficio "directo" con el desarrollo del software, con la construcción de la aplicación, y que únicamente sirve para informar los avances a la gerencia.

A veces creo que sólo somos especialistas en desarrollo, especialmente cuando empezamos, porque nos gusta analizar, diseñar, programar, en general construir aplicaciones, hacer que la computadora realice lo que queremos. Entiendo que si nos hubiera gustado como especialidad, el controlar y hacer seguimiento, posiblemente estaríamos en otra carrera. Pero lo que tenemos que comprender es que en general cualquier especialización a la que nos dediquemos requiere una administración, control, seguimiento para que finalmente logremos el objetivo trazado.

En estos casos, no es solamente conocer una metodología de control y seguimiento, es necesario entenderlo, es necesario vivirlo. Para ello, necesitamos darnos una oportunidad, que nos permita vivir un proyecto con el control y seguimiento adecuado, para entenderlo y con ello, compararlo con situaciones anteriores (proyectos sin control ni seguimiento), para evaluar y comprender el impacto positivo que anteriormente no era posible medirlo (en vista que no se entendía).

Ejemplos de impacto positivo,

1. Acciones oportunas, con el seguimiento, se detectan los problemas en el momento, y no al final cuando es mucho mas difícil corregir.
2. Equipo sin estrés (en proyectos con problemas o sin problemas), desde el momento que se tiene conocimiento de la situación real con las acciones de corrección claramente definidas, la situación es mejor (no necesariamente bueno, en proyectos con problemas), pero mejor.
3. Confianza en el plan, creer en el plan, creer en la fecha de termino, al margen de problemas y correcciones, tener la versión real de la situación, que nos permitan tomar la mejor decisión. Sin un seguimiento, la fecha del plan es irreal, con lo cual no es posible tomar la decisión adecuada.
4. Preocupación individual de cada integrante, teniendo el plan actualizado, cada integrante tiene una guia por cumplir, para evitar que el plan general (creíble para todos los integrantes) no se vea afectado. Esta actividad no es únicamente del jefe de proyectos (como pareciera inicialmente), entendemos que la gestión es de todos los integrantes (cada uno en sus actividades), donde el jefe de proyectos los consolida.

Al tener el impacto positivo, valoraremos más el esfuerzo por realizar el control y seguimiento, entenderemos mejor sus beneficios y será difícil dejarlo en los siguientes proyectos, con ello habremos cultivado la cultura de control y seguimiento en los proyectos.

Mi historia en la gestión de proyectos ... a cocachos aprendí ... (Parte III)

Primeros logros ...

En este proyecto fuimos reconocidos como el equipo que tenía la mejor gestión de proyectos. Además de reducir el promedio 35% de variación con respecto al esfuerzo estimado inicial los proyectos (promedio de la evaluación de proyectos de 1999) a sólo 2% por responsabilidad del equipo de trabajo, permitió sentir los primeros éxitos en un proyecto, recordando que, "Este proyecto no fracasará... " se estaba cumpliendo...

No sólo logramos cumplir con las expectativas del proyecto en cuanto a avances, fechas y resultados económicos, sino también se incrementó la confianza del equipo de trabajo respecto a su desempeño, se generaba expectativa positiva y motivación en el equipo sobre el plan de trabajo, la planificación de las vacaciones se cumplían....

Asimismo, teníamos la confianza de nuestro usuario, que además, realizaba una más exhaustiva evaluación de los requerimientos que solicitaba ... en vista que se tenía claramente registrado los requerimientos y/o incumplimientos por su responsabilidad.

Con la confianza y buenos resultados, empezábamos a generar una cultura positiva en el equipo respecto a la gestión de proyectos.

Difusión total ... Replicación masiva ...

Otros proyectos empezaron a buscarnos para utilizar la metodología de control operativo de proyectos (esquema de control y seguimiento) para mejorar su desempeño y cumplir con sus objetivos.

Empezamos a capacitar a los diferentes jefes de proyectos con los temas de gestión de proyectos y luego con la metodología de control operativo de proyectos, para seguidamente pasar a la implementación de la metodología en cada uno de sus proyectos. Esta implementación se realizaba en cinco semanas, donde al final el jefe de proyectos tomaba el control de la metodología y de su proyecto.

Cuando terminamos la implementación de la metodología de control de proyectos teníamos información suficiente para evaluar la variación del esfuerzo estimado de cada uno de los proyecto para esa fecha. El resultado, 15% como promedio de variación con respecto al esfuerzo estimado inicial de los proyectos.

Esta reducción a 15% del promedio de variación del esfuerzo estimado de los proyectos, indicaba que ibamos por la dirección correcta con el uso de la metodología.

Nueva meta ... nuevo objetivo ...

Consideraba que lo razonable en los proyectos de desarrollo de software, el promedio de la variación de los esfuerzos estimados debería estar por debajo del 10%, fijamos la meta de 5%.
Al cabo de varias semanas ... con el ingreso y salidas de proyectos fuimos ajustando el indicador hasta llegar al 5% y a partir de alli lo mantuvimos entre el 5% y 7%.

Al tener estandarizada la gestión de los proyectos con la metodología de control y seguimiento nos permitiría consolidar todos los proyectos en un plan consolidado, con lo cual tendríamos claramente, no sólo, las fechas de inicio y fin de cada proyecto, o las variaciones de los mismos, así como las responsabilidades identificadas para cada equipo de trabajo o para el usuario, sino también podíamos controlar los ingresos y salidas de los recursos de manera que optimizabamos los tiempos muertos entre proyectos, negociando los inicios de los nuevos proyectos, ajustando las vacaciones de los colaboradores a los periodos libres entre proyectos.

Una forma de asegurar el pan para mañana ...

El estandar de control y seguimiento de proyectos nos permite controlar los proyectos y optimizar el uso de los recursos, pero además, en el caso de las consultoras cuyo negocio es ejecutar proyectos, las cobranzas están relacionadas a los entregables de cada proyecto, es muy útil el estandar debido a que los entregables nos dan la referencia del flujo de caja positivo, mientras que los pagos a los colaboradores nos dan como referencia el flujo de caja negativo, teniendo por consiguiente el flujo de caja de cada proyecto y finalmente un flujo de caja del
consolidado de todos los proyectos de la consultora. Inclusive, podemos establecer metas sobre el flujo de caja del consolidado de los proyectos, incluyendo proyectos futuros aun no iniciados.

Finalmente, a cocachos aprendí ...

Para nosotros, desarrolladores de sistemas es importante conocer y saber utilizar la herramienta de desarrollo y las metodologías de desarrollo, también es importante el resultado tecnológico funcional del producto en elaboración, pero en algunos casos, no se le da la suficiente importancia a la gestión del proyecto.

Por tanto, podemos terminar con un producto tecnológica y funcionalmente fabuloso y espectacular, pero tal vez, no en la fecha esperada inicialmente, o no con los recursos económicos inicialmente presupuestados, o tal vez con un equipo de trabajo estresado y cansado, esperando no participar en otro proyecto similar.

Con el estandar de control y seguimiento de proyectos, lo importante es la tranquilidad y confianza en un equipo de trabajo durante la ejecución del proyecto, en base a una identificación real y oportuna de los imprevistos y variaciones en el proyecto, de manera que, se tomen las acciones correctivas rápidamente, cuyas soluciones son más faciles de implementar, en comparación a la acumulación de problemas por la falta gestión y seguimiento.

Finalmente, proyectos con calidad, terminados en tiempo y dentro de presupuesto, con los recursos productivos, eficientes y satisfechos, es realmente posible, en la medida que la gestión y seguimiento sea más importante para las empresas y los equipos de trabajo.

Mi historia en la gestión de proyectos ... a cocachos aprendí ... (Parte II)

Microsoft Project... la herramienta

Tenía experiencia utilizando MS Project desde 1996, pensaba que sabía utilizar la herramienta, cuando en realidad sólo registraba las actividades para mostrar en un diagrama de gantt. Para mostrar los avances, registraba los porcentajes o construía un nuevo diagrama de gantt. Para el esquema de control del nuevo proyecto, pensé en definitiva utilizar el MS Project, pero esta herramienta debería tener una mayor utilidad, que simplemente mostrar un diagrama de gantt (en todo caso, podríamos utilizar el MS Excel para hacer lo mismo, sin gastar en licencias de otros productos).

Con el MS Project buscaba cerrar el ciclo completo de control y seguimiento de un plan de trabajo, es decir, que basándome en un plan de trabajo inicial con actividades y recursos definidos, debería periódicamente alimentarlo con las horas aplicadas (horas reales) por los recursos en las diferentes actividades, así como modificaciones en las actividades y/o sus estimados de esfuerzo o fechas de realización, de forma que con los ajustes necesarios, terminaba siendo en mi plan de trabajo inicial para el siguiente periodo.

Finalmente logré establecer el ciclo completo, para quienes conocen MS Project, dos funciones completaron (para mí) el complejo esquema de control y seguimiento de un plan de trabajo, "reprogramar trabajo restante" y "redistribuir recursos", ambos permiten "sincerar el proyecto" debido a las diferentes variaciones en las actividades durante el periodo.

Esquema de control y seguimiento ... su impacto y sorpresas ...

Inicialmente, mientras definía el esquema las revisiones y actualizaciones semanales del plan de trabajo me tomaban alrededor de 12 horas, para 4 recursos en el proyecto, incluía, registrar los reportes de hora de cada uno de los recursos, identificando las actividades de los reportes en el plan de trabajo, ingresar nuevas actividades no contempladas inicialmente, identificar y analizar las variaciones en el proyecto, buscar justificarlas, reajustar el proyecto para reducir o eliminar el atraso en el proyecto, para finalmente cerrar con el informe de avance semanal. Cuatro meses después la actualización semanal tomaba alrededor de 1.5 horas, para 10 recursos en el proyecto, ¿qué cambio?

1. Madurez del esquema de control y seguimiento. Metodología de Control Operativo de Proyectos.


2. Mayores herramientas de identificación de variaciones, como vistas, reportes, etc.


3. Mejora en el registro del reporte de horas de cada uno de los recursos. Más sincero.


4. Mayor compromiso de cada uno de los recursos en sus actividades, debido a la identificación de responsabilidades dentro del proyecto.


5. Mejora en el cumplimiento de los tiempos y estimados de esfuerzo en las actividades para cada uno de los recursos. Cada uno administraba su "plan de trabajo".


6. Reevaluación previa de las actividades futuras y sus estimados que permitan tomar acciones de corrección con anticipación.


7. La identificación anticipada y oportuna de los atrasos o incremento de los esfuerzos por reestimación, que permiten recuperar el tiempo con mayor holgura y tranquilidad. Evitando acumular los atrasos al final de cada fase, entregable o final del proyecto, donde no existe tanto margen de acción.


8. La actitud positiva del equipo de trabajo, creyendo en el objetivo del proyecto, creyendo en el equipo de trabajo y creyendo en el plan de trabajo.


9. Finalmente, la cultura de planificación, control y seguimiento en cada uno de los participantes en el proyecto, como herramienta imprescindible para el mejor desarrollo de los proyectos.
   

Con todos estos cambios, todos los recursos estaban alineados y comprometidos con sus actividades, veía en cada uno de ellos,

1. No habían atrasos que recuperar, o eran mínimos. Mínimas variaciones, justificadas por los recursos y fácilmente recuperables.


2. Rápido registro de horas de los recursos


3. Mínimo reajuste, en vista que no hay atrasos.


4. Mínima justificación por responsabilidad del equipo de trabajo.


5. Sin estrés en el proyecto, sin amanecidas u horas extras innecesarias.
   

Por ello, la actualización se redujo de 12 horas a sólo 1.5 horas en la semana. El proyecto mantenía sus fechas originales o sólo tenía alguna variación por requerimientos adicionales de los usuarios.

Mi historia en la gestión de proyectos ... a cocachos aprendí ... (Parte I)

Sólo metodología de desarrollo poca gestión...

En 1996, iniciamos un proyecto de consultoría para la reingeniería de una área en una compañía financiera, con el análisis de los procesos logramos la reducción de tiempos, optimización de las actividades para lograr un área eficiente que permita a la compañía financiera estar preparada para incrementar su producción en los próximos años. Finalmente, este proyecto determinó la necesidad de desarrollar un nuevo software para el área que permita automatizar los procesos optimizados ya implementados.

Por ese entonces, mi experiencia en proyectos de desarrollo era alrededor de 7 años, habiendo participado en 10 proyectos aproximadamente, tanto como programador, analista programador y líder de proyecto. Mis conocimientos de desarrollo se basaban en las metodologías de desarrollo de software, tanto para análisis, diseño, programación, pruebas, gestión, etc.

Para el nuevo software para los procesos optimizados, se preparó un proyecto de desarrollo, donde tenía la responsabilidad del proyecto, era el líder del proyecto, participé en la definición y estimación del proyecto, calculado en 24 meses de duración. Finalmente, iniciamos el proyecto con un equipo estaba conformado inicialmente por 4 personas. Al cabo de 2 meses de proyecto, el analista principal (persona con mayor experiencia en el proyecto) comenta respecto a los resultados de la evaluación económica del proyecto (resultado positivo): "Con el resultado obtenido a la fecha, el proyecto fracasará económicamente...". Este comentario, que lógicamente no me gustó, me hizo pensar: "¿cómo es posible que en dos meses de avance de un proyecto de 24 meses, podamos señalar que el proyecto (en positivo) fracasará, teniendo todo el tiempo por delante para tomar las acciones correctivas necesarias para evitarlo?. Pero, el problema no era el comentario, al margen si era cierto o no, finalmente no sabía como controlarlo, para evitar a que fracasara.

A partir de esa fecha, me enfoqué a las metodologías de análisis, diseño y programación, para que el proyecto no fracasara, también teníamos planes de trabajo, pero no había el seguimiento correcto, tampoco lo entendía en ese momento. El proyecto terminó con los alcances solicitado, pero no en los plazos estimados, ni con los resultados económicos esperados, mi compañero tuvo razón, pero no porque sea un visionario, sino porque no hicimos las gestiones necesarias para evitarlo y corregirlo. Luego de esa experiencia pensamos en, darle énfasis a la supervisión de la aplicación adecuada de las metodologías de desarrollo, insuficiente claro, no lo entendía en ese momento, el tema de gestión era muy gaseoso ...

En los siguientes meses, nos dedicamos a la supervisión de proyectos bajo la metodología de desarrollo definida por la consultora, con planes de trabajo y seguimiento periódico a la metodología, pero algo faltaba...

Escalofriantes números ...

A finales de 1999, realizamos un análisis de los proyectos desarrollados durante el año, incluían aquellos iniciados antes de 1999 y aquellos que terminarán después de 1999. La evaluación debería determinar la variación del esfuerzo real total (horas hombre aplicadas más horas hombre pendientes por aplicar) con respecto al esfuerzo total original de la propuesta de cotización. El resultado fue, el esfuerzo real era un 35% adicional respecto al esfuerzo de la propuesta original, es decir, estábamos trabajando un 35% más del esfuerzo por el cual estamos cobrando. Este adicional que representaba un equivalente a 60 meses de sueldo de una persona promedio en la organización, o la planilla de sueldos de un mes.

Incluso se pensaban que no era 35% sino 50% ..., en realidad el 35% o 50% adicional no solo consideraba la responsabilidad del equipo de trabajo, por no controlar adecuadamente el proyecto, sino también incluía requerimientos adicionales del cliente, o modificaciones a las especificaciones iniciales que por motivos diferentes no eran presupuestados y por tanto, era asumido por el proyecto. ¿Motivos?, falta de control y seguimiento al proyecto, inexperiencia del equipo para identificar los adicionales o modificaciones, "rabo de paja" por los errores cometidos durante el proyecto, que no permite negociar con el cliente, falta de gestión comercial, etc.

Consideraba que con un mayor control y seguimiento al proyecto en lapsos de tiempos mas cortos podría reducirse el esfuerzo adicional, o podría rápida y fácilmente identificarse cualquier requerimiento adicional o modificación bajo la responsabilidad del cliente. El problema era ¿cómo identificar? ...

Un fracaso más, si importa ...

En el año 2000, iniciamos un proyecto cuyo contrato tenía muchas penalidades por incumplimientos de cláusulas, ya cansado de tantos proyectos estresantes por carga de trabajo, plazos sin cumplir, resultados económicos negativos, etc. Me propuse definir un esquema de planificación y control, que me permita identificar las diversas variaciones de esfuerzo y de fechas de las actividades, a lo largo de la ejecución del proyecto. Que, esta identificación de variaciones también me permita identificar al responsable de los mismos, de manera que se tenga claramente identificados las responsabilidades del contrato. Decía: "Este proyecto no fracasará, y menos por mi responsabilidad...".

Tenía los elementos suficientes para el éxito del proyecto, esquema de organización adecuada, buenos recursos, experiencia metodológica en el desarrollo de proyectos, pero faltaba el esquema de control...Es decir, tenía todos los elementos suficientes para sobrevivir en la selva, comida, agua, carpa, abrigo, herramientas, linternas, etc. pero, ¡¡¡no tenía el mapa ni una brújula!!!

Con mi copiloto al lado...

¿Cual es nuestro problema? es que para mantener el trabajo, pensamos en que debemos atornillamos a nuestros puestos, donde en lo posible, nadie más conozca como lo hacemos. Y con ello, no nos damos cuenta que, de esa manera, nosotros mismos cortamos nuestras oportunidades.

Desde hace varios años, al iniciar cualquier proyecto personal o profesional busco un Copiloto como apoyo. Con la Gerencia de Sistemas como responsabilidad busqué tener a una persona que conociera todas las actividades que yo realizaba, y principalmente que conociera los criterios con los cuales tomaba las decisiones. De esta manera, a parte de cubrirme ante cualquier ausencia mía, me apoyaba en momentos de mucha carga de trabajo. Y para mi Copiloto una oportunidad para crecer profesionalmente realizando actividades sobre nuevos roles.

Contar siempre con un segundo a tu lado, nos permitirá mejorar nuestras oportunidades, un Copiloto con potencial profesional para que te reemplace ante cualquier situación (cosa que, pocos son los que lo hacen, por temor a perder el puesto). Copiloto a quien le debes enseñar todo lo que haces tu. ¿Cuál es el fin?, que puedas salir de vacaciones, que te ayude en épocas pico, pero cual es el motivo principal (egoísta si quieres verlo), que finalmente en el momento en que estés preparado para tomar nuevas responsabilidades, tienes a alguien preparado en tu puesto para reemplazarte, con lo cual, tranquilamente vas a tomar tus nuevas responsabilidades.

Una manera de fomentar estos desarrollos personales y profesionales, es solicitando a mis colaboradores directos que busquen "ocupar mi escritorio", ocupar mi puesto, de manera que intenten hacer las cosas de la misma forma que yo o mejor aún. En estos casos, mis colaboradores preocupados por si esto sucedía, me preguntaban, "¿y luego que vas a hacer?", yo respondía ... "siempre hay nuevas oportunidades...".

Cuando tu jefe necesite asignar una nueva responsabilidad, preguntará, ¿quién lo puede tomar?, decidirá por ti ya que estas profesionalmente preparado, luego, la siguiente pregunta será, ¿y lo que haces, quien lo puede hacer?, en caso no haya nadie, la asignación en tu persona será muy difícil. En cambio, al tener tu Copiloto al lado fácilmente podrás acceder a esa nueva oportunidad.

Al final, todos ganamos, uno mismo al crecer con las oportunidades, el Copiloto quien recibe la enseñanza y también las oportunidades y la organización con una actitud al crecimiento y desarrollo, más no atornillarse en el trabajo.

Por fin me animé ...

Por fin me animé ... compartir mis anécdotas, experiencias profesionales y personales que recibí en el tiempo. Desde hace varios meses anduve pensando abrir un blog de este tipo, que aún no sé cómo elaborarlo... pero vamos a intentarlo...

Espero que estas anécdotas y experiencias puedan ser recibidas para el mejor provecho de cada uno de uds. en la forma como me ha servido a mí.

Tengo estudios de ingeniería industrial con experiencia en el área de tecnología, particularmente en desarrollo de software y gestión de proyectos.