¿Cómo lidiar con solicitudes de funcionalidad ridícula en su software?

Question

Por supuesto, la mayoría de las veces este tipo de solicitud proviene de la gerencia que ni tiene ni idea de lo que los usuarios realmente quieren, ni tiene una pista sobre los aspectos técnicos de construir un software o proyecto de software específico en general. Ver Dilbert's Pointy-Haired Boss para más detalles.

Sin embargo, ese es solo un aspecto. ¿Qué pasa con las solicitudes de artículos que usted sabe que dañarán el rendimiento general del sistema que está creando? ¿O qué tal el idiota técnico al que tontamente se le ha dado autoridad y sin embargo, casi todo lo que hacen se convierte en dook? (Ver this post para un ejemplo impresionante)

En última instancia, ¿cómo se forma elocuente, profesionalmente y con cuidado tratar las solicitudes o edictos a lo que usted está construyendo que sabe que en última instancia daño al proyecto?

---

Dupe: When the Client asks for something ludicrous and insists

Answer 1

Un diseñador buen software será abstenerse de llamar a una solicitud de función ridícula. Tienes que confiar en tu instinto, pero es solo una buena indicación de que deseas considerar el problema cuidadosamente.

que sugieren un modelo simple:

1. tratar de entender cuál es el problema real es, no la solución el usuario está pidiendo. La regla de diseño dorado "Don't discuss solution with the client, discuss requirements".

2. ser capaz de explicar donde en su opinión, el problema con las mentiras de características propuestas. Paul Graham tiene una excelente pieza llamada "How to Disagree".

Estos dos pasos simples le ayudarán a los usuarios y para profundizar en la comprensión del problema real. El software no tiene sentido sin los usuarios, la mayoría de nosotros dependemos de los usuarios que lo pagan. Trabaja con los usuarios en lugar de alienarlos con una actitud que puede parecer insultante.

Algunas solicitudes de funciones "ridículas" tienen sus raíces en problemas muy interesantes y difíciles de resolver.

Answer 2

se refieren siempre a cualquier solicitud de dinero. Las personas que se presentan con estas peticiones son por lo general más preocupados por el dinero así que asegúrese de que son conscientes de que va a costar ellos más porque:

• que va a tomar más tiempo
• es probable que introducir más errores
• es probable que reducir la velocidad de mantenimiento
• que se ralentizará el desarrollo de nuevas características relacionadas con él

Answer 3

creo que la única cosa que puede hacer es muy concisa describen los problemas principales º en la solicitud de cambio aparecerá a las personas involucradas. En mi lugar de trabajo tenemos el mismo problema que tú.

Algunas de las solicitudes de cambio obligan a los desarrolladores a saltar a través de aros solo para hacerlo y al final resulta en un código menos mantenible para una función que alguien arriba pensó que sería una buena característica.

En mi experiencia, realmente no hay nada que pueda hacer para detener esto y, finalmente, la administración empezará a quejarse sobre cuánto tiempo tarda el desarrollo, etc. Es un horrible ciclo que terminará en el sitio que se está reconstruyendo o equipo que pasa la eternidad en el infierno del código

Buena suerte.

Answer 4

Existen diferentes tipos de "ridiculez".

• que es demasiado caro: Argumento que los clientes necesitan debe ser vale la pena el dinero para gastar
• Es sólo cosas innecesarias: Trato de explicar que el cliente no puede utilizarlo. Si todavía lo quieren, pueden tenerlo.
• Va contra los conceptos existentes: Esto es realmente "demasiado caro" del tipo "inaccesible". Ellos no lo entenderán

me gustaría hablar acerca de los requisitos :-)

Editar:

Una discusión típica

• comercialización Guy: Al lado de esta tabla que necesitamos un botón para proporcionar una función X a la selección.
• Desarrollador: Pero necesitamos parámetro adicional P para la función X
• M: Parámetro P es evidente es muchos casos
• D: Pero tenemos que cubrir todos los casos. Necesitamos solicitar P
• M: ¡No! ¡A los usuarios no les gusta que se les pida valores obvios! Solo quieren "hacer clic y avanzar".
• D: Es imposible en este caso. Necesitamos avisar.
• M: (complaciente) ¿No puedes adivinarlo y solo preguntar si realmente es realmente necesario?
• D: Es difícil de adivinar de manera confiable. En realidad lleva semanas o incluso meses implementarlo y es un alto riesgo. ¿Qué pasa si adivinamos mal? Necesitaríamos inteligencia artificial para esto.
• M: Pero es muy simple: siempre en caso de blahblah, sabemos P
• D: Sí, claro, pero no sabemos lo que el usuario sabe.
• M: Hm. Tus desarrolladores siempre son tan complicados.
• D: ...
• M: Entonces, ¿puedes hacerlo o no?
• D: No.
• M: ¿Por qué?
• D: (irritado) Acabo de explicar. Después de todo, ¿cree que al usuario le gusta que el sistema adivine P si realmente quiere decidir?
• M: Solo tiene que adivinar lo que el usuario decida.
• D: ¿Pero dónde lo sé?
• M: Es esta situación blahblah ...
• D: Lo sé, pero no es tan simple como eso.
• M: Ok, voy al jefe del proyecto, él te dará una tarea.
• D: ...

Answer 5

Si se trata de un cliente y técnicamente posible hacerlo, y usted puede hacerlo, obtener una declaración de trabajo - y hacerlo.

Si es un trabajo que tiene, usted hace lo mismo que cualquier otra cosa. Usted dice: "Sí, señor (o señora), me alegrará hacer eso. Y no me importa hacerlo. Solo pensé que podría querer saber cómo esto podría afectar nuestros otros sistemas o presupuesto. No digo que estés equivocado, solo dices que tal vez deberíamos pensar un poco sobre esto. ¿Está bien? "

Si dicen que no, bueno, lo firmaron y lo haces. Si realmente te preocupa, documenta tu conversación donde no se hizo caso de tus consejos. Recuerde, si no lo documenta, no sucedió. Si te escuchan, entonces ganas un amigo.

Ésta sería la misma para cualquier trabajo - ordenador, trabajador de la construcción, lo que sea.

EDIT:

que tomé de mi comentario a continuación:

qué nadie ver Star Trek TNG o más condiciones de servicio? Recuerde que el Número Uno le haría saber al Capitán Picard algo equivocado y algunas veces Jean-Luc estaría de acuerdo y otras no. Eso es todo lo que digo

Answer 6

encuentro la frase "vamos a hacer que en la fase dos?" funciona de maravilla, posiblemente respaldado con "Creo que podemos arreglárnoslas sin eso, para empezar, saquemos algo primero".

Answer 7

Nos tienen a veces estas solicitudes procedentes de los gerentes de producto.

En un caso, expliqué que iban a haber problemas de rendimiento y el directivo confirmó que así lo ganamos.

La próxima vez me planteó una preocupación similar, pero el hombre de la tercera edad no estaba disponible, así que hice lo que ellos querían porque a nadie realmente le importaba. Decidí que no también.

Probablemente se refiera a cosas como enviar una solicitud de criterios múltiples a la base de datos, mostrando los resultados y al mismo tiempo mostrando cuál de todos esos criterios tuvo éxito. ¿Lo has adivinado?

Answer 8

Su arma de elección debe ser la estimación . La funcionalidad ridícula, generalmente viene con una estimación ridícula. Cuando debe tener la característica X obtiene una estimación años 3 hombre, que mágicamente se convierte en, bueno tener la característica X.

Answer 9

Me tomaría el tiempo para escuchar cortésmente, si hay más de una solicitud, pídales que les den prioridad y que la soliciten por escrito, idealmente "firmada" o cualquier procedimiento que tenga. Luego, dígale a su gerente/cliente que revisará las solicitudes y les responderá con las estimaciones y el impacto que tendrá en su calendario. Explique que solo para producir estos datos necesitará tomar X número de horas (o días) y, por lo tanto, su otro trabajo se retrasará ...

Luego, vuelva con las estimaciones: si la solicitud fue ridícula, entonces su estimación es probablemente para reflejar eso :-)

Si su gerente/cliente quiere continuar y perder mucho tiempo y dinero, al menos ha dejado en claro y usted ha hecho todo lo posible para ayudarlos.

Si es posible, debe pedirles que posterguen dichas solicitudes hasta una fase futura, sugiera que lo analicen en la próxima versión (creo que algunas otras respuestas ya mencionaron esta idea).

Answer 10

Estas son todas buenas respuestas. Necesitas datos duros (si es posible generarlos), estimaciones "increíblemente ridículas" y, sobre todo, respeto.

La respuesta de Johnny estaba en lo cierto, en esencia, si no en las palabras exactas (comentaría si hubiera construido suficientes repeticiones). Sin embargo, en algunos casos, el uso de esas palabras exactas puede crear suficiente disonancia para que el solicitante examine por segunda vez el contenido de sus objeciones. Y sí, esto se aplica a cualquier basado en proyectos esfuerzo: software, diseño publicitario, incluso (¡oh!) La construcción.No es que el gruñido que porta el mortero tenga el fundamento o la fuerza para objetar un diseño defectuoso, pero el líder de la construcción sí tiene la obligación de decirle al arquitecto si sus planes no se pueden construir.

Si todo lo demás falla, documente la discusión & compilar de todos modos. Ya no es tu responsabilidad.

Answer 11

Las solicitudes de funciones ridículas caen en dos campos para mí cuando respondo a ellas.

1. característica hará que la aplicación deje de funcionar como se espera, es decir, se rompe, se ralentiza en exceso, hace que sea inviable Característica
2. que no va a hacer que la aplicación deje de funcionar como se esperaba pero no lo hago entiendo por qué querría esa función

Para el tipo 1 analizaré la solicitud y responderé con hechos concretos o con opiniones profesionales. Si el análisis indica que puede ser posible con un esfuerzo adicional en el código existente, ¡entonces estime y estime los valores altos!

Para el tipo 2, primero le pediré al solicitante que me explique la característica con más detalle, después de todo, pueden funcionar en un área del negocio que no entiendo claramente más allá del espacio problemático para el especificación de la aplicación original Si todavía no lo entiendo y realmente no puedo ver el propósito de la función, estimo que es alto para desalentarlos.

Si aceptan el presupuesto o lo hago, finalmente, obtenlo, entonces lo hago.

Al final del día, son el cliente y si un cliente va al sastre y pide un pantalón de 4 patas, el sastre puede discutir por un tiempo, pero al final es un trabajo personalizado y mucho más costoso . Entonces, si ven suficiente valor en la función que están dispuestos a pagar, estén dispuestos a tomar su dinero; solo porque no puedas ver el valor no significa que estén equivocados.

Answer 12

• A veces se explica por qué la funcionalidad es ridícula y se elimina la funcionalidad.

• A veces puede hacer que alguien más mayor diga "no" por usted.

• A veces eres lo suficientemente mayor (o influyente) para decir "no" por ti mismo.

• Algunas veces puede decir "sí", pero le da poca prioridad a la tarea (y nunca lo haga).

• A veces solo tiene que seguir con ello.

En este último caso, debe asegurarse de hacer la tarea muy, muy bien. ¿Por qué? Brillarás, y mientras lo haces, la sombra de lo ridículo se enfocará.

Answer 13

Me parece que la mayoría de las personas que piden lo imposible no se dan cuenta de por qué lo que están pidiendo es un problema.

En general, me acaba de pedir más y más aclaración de las exigencias y más y más detalles hasta que:

• Una bombilla se enciende en mi cabeza, me di cuenta de lo que están tratando de y puedo decir "ah, lo que realmente quieres es X, no Y". En ese momento, generalmente dirán "sí, eso es lo que estaba diciendo todo el tiempo".

• Se dan cuenta de lo poco realista que están siendo y que retiren la solicitud

• Se da cuenta de forma conjunta que sería muy bueno, pero no es posible. Por lo general, en mi experiencia, ese es el caso porque necesitarías hacer un cambio en una aplicación de código cerrado grande, en cuyo caso, simplemente lo conviertes en una función solicitada al proveedor, lo cual es más satisfactorio para los no expertos que para los técnicos; Microsoft no realiza cambios en Excel porque una pequeña empresa se lo pidió.

Answer 14

Los requisitos creados por el cliente pueden ser una de las principales causas de este problema. El problema es que el cliente algunas veces intenta hacer el trabajo de un desarrollador de software.

que tienen un problema y luego trabajar en lo que será función de resolver ese problema. Desafortunadamente, algunas (la mayoría) de estas pobres almas no son muy buenas en el diseño de software, por lo que se obtiene una característica muy curiosa al final.

Una manera de eliminar algunos de estos tipos de características retraso es sólo a través de la función recursiva .¿Por(). Siga preguntando por qué hasta que encuentre su problema y luego diseñe la función usted mismo. En muchos escenarios, puede rediseñarlo de una manera simple, económica y que satisfaga a todas las partes.

---

También hay ocasiones en que lo que parece ser una petición ridícula funcionalidad no desplazarse en realidad ser una buena. Hay momentos en que los desarrolladores de software (y me han cogido a mí mismo haciendo esto en el pasado) dicen que no a una característica razonablemente complejo pero muy útil que se hacer la empresa un montón de dinero. Entonces, cuando encuentre una característica "ridícula", asegúrese de calcular su valor potencial para la empresa antes de descartarla al instante.