Desarrollo de software a "suma alzada" o "llave en mano"

Desarrollo de software a "suma alzada" o "llave en mano"

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.