archivo

Archivos Mensuales: marzo 2013

Se tiende a añadir más y más funcionalidades al producto, pensando que de esta forma se le estarán dando al usuario más posibilidades, sin caer en la cuenta de la relación coste/beneficio de las mismas y que llegado el momento el usuario utiliza casi siempre las mismas.

Eso en el caso de que se piense en el usuario y no en incrementar la facturación a costa de eso (que es lo que suele ocurrir: crear necesidades donde no las hay).

Las nuevas funcionalidades visten más que otras tareas a realizar en el sistema y que son mucho más importantes, como rematar bien funcionalidades que sí que resultan esenciales, mejorar el rendimiento y la usabilidad o situar la deuda técnica en unos niveles acordes a las características del sistema.

Nuevas funcionalidades sí, siempre y cuando aporten valor, pero un valor real.

Sobre este tema Mary Poppendieck opina lo siguiente: “Nuestros sistemas software contienen más funcionalidades que las que se van a utilizar jamás. Esas funcionalidades extras incrementan la complejidad del código y elevan los costes de manera no lineal. Si ni siquiera la mitad de nuestro código es innecesario, el coste del sistema con le código adicional no es el doble, es por lo menos diez veces más caro de lo que debería ser”.

Con más funcionalidades se incrementa la deuda técnica, las mismas tendrán feedback y se realizarán ajustes, habrá errores que lleguen a producción y puedan tener influencia sobre otras funcionalidades más importantes y casi lo peor de todo: nuestra atención se desvía de lo realmente importante y se centra en lo accesorio, afectando al acabado y calidad del producto final.

No rematar las tareas y arrastrar deficiencias en el producto constituyen una resistencia importante al proceso de desarrollo, afectando a la velocidad del equipo de desarrolladores y lo más importante, afectando al nivel de satisfacción de los usuarios.

Por ese motivo es fundamental que se tengan en cuenta en el proceso de desarrollo, ya sea dentro de la línea principal y/o como parte de un segundo equipo dedicado exclusivamente a resolver estos problemas, en base a las prioridades que se establezcan para las mismas.

Sobre este tema Mary Poppendieck realiza la siguiente reflexión: “La única forma de prevenir que se nos escapen defectos en el futuro es examinar los que se producen en el presente, metódicamente encontrar sus causas y, uno a uno, eliminarlos”.

El ritmo de desarrollo es muy importante, ya que condiciona la capacidad de adaptación al cambio del producto, ya sea provocado por el entorno o por las necesidades del usuario, por ese motivo, reducir la probabilidad de que se produzcan contingencias que afecten al funcionamiento continuo de la “maquinaria” resulta esencial.

El premio Nobel de medicina en 1937, el húngaro Albert Szent-Györgyi, tiene una cita que habla de descubrimiento, pero que realmente encierra tras ella, la clave de lo que resulta realmente la innovación: “El descubrimiento consiste en ver lo que todo el mundo ha visto y pensar lo que nadie más ha pensado”.

Muchas veces vemos un app nueva para dispositivos móviles, un producto software, una idea materializada que triunfa y que provoca que irremediablemente nos hagamos la pregunta de: ¿cómo es posible que no se me hubiera ocurrido a mi?.

Y es que esto funciona así, no basta solo con observar, se trata de interpretar lo que ves y tratar de llegar más allá. Es cierto que muchas veces se alcanza ese punto y lo que sucede es que no se termina materializando o se llega demasiado tarde porque ten en cuenta que no eres, ni mucho menos, el único gallo de este corral.

El esfuerzo denota intención, ganas, el deseo por mejorar y querer conseguir unos objetivos y como tal se debe valorar.

Desgraciadamente, cuanto más lejos está la gestión de las trincheras, más borroso se hace el trabajo que hace cada uno y se confunde la gente que se esfuerza y los que se esfuerzan por aparentar que se esfuerzan.

El efecto desmotivador que tiene esto es devastador.

Sin embargo, al final de todo están los resultados. Deming realizó una reflexión demoledora sobre esto: “Estamos siendo arruinados por los mejores esfuerzos”, viniendo a decir que los resultados son los verdaderos jueces de todo esto.

Como decía antes, el esfuerzo se debe valorar pero tarde o temprano tendrás que conseguir resultados. El esfuerzo te dará más cuerda, pero nada más.

Con esfuerzo la recompensa llegará, tal vez no ahora, tal vez no en este proyecto o en esta organización, pero llegará. Para ello, tendrás que asumir la derrota pese a haberte dejado la piel, aprender de los errores (si no es imposible), volverte a levantar y seguir intentándolo con esa actitud.

“Vamos a implantar un servicio para el aseguramiento de calidad de los productos software”.

Interesante slogan comercial que normalmente se traduce en un mayor coste en los productos software que se desarrollan y en la implantación de la infraestructura necesaria (personas y equipamiento) que estará por encima de los beneficios reales sobre el conjunto de productos software y sobre la organización.

Los lectores habituales del blog sabrán que soy un defensor a ultranza de los testers y de las tareas de testing en general y cada día que pasa lo soy más.

¿Qué no defiendo? Los slóganes vacíos como el que pone el punto de inicio de este artículo. Quienes hablan de asegurar o certificar la calidad del software no lo están haciendo desde una base real porque entre otras cosas lo hacen si conocer a priori cuáles son los umbrales de calidad definidos en la organización ni tampoco los que existen para cada proyecto concreto, lo que vendrá a significar, muy probablemente que el aseguramiento de la calidad lo pretenden conseguir a través de la implantación de procesos en todo lo que rodea al desarrollo del software porque entienden que lo importante realmente es el proceso y que eso puede con todo.

Me parece mucho más real hablar de servicios que pretenden mejorar la calidad de los productos software y del control que la organización tienen sobre el código fuente, librerías dependientes, etc…, así como de determinados entregables documentales que de asegurar la calidad.

Asunto muy controvertido. Por un lado se encuentra el hecho de tener a las personas el mayor porcentaje posible de su tiempo asignado a tareas facturables y por otro la certeza de que una persona que tiene su cabeza en muchos proyectos tiene su enfoque dividido y eso afecta a su rendimiento.

Estar en un 20% en un proyecto, un 5% en otro, un 50% en otro, un 10% en otro y un 15% en otro, no es ninguna exageración, incluso puedo quedarme hasta corto. Quien se haya encontrado o se encuentre en esta situación o quien dependa de personas que se encuentran en la misma sabrán lo que eso significa: el porcentaje final en cada proyecto será probablemente superior al asignado (lo que implicará overtime) y con un rendimiento en términos generales probablemente inferior al porcentaje final (y en consecuencia también inferior al asignado oficialmente).

Y eso si intentas equilibrar tu esfuerzo, si por las circunstancias terminas dedicando más esfuerzo a uno de esos proyectos que a los otros, vistes uno pero dejas sin nada al resto.

Cada cual sabe cuáles son sus límites pero en ningún caso se llegará a infinito y cuando son tantos los proyectos a los que estás asignado y menor es el porcentaje que puedes dedicar a los mismos más te estarás acercando al mismo.

Es complicado alcanzar el equilibrio entre ocupación máxima a nivel de facturación y asignación óptima a proyectos para que la productividad no se vea resentida (o muy poco resentida) pero el hecho de que sea difícil no quiere decir que no deba ser un objetivo.

Mary Poppendieck y Tom Poppendieck realizan la siguiente reflexión sobre este tema (traducción libre): “La asignación de personas a múltiples proyectos es una fuente de pérdidas. Cada vez que los desarrolladores de software cambian entre tareas, se pierde un tiempo significativo en volver a alinear los pensamientos y entrar en el flujo de la nueva tarea”.

“Tenemos todos nuestros procesos perfectamente especificados y detallados, en los que incluso se describen casos de uso para que sea más fácil de entender su aplicación en circunstancias reales, por tanto, si se siguen de manera adecuada el proyecto será un éxito y además la organización podrá obtener del mismo información que favorezca la mejora continua del mismo proceso de desarrollo de software”.

Como slogan publicitario viste bien, pero realmente lo importante no es lo bien que esté detallado el proceso sino que realmente sirva para algo. Los procesos no se deben medir por su peso sino por su calidad.

En el mundo del desarrollo de software cuando tenemos procesos de esas características generalmente no suelen ser buenos porque su rigidez impide ser ágil o, viéndolo de otra manera, lo que es lo mismo serían buenos en un contexto estable y para proyectos que tengan una serie de elementos repetibles.

Insisto, no es un asunto de procesos sí o procesos no, sino de que los que hayan realmente aporten y no supongan un freno real a los proyectos.