¿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.