20 razones por las que fallan los

proyectos de software
 José Luis Becerra Pozas

Desde expectativas desmesuradas hasta cambios de características

fundamentales, los proyectos de desarrollo de software se descarrilan
o fallan debido a una variedad de factores técnicos y de gestión de
proyectos. Revisemos una veintena de ellos.

Todo proyecto de software comienza con grandes sueños y grandes visiones. En

algún lugar de un universo alternativo, hay un proyecto que cumple todos los
sueños, pero con demasiada frecuencia los proyectos de software en nuestro
universo tropiezan hacia la línea de meta y, a veces, la cruzan. 

Por supuesto, por definición, el fracaso de un proyecto de software no es algo

binario. Puede terminar con un código que se ejecuta bien, pero que nadie usa. O
puede terminar con un código que ni siquiera se compilará. A veces se puede
rescatar algo útil de los restos en llamas y, a veces, es mejor huir antes de que
explote.
Cuando el desorden humeante se enfría, comienzan las autopsias, ya que la gente
quiere saber qué salió mal. Estos que describo a continuación son los “culpables”
más comunes:

Muy pocos miembros del equipo

Tratar de hacer demasiado con muy pocos programadores es un problema
común. Los desarrolladores sólo pueden eliminar una cantidad determinada de
código antes de que se agoten. Una vez trabajé en un equipo donde el gerente
pensó que la forma correcta de exprimir más trabajo a los equipos ágiles es
programar cada “sprint” para que comenzara inmediatamente después del
anterior. Sin pausas para pensar qué funcionaba y qué no. El Sprint 42 terminó el
miércoles a la 1:59 pm y el Sprint 43 comenzó el miércoles a las 2:00 pm. Se
programaron reuniones de análisis retrospectivo después de que comenzara el
siguiente sprint. Un tipo inteligente sugirió que se rebautizaran como “maratones” y
pronto encontró otro trabajo.

Por supuesto, es difícil saber cuántos programadores son suficientes. A veces, los
obstáculos y los problemas se interponen en el camino. Puede que no sea culpa
del gerente que el trabajo duplique su tamaño, pero si no tiene suficientes
personas en el trabajo, es probable que su proyecto esté condenado al fracaso.

Demasiados miembros del equipo

Si muy pocos programadores pueden ser malos, muchos podrían ser peores, ya
que los efectos de red pueden arruinar un proyecto de software. Más gente
significa más coordinación y eso significa más reuniones, lo que le quita tiempo a
la escritura de código. Pero si no tiene suficientes reuniones, pronto descubrirá
que la API del equipo A no interactúa con los microservicios del equipo B.

Sería bueno si pudiéramos gastar dinero en un problema mediante el exceso de

personal en un proyecto, pero usted no puede.

Demasiada comunicación
El software de escritura es un arte solitario. Los humanos pueden trabajar juntos,
pero sólo en episodios limitados. Muchos desarrolladores odian las reuniones
porque necesitan cambiar sus engranajes mentales del pensamiento lógico
inmersivo profundo al modo social más abierto. Esto lleva tiempo. Algunos líderes
de equipo intentan combatir el fracaso celebrando más reuniones para mantener a
todos sincronizados. Es un esfuerzo noble, pero se oye rechinar los engranajes. El
equipo necesita compartir suficiente información para mantenerse sincronizado,
pero más solo desperdicia los ciclos cerebrales.

Cambios de características fundamentales

En teoría, a los desarrolladores les gusta considerarse ágiles. Por eso abrazan la
palabra. Pero a veces la agilidad puede desequilibrar a todos. Todo depende de si
el cambio requiere cambios fundamentales en el marco subyacente. Es fácil ser
ágil al mover un botón o cambiar un color. Pero cuando se trata de reelaborar el
esquema de la base de datos o jugar con fragmentación y replicación, no hay una
manera fácil de pivotar con gracia.

Elegir la tecnología incorrecta para el trabajo

Incluso si planifica cuidadosamente y elabora la lista correcta de características,
las cosas pueden fallar si usa la tecnología incorrecta. Las bases de datos, por
ejemplo, están diseñadas para ser generales y flexibles, pero tienen limitaciones
arquitectónicas. Instálelos para que ofrezcan algo para lo que no están diseñados,
y se detendrán virtualmente cuando se les pida que escalen. O puede comenzar
con una base de datos NoSQL porque suenan geniales solo para descubrir más
tarde que realmente necesita transacciones de grado ACID para mantener las
cosas consistentes y la base de datos no las ofrece. UPS.

Priorización deficiente
Los buenos planificadores elaboran una lista de características y las
priorizan. Pero a veces las prioridades no se alinean con la realidad de
implementarlas. En el peor de los casos, las características más importantes son
las más difíciles de crear.

¿Qué van a hacer sus desarrolladores? Si se concentran en la característica más

importante, no progresarán y pueden terminar sin entregar ninguna de las
funciones. Pero si comienzan a eliminar los fáciles, pueden terminar con algo que
no vale la pena.

Una buena planificación requiere más que una lista de verificación. La visión
arquitectónica debe tener en cuenta las necesidades y el costo de su entrega.

Se cierra la ventana del mercado

A veces no es culpa del programador. Uno de mis proyectos fue convertir un libro
de referencia de gran éxito en ventas en una aplicación. El libro se vendió como
pan caliente en los años anteriores a Internet. El plan era aprovechar esa
demanda y crear una versión interactiva que permitiera a las personas clasificar y
buscar los datos. El equipo de programación entregó un software que incluía todo
en el libro, pero era más rápido, más bonito y mucho más ligero que el libro en
sí. Pero ya nadie lo quería. Había suficientes otras fuentes y nadie necesitaba otra
aplicación que hiciera lo mismo que hacen los sitios de noticias en todas partes.

A veces, una idea parece genial, pero el mercado ha avanzado.

Malas decisiones arquitectónicas

En un proyecto, me dieron el trabajo de cambiar un número en una fila en la base
de datos. Cuando el usuario terminó de registrarse, debía agregar el número de
identificación del usuario al último pedido. Suena simple, ¿verdad? Pero el sistema
se construyó sobre una arquitectura de microservicios y no pude resolver esto
escribiendo una línea de código que le dijera a la base de datos que “actualizar
esa columna no era lo mejor”. El plan arquitectónico era agregar una nueva
llamada de microservicio a la pila existente e incluso esto fue difícil porque mi
primera llamada de microservicio necesitaba desencadenar otra llamada de
microservicio y así sucesivamente.

Al final, el genio de la arquitectura que creó esta red de microservicios me dijo que
todo era muy simple y trazó un camino sinuoso a través de cinco capas de la
arquitectura. Mi trabajo consistía en agregar cinco nuevas llamadas API a cinco
microservicios diferentes, lo que también significaba agregar cinco conjuntos de
pruebas automatizadas para cada capa. Y cada API fue desarrollada por un
equipo diferente a lo largo de los años, lo que me obligó a comprender y emular
cinco estilos diferentes de codificación. Todo para cambiar un número.

Las decisiones arquitectónicas pueden durar toda la vida, especialmente si su ego

está completamente invertido en ellas y no puede cambiarlas. Los gerentes de
proyecto deben estar listos para darse cuenta cuando el plan arquitectónico
principal no está funcionando para que se puedan tomar decisiones importantes.

Conflictos políticos
Culpar a los factores políticos por una falla técnica puede parecer una tontería,
pero es cada vez más cierto. A medida que los proyectos crecen y abarcan
múltiples organizaciones, no debería sorprender que aparezcan facciones y
grupos que luchan por el control, los recursos y, en última instancia, el poder.

Las facciones políticas son diferentes de las diferencias técnicas reales. A

menudo, existen estándares técnicos o bases de código que hacen lo mismo de
diferentes maneras. Tome XML y JSON. Ahora que lo he escrito, puedo sentir que
los fanáticos de cualquiera de los dos se apresuran a explicar por qué no son
iguales y su elección favorita es la correcta. Pero cuando una parte de un equipo
ama una opción y otra tiene a la facción competidora en la más alta consideración,
bueno, la fricción los destrozará.

Esto se ha vuelto aún más común a medida que los arquitectos dividen las
aplicaciones en varios servicios y API más pequeños. Diferentes grupos
terminarán controlando estos y no siempre se llevarán bien. Si al Grupo A le gusta
JSON y el Grupo B se aferra a XML, bueno, su equipo deberá implementar ambos
o hacer que uno de ellos cambie. Los tres son un dolor para cualquier equipo que
deba trabajar tanto con el Grupo A como con el Grupo B.

Apostar por la tecnología que no está lista para la

producción
A los programadores les encantan las últimas herramientas y marcos. Quieren
creer que el nuevo enfoque eliminará todo el problema que empantana a la
generación anterior.

Pero a menudo, la próxima generación no está lista para su uso en

producción. Las nuevas funciones pueden parecer perfectas, pero a menudo hay
lagunas que no son obvias de inmediato. A veces, el código admite solo unos
pocos tipos de archivos o interfaces con solo unas pocas bases de datos. Los
otros llegarán pronto, le aseguran, pero su proyecto debe enviarse este mes y
“pronto” podría significar seis o más meses antes de que se completen las
funciones que necesita.

Apostar por una tecnología que pronto quedará

obsoleta
En mi experiencia, el material antiguo suele ser más fiable y probado en batalla,
pero eso no significa que la tecnología antigua sea perfecta. Es posible que falten
funciones que son vitales para su proyecto de software una vez que se pone en
marcha. Peor aún, apostar por la tecnología antigua puede hacer que pierda
oportunidades futuras en función de los cambios que se produzcan en el
futuro. Aparecen nuevas ideas, protocolos y formatos de archivo, y es posible que
no se implementen. Y si alguien de un equipo de la competencia insiste en que
apoyes algún protocolo nuevo, la tecnología anterior se verá afectada.

Plazos poco realistas

Los plazos son complicados. Muchos proyectos necesitan llegar al mercado en
una temporada o evento en particular. Sin embargo, cuando se anotan los plazos
por primera vez, los desarrolladores no han comenzado a descubrir los obstáculos
y obstáculos en su camino. Luego, si el proyecto falla y el evento pasa sin que se
inicie el software, todo el proyecto se considera un error, incluso si el código está a
punto de ejecutarse sin problemas. Los plazos ayudan a todos a concentrarse y
trabajar juntos, pero también crean expectativas que pueden ser poco realistas.

Competencia imprevista
Un buen gerente de producto encuesta a la competencia antes de sumergirse,
pero nadie puede predecir qué competencia puede aparecer de la nada. Si nuevos
competidores introducen nuevas funciones que debe duplicar, consulte las
secciones sobre cambios de funciones y desajustes de prioridad, más arriba.

Acelerando el proceso
Muchos proyectos de software comienzan como la visión de una persona o equipo
que quiere arreglar algo. Se les ocurre una frase como “Snapchat para Y” o “Uber
para Y” y luego esperan que el equipo de producto sea tan receptivo como
Snapchat o Uber. El problema es que averiguar el alcance del proyecto, esbozar
los flujos de datos e imaginar la interfaz de usuario a menudo es diez veces más
trabajo que escribir el código. Pero los imaginadores quieren pasar de la idea al
código de inmediato.

Los wireframes, el esquema de la base de datos y las historias de los usuarios no

son solo un movimiento de manos, sino una parte esencial del trabajo. Pero la
mayoría de la gente quiere creer que un proyecto de software es solo escribir
código para implementar una idea.

Falsa creencia en el poder del software

Los soñadores suelen tener creencias poco realistas sobre el poder del software
para cambiar el mundo. Muchos imaginaron que las redes sociales nos unirían,
pero de alguna manera son solo líneas de falla expuestas que siempre fueron
obvias. Los proyectos de software a menudo comienzan con presentaciones de
diapositivas que prometen revolucionar algún rincón del mundo. Cuando meter bits
en una base de datos no transforma a nadie, bueno, la gente se enoja, se aburre,
se confunde o peor. Dicen que el software no funciona porque no logra la
transformación mágica que todos esperaban.

Muchos proyectos de software pueden compilar, aprobar el control de calidad,

enviar e incluso obtener revisiones decentes, pero en última instancia no logran
cumplir ninguna de las promesas de la plataforma de diapositivas porque, bueno,
esas promesas de cambiar el mundo son imposibles.

Subcontratistas malvados
Amamos a los proveedores que producen las bibliotecas y herramientas que nos
permiten crear magia con solo unas pocas líneas de código. De vez en cuando, se
enteran de su poder y lo utilizan para destruir un proyecto. La hoja de presupuesto
de la versión 1.0 era tan buena que la dirección no dudó en aprobar la versión
2.0. Entonces el vendedor decide exprimirnos triplicando o quintuplicando el
precio.

Este efecto se puede sentir incluso cuando los proveedores no lo hacen a

propósito. Los niveles gratuitos pueden hacer que un proyecto parezca muy
económico. Luego, cuando la demanda se dispara y la segunda versión expande
la demanda, los precios reales entran en acción.

Cambio de mar 
En un año de pandemias y protestas, nada ha cambiado más rápido que el
zeitgeist. ¿El proyecto hizo de las fuertes protecciones de privacidad una
característica central? ¡Ups! La pandemia ha hecho que todos se interesen en el
rastreo de contactos. ¿Alguien quería centrarse en los viajes de
negocios? ¡Ups! La industria hotelera se ha derrumbado. Los proyectos de
software más grandes que pueden tardar un año o más corren el riesgo de ser
trastocados por eventos cataclísmicos. Lo que parecía una idea maravillosa al
principio puede parecer irremediablemente perdido y desconectado cuando llega
el momento de lanzarse.

Turnos técnicos
No se trata solo de cambios en el mundo en general. Los cambios de marea en la
comunidad tecnológica pueden tener el mismo efecto. NoSQL fue una vez una
idea genial que nos liberaría del esquema relacional. Entonces alguien se dio
cuenta de que los archivos se hinchaban porque cada registro tenía un esquema
local. Un buen equipo de desarrollo ágil puede cambiar cuando los cambios
tecnológicos cambian las actitudes de los líderes y los clientes. Pero incluso los
equipos más ágiles no pueden hacer frente a grandes cambios que absorben todo
el aire de sus planes arquitectónicos. El sistema se construyó asumiendo que X
era una gran idea y de repente X es suciedad. A veces es mejor hacerla explotar y
volver a protagonizar.

Demasiadas adiciones
Algunos proyectos de software comienzan bien e incluso se envían con
éxito. Luego, alguien agrega una característica adicional o tres, insertando un
nuevo código en la versión existente de una manera que el código continúa
cojeando. Los desarrolladores heroicos pueden lograr esto varias veces,
especialmente si el arquitecto inicial lo planeó bien. Pero en algún momento, los
cimientos se derrumban. Quizás la base de datos no pueda manejar la
carga. Quizás se necesitan demasiados JOIN para satisfacer las distintas
consultas. Un buen software puede engordar demasiado, a veces gracias a
pequeñas mejoras que lo llevaron al límite.

Mover postes de meta

Los planes iniciales requerían una base de datos para rastrear los gastos de los
clientes para ayudar con los planes de marketing. Luego, un genio agregó una
función que usa inteligencia artificial para correlacionar el gasto con el pronóstico
del tiempo. O alguien más quería que el software pujara automáticamente por los
anuncios de los motores de búsqueda. Cambiar el destino puede poner patas
arriba un proyecto.

Es raro que los cambios arruinen las cosas por sí solos. Pero los nuevos objetivos
pueden revelar debilidades y desencadenar modos de falla. Quizás el equipo
ahora sea demasiado pequeño para completar el proyecto con éxito. Quizás las
bases técnicas sean tremendamente ineficientes para el nuevo enfoque. Es difícil
para todos anticipar la inquietante combinatoria cuando se toma la decisión de
cambiar los objetivos. 

Peter Wayner, CIO.com