lunes, 8 de abril de 2013

¿Qué es la productividad del software?

Conflictos

Si se quiere medir la productividad del software, hay que definir claramente qué es la productividad y medir lo definido. Empresas de servicios y clientes de las empresas de servicios pueden tener una perspectiva distinta y llegar a conflictos que podrían evitarse. 

He estado en el mundo de la Informática durante 40 años (empecé muy joven). Desde el comienzo ya había cierta preocupación por medir la “productividad” del desarrollo, y 40 años después sigue habiéndola.

Si he aprendido algo en estos años es que la mayor causa de problemas, en la Informática y fuera de ella, cuando hay personas que hablan con otras personas, es el lenguaje *.  ¿Qué significa “productividad? La RAE da una definición aparentemente clara: “Relación entre lo producido y los medios empleados, tales como mano de obra, materiales, energía, etc.” Esta es la definición habitual en el mundo del desarrollo y de las empresas de servicio, y entre sus clientes, pero una vez más hay un problema de significado: ¿Qué es “lo producido”?  

Las empresas u organismos de desarrollo piensan que “lo producido” es el sistema construido, mientras que los clientes de esas empresas u organismos suelen pensar que “lo producido” es el beneficio conseguido por medio del uso del sistema construido, medido, tal vez como aumento de ventas y reducción de costes, de plazos o de riesgos.

Y esto sí que es una diferencia crucial de perspectiva. Mientras los fabricantes de coches pueden considerar que “lo producido” es un vehículo, quienes compran un coche consideran que “lo producido” es “la capacidad de transportar personas o mercancías y generar unos ingresos determinados, con fiabilidad y costes de explotación razonables”, o “la satisfacción de unas necesidades o deseos propios concretos, si se va a usar para un fin no comercial”. La imagen de “lo producido” no es el vehículo en sí, sino la cuenta de resultados obtenida explotando ese vehículo o la satisfacción conseguida con su uso.

Por mucho que se afanen las personas de desarrollo y por muy bien construido que esté el sistema –cumple rigurosamente todas sus especificaciones y satisface los requisitos aceptados–, es inútil si no se usa (o no se vende), por lo que medir la productividad considerando que el sistema es el fin último de la fabricación del software, y no tener en cuenta el uso que se hará de ese sistema es no tener en cuenta los porqués de lo que se está haciendo. Esto no es extraño: este enfoque parcial es habitual en todos los ámbitos humanos, desde la gestión de la propia vida (por ejemplo, confundir tener con ser)  hasta la de empresas –incluidas las multinacionales que forman parte de la tecnoestructura-,  gobiernos enteros y sus asociaciones.

En el desarrollo de software todo el mundo se preocupa por definir y medir la productividad en la construcción de sistemas (expresada con términos como coste unitario y tablas de tiempos de desarrollo), y es necesaria, porque los clientes suelen medirla y perseguirla con rigor extremo, pero muy poca gente se preocupa de medir la productividad, entendida como rentabilidad o satisfacción, con todos sus componentes (económico, reducción de riesgo, mejora de la calidad, etc), del uso de los sistemas.

La medición habitual de la productividad en el desarrollo debe completarse con la medición de su beneficio por medio de su uso, porque en el uso inapropiado, o lo que es lo mismo, en la construcción de sistemas inapropiados, se genera el despilfarro de cantidades ingentes de dinero en sistemas que no llegan a terminarse o, aunque estén terminados e implantados, nadie usa: No hay que buscar mucho en la prensa para encontrar noticias de proyectos con coste de decenas o cientos de millones que acaban por convertirse en nada más que la propia noticia y, a veces, en sonados juicios por reclamaciones de daños o incumplimiento de contrato.

Un sistema de medición de la productividad debería siempre medir las dos partes de la ecuación: el valor que genera “lo producido”  para los clientes –y ésta es la parte más importante– y el coste y plazo de la producción. La escritura de casos de negocio para definir claramente y justificar los sistemas, y la construcción de mecanismos de medición –real, no “estimada” o inventada– del beneficio producido es la asignatura pendiente de este sector.

Por poner un símil, pensemos en un edificio que va a servir como hotel. Por supuesto que alguien debe preocuparse por el coste de construcción del hotel, pero más aún, alguien se debe preocupar por la rentabilidad obtenida explotando ese hotel, que determinará características esenciales de la arquitectura y el diseño. Quien, construyendo edificios, considere que su preocupación debe centrarse sólo sobre el coste, los plazos y la calidad interna de la construcción, olvide tener en cuenta el uso del edificio y no ayude desde el principio a la definición, medición y logro del beneficio de la explotación de ese hotel, se encontrará que, año tras año, tendrá más dificultades para poder cobrar un precio justo o razonable por lo que produce.

La especificación de un sistema debe contener la definición del sistema de medición del beneficio de su uso, no sólo la definición del comportamiento del sistema.  En estos tiempos, esta afirmación, más que importante es vital. No quiere esto decir que mida cómo evoluciona el negocio por todos los factores participantes, sino cómo evoluciona el negocio por el factor “uso del sistema construido”.

La norma ISO/IEC 38500, que formula el principio de “Desempeño” (Performance), ayuda a tener claro, desde el principio de las actividades de desarrollo, que el objetivo no es el sistema en sí, sino el efecto que ese sistema va a producir sobre la empresa que lo usará. 
En mis años de experiencia siempre he visto implantados y ejecutados mecanismos rigurosos de control y medición del avance de la construcción de sistemas, de sus presupuestos y calendarios, pero muy pocas veces he visto que ni el sistema producido ni el procedimiento de control de desarrollo llevara dentro mecanismos para controlar y medir el cumplimiento de los objetivos explícitos del negocio, para lograr los cuales se construye el sistema, durante y una vez concluido el desarrollo de ese sistema.

Si todo sistema que se construye lleva escrito el caso de negocio –que justifica los gastos de construcción y explotación de un sistema gracias a los beneficios que producirá- permite empezar a pensar en ese sistema como un beneficio, en vez de como un coste. Si el propio sistema permite ir comprobando que se cumple el caso de negocio, mejor aun comenzando con  pequeños prototipos, permitirá también ordenar la demanda y hará recaer la responsabilidad de las decisiones sobre quienes las toman,- a veces con escasa o ninguna perspectiva, no, como casi siempre, sobre las personas o empresas de desarrollo.

Si las personas que construyen sistemas ayudaran a los clientes a definir e implantar mecanismos de medición del beneficio, ayudarían, y mucho, a reducir el despilfarro de este sector y a mejorar su eficacia y su eficiencia.

Por ahí se debe mejorar: por prestar más atención al fin último (el uso del sistema) y pensar que ése es el modo de demostrar la productividad del software a los clientes. Es la cara de la moneda. Medir la productividad desde el punto de vista interno de la construcción, es la cruz. Toda moneda debe tener ambas. Es difícil, o imposible, hablar de productividad con los clientes, si no se mide, gestiona y comunica la cara de la moneda, y sólo se presta atención a la cruz.  Por el contrario, es imposible ser competitivo en calidad interna, precio y costes si se olvida la cruz.

Ya sé que alguien dirá que es imposible medir algo –el uso que se da a los sistemas– que se escapa de la propia actividad –la construcción de sistemas o de algunas de sus partes– pero es lo que lleva haciendo la industria y el comercio desde hace siglos: además de medir cuánto y a qué coste producen, comprueban e incluso se anticipan a la satisfacción de los clientes, así que tal vez tengamos ahí el modelo a seguir.

--------------------------
* Recomiendo a todo profesional de la TI la lectura profunda y la comprensión del libro: Language in Thought and Action, 5th edition, de S.I. Hayakawa y otros.

3 comentarios:

  1. Frente a ello ¿Qué hacer?...

    Hace ya tiempo decidí no vender software, sino lo producido por mi software.

    Por ejemplo, si un cliente quiere un sistema de control estadístico se lo hago, pero no le vendo el software le vendo los informes producidos.

    Por lo que ya casi no desarrollo para otros, lo hago fundamentalmente para mi y vendo los servicios que mi buen software produce.

    Esto tiene varias ventajas:

    1) No se discute por el precio del kilo de software, se valoran productos más tangibles.

    2) La reducción de costes en desarrollo es del 90%, no hay que desarrollar sistemas resistentes a usuarios torpes, ni hay que hacer manuales, ni interfaces que se mueven con el dedete, ni que corra en varios sistemas operativos, ni bonitos, etc.

    3) La pirateria es nula, nadie tiene el software, solo sus resultados.

    Me preguntan: ¿Cómo puedes ser tan productivo dando servicios? La respuesta verdadera pocos la entienden, tengo mucho software que trabaja para mi.

    Algunos cuando ven mi software me dicen: Este softwares es muy útil ¿Por qué no lo vendes? La respuesta es no, ya que es mi ventaja competitiva.

    Espero que os guste mi contribución.

    A. Salmerón, PhD, MBA
    edicionesaContracorriente.com

    ResponderEliminar
    Respuestas
    1. Esto es lo que nos hace falta: gente con ideas claras y espíritu para explotar esas ideas, sobre todo teniendo en cuanta la tendencia que siguen los precios que se quiere imponer a las consultoras y empresas de servicios. Una gran TELCO europea alardea de ofrecer 23 euros por hora de consultor, a las grandes empresas de consultoría. ¿Cuánto cobra el consultor, que suele o debe ser titulado superior?
      Parece claro que A. Salmerón va por el buen camino.

      Eliminar
  2. No es lo mismo la productividad del SW que la productividad del desarrollo de SW.

    Entiendo que cuanto más cerca nos movamos del beneficio, mejor se resuelve el negocio. Y que en muchos casos es posible dar el paso.

    Pero el problema de medir la productividad de los desarrollos no desaparece por cambiar de puesto en la empresa (o la empresa de mercado). Solo cambia la persona a quien le cae el marrón.

    ResponderEliminar

Related Posts Plugin for WordPress, Blogger...