¿Es responsabilidad del desarrollador de software entender lo que el cliente quiso decir con su solicitud?

¿Una pregunta de sí / no y por qué?

¿Es responsabilidad del desarrollador de software entender lo que el cliente quiso decir con su solicitud o es responsabilidad del cliente explicar adecuadamente su solicitud al desarrollador?

La situación en el trabajo es actualmente "el cliente ya nos explicó lo que quiere. Es su responsabilidad entender la solicitud, no hacer más preguntas".

Si bien el inglés no es mi conjunto fuerte, todas las solicitudes están escritas en un inglés oscuro con palabras extraviadas y oraciones difíciles de entender, algunas solicitudes suponen una comprensión previa del sistema por mi parte.

Soy el tercer o cuarto desarrollador del sistema (los últimos desarrolladores abandonaron el trabajo) y esa podría ser la razón por la que el cliente espera un poco de comprensión por parte de los desarrolladores.

El sistema en sí es bastante desordenado tanto en la interfaz de usuario como en el nivel del código fuente. Esto me parece una codificación de mono: codifique y espero que obtenga la solicitud correcta, sin entender realmente la solicitud.

De hecho, estoy pensando en dejar el trabajo, pero aún no lo he hecho, dado que no estoy seguro de quién tiene razón y quién está equivocado.

Si es tu trabajo entender, es tu trabajo hacer preguntas hasta que lo hagas

La persona a la que pregunta puede ser alguien que no sea el cliente (a menudo hablé con un intermediario, que estaba en contacto con el cliente), por lo que los que le prohíben hablar con el cliente deben responder las preguntas por sí mismos o remitirlo a Alguien que pueda.

Pero, al final tiene que haber algún tipo de comunicación. Si lo niegan (y proporcionar algunos documentos que no comprende es negar la comunicación de manera efectiva), debe hacer lo que hicieron sus predecesores: huir, rápidamente.

Cuando sus clientes y superiores lo dejan con un rastro de papel desordenado, lo único que puede hacer es obtener el mayor sentido posible de lo que tiene y comenzar a escribir escenarios en inglés simple en un intento de estructurar qué conocimiento hay sobre cómo Se supone que el sistema debe comportarse.

Los escenarios dados / cuándo / luego le permiten entrar en detalles sobre lo que debe suceder y, dado que están escritos en inglés simple y estructurados, puede usarlos para comunicarse con su superior y cliente: "Escuche, He llegado a este punto y no tengo idea de qué se supone que debe hacer el sistema aquí ".

Si simplemente evitó cuando solicita una aclaración adicional, a pesar de que ha realizado un esfuerzo para documentar todo lo que hace y no comprende, los desarrolladores anteriores fallaron no porque no supieran cómo comunicar las especificaciones, sino porque Es imposible hacerlo.

En mi opinión, tanto (el cliente como el desarrollador) tienen que obtener la misma comprensión del problema y su solución.

Si no comprende la solicitud, no puede crear la solución.

Entonces tienes que leer las especificaciones. Si la especificación no es lo suficientemente clara (o no hay una especificación escrita), debería haber alguien que pueda dar las respuestas.

Trabajo en equipos que tienen una persona que puede responder las preguntas de negocios. El dueño de este negocio es un miembro de la empresa de desarrollo para la que trabajo que conoce el negocio de los clientes o un miembro del equipo de clientes.

Parece que en su situación específica, el gerente del proyecto teme que el cliente se moleste si se le hacen las mismas preguntas varias veces (necesarias debido a la rotación del desarrollador), y que esto se reflejará mal en él y su empresa.

Por supuesto, si no hace esas preguntas, le llevará mucho más tiempo completar / modificar el sistema y el resultado puede no ser lo que el cliente quería, lo que causará más demoras y TAMBIÉN se reflejará mal en el gerente del proyecto y su empresa, al menos a los ojos del cliente.

Hay algunas razones por las cuales el gerente de proyecto podría elegir no permitirle hacer preguntas:

1. Realmente no entiende las consecuencias negativas o las niega.
2. Conoce las alternativas, pero sabe que es más probable que el cliente acepte demoras y mala calidad que las preguntas molestas.
3. Está jugando juegos políticos: tal vez sabe que abandonará el proyecto pronto y quiere mantener ocultos los problemas hasta entonces, o planea culparlo por los problemas causados ​​por esta falta de comunicación.

La razón 2 de la OMI es poco probable. Para eliminar la razón 1, intente explicarle las alternativas y pídale que haga una elección explícita entre ellas, sugiérale que explique el problema al cliente para reducir la molestia. Para eliminar la razón 3, haga esto por escrito para que pueda probar que estaba al tanto de los posibles problemas desde el principio e intentó solucionarlos. Pero para ser honesto, si sospecha que esto es necesario, probablemente debería salir lo más rápido posible.

Creo que siempre es responsabilidad del proveedor de servicios asegurarse de que han entendido las intenciones de los clientes.

Como expertos en nuestro campo, no es solo nuestro trabajo completar informes sino también ayudar a guiar a nuestros clientes a través del proceso de uso de nuestro servicio, y esto implicó educarlos sobre las posibilidades que ofrecemos y lo que hacemos ahora.

Creo que un enfoque centrado en el cliente es absolutamente la forma de hacer las cosas, es un modelo comercial probado y probado.

El cliente y los desarrolladores deben trabajar juntos para refinar su comprensión del sistema.

La compañía de software necesita llegar a un acuerdo con el cliente sobre lo que se requiere de cada parte, ese es el aspecto fundamental de un contrato. Si no hay una "reunión de mentes", entonces, en un sentido muy real, no hay contrato.

Asumir que usted es un programador competente, si la especificación no es clara, simplemente decirle "Es su responsabilidad entender la solicitud, no hacer más preguntas" es bastante tonto.

Esto se basa en información nueva en los comentarios sobre la pregunta original.

La declaración de que

El cliente ya nos explicó lo que quiere. Es su responsabilidad entender la solicitud, no hacer más preguntas.

proviene del líder del proyecto; la justificación declarada es

que, dado que no soy el primer desarrollador del sistema, no deberíamos molestar al representante del cliente con más preguntas, sino intentar y, si es necesario, dedicar más tiempo a interpretar la pregunta

Entonces, lo que se le dice específicamente que evite es molestar al cliente con preguntas .

Pedirle que "pase más tiempo interpretando la pregunta" no es necesariamente irrazonable. Debe hacer un esfuerzo razonable, o tal vez incluso un esfuerzo poco razonable, para determinar cuáles son los requisitos en función de lo que el cliente ha dicho realmente. Si nada más, esa es una habilidad valiosa.

Si eso falla (y parece que ya lo ha hecho, por varias razones), solicite ayuda a su líder de proyecto. Trate de ser lo más específico posible en sus preguntas, mostrando que ha hecho su tarea. Por ejemplo, en lugar de

¿Qué quieren estas personas ?

pregunta algo como

En el párrafo 17 del documento de requisitos, dice que el foobar debe frizzlear el frozzle; ¿a cuál de estos tres frozzles se refiere eso? "

O, si los requisitos están realmente tan mal escritos que no puedes descifrarlos, díselo.

Yo diría que, en última instancia, es responsabilidad del líder del proyecto asegurarse de que los requisitos se entiendan correctamente (sin duda lo que más le interesa es que el proyecto tenga éxito). Pero como miembro del equipo, usted comparte parte de esa responsabilidad. Si demuestras que has hecho un esfuerzo por ti mismo y el líder del proyecto se niega a ayudarte, entonces es totalmente tu responsabilidad. Si llega a ese punto, asegúrese de que él lo sepa.

En un mundo perfecto, debería haber una lista de características y especificaciones en algún lugar, algo escrito en un contrato que vincule a su empresa y a su cliente.

Para responder a su pregunta, el desarrollador debe comprender lo que quiere el cliente y tener un documento escrito para que ambas partes acuerden la misma visión.

Por supuesto, este no es un mundo perfecto y, a menudo, no hay especificaciones, y si no tiene ninguna especificación escrita, bueno, esto será difícil. ¿Queda alguien en su empresa que trabaje como delegado de relaciones con el cliente y que pueda ayudarlo a comprender lo que quiere el cliente?

Si no, en su posición, trataría de obtener información de los desarrolladores anteriores, suponiendo que entendieran la tarea, por supuesto.

Creo que el rol real que especifica quién se encarga de comprender los requisitos varía según algunas de estas variables

• Tamaño del equipo
• Estándares de la empresa
• La forma en que el jefe está acostumbrado a trabajar
• Diferente experiencia entre los miembros del equipo.

Entonces, si usted es solo un equipo de un solo hombre, debe hacer todo lo posible para llegar al fondo de las solicitudes. Si es nuevo en un proyecto en curso, debe hacer un esfuerzo para repasar las solicitudes nuevamente con el cliente.

EDITAR: Lo más importante es que el cliente puede no saber que hizo requisitos tan pobres, y el proceso de recopilación de requisitos a menudo es largo y tedioso, pero es un proceso importante, y si recae sobre usted porque nadie más lo hace, entonces debe hazlo con ellos.