Creo en rechazar los malos requisitos. Pero también creo que cuando has dado tu mejor oportunidad para explicar por qué son malos y todavía los quieren, entonces estás de acuerdo y haces tu trabajo.
Por ejemplo, he tenido personas que quieren requisitos que se excluyen mutuamente de algo que la aplicación ya hace. Si hago eso, entonces esto, 100% garantizado, se romperá. Así que les devuelvo el requisito y les digo que esto romperá esta otra regla comercial que ya tenemos establecida y ¿quieren cambiar también esta regla? A menudo, el pequeño grupo que presenta un requisito particular no tiene acceso a una imagen más amplia de lo que puede hacer el resto de la aplicación. La mayoría de las veces, cuando envié uno de estos, el cliente se dio cuenta de que la regla inicial era más crítica y decidió que el cambio que quería no valía la pena. Cuando decidieron hacer el cambio, lo hicieron después de consultar con las personas que impulsaron el requisito inicial.
A veces, solo hacer preguntas de aclaración les hará ver que el problema no es tan simple como pensaban. A veces quieres preguntar por qué quieren algo y llegar a la verdadera necesidad que está impulsando el cambio. Una vez que comprenda eso, a menudo es más fácil ver una solución alternativa que funcione para usted como desarrollador y satisfaga sus necesidades. Si puede presentar esa solución en términos de cómo satisfará mejor sus necesidades que la sugerencia original, habrá mejorado enormemente sus posibilidades de que se acepte su cambio.
A veces, cuando un cambio va a crear estragos en un nivel básico en su diseño, solo darles la nueva estimación de las horas que tomará el cambio es suficiente para desactivarlo. Si combina eso con una evaluación de riesgos que señala en qué funcionalidad crítica podría estar introduciendo nuevos errores al decirles que tomará 6 semanas de esfuerzo dedicado de 3 personas, de repente ya no es tan importante.
Pero a veces les dices que no es una buena idea y por qué, y todavía dicen: "Lástima que la necesitemos". Ganas algo y pierdes algo y, a veces, las necesidades del negocio realmente han cambiado y la aplicación debe adaptarse a eso. Una vez que se ha finalizado la decisión, ya no es el momento de cuestionar lo que está haciendo y el momento de seguir haciéndolo. Si ha documentado sus objeciones, entonces personalmente debería estar en un buen lugar cuando sobrepase el presupuesto y cause errores nuevos y más emocionantes. E incluso podrían estar más dispuestos a escucharte la próxima vez cuando hayas acumulado un historial de estar en lo cierto en este tipo de cosas.
La clave para ganar muchas de estas discusiones (nadie las gana todas) es primero construir un historial para saber de qué está hablando. Luego envíe un documento escrito que indique qué preocupaciones tiene (muchos gerentes son adversos al riesgo, es más probable que no quieran que alguien tenga un documento que demuestre que está equivocado más tarde, por lo que prestan más atención a lo que usted escribe) y finalmente para asegurarse de que entiendan todos los costos (no solo horas, sino también riesgos de seguridad, la introducción de nuevos errores, la falta de plazos, etc.) de realizar el cambio. El cambio no es gratuito y deben entenderlo. La siguiente clave es hacer esto como un adulto y no como un niño quejumbroso ("pero no quiero usar ... porque no me gusta"). Haga un caso de negocios por no hacerlo y obtendrá mucho más lejos para retrasar un mal requisito.