¿Qué tan importante es conocer la funcionalidad antes de codificar?

Trabajo para una empresa de desarrollo de software en la que el trabajo de desarrollo nos ha sido enviado. El equipo en tierra maneja el apoyo y habla directamente con los clientes. Nunca hablamos con los clientes directamente, solo hablamos con personas del equipo en tierra, que hablan directamente con los clientes.

Cuando llegan los requisitos, el equipo en tierra habla con los clientes y hace los documentos de requisitos e informanos. Hacemos documentos de diseño después de estudiar los requisitos (seguimos el modelo de cascada tradicional).

Pero hay un problema en todo el proceso: nadie en el equipo off-shore o on-shore entiende completamente la funcionalidad de la aplicación. Solo sabemos que es una gran aplicación web compleja que maneja el procesamiento complejo de pedidos, la gestión de catálogos, la gestión de campañas y otras actividades. Luchamos con el documento de diseño ya que los requisitos no serían claros. Luego entra en una serie de preguntas / respuestas de ida y vuelta entre el equipo en tierra, el equipo en tierra y los clientes. A menudo se nos dice que comprendamos la funcionalidad del código. Pero eso generalmente no es factible ya que la base del código es enorme e incluso comprender un elemento de menú simple lleva días, si no semanas. Intentamos decirles a los clientes que nos den transferencia de conocimientosobre la aplicación pero fue en vano. Nuestro gerente a menudo nos dice que comencemos a codificar incluso si el documento de diseño no está completo o los requisitos no son claros. Comenzaríamos por codificar la parte de los requisitos que parece clara y esperar el resto.

Esto generalmente demoraría el despliegue en un mes. En casos extremos, tendríamos errores muy bajos en el desarrollo y la producción, pero los clientes dirían que no es lo que pidieron. Eso comenzaría un juego de culpa y una serie de solicitudes de cambio y terminaríamos desarrollando algo muy diferente.

Mi pregunta es ¿cómo haría el trabajo de desarrollo si no conoce la funcionalidad de la aplicación por completo?

ACTUALIZAR

La metodología de desarrollo no es realmente mi elección y no soy el líder de mi equipo. Es la forma en que comenzó. Traté de decirle a la gente sobre las ventajas de ágil pero fue en vano. Además, no creo que mi equipo tenga la mentalidad necesaria para trabajar en un entorno ágil.

Version corta:

Saber qué hacer ≠ conocer a su cliente.

Imagina esto: eres una empresa relacionada con el desarrollo inmobiliario. Le pides a tu pareja que construya un gran complejo. El socio dice que a pesar de todos los documentos que le entregó, también necesita hablar directamente con las personas que comprarían los apartamentos en este complejo. ¿Seriamente?

Versión larga:

Siempre es bueno saber cómo se usará una aplicación específica, porque es divertido aprender cosas, pero no siempre es posible en proyectos grandes.

Algunos dominios son demasiado complejos. Si solo es un desarrollador y está trabajando en múltiples aplicaciones de múltiples dominios, no siempre puede entender lo que está haciendo el usuario final , porque requeriría que pase cinco años aprendiendo contabilidad, diez años en la escuela de medicina, seis años en la facultad de derecho, etc.

Por otro lado, un producto de software hecho sin comprender el dominio específico será, en el mejor de los casos, un poco inutilizable .

Es por eso que los requisitos funcionales y no funcionales deben ser escritos por personas que entiendan completamente el dominio. En general, la recopilación de requisitos implica al mismo tiempo:

1. Técnicos (por ejemplo, desarrolladores que dirían que una característica específica es imposible, que esta otra puede ser mucho mejor si se hace de esta manera, y esta costará miles de dólares mientras haya una alternativa mucho más barata),

2. Personas especializadas en gestión de proyectos,

3. Personas especializadas en el dominio del cliente , que tienen la plena comprensión de este dominio y las necesidades precisas del cliente. Por supuesto, este puede ser el propio cliente.

Los requisitos funcionales y no funcionales están escritos y son lo suficientemente precisos, no necesita nada más como persona cuyo trabajo es traducir esos requisitos en código.

En cuanto a su caso específico, usted mismo describe la causa del problema:

Luchamos con el documento de diseño ya que los requisitos no serían claros.

No es la falta de conocimiento sobre el cliente lo que causa todos los problemas , es la baja calidad de los requisitos. En un proyecto gestionado correctamente, los requisitos funcionales y no funcionales deben ser perfectamente claros e inequívocos. Si el documento de requisitos no es claro o si le dice que "el diseño visual del producto debe ser atractivo" u otras estupideces como esa, es porque fue escrito por personas que no saben cómo escribirlo.

Sabiendo eso, debes actuar de manera diferente:

• Si sabe que el equipo que reúne los requisitos está desesperado, y su propio equipo tiene personas capacitadas para la recopilación de requisitos, explique la situación a su superior y dígale que el otro equipo debe ser reemplazado por alguien competente , por ejemplo, las personas del suyo.

• De lo contrario (es decir, si no están desesperados), intente determinar su causa interna de esos requisitos bajos y persuadirlos de que hacer su trabajo correctamente solo reducirá el costo total del proyecto . Es una buena idea mostrar las estadísticas sobre cómo los requisitos mal escritos influyeron en el proyecto al aumentar el costo (¿cuánto?) Y el riesgo de no estar listo para la fecha límite.

Probablemente el documento de requisitos es simplemente incompleto. Lo veo todo el tiempo: los gerentes de proyectos sin experiencia están convencidos de que un documento de una página es suficiente, y no entiendo por qué alguna vez escribirían entre trescientas y cuatrocientas páginas en lugar de una. Si es el caso en su empresa, demuestre que dedicar más tiempo a los requisitos reduciría los costos.

Está utilizando exactamente la metodología de desarrollo incorrecta para los problemas que enfrenta.

Al usar Waterfall, se compromete a:

1. Obteniendo los requisitos correctos por adelantado, esto obviamente no está funcionando
2. Codificar los requisitos lejos del cliente: no puede verificar efectivamente los problemas con el cliente dado que se ha comprometido a cumplir con los requisitos
3. La primera oportunidad que tiene el cliente de ver su funcionalidad es durante las pruebas; esto es demasiado tarde debido a los problemas que tiene.

Considere usar, si es posible, una forma diferente de administrar el proyecto. El desarrollo de software ágil tiene varias características que están diseñadas para abordar los problemas que enfrenta.

Una comparación decente de Waterfall vs Agile se escribió hace un tiempo, tomemos un par de citas que resalten sus problemas:

Falta la marca:

Una vez que se completa una etapa en el método de cascada, no hay vuelta atrás, ya que la mayoría del software diseñado e implementado bajo el método de cascada es difícil de cambiar según el tiempo y las necesidades del usuario. El problema solo se puede solucionar volviendo y diseñando un sistema completamente nuevo, un método muy costoso e ineficiente.

Atado...

Los métodos ágiles permiten cambios en las especificaciones según los requisitos del usuario final, lo que explica la satisfacción del cliente. Como ya se mencionó, esto no es posible cuando se emplea el método de cascada, ya que cualquier cambio que se haga significa que el proyecto debe comenzar de nuevo.

... e incapaz de moverse

Para sinopsis de la diferencia entre los dos, se puede decir que el método clásico de cascada significa previsibilidad, mientras que la metodología ágil explica adaptabilidad. Los métodos ágiles son buenos para reducir los gastos generales, como la justificación, la justificación, la documentación y las reuniones, manteniéndolos tan bajos como sea posible. Y es por eso que los métodos ágiles benefician a los equipos pequeños con requisitos en constante cambio, más que a proyectos más grandes.

Donde estás ahora es malo; no está cumpliendo con los requisitos del cliente y, si tiene la culpa del desarrollo de software, la productividad desaparecerá, la desconfianza aumentará y es probable que las cosas empeoren, no mejoren.

La relación con el cliente es crítica ; aquí, parece que no puede recopilar eficazmente sus problemas y adaptarse a sus requisitos cambiantes en la forma en que trabaja actualmente; por lo tanto, debe buscar formas de cambiar eso.

Así no es como funciona. Uno de los temas de mi educación actual es el análisis y la relación con un cliente. El énfasis siempre ha estado en definir claramente el proyecto. Imagina esto:

• Usted ordena a una empresa constructora que construya una casa pero no sabe cómo quiere que se vea. Simplemente personaliza el primer piso, para que el equipo construya una casa hasta el primer piso. Entonces desea que la planta baja se distribuya de manera diferente. Ups ...

A menos que esté muy seguro de que puede (parcialmente) establecer las bases correctas para la aplicación, le diría al cliente que no hay otra forma de hacerlo que con objetivos y funcionalidades claramente definidos. Porque si solo apuntas a lo que podría ser, te arriesgarás a tirar mucho dinero y tiempo por el desagüe.

Aquí hay algunas cosas que ayudarán a superar los problemas:

1. Mejora la comunicación entre los dos equipos. Pídale al otro equipo que comprima el requisito a 3 palabras, y luego el programador implementará esas palabras exactamente. Las palabras solo necesitan ser correctas. Nada se implementará sin esas palabras. Cada palabra te da 2000 líneas de código. La implementación comienza cuando se conoce una nueva palabra.
2. Si una palabra no está clara de inmediato para sus programadores, se les permite hacer una sola pregunta . La pregunta nuevamente tiene que ser correcta. Necesita una respuesta inmediata: la respuesta no puede esperar un viaje de ida y vuelta desde el otro lado del mundo, pero debe conocerse de antemano. La implementación comienza inmediatamente después de recibir la respuesta y la respuesta se seguirá a la letra.
3. Si durante la implementación hay requisitos poco claros o confusos, la forma de resolverlos es primero mirar las 3 palabras (existentes). Si aún no está claro, entonces el programador hace la mejor suposición posible . Cualquier retraso en este proceso está absolutamente prohibido; y pedir ayuda al otro equipo no es la forma correcta de resolverlo: ya tenían la oportunidad de cambiar los requisitos al decidir las 3 palabras correctas.
4. Si después de todo esto, el requisito aún no está claro o es imposible de implementar, la forma correcta de manejarlo es rechazar esas 3 palabras que causaron el problema y pasar a las siguientes. Las palabras rechazadas se recopilarán y pasarán al otro equipo, y deberán modificar las palabras antes de volver a ingresarlas al sistema. Rechazar palabras siempre mueve la fecha límite y la implementación deberá planificarse nuevamente.
5. Los equipos tendrían que ser evaluados en función de cuántas palabras rechazadas tienen. Una vez implementado el requisito, se arregla para siempre y ya no se puede cambiar . Cualquier intento de cambiar las características ya implementadas será rechazado.
6. El problema real con la pregunta es que supone que más información facilita la implementación. Esto no es verdad. Cuanta más libertad tengan sus programadores, más fácil será la implementación . La compresión de los requisitos permite comunicar grandes cantidades de información sin restringir demasiado lo que los programadores pueden hacer.