En el sector de Gobierno, hemos visto frecuentemente que la mayoría de los proyectos de desarrollo de software son bajo la modalidad de "suma alzada" o "llave en mano". Este es un buen método para conocer el precio final a pagar, y sólo se debería utilizar cuando las especificaciones del requerimiento están sumamente detalladas. Por eso, se utiliza siempre industrias como la Construcción, Minería, etc.

Sin embargo, también existe varias desventajas con este formato. Sobre todo en la industria de desarrollo de Software. Entre ellas:

• El incentivo para el proveedor es desarrollar la funcionalidad al menor costo posible. No hay incentivo a desarrollar una funcionalidad de buena calidad. Si mayor calidad implica mayor tiempo de desarrollo, entonces definitivamente el proveedor privilegiará desarrollar minimizando su tiempo de desarrollo.
• Es más dificil o complejor incluir la revisión "cruzada" (o code review). Si la funcionalidad hace lo que se especifica en el requerimiento, entonces no importa que el código esté desordenado y poco claro. (A no ser que en el requerimiento se especifique claramente las guías y estándares de desarrollo.).
• La documentación típicamente será muy simple y reducida. ¿Como se puede especificar en un documento de requerimientos que se requiere documentación completa y de alta calidad ?

Desarrollo de software... ¿un arte?

El desarrollo de software debe ser considerado más como un Arte. Usted puede levantar un requerimiento sumamente detallado de que desea una pieza de arte similar a un Van Gogh o Picasso. Puede especificar el escenario ideal, colores de preferencia, estilo de dibujo, etc, con el máximo de detalle.

Luego, deberá considerar unos buenos criterios de selección, ya que de lo contrario, el proveedor que oferte al menor costo se ganará el proceso de licitación. Y sabemos muy bien que la calidad es muy distinta según la experiencia y conocimientos del artista. Hasta un niño podría hacer un cuadro siguiendo las especificaciones.

Es por eso, y los motivos previamente descritos, que si lo que se desea es construir un software con una alta calida de diseño, lógica y arquitectura, lo mejor será trabajar en un formato de pago por horas.  

Le propongo al lector que hagamos el siguiente ejercicio práctico y liberemos nuestra imaginación  —hay que ser creativos, ¿no?—.

Requerimiento Presidencial

El presidente de la república ha solicitado una pintura de arte de su equipo ministerial. El mismo presidente señaló que el cuadro debe ser excepcional, ya que será puesto en unos de los pasillos del palacio de la moneda. Sencillamente no puede ser un trabajo mediocre, sino que debe apuntar a lo más alto.

Obviamente no se puede hacer un trato directo como nos gustaría, ya que nos rige la ley de compras públicas, y, por lo tanto, estamos obligados a realizar un proceso de licitación pública —al menos, me parece que el servicio no califica dentro de las causales para un trato directo—. Con una licitación pública, todos los pintores —proveedores— del país estarán invitados a participar en un proceso abierto y transparente. Excelente, sigamos.

Desde el punto de vista del comprador, la licitación debe incluir una serie de elementos como criterios de selección, estado de avance, entregables, forma de pago, multas y un serie de condiciones contractuales para prevenir un escenario adverso. Respecto de los requerimientos técnicos mínimos, éstos podrían ser:

• Licenciatura en diseño, arte o similar.
• Al menos 5 años de experiencia demostrable.

Respecto de los criterios de selección, se me ocurre algo así —más bien es lo que típicamente se utiliza en proyectos de desarrollo de software—:

• (40%) Experiencia.
• (30%) Plazo de entrega ofertado.
• (30%) Precio ofertado.

¿Tiene sentido pedir título profesional? Quizás sí, pero con ello también podríamos excluir a grandes pintores que no tienen título.

Respecto de la experiencia, ¿cómo la medimos?, ¿según años de trabajo?, ¿por cantidad de exposiciones?, ¿por número de obras de arte realizadas?, ¿por monto de facturación a clientes? ... Nadie dijo que sería sencillo este proceso.

Por el plazo de entrega, ¿tiene sentido premiar al pintor que entrega el producto antes ? ¿en 1 día? La verdad es que no tengo la menor idea cuanto se demora un gran artista en terminar un trabajo. Imagino que algo dependerá el tamaño del cuadro, pero nada más.

En cuanto al precio, ¿tiene sentido calificar mejor a la oferta más económica? Pensando en el mejor uso de los recursos públicos, imagino que sí.

Bueno, todas estas ideas se asemejan bastante al área de desarrollo de software. Si bien puede sonar un poco ridículo, es lo que realmente sucede con muchas de las licitaciones de software. En muchas de ellas se adjudica al proveedor más económico y al que entregue antes. ¿Se imaginan la calidad de esos productos?

Quizás la mayor diferencia es en cuanto a la utilidad o funcionalidad del producto entregado. En el caso del software podemos fácilmente validar que cumpla el objetivo por el cual fue solicitado, mientras que para un cuadro de arte no imagino como validar su función u utilidad. Pero a diferencia del arte, validar la funcionalidad de una aplicación de software es una prueba limitada e imprecisa. La mayoría de los productos de tecnología nunca finalizan, y están continuamente adaptándose a los nuevos desafíos. ¿Acaso Amazon ya dejó de desarrollar? Claro que no, lo llevan haciendo por más de 30 años, y seguirán haciéndolo por muchos años más. Por lo tanto, una correcta evaluación debe incluir otras dimensiones como escalabilidad, seguridad, confiabilidad y mantenibilidad, —entre otras—.

Por otra parte, desde el punto de vista del proveedor, también es un desafío poder participar de este negocio. Cabe recordar que el incentivo para cualquier proveedor es maximizar su beneficio propio —exposición, rentabilidad, etc—. Ahora bien, la incertidumbre de este proceso implica riesgos para el proveedor.

Para hacer más compleja la historia, pensemos que el desarrollo de la pintura fue adjudicada al pintor Juan Pérez. La pintura se hizo y se entregó según los plazos establecidos. El cuadro cumple con lo especificado en las bases técnicas de la licitación. El presidente, o la figura de lo que parece ser el presidente, está representado en el centro del cuadro. ¿Cómo sabemos si la calidad del cuadro es buena o mala? ¿No será necesario que una contraparte técnica externa evalúe el trabajo? Así, tendremos una opinión válida de un pintor externo que sustente el trabajo realizado. Con el software pasa algo similar. Las mejores prácticas de un buen proceso de desarrollo de software incluye una revisión cruzada entre pares o profesionales de la misma especialidad.

Ahora bien, continuando con nuestro proyecto de arte, pasado el tiempo se nos solicita realizar unas pequeñas modificaciones al cuadro. Faltó un pequeño detalle que ahora necesitamos incorporar —alguien olvidó mencionar en el requerimiento inicial que la pintura debía incluir la bandera de Chile en el fondo—. Entonces debemos realizar un nuevo proceso del licitación ya que no es factible realizar un trato directo con el proveedor adjudicado del primer proceso. Esta vez sin embargo, el proceso de licitación se adjudicó a un proveedor (pintor) distinto, quién será responsable de incluir la bandera chilena en la obra de arte.

Mmm... Esto último me suena conocido. Lo he visto no una, sino varias veces. Distintos proveedores de desarrollo de software se deben hacer cargo del mismo proyecto en tiempos distintos. En particular recuerdo un proyecto en PHP sobre el framework Zend que en 5 años tuvo 7 proveedores distintos. ¿Se imaginan como es la calidad del código? ¿Qué incentivo tienen el séptimo proveedor para mejorar la calidad de la aplicación si más adelante ya no será responsable, sino que posiblemente habrá un nuevo proveedor? Mal.

Además este sin fin de proveedores abre la puerta para las típicas excusas del tipo “el anterior proveedor era inexperto y dejó la embarrada”. Y no sólo eso, sino que a medida que acumula errores y deuda técnica, se hace más difícil de mantener y soportar, lo que termina aumentando los costos de desarrollo y soporte. Se transforma en un proyecto cacho.

Si bien toda esta historia parece muy alejada de la realidad, puede que no sea tanto. Podríamos asimilar varios aspectos de esta historia a los mismos desafíos en el desarrollo de software.

• Es difícil evaluar y comparar la calidad entre distintos desarrolladores de software. Muchas veces el título, o los años de experiencia no son representativos del nivel profesional del individuo.
• No es fácil medir o controlar la calidad de un desarrollo tecnológico. Un sistema puede funcionar bien por “fuera”, pero también es necesario revisarlo “por dentro”. ¿Sobre qué fue construido? ¿Que diseño consideró? Muchos problemas de software se conocen con el tiempo, cuando escalan —se saturan— o cuando se deben implementar nuevas funcionalidades.
• Es complejo mantener y soportar un servicio o aplicación cuando distintos proveedores intervienen el código. Cada uno tienen sus propios estándares, experiencia y calidad de profesionales.
• El desarrollo de software no sólo está enfocado en algo puramente funcional, sino también debe ser atractivo, simple y fácil de usar. El software debe ser un aporte para el usuario final.

Gracias por leer ! :-)