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