15 razones por las que algunos proyectos de software están condenados al fracaso

Desde expectativas demasiado grandes hasta cambios fundamentales en la funcionalidad, los proyectos de software a veces fracasan debido a factores técnicos y a una mala gestión.

0
24

Todos los proyectos de software comienzan con grandes sueños y grandes visiones. En algún lugar de un universo alternativo, hay un proyecto que cumple todos tus sueños, pero con demasiada frecuencia los proyectos de software en nuestro universo tropiezan con el camino hacia la meta final o, en el peor de los casos, ni siquiera lo completan. Aquí están las principales causas que llevan a su fracaso.

Muy pocos miembros del equipo
Intentar hacer demasiado con unos pocos programadores es un problema común, también porque los desarrolladores «se agotan» tarde o temprano. Una vez trabajé en un equipo de desarrollo en el que el gerente pensó que la forma correcta de exprimir más trabajo era programar cada «sprint» para que empezara inmediatamente después del anterior. No hay pausas ponderadas para averiguar qué funcionó y qué no. El Sprint 42 terminó el miércoles a la 1:59pm y el Sprint 43 comenzó el miércoles a las 2:00pm.

No me sorprendió tanto que algunos miembros del equipo prefirieran cambiar lugar de trabajo. Por supuesto, es difícil saber cuántos programadores son suficientes, y puede que no sea culpa del gerente que el trabajo se duplique en tamaño, pero si no tienes suficientes programadores en tu equipo desde el principio, es probable que tu proyecto ya esté condenado al nacer.

Demasiados miembros del equipo
Si muy pocos programadores pueden ser dañinos, tener demasiados podría ser potencialmente peor. De hecho, más gente significa más coordinación, y eso significa más reuniones, lo que requiere un tiempo valioso para escribir el código. Pero si no organizas suficientes reuniones, pronto descubrirás que la API del Equipo A no interactúa con los micro servicios del Equipo B. Sería estupendo pudiéramos resolver un problema simplemente aumentando el número de desarrolladores (y así gastando más), pero no podemos.

Demasiada comunicación
Escribir software es un arte solitario. Los humanos pueden trabajar juntos pero sólo en períodos limitados. Muchos desarrolladores odian las reuniones porque necesitan cambiar sus engranajes mentales de un pensamiento lógico profundo e inmersivo a un modo social más abierto. Esto lleva tiempo. Algunos líderes de equipo tratan de luchar contra la hipótesis del fracaso del proyecto celebrando múltiples reuniones para mantener a todos en sincronía. Es un noble esfuerzo, pero el equipo necesita compartir sólo la información suficiente para mantenerse en sincronía y no ser abrumado por las reuniones y encuentros.

Cambios fundamentales en la funcionalidad
En teoría, a los desarrolladores les gusta considerarse ágiles, pero a veces la agilidad puede hacerte perder el equilibrio. Es fácil ser ágil cuando mueves un botón o cambias un color. Pero cuando se trata de reelaborar un esquema de base de datos o de poner características completas, no hay una forma fácil de hacerlo sin causar otros problemas.

Eligiendo la tecnología equivocada para el trabajo
Incluso si planeas cuidadosamente y elaboras la lista correcta de características, las cosas pueden salir mal si usas la tecnología equivocada. Las bases de datos, por ejemplo, están diseñadas para ser flexibles, pero tienen limitaciones arquitectónicas. Empújenlos a proporcionar algo para lo que no fueron diseñados, y cuando se les pida que escalen, fallarán. O podrías empezar con una base de datos NoSQL porque suena interesante, sólo para descubrir más tarde que necesitas transacciones ACID para mantener las cosas consistentes y que la base de datos no las ofrece.

Prioridades equivocadas
Los buenos planificadores elaboran una lista de funciones y les dan cierta prioridad. Pero a veces las prioridades no se ajustan a la realidad de su aplicación. En el peor de los casos, las características más importantes son las más difíciles de crear. ¿Qué deberían hacer sus desarrolladores entonces? Si se centran en la característica más importante, no harán progreso y puede que no ofrezcan ninguna funcionalidad. Pero si empiezan a deshacerse de los fáciles, pueden terminar con algo inútil. Una buena planificación requiere más que una lista de control. La visión arquitectónica debe tener en cuenta las necesidades y el costo de la entrega.

La ventana del mercado se cierra
A veces no es culpa del director del equipo. Uno de mis planes era convertir un libro muy exitoso de antes de la era de Internet en una aplicación. El plan era crear una versión interactiva que permitiera a la gente buscar entre los datos del libro. El equipo de programación creó una aplicación que incluía todo el libro y que permitía su consulta más rápida, más agradable y más ligera. Es una pena que el libro en sí ya no le interesara a nadie. De hecho, había otras fuentes a las que acceder y nadie necesitaba otra aplicación que hiciera casi lo mismo que docenas de sitios. A veces una idea suena genial, pero si el mercado ya no es receptivo en esa ventana de tiempo es un problema.

Malas decisiones arquitectónicas
En un proyecto se me asignó la tarea de editar un número en una línea de la base de datos. Cuando el usuario terminó el registro, tuve que añadir el número de identificación del usuario en el último pedido. Suena simple, ¿no? Pero el sistema fue construido en una arquitectura de microservicio y no pude resolverlo escribiendo una línea de código para decirle a la base de datos que ACTUALIZARA esa columna. No. El plan arquitectónico era añadir una nueva llamada de microservicio a la pila existente e incluso eso era difícil porque mi primera llamada de microservicio tenía que desencadenar otra llamada de microservicio y así sucesivamente.

Al final, la gente que creó esta red de microservicios me dijo que todo era muy simple y trazó un camino tortuoso a través de cinco capas de arquitectura. Mi tarea era añadir cinco nuevas llamadas API a cinco microservicios diferentes, lo que también significaba añadir 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 entender y emular cinco estilos de codificación diferentes. Todo para cambiar un número. Los directores de proyecto deben estar preparados para notar cuando el plan arquitectónico principal no funciona.

Apostar por una tecnología que no está lista para la producción
A los programadores les encantan las últimas herramientas y marcos de trabajo y quieren creer que el nuevo enfoque acabará con la generación anterior. Pero a menudo la nueva generación no está lista para su uso en la producción. Las nuevas características pueden parecer perfectas, pero a menudo hay lagunas que no son inmediatamente aparentes. A veces el código sólo admite unos pocos tipos de archivos o interfaces con pocas bases de datos. Su proyecto tiene que ser entregado este mes y puede tomar seis o más meses antes de que la funcionalidad que necesita esté completa.

Apostar por una tecnología que pronto quedará obsoleta
En mi experiencia, las cosas viejas suelen ser más fiables, pero eso no significa que la tecnología vieja sea perfecta. Puede carecer de la funcionalidad que es vital para su proyecto de software una vez activo. Peor aún, apostar por la vieja tecnología puede hacer que se pierdan futuras oportunidades entre nuevas ideas, protocolos y formatos de archivo que no se pueden implementar.

Plazos poco realistas
Los plazos son difíciles de cumplir. Muchos proyectos tienen que llegar al mercado para una temporada o evento en particular. Sin embargo, cuando se deciden los plazos por primera vez, sus desarrolladores aún no han descubierto los problemas y obstáculos en su camino. Los plazos ayudan a todos a concentrarse y a trabajar con el compromiso necesario, pero también crean expectativas que pueden ser poco realistas.

Competencia imprevista
Un buen director de producto siempre comprueba la competencia antes de emprender un nuevo proyecto, pero nadie puede predecir un competidor que aparece de repente de la nada. Si los competidores introducen nuevas e interesantes características que usted quiere incorporar a su aplicación, debe estar listo y ser ágil para implementarlas, con todo lo que ello implica en cuanto a plazos y nuevas e inesperadas características a añadir.

Acelerar el proceso
Muchos proyectos de software comienzan como la visión de una persona o equipo que quiere arreglar algo. El problema es que comprender el alcance del proyecto, trazar los flujos de datos e imaginar la interfaz de usuario suele requerir diez veces más trabajo que escribir el código. Pero los «visionarios» quieren ir directamente de la idea al código porque creen (erróneamente) que los proyectos de software se refieren simplemente a escribir código para implementar una idea.

Demasiadas adiciones
Algunos proyectos de software empiezan bien y tienen éxito. Así que alguien añade una o dos características extra y algunos desarrolladores pueden hacerlo varias veces, especialmente si el arquitecto inicial del proyecto ha planeado bien las cosas. Pero en algún momento algo puede empezar a desmoronarse. Tal vez la base de datos no es capaz de manejar la carga, o tal vez hay demasiadas necesidades de JOIN para satisfacer las query.

Alejarse del objetivo primario
Los planes iniciales de software requerían una base de datos para rastrear los gastos de los clientes para ayudar con los planes de marketing. Así que algunos «genios» añadieron una característica que utiliza la inteligencia artificial para correlacionar los gastos con los pronósticos del tiempo. O alguien más quiere que el software oferten automáticamente por los anuncios en los motores de búsqueda. Cambiar el objetivo original de un software puede arruinar completamente un proyecto, con nuevas adiciones que pueden revelar debilidades y conducir a serios problemas. De hecho, el equipo puede ser demasiado pequeño para completar con éxito el proyecto, o las base técnicas pueden resultar completamente ineficiente para el nuevo enfoque.

Peter Wayner CIO.com – Redacción Cambio Digital On Line