Software Product Quality Beyond Defects

Hemos publicado un artículo acerca de calidad de producto de software y la evolución de una organización en su intento de lograrla.

En el artículo se muestra un caso práctico y el análisis del mismo.

El articulo lo pueden encontrar en 

Software Product Quality Beyond Defects

La publicación completa la pueden ver en:

Testing Experience

El mapa y el camino - Supuestos y realidad

Hicimos nuestra estimación de la prueba, planificamos para lograr el objetivo buscado y nos preparamos a ejecutar.....
Luego viene la realidad, con sus detalles y cambios. 
Podemos adelantarnos a algunas cosas? Sirven los supuestos? 

Se presentan algunas ideas simples a tener en cuenta al estimar el esfuerzo y el tiempo y la posterior planificación de una prueba de producto de software. 
No nos centraremos en estimar, sino en supuestos y riesgos. 
Son pequeñas ayudas de todos los días, para tener en cuenta al desarrollar la estimación y en la posterior planificación del trabajo de prueba.

Proceso de estimación y presupuesto original

Para hacerlo más comprensible, tomemos como escenario una contratación en la modalidad de proyecto de prueba, no "body shopping" y siguiendo un proceso tradicional. La estimación puede (y deseablemente debe) tomar como base, entre otras cosas:

• El Alcance, que determina la cantidad de trabajo a hacer en función a la cantidad de requerimientos funcionales y no funcionales y contextos a probar
• Los riesgos y en función de ellos, la rigurosidad de la prueba. 
• La experiencia o seniority de los perfiles requeridos en el Equipo de prueba y los del resto de los equipos de trabajo intervinientes.
• El proceso que seguirá el Desarrollador u otro equipo de trabajo, para producir los entregables objeto de la prueba.
• La calidad esperada de los entregables a recibir.
• .....

Factores que pueden alteran el presupuesto original

1. Errores propios de la estimación del Equipo de prueba

El equipo puede  introducir errores en su estimación provenientes de:

• Diferencias entre los estimadores.
• Interpretaciones equivocadas de la complejidad de las tareas, producto de la poca información disponible al momento de la estimación.
• .....

Estos desvíos no deberían incidir en más de un porcentaje relativamente bajo, 5% a 10% por ejemplo, del esfuerzo y/o calendario original, y no alterarán el presupuesto original para el Cliente. 
En otras palabras, si a este nivel nos equivocamos, lo tendremos que asumir.

2. Otras fuentes de desvíos

Los siguientes puntos, identifican otras posibles fuentes de desvíos, ya no imputables al Equipo de prueba. 
Cada uno de ellos debería figurar como un Supuesto en el propuesta, de modo que un cambio en el supuesto pueda justificar un cambio en la propuesta original.

Fuentes de Desvío	Desvío que puede generarse	Comentarios
Entregas fuera de fecha	Esfuerzo no productivo incurrido por entrega tardía por parte del Desarrollador u otro equipo de trabajo, o bien entrega de menos productos que los planificados, estando el personal de prueba ya asignado.	El Equipo de Prueba deberá tratar de utilizar estos tiempos muertos en tareas que puedan adelantarse, si bien esto no siempre es posible.
Desvíos por cambio de Alcance y/o cambio de Requerimientos	Esfuerzo y/o tiempo adicional por cambio o extensión de los requerimientos funcionales y/o no funcionales, o contextos de prueba, en cantidad y/o complejidad.
Desvíos por re-trabajo o baja calidad de los entregables	Esfuerzo y/o tiempo adicional por productos entregados al Equipo de Prueba con calidad inaceptable, o incompletos. La columna siguiente muestra los parámetros y supuestos que se pueden tomar en cuenta para la planificación y para explicitar en la propuesta.	Cantidad de entregas: -Plan desarrollado en base a una cantidad de entregas determinada. Un indicador de baja calidad es un número de entregas mayor al planificado. Parámetros de estimación: -Cantidad de entregas esperadas -Frecuencia esperada de las entregas Tiempo de estabilización: -Calculado en base a una calidad comprometida de la entrega. Una calidad más baja redunda en un mayor tiempo de estabilización. Parámetros de estimación: -Tiempos de estabilización planificados - Desvíos aceptables Cantidad de Defectos Críticos: -Defectos críticos abiertos y no corregidos, que impiden la continuidad de la prueba. Parámetro de estimación: -Cantidad de defectos críticos esperados Entrega en fecha, pero no con la calidad esperada: -Producto con fallas que extienden el tiempo entre la entrega al Equipo de Prueba y la liberación al próximo paso. Supuesto en la estimación: -Calidad del entregable recibido igual a la esperada Capacitación y seniority de los grupos de trabajo: -Se asumen equipos de trabajo de seniority equivalente; una falla en esa nivelación produce estimaciones erradas por las reiteradas devoluciones de los productos. Supuesto en la estimación: -Nivel de seniority esperado de los recursos de los distintos equipos de trabajo
Desvíos por incremento de horas de supervisión	Esfuerzo adicional debido al crecimiento no planificado de la cantidad de recursos del Equipo de Prueba, que causa aumento en la supervisión requerida.	Un líder no puede gestionar adecuadamente y en forma simultánea a más de 5 a 8 recursos. Se recomienda que en estos tamaños de equipo, ese líder no tenga tareas operativas asignadas, adicionales a la supervisión.
Desvíos por supuestos incorrectos de otros equipos de trabajo	La estimación de esfuerzo del Equipo de prueba, además de lo detallado, toma en cuenta un porcentual del esfuerzo del Desarrollador u otro equipo de trabajo como base para calcular su esfuerzo.	Una estimación errónea del esfuerzo de los desarrolladores arrastra un error también en la estimación de la prueba. Ejemplo: el esfuerzo de prueba es el 40% del esfuerzo de desarrollo.
Otros desvíos con motivo de extensiones / eventos desconocidas en la planificación original	El desplazamiento del calendario se impacta con eventos no previsibles en el momento de la planificación original.	Desplazamientos por: - Licencias del personal por vacaciones. -Requerimientos del personal por urgencias u otros proyectos. - ....

3. Conclusión

Lo anterior no pretende ser una lista exhaustiva y se recomienda seguir completándola con la experiencia de cada uno. 

Tampoco es una lista de excusas ante problemas de desplazamientos en los objetivos del proyecto que todos debemos colaborar a que se logren. Simplemente intenta explicar supuestos que solemos hacer y la diferente realidad que podemos encontrar.

Algunas de estas fuentes de desvíos podrán expresarse como riesgos, otras como supuestos,  en nuestras propuestas y compromisos de trabajo con los clientes, pero lo importante es recordarlos  al momento de tener que administrar y explicar cambios a la propuesta original.

Finalmente todo, mapa y camino, formará parte de las lecciones aprendidas para el próximo proyecto. 


Nota: Revisión del artículo originalmente publicado en excelza en marzo 2010.

¿Encajar una pieza cuadrada en un hueco redondo? El Jefe de Proyecto y la Organización no orientada a proyectos

Varios de Uds. se habrán encontrado con este tema. Yo también.

¿Es posible desarrollar una organización por proyectos, práctica de Administración por Proyecto, el rol de Jefe de Proyecto, en una Organización no orientada a proyectos?

¿La típica matriz es viable en estas organizaciones?

¿Se puede asignar responsabilidad sin dar autoridad?

Organizaciones no orientadas a proyecto

Las organizaciones funcionales típicas, no orientadas a proyecto, y presentes en gran cantidad de empresas, representan a primera vista, como explica Kerzner⁽¹⁾, un desafío para desarrollar la práctica de Administración por Proyectos y el rol del Jefe de Proyecto.

Como lo demuestran la teoría y la práctica 

• Las personas residen en las áreas funcionales que llevan adelante la producción, cada uno con una serie de tareas asignadas normalmente por especialidad.
• Los proyectos son disruptivos en esta rutina ya que reasignan los recursos hacia otras actividades.
• Si bien los proyectos implementan la estrategia de la Compañía en áreas de interés, la producción es lo que la mantiene operando y genera los ingresos del día a día. De allí podrían provenir los primeros problemas de prioridad.

¿Qué inconvenientes se presentan con los proyectos en este tipo de organizaciones?

• El ya conocido problema de los silos funcionales.
• La inexistencia de la visión de proyecto como un todo con un objetivo único, o la visión del mismo a través de los silos funcionales, con sus objetivos particulares.
• La posible demora de las tareas del proyecto en estos silos, debido a prioridades sobre los recursos, en conflicto con las tareas funcionales ⁽²⁾ . 
• Priorización del día a día sobre el calendario del proyecto (la producción tiene urgencias que no pueden esperar y el proyecto aún no las vive y se cree que las puede recuperar).

¿Qué problemas se presentan con el rol de Jefe de Proyecto?

• El rol del Jefe de Proyecto es muchas veces informal.
• Es un trabajo de tiempo compartido. Un Jefe de Proyectos administra 7 proyectos (¿son proyectos?).
• Tiene escaso o nulo control del presupuesto del proyecto. 
• Tiene poca o ninguna autoridad sobre la asignación de recursos (el típico “el equipo ya me llega armado”). 
• Tiene en general poca autoridad debido a su posición en la estructura, en muchos casos subordinada a los mismos jefes funcionales que deben asignarle las personas. 
• Los responsables de las áreas funcionales tienen poca voluntad para aceptar la autoridad del Jefe de Proyecto.

 Pero… ¿En qué casos una Organización no orientada a proyectos necesita trabajar por proyecto?

Una pregunta interesante es por qué necesitaríamos esta organización, si puede traer tantos inconvenientes.

Un buen resumen ⁽³⁾ confirmado por la práctica es el siguiente:

• Al desarrollar un tema nuevo, debe intervenir más de un área de la Organización, siendo crítico que trabajen coordinadas, por ejemplo, el rediseño de un sistema central a la empresa con nuevas tecnologías y criterios de calidad más estrictos, el desarrollo de nuevos procesos, la instalación de un ERP que cambiará la forma de operar de la Compañía, u otros casos similares. 
• Cuando hay dudas acerca de la conveniencia de una tecnología y conviene probar en un ambiente controlado (el del proyecto). 
• Cuando hay restricciones económicas o de recursos importantes para desarrollar una nueva idea, que exigen un estricto control de estas variables. 

Como vemos, estas pueden no ser tareas rutinarias en las organizaciones.

Finalmente… ¿Podremos hacer encajar las piezas?

Las siguientes ideas tratan de ayudar a aclarar algunos de estos temas, a evitar que el rol de Jefe de Proyecto esté “pintado” en la Organización y también a que se comprenda el sentido de la organización "proyecto":

• No engañarse y aceptar que no todo emprendimiento es un proyecto ni puede organizarse como tal. Llamar a algo proyecto, no lo convierte en uno.
• Tener en cuenta que la organización por proyecto puede convivir con la funcional para cierto tipo de emprendimientos, por ejemplo como los mencionados en el apartado anterior. 
• Si se encara esta organización de proyecto, formalizar los roles a través de definir su autoridad y responsabilidad, pudiendo incluirlo en el Plan de Carrera o su equivalente.
• Ubicar el rol de Jefe de Proyecto en la estructura de modo tal que acceda a los mismos niveles de decisión que los Jefes Funcionales, ya sea en forma directa o a través de un sector que los agrupe.
• Capacitar en la práctica de Administración de Proyectos.
• Comunicar, comunicar y comunicar a todos los interesados la idea de este tipo de organización, el rol del Jefe de Proyecto y la práctica de Administración de Proyectos.
• Evitar en todo lo posible la continua injerencia de los Jefes Funcionales en los trabajos del Proyecto y sobre las personas asignadas.
• Asignar la responsabilidad completa del Proyecto al Jefe de Proyecto y la correspondiente autoridad.
  
• No desperdiciar el nombre "Jefe de Proyecto", si no lo es. Hay alternativas que proponen la literatura y la experiencia que definen mejor la posición. "Coordinador de Proyectos", "Asistente de Proyectos", etc..Es muy común sobre todo en empresas y proyectos de tamaño importante una multitud de “jefes de proyecto”, algunos cuya labor es el registro administrativo de las variables del proyecto (fundamentalmente tiempo, costo y alcance) pero sin decisión sobre ellas. Es decir efectúa el seguimiento pero las actividades de control y decisión de cambios está fuera de su responsabilidad. Convendría entonces revisar los nombres para no crear confusión.

Volviendo al título, si la pieza es cuadrada y el hueco redondo, obviamente será difícil el encaje. Pero si adecuamos ambas partes, aunque no sea en forma perfecta, explicando las diferencias y mostrando resultados, seguramente lo lograremos.

Nota: Este entrada es una revisión de un artículo oportunamente publicado en nuestro blog Excelza en marzo de 2010.

Referencias

1. Project Management, H. Kerzner

2. PMBOK 4th Edition, PMI

3. Problems of Matrix Organizations, Davis and Lawrence, HBR

“Herding cats”(*)

Nuestro producto tiene gran cantidad de interesados. Muchos de ellos colaboran, mientras otros bloquean el logro de algo útil y exitoso.

La pregunta es entonces cómo los organizamos? Qué es lo que los alinea?

Pensemos en ese universo de interesados, positivos y negativos, existente alrededor de un producto de software:

Desarrolladores, Testers, Personal de mantenimiento, Operadores, Dueños de plataformas, Personal de seguridad, Gerentes de producto, Auditores externos, Auditores internos, Instructores, Evaluadores, Adquirentes, Proveedores, Competidores, Hackers / atacantes, Clientes / Usuarios / Consumidores, etc.

Son muchos. Pero uno de ellos es el Cliente, para el cual trabaja la mayoría de los otros tratando de proveerle, cada uno en su tema, una buena experiencia

con el producto^(**), o bien tratando de frustrarla.

Partiendo de satisfacer la expectativa del cliente como guía para alinearnos, debemos ir construyendo un producto de calidad.

Todos las partes interesadas verán la calidad en relación a cómo el producto, o la parte en la que el interviene, se “adecúa a su propósito” para hacer su tarea, pero sin perder de vista que la experiencia del cliente sea superior para que quede deleitado y sorprendido al utilizar el producto.

Esto nos muestra además que esa experiencia de cliente es mucho más que la usabilidad.

Por supuesto que no sólo el producto de software es lo que genera la experiencia del cliente, sino que concurren a ella todo el resto de la Organización. Pero será un eslabón importante para lograr esa calidad que genera clientes fanáticos y leales, que estarán dispuestos a pagar un precio superior en un mundo donde todo se transforma en commodity.

Tendremos entonces una herramienta para “alinear a nuestros gatos”.

------

Algunas referencias de cómo encontrar a estos interesados están en:

1.     Understanding Your Users - Courage and Baxter

2.     Mastering the Requirements Process - S. Robertson, J. Robertson

3.     BABOK® - Business Analysis Body of Knowledge®

------

^(*)Herding cats se refiere a una expresión idiomática que habla del intento de control u organización sobre una clase de entidades que son incontrolables o caóticas.

^(**) Ya que el foco de la entrada es otro y para evitar entrar en la polémica sobre UX, CX, UCD, dejo algunas definiciones de CX:

Wikipedia: Suma de todas las experiencias que un cliente tiene con un proveedor de bienes y/o servicios, mientras dure la relación con él. Desde la toma de conciencia, el descubrimiento, la atracción, la interacción, la compra, el uso, el cultivo de la relación y su recomendación.

Gartner: Percepciones y sentimientos relacionados del cliente causados por el efecto,  de única vez y acumulativo, de la interacción con los empleados del  proveedor, canales, sistemas o productos.

Sintaxis y semántica

Según la Real Academia Española, la sintaxis (que deriva del latín y del griego con significado “coordinar”), es la “parte de la gramática que enseña a coordinar y unir las palabras para formar las oraciones y expresar conceptos” o el “Conjunto de reglas que definen las secuencias correctas de los elementos de un lenguaje de programación”, y la semántica es el “Estudio del significado de los signos lingüísticos y de sus combinaciones, desde un punto de vista sincrónico o diacrónico”. Donde estudio sincrónico significa con independencia de la evolución temporal, aplica a una época dada, mientras que diacrónico considera la evolución temporal.

Similares aunque más completas definiciones y detalle, aparecen en la Wikipedia.

Entonces… ¿por qué y para qué hablamos de la sintaxis y la semántica de los datos? … ¿con qué sentido se aplica? ¿cómo afecta a la calidad de los productos que construimos?

Sin duda, en primer término afecta a la calidad porque la información que los sistemas proveen, derivan de los datos. Y la información es la que hará o no que el sistema resulte útil a clientes, consumidores, usuarios diversos.
Y porque en la actualidad, la información también es una importante base de intercambio, se provee y/o analiza, hasta se compra y se vende y desde luego, puede provenir de distintas fuentes de datos: se requerirá consistencia semántica aparte de conocer su sintaxis. Fluye y cambia en tiempo real, entre sistemas y plataformas cada día más complejos y fuera de nuestro control: se requerirá integración.

“Sintaxis” y “semántica” aparecen en el mundo de los sistemas de información y las ciencias de la computación con diversos significados o sentidos y asociadas a importantes conceptos como estructura de datos, modelos de datos, lenguajes de modelado de información, metadata,  interoperabilidad, etc.

Ambos aspectos, sintaxis y semántica, nada nuevos, juegan un importante rol en relación a las características de calidad de los datos, como las propuestas en ISO/IEC 25012 [1].

Por ejemplo:

• Ambas afectan a la exactitud (Accuracy) de los datos.
• La sintaxis de los datos, su estructura y secuencia, se relaciona también con su característica de calidad precisión (Precision).
• La semántica de los datos (diacrónica), su significado y combinación en el tiempo, se relaciona también con su actualidad (Currentness).

Entonces, vale que pensemos en la semántica y la sintaxis de los datos que manejan o almacenan nuestras aplicaciones, porque finalmente pueden resultar en colaborar en deleitar a los interesados, o en un fracaso del producto.

---
[1] ISO/IEC 25012 Software engineering — Software product Quality Requirements and Evaluation (SQuaRE) — Data quality model.

Calidad de datos – Another brick in the wall?

Es indudable que la calidad es un viaje, más que un punto determinado. A lo mencionado en otros post sobre la calidad del producto y la calidad en uso, debemos agregarle la calidad de datos.

Imaginemos por un momento el mejor software, el más rápido, seguro y de gran usabilidad, pero que no es confiable en la información que muestra o actualiza, ya sea en su valor o en su representación.

¿Lo apreciaríamos como de calidad? Seguramente no.

En ese sentido la ISO 25000, a través de su estándar 25012, hace un aporte interesante, al aplicar un criterio similar al propuesto para la calidad del software, es decir características que definan la calidad pero esta vez de los datos retenidos en el sistema.

Lo interesante de la propuesta es que esas características, 15 en total, están divididas en dos grandes categorías, aquellas que dependen de los datos en sí mismo: inherentes - valores en un dominio, relaciones entre los valores de los datos, metadatos, y aquellas dependientes del sistema – cómo son accedidos, almacenados y preservados.

Demos algunos ejemplos:

Inherentes:

Exactitud (accuracy): ¿Sirve para lo que quiero guardar?

Completitud: ¿Tiene toda la información y relaciones que necesito?

Credibilidad: ¿Podré confiar en que sus valores son verdaderos?

Actualidad (currentness): ¿Estará “fresco” o vigente cuando lo utilice?

Dependientes del sistema:

Disponibilidad: ¿Podré acceder si tengo permisos, cuando lo necesite, aún durante respaldos y a la vez que otros usuarios?

Recuperabilidad: ¿Podré volver a su estado previo luego de una falla?

Inherentes + Dependientes del sistema:

Precisión (precision): ¿Representará fielmente lo que necesito?

Trazabilidad: ¿Podré saber quién lo accede y modifica?

La calidad de los datos puede tenerse en cuenta entonces desde que estos se diseñan, durante su recolección y procesamiento, y hasta que se descartan.

El otro tema a tener en cuenta es que este modelo de calidad de los datos es transversal a los diferentes sistemas / software, preservando así la calidad a lo largo de ellos. Esto unifica y mantiene los aspectos funcionales, arquitectónicos y de usabilidad. El modelo de calidad de los datos podría ser diseñado e implementado independientemente del sistema / software que utilice esos datos.

Ampliando la pirámide entonces podríamos representarlo así:

Indicadores accionables

Indicador accionable. Qué es eso?

Pensemos en un indicador de negocio y pensemos también que su valor o tendencia indique que alguna parte de este negocio va bien o mal, traducido: estamos ganando o perdiendo dinero.

No es sencillo imaginarlo. Los indicadores financieros de alto nivel, parecen de poca utilidad, ya que su variación depende de muchas variables, entre las cuales la pieza de software es sólo una más.

Difícilmente una persona cercana al producto de software pueda concluir de este tipo de indicadores de alto nivel algún mal funcionamiento o mejora y repararlo.

Entonces?
Varias preguntas a responder, desde qué rol cumplimos nosotros respecto a la Organización y a su negocio, hasta cuál es el negocio: 

Nuestra posición: Pueden presentarse al menos dos casos bien diferenciados, y pueden darse algunas cuestiones inherentes a la Organización que se relacionan fuertemente con lograr estos indicadores accionables:
Desarrollamos software para el negocio. Podemos ser externos o internos a la Organización. 

Caso 1: Somos proveedores externos. Fabricamos  y allí terminamos nuestra intervención. Los indicadores que interesan a nuestro negocio como organización proveedora, serán los típicos de los proyectos tiempo-costos-alcance. Cumplido esto, habremos entregado un producto de calidad de acuerdo a lo especificado.

Caso 2: En el segundo caso (internos a la Organización), estamos en la segunda categoría. Estamos dentro del negocio. Somos parte integrante de él.
El negocio no necesita ser el negocio completo de la Organización; por ejemplo, en un banco el negocio del que hablamos podría ser su área de home banking y aplicarse estas ideas a ese área. En este caso valen los primeros indicadores, pero se agregan otros indicadores de éxito. Aquéllos que relacionan el comportamiento del negocio de home banking con el comportamiento del software que lo soporta.


Otras preguntas: Relacionadas con cuestiones inherentes a la Organización que se relacionan fuertemente con lograr estos indicadores accionables:

En relación al negocio: 
Puede el negocio traducir su comportamiento (si gana o pierde) en indicadores que sean accionables, es decir que se pueda tomar una acción en base a ellos?. Y que tales indicadores a su vez estén relacionados lo más cercanamente posible al producto de software?
Esta es una pregunta difícil y el tema también lo es. La relación raramente es tan directa y los indicadores dependerán de qué podemos medir para determinar ese comportamiento. Por ejemplo: conversiones de visitas en ventas de otros productos bancarios, abandonos, incidentes, motivos de quejas de clientes.
. 
En relación a la cultura de la Organización: 
Es capaz la Organización de abrir ese tipo de información (si gana o pierde como en el ejemplo anterior del home banking) a sus áreas normalmente consideradas técnicas y de servicio, o esa es información que no se difunde?.


Ejemplo de Indicadores por nivel de la pirámide.