Los aspectos más importantes que nadie te dijo antes de empezar a desarrollar una aplicación

Desde hace casi 50 años -desde que Fred Brooks publicó el clásico “El mítico Hombre-Mes”-, los equipos de desarrollo de software han luchado con el modo de desarrollar un proyecto de programación a tiempo y de acuerdo con las especificaciones requeridas.

No es una tarea fácil. Esto es lo que se les olvida decirte antes de que empiezas a desarrollar esa nueva aplicación para un cliente. Aquí van los aspectos más críticos que nadie te dijo antes de empezar a desarrollar una aplicación.

El producto final no se parecerá en nada a las especificaciones originales

Construir una aplicación debería ser bastante sencillo. Te sientas con unas cuantas personas en una sala, te pones de acuerdo en unas cuantas especificaciones y luego dejas que las personas más inteligentes de la sala vayan a trabajar programando lo que acabas de terminar de discutir. Bastante fácil, ¿verdad? Error.

Existe una alta probabilidad de que el producto final no se parezca en nada a las especificaciones originales. Hay un número de muy buenas razones para que esto suceda, y no tiene nada que ver con la competencia (o incompetencia) del equipo de desarrollo de software.

Los plazos cambian. Los planes cambian. En algunos casos, incluso el problema original que se estaba tratando de resolver con los cambios. De hecho, es un milagro que al final se llegue a desarrollar algo 🙂

Cuantas más partes interesadas tenga un proyecto, más complicado será la obtención de un resultado concreto

A primera vista, parecería tener mucho sentido limitar el número de “chefs” en la cocina, pero te sorprendería saber cuántas personas totalmente sensatas lo ignoran.

Al contrario, hay un afán de involucrar no sólo al equipo de desarrollo, sino también al equipo de ventas, al equipo de marketing y tal vez incluso al tipo que está al final del pasillo y que no sabe absolutamente nada de software pero es muy buena persona…

Y lo que sucede a continuación es como el clásico juego del teléfono, en el que cada persona que escucha una conversación la repite de forma ligeramente diferente a la siguiente persona de la cadena.

De acuerdo con lo que ahora se conoce como la Ley de Brooks (en honor a Fred Brooks),  que viene a decir algo así como que “añadir personal a un proyecto de software que va con retraso, solo hace que se retrase más”.

Siempre habrá una parte del producto final del software que nadie sabe exactamente lo que hace

En el mejor de los casos (es el escenario idílico, casi utópico), siempre habrá un trazado directo -uno a uno- entre todas las características diseñadas inicialmente por el equipo de desarrollo de software, y las características finales que aparecen en la aplicación o software. Es decir, una correspondencia total entre las funcionalidades diseñadas sobre el papel y las funcionalidades que efectivamente tiene la aplicación que se ha programado.

Pero el problema es que la mayoría de los equipos de desarrollo de software se sienten tan presionados para que el proyecto salga a flote que escatimarán en la documentación de lo que se supone que cada línea de código debe hacer en realidad.

Si se repite esto muchas veces, inevitablemente conduce a una “característica” que nadie sabe realmente lo que hace, o incluso cómo apareció en primer lugar. (Y hagas lo que hagas, nunca digas que es un “error” – ¡siempre di que es una “funciónalidad”)!

Siempre habrá un miembro de tu equipo encargado de mover “los postes de la portería”

Por mucho que a las personas les guste hablar de “estar alineadas” (o cualquier otra palabra que sea la última jerga del curso MBA), las personas rara vez están alineadas. Eso es lo que nos convierte en personas, y no en máquinas.

Una de esas personas (extraoficialmente, por supuesto) se auto-nombrará a sí misma como la persona encargada de “mover los postes de la portería”. Ya sabes, la persona que se presenta en la reunión del lunes por la mañana y anuncia de la nada que la fecha límite del proyecto se ha adelantado unas semanas, o que una de las funciones hace tiempo olvidadas es ahora “crítica para la misión” y debe ser añadida de inmediato.

Conclusión

Así que si tienes que liderar un proyecto de desarrollo de una aplicación, la próxima vez que te sientes con tu equipo y empieces a negociar los plazos y especificaciones, ten en cuenta estos puntos. Podría ahorrarte mucha sangre, sudor y lágrimas.

Artículos relacionados con proyectos de software

Artículos relacionados: 15 buenas prácticas para proyectos de desarrollo de software, 5 formas de agilizar tus proyectos de desarrollo de software, Podcast: Los secretos de buen análisis en los proyectos de software, ¿Cómo afrontar un nuevo proyecto de software?, ¿Necesitas nuevos proyectos de software? 

Nota: este artículo es una traducción para hacerlo accesible a desarrolladores y programadores hispano-hablantes.

 

Este artículo Los aspectos más importantes que nadie te dijo antes de empezar a desarrollar una aplicación es original de Velneo.