El tamaño importa

He leído recientemente en algún blog, sobre la forma adecuada de medir el tamaño del software, y que ésta, debe ser contraria a la que se usa en construcción de casas.

Vaya con la maldita manía de que como se supone que el software y las casas son distintos (según algunos, radicalmente opuestos), pues las formas de trabajar, medir, etc, deben serlo también. Esto ya es incluso un caldo de cultivo para los defensores del "agilismo porque sí", ya que como una casa se hace por fases, y esto se asimila a un método de desarrollo en cascada, está claro que eso es algo obsoleto y por tanto, la forma de trabajar en el software ha de ser distinta. Interesante, pero absurda conclusión.

Para medir el tamaño del software, podremos usar Puntos Función (PF), o cualquier otra medida. En la construcción de casas, esa medida no es válida, claro está.

Tambien se suele afirmar que en la construcción de software, la unidad de medida habitual sigue siendo en esfuerzo: se paga por la cantidad de esfuerzo empleado en lugar de por lo efectivamente producido (valor). Aquí sí que tienen ventaja las metodologías ágiles, ya que se centran en el valor incorporado en cada iteración.

Creo que tenemos un problema. Somos nosotros, los desarrolladores, los que pretendemos que nos paguen por esfuerzo. No es que sea la medida habitual: es lo que habitualmente pretendemos. Los clientes no quieren saber si nos costó 1000 ó 1050 horas hacer su programa de facturación, o su sistema de control de fábrica. El cliente quiere saber lo que realmente necesita para su negocio que es:

• Fecha: ¿Cuándo estará el software disponible? ¿Cuándo podrá integrarlo con otros productos? ¿Cuándo tendrá que tener lista la formación para su personal? ¿Cuándo tienen que estar disponibles los responsables de sistemas para su puesta en marcha? ¿Llegará el producto a tiempo para hacer lo que tiene comprometido por contrato en una fecha concreta?
• Coste: ¿Cuánto dinero va a costar? ¿Se puede pagar a plazos? Los clientes no tienen un baúl como en los dibujos animados lleno de dinero. El dinero en las empresas, no suele estar disponible en todo momento. Depende de la facturación, de si toca o no pagar impuestos, etc. Muchas empresas necesitan pedir un préstamo para acometer pagos, incluso los previstos.
• Calidad: ¿se cumplirán las necesidades y requisitos establecidos? ¿estarán todas las normas obligatorias recogidas? ¿Hay criterios de calidad adicionales que aporten valor (usabilidad, etc)?

Si os fijáis, estos factores son significativos. El negocio del cliente es directamente dependiente de estos factores. Un pequeño cambio en cualquiera de los tres, y podemos hacer que la empresa del cliente se arruine, y sus trabajadores acaben en la calle. Y esto sirve para todo, no solo para el software.

El coste, por otro lado, estará marcado por el mercado. Habrá productos, que si no sabemos desarrollarlos por un coste inferior al precio de mercado, tendremos un problema. Aquí está la clave: ser competitivos.

¿Entonces porqué esa manía de medir el software en esfuerzo? Pues porque es lo único que nos importa, en un entorno todavía inmaduro que parece no querer ver más allá y no involucrarse en satisfacer al cliente.

Se está huyendo de dos premisas, muy integradas culturalmente en otros sectores, pero que parece que en el software nos negamos a asimilar:

• Compromiso. Los acuerdos se hacen mediante contratos. Y los contratos están para cumplirlos.
• Disciplina/Ingeniería: debemos tener las herramientas y procesos adecuados para estimar y reestimar progresivamente si vamos a terminar en fecha y con el coste pactado. Y por supuesto, con la calidad pactada como mínimo.

Se oye hablar de que las casas se venden por metro cuadrado, y que esto no es válido para el software, ya que las casas siguen un método industrial (supuestamente radicalmente diferente del desarrollo software). De nuevo, otra falacia interesada.

Las casas, si se fabrican iguales, costarán un precio similar. El problema no es el método, sino que los materiales, mano de obra, etc., están muy estandarizados en la construcción de casas. Pero siempre existirán casas hechas a medida, con piezas no estándar, y que costarán un ojo de la cara (es decir, su precio por metro cuadrado, se dispara). De todas formas, si nos fijamos en las casas estándar normales...¿habéis comprado alguna casa? ¿Os habéis fijado que en mismo edificio de casas, donde dos de ellas supuestamente deberían ser iguales...no han salido igual? ¿Verdad que todas las casas no salen con los mismos fallos? ¿Verdad que si medís los metros cuadrados de todas las viviendas...ninguna cumple exactamente con lo que dicen los planos?

Por tanto, llegamos a la conclusión de que las casas no son iguales, no se construyen iguales (sencillamente porque es imposible), y se requiere una ingeniería detrás para poder conocer cuándo podrán estar terminadas, y cuánto dinero van a costar. Eso se hace con planificación y gestión. ¿Por qué no hacemos lo mismo con el software? ¿Porqué seguimos renegando de los métodos de ingeniería, pero no estamos dispuestos a que dejen de llamarnos ingenieros?