Por qué la gente piensa que las Agencias apestan

Todos conocemos esas historias de terror sobre Agencias de Software. Agencias que entregan software defectuoso. Software que no se entregó en el plazo dicho. O gastos que fueron mucho mayores de lo esperado.

¿Pero cuál es el problema real? Normalmente es una combinación de mala comunicación, falta de reporting, riesgos imprevistos y tareas que no se han contabilizado.

Entonces, ¿cómo construimos mejor software, manteniendo los costes bajos? (outcome soñado)

El Cuadrángulo del Diablo

Echemos un vistazo al llamado Cuadrángulo del Diablo.

Quizás hayas oído del Triángulo Mágico. El Triángulo Mágico consiste en tres restricciones de proyecto: Tiempo, Coste y Scope. Estas restricciones necesitan equilibrarse entre sí para entregar un proyecto. Cambiar una de ellas impactará a las otras dos.

Harry Sneed, un profesor de Ingeniería de Software, ha extendido este modelo con una cuarta restricción "Calidad". Esta versión extendida se conoce normalmente como el Cuadrángulo del Diablo de Gestión de Proyecto o el Cuadrángulo del Diablo de Sneed. Separa la calidad del Scope, que ahora se enfoca únicamente en el contenido del scope y no en la calidad de la entrega del scope.

Pensémoslo. Si queremos tener software entregado en una cantidad de tiempo muy corta, probablemente necesitemos contratar muchos más desarrolladores, posiblemente reducir el scope e incluso sacrificar calidad del software.

Enfocarse en los gastos de desarrollar software resulta en menor calidad del software, scope más ajustado y velocidad de entrega más lenta.

Igualmente, enfocarse en calidad gastando más, teniendo un scope más ajustado y muy probablemente un launch de proyecto retrasado. Y tienes que lidiar con costes de desarrollo de software mucho mayores al optimizar para calidad, scope y velocidad de entrega (ver figura).

Una de las muchas razones por las que las Agencias de Software tienen mala reputación es la desalineación de expectativas. Asegúrate siempre de establecer expectativas realistas y elegir los trade-offs que estás dispuesto a hacer.

"Rápido, Barato o Bueno. Solo puedes elegir dos."

Coste de la Calidad

Otra gran forma de mostrar esto es el gráfico de abajo.

Cuanto más tiempo gaste tu equipo testeando y optimizando el software, menos defectos tendrá. Como consecuencia los costes de prevención serán más altos. Como tales, los costes de prevención son exponenciales. Esto significa que cuanto más estable quieras que sea tu software, exponencialmente más tiempo tienen que gastar tus desarrolladores testeando y optimizando.

Si tu software se usa en aviones por ejemplo, definitivamente no puedes arriesgar ningún error, por esa razón quizás quieras invertir mucho más tiempo en prevención. Lo mismo aplica a aplicaciones en Web3 ya que normalmente estás tratando con grandes cantidades de fondos de clientes. Dependiendo de dónde se use tu software, querrás estar en algún lugar de esa curva, normalmente dentro del rango operacional.

Cambiemos a costes de fallo. Cuantos más errores ocurran en producción, más hay que compensar. Esto puede ser daño a tu marca, deuda técnica, overhead adicional de mantenimiento o daño monetario real por gente demandándote por ejemplo.

Como consecuencia normalmente quieres simplemente gastar lo suficiente en prevención para tener costes de fallo razonables. Esto se llama el equilibrio económico.

¿Y los Riesgos?

Hacer cualquier cosa en la vida viene con riesgos. Cosas de las que somos conscientes y riesgos que reconocemos cuando ya es demasiado tarde.

Desafortunadamente, también tenemos que lidiar con eso en el Desarrollo de Software. Como consecuencia los riesgos de proyecto pueden poner presión significativa sobre cualquier presupuesto de proyecto. Echemos un vistazo rápido.

Cada presupuesto de proyecto debería estructurarse en tres buckets. Estimates de paquetes de trabajo (features, cosas que quieres construir), Reservas de contingencia (trabajo que necesita hacerse si ocurre algún escenario peor identificado) y Reservas de gestión (un presupuesto plano que esperemos cubra todos los escenarios peor imprevistos y que realmente ocurran). Contabilizar riesgos reduce significativamente el riesgo general del proyecto ya que hay un presupuesto claro asignado para resolver el problema.

Ver también: la mayoría de disfunción de agencia viene de incentivos desalineados. Nuestro modelo Fractional CTO Austria arregla eso alineando a un CTO senior directamente con tus outcomes, sobre un Werkvertrag (contrato de obra) en lugar de un treadmill de horas facturables.