20 razones por las que los proyectos de software fallan
Cada 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 una cosa binaria. Puedes terminar con un código que funciona bien pero que nadie usa. O puedes terminar con código que ni siquiera se compila. A veces puedes rescatar algo útil de los restos en llamas y a veces es mejor huir antes de que explote.
Cuando el desorden se enfría, comienzan las autopsias, ya que la gente quiere saber qué salió mal. Estos son los culpables más comunes.
Muy pocos miembros del equipo
Intentar hacer demasiado con muy pocos programadores es un problema común. Los desarrolladores solo pueden moler hasta cierto punto de código antes de agotarse. Una vez trabajé en un equipo en el que el gerente pensó que la manera correcta de exprimir más trabajo de los equipos ágiles era programar cada «sprint» para que comenzara inmediatamente después del anterior. Sin pausas reflexivas para averiguar qué estaba funcionando y qué no. Sprint 42 terminó el miércoles a la 1:59 pm y Sprint 43 comenzó el miércoles a las 2:00 pm. Las reuniones de análisis retrospectivo se programaron después de que el siguiente sprint ya comenzara. Un tipo inteligente sugirió que se llamaran «maratones» y pronto encontró otro trabajo.
por supuesto, es difícil saber cuántos programadores es suficiente. A veces, obstáculos y 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.
Demasiados miembros del equipo
Si muy pocos programadores pueden ser malos, demasiados podrían ser peores, ya que los efectos de red pueden arruinar un proyecto de software. Más personas significa más coordinación y eso significa más reuniones, lo que le quita tiempo a escribir 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 que pudiéramos gastar dinero en un problema al sobrecargar de personal un proyecto, pero no puedes.
Demasiada comunicación
El software de escritura es un arte solitario. Los humanos pueden trabajar juntos, pero solo en combates 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 luchar contra el fracaso celebrando más reuniones para mantener a todos sincronizados. Es un esfuerzo noble, pero puedes escuchar los engranajes rechinando. El equipo necesita compartir suficiente información para mantenerse sincronizado, pero cualquier otra cosa solo desperdicia ciclos cerebrales.
Cambios fundamentales en las funciones
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 implica la reformulación del esquema de base de datos o jugando con la fragmentación y la replicación, no hay una manera fácil de correctamente pivote.
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. Presiónelos para que entreguen 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 bien solo para descubrir más tarde que realmente necesita transacciones de grado ÁCIDO para mantener las cosas consistentes y la base de datos no las ofrece. Oops.
Mala priorización
Los buenos planificadores elaboran una lista de características y las priorizan. Pero a veces las prioridades no se alinean con la realidad de su implementación. En el peor de los casos, las características más importantes son las más difíciles de crear.
¿Qué deben hacer sus desarrolladores? Si se concentran en la característica más importante, no harán ningún progreso y pueden terminar sin ofrecer ninguna de las funcionalidades. Pero si empiezan a eliminar las fáciles, pueden terminar con algo que no vale nada.
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.
La ventana del mercado se cierra
A veces no es culpa del programador. Uno de mis proyectos era convertir un libro de referencia más vendido en una aplicación. El libro se vendía como pan caliente en los años anteriores a Internet. El plan era aprovechar esa demanda y hacer una versión interactiva que permitiera a las personas ordenar y buscar los datos. El equipo de programación entregó 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 los sitios de noticias en todas partes.
A veces una idea parece genial, pero el mercado ha seguido adelante.
Malas decisiones arquitectónicas
En un proyecto, se me dio 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 indicara a la base de datos que ACTUALIZARA esa columna. No. 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 activar otra llamada de microservicio y así sucesivamente.
Al final, el genio arquitectónico que creó esta red de microservicios me dijo que todo era muy simple y trazó un camino serpenteante a través de cinco capas de la arquitectura. Mi trabajo consistía en agregar cinco nuevas llamadas de 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 tu ego está completamente invertido en ellas y no puedes cambiarlas. Los gerentes de proyecto tienen que estar listos para notar cuando el plan arquitectónico principal no funciona, por lo que se pueden tomar grandes decisiones.
Conflictos políticos
Culpar a los factores políticos de un fallo técnico puede parecer una comadreja, pero es cada vez más cierto. A medida que los proyectos crecen y abarcan varias organizaciones, no debería ser una sorpresa que aparezcan facciones y grupos que se disputen el control, los recursos y, en última instancia, el poder.
Las facciones políticas son diferentes de las diferencias técnicas reales. A menudo hay estándares técnicos o bases de códigos que hacen lo mismo de diferentes maneras. Tome XML y JSON. Ahora que he escrito eso, puedo sentir a los fanáticos de apresurarse a explicar por qué no son los mismos 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 estima, 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 múltiples servicios y API más pequeños. Los diferentes grupos terminarán controlándolos y no siempre se llevarán bien. Si al Grupo A le gusta JSON y al Grupo B se aferra a XML, bueno, su equipo tendrá que 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 frameworks. Quieren creer que el nuevo enfoque barrerá con todo el embrollo 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 características pueden parecer perfectas, pero a menudo hay brechas 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 demás llegarán pronto, te aseguran, pero tu proyecto debe enviarse este mes y «pronto» podría significar seis o más meses antes de que se completen las funciones que necesitas.
Apostar por una tecnología que pronto quedará obsoleta
En mi experiencia, el material antiguo suele ser más confiable y probado en batalla, pero eso no significa que la tecnología antigua sea perfecta. Pueden faltar características que son vitales para su proyecto de software una vez que se active. Peor aún, apostar por tecnología antigua puede hacer que te pierdas oportunidades futuras basadas en cambios en la línea. Aparecen nuevas ideas, protocolos y formatos de archivo, y pueden no implementarse. Y si alguien de un equipo de la competencia insiste en que apoyes algún nuevo protocolo, la vieja tecnología hará daño.
Plazos poco realistas
Los plazos son complicados. Muchos proyectos necesitan llegar al mercado para una temporada o evento en particular. Sin embargo, cuando los plazos se escriben por primera vez, sus desarrolladores no han comenzado a descubrir los obstáculos y obstáculos en su camino. Luego, si el proyecto se desliza y el evento pasa sin que se inicie el software, todo el proyecto se ve como un error, incluso si el código está a punto de ejecutarse sin problemas. Los plazos ayudan a que todos se concentren y se unan, 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 características que debe duplicar, consulte las secciones sobre cambios de características y desajustes de prioridad, más arriba.
Acelerar 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, dibujar 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 imagineros quieren pasar de la idea al código de inmediato.
Los marcos de alambre, el esquema de base de datos y las historias de usuario no son solo gestos manuales, sino una parte esencial del trabajo. Pero la mayoría de la gente quiere creer que un proyecto de software solo está escribiendo código para implementar una idea.
Creencia falsa en el poder del software
Los soñadores a menudo tienen creencias poco realistas en el poder del software para cambiar el mundo. Muchos imaginaron que las redes sociales nos unirían, pero de alguna manera solo se exponen líneas de falla que siempre fueron obvias. Los proyectos de software a menudo comienzan con plataformas de diapositivas que prometen revolucionar algún rincón del mundo. Cuando empujar bits en una base de datos no transforma a nadie, bueno, la gente se enoja, se aburre, se confunde o algo peor. Dicen que el software está roto porque no logra la transformación mágica que todos esperaban.
Muchos proyectos de software pueden compilar, pasar el control de calidad, enviar e incluso obtener revisiones decentes, pero en última instancia no logran cumplir ninguna de las promesas en la cubierta de diapositivas porque, bueno, esas promesas de cambiar el mundo son imposibles.
Subcontratistas malvados
Nos encantan 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, obtienen viento de su poder y lo usan para destruir un proyecto. La hoja de presupuesto para 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 se vea muy barato. Luego, cuando la demanda se dispara y la segunda versión expande la demanda, los precios reales entran en acción.
Sea change
En un año de pandemias y protestas, nada ha cambiado más rápido que el espíritu de la época. ¿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 verse afectados por eventos cataclísmicos. Lo que parecía una idea maravillosa al principio puede parecer irremediablemente perdido y desconectado cuando es hora de ir en vivo.
Cambios técnicos
No son solo 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 llevaba 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 lidiar con 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 tierra. A veces es mejor volarlo y volver a protagonizarlo.
Demasiadas adiciones
Algunos proyectos de software comienzan bien e incluso se envían con éxito. Luego, alguien agrega una característica adicional o tres, injertando código nuevo 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 planeó bien. Pero en algún momento, la base se desmorona. Tal vez la base de datos no pueda manejar la carga. Tal vez haya demasiadas combinaciones necesarias para satisfacer las diversas consultas. Un buen software puede engordar demasiado, a veces gracias a pequeñas mejoras que lo empujaron al límite.
Mensajes de objetivos móviles
Los planes iniciales requerían una base de datos para rastrear el gasto de los clientes y 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 anuncios de motores de búsqueda. Cambiar el destino puede dar un vuelco a 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. Tal vez el equipo es ahora demasiado pequeño para completar el proyecto con éxito. Tal vez los fundamentos técnicos sean tremendamente ineficientes para el nuevo enfoque. Es difícil para todos anticipar la combinatoria molesta cuando se toma la decisión de cambiar los objetivos.