¿Es responsabilidad del desarrollador del software entender qué quiso decir el cliente con su solicitud?

12

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

¿Es responsabilidad del desarrollador del software entender qué quiso decir el cliente 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 mal ubicadas y oraciones difíciles de entender, algunas solicitudes suponen una comprensión previa del sistema por mi parte.

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

El sistema en sí está bastante desordenado tanto en la interfaz de usuario como en el nivel del código fuente. Esto me parece un código de mono, código y espero que recibas la solicitud correctamente, aunque en realidad no la entiendo.

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

    
pregunta Dante 03.05.2012 - 09:36

9 respuestas

41

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

La persona a quien le pregunta puede ser alguien que no es 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 en su lugar, debe responder las preguntas o remitirlo a alguien que pueda hacerlo.

Pero, al final, tiene que haber ALGUNA clase de comunicación. Si lo niegan (y proporcionar algunos documentos que no entiendes está negando efectivamente la comunicación), debes hacer lo que hicieron tus predecesores: huir rápidamente.

    
respondido por el keppla 03.05.2012 - 10:27
6

Cuando sus clientes y superiores lo dejan con un rastro de papel desordenado, lo único que puede hacer es reunir el mayor sentido posible de lo que tiene y comenzar a escribir escenarios en un lenguaje sencillo en un intento de estructurar el conocimiento que existe. sobre cómo se supone que se comporta el sistema.

Los escenarios dados / cuándo / entonces le permiten entrar en detalles sobre qué Tiene que suceder y, como están escritas en un lenguaje sencillo y estructurado, puede usarlas para comunicarse con su superior y cliente: "Escuche, llegué a este punto y no tengo idea de lo que se supone que es el sistema hacer aquí ".

Si simplemente se niega cuando solicita una aclaración adicional, a pesar de que ha invertido esfuerzos para documentar todo lo que hace y no entiende, entonces los desarrolladores anteriores no fallaron porque no sabían cómo comunicar las especificaciones , pero porque es imposible hacerlo.

    
respondido por el Filip Dupanović 03.05.2012 - 10:17
6

En mi opinión, ambos (el cliente y el desarrollador) tienen que entender lo mismo del problema y su solución.

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

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

Trabajo en equipos que tienen una persona que puede responder las preguntas de negocios. Este propietario del 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.

    
respondido por el k3b 03.05.2012 - 10:25
3

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

Por supuesto, si no hace esas preguntas, tardará mucho más en completar / modificar el sistema y el resultado puede no ser lo que el cliente deseaba, lo que causará más demoras y TAMBIÉN reflejará el proyecto de manera deficiente. gerente y su compañía, al menos a los ojos del cliente.

Hay algunas razones por las que el gerente de proyecto puede elegir no permitirte hacer preguntas:

  1. Él realmente no entiende las consecuencias negativas o está en negación acerca de ellas.
  2. Es consciente de las alternativas, pero sabe que es más probable que el cliente acepte retrasos y poca calidad que las preguntas molestas.
  3. Está jugando a juegos políticos: quizás sepa que está abandonando el proyecto pronto y quiere mantener los problemas ocultos hasta entonces, o planea culparlo por los problemas causados por esta falta de comunicación.

La razón 2 de la OMI es improbable. Para eliminar la razón 1, intente explicarle las alternativas y pídale que haga una elección explícita entre ellas; sugiera explicarle el problema al cliente para reducir la molestia. Para eliminar la razón 3, haga esto por escrito para que pueda probar que estuvo al tanto de los posibles problemas de los equipos desde el principio y trató de solucionarlos. Pero para ser honesto, si sospechas que esto es necesario, probablemente deberías salir lo más rápido posible.

    
respondido por el Michael Borgwardt 03.05.2012 - 12:37
2

Creo que siempre es responsabilidad del proveedor del servicio garantizar que hayan entendido las intenciones de los clientes.

Como expertos en nuestro campo, no solo es 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 involucró educarlos sobre las posibilidades que ofrecemos y lo que hacemos ahora.

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

    
respondido por el Mild Fuzz 03.05.2012 - 10:02
2

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.

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

    
respondido por el Jaydee 03.05.2012 - 10:11
2

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

La declaración de que

  

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

viene del líder del proyecto; la justificación indicada es

  

que, como no soy el primer desarrollador del sistema, no deberíamos   moleste al representante del cliente con más preguntas, pero intente y   si es necesario, dedique tiempo adicional a interpretar la pregunta

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

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

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

  

¿Qué quieren estas personas ??? "

preguntar algo como,

  

En el párrafo 17 del documento de requisitos, dice que el foobar debe encrespar la boquilla; ¿A cuál de estos tres frozzles se refiere? "

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

Diría que, en última instancia, es responsabilidad del líder del proyecto asegurarse de que los requisitos se entiendan correctamente (sin duda, lo mejor para él es que el proyecto tenga éxito). Pero como miembro del equipo, compartes parte de esa responsabilidad. Si demuestra que ha hecho un esfuerzo usted mismo, y el líder del proyecto se niega a ayudarlo, entonces es su responsabilidad. Si llega a ese punto, asegúrate de que sepa eso.

    
respondido por el Keith Thompson 03.05.2012 - 23:27
1

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 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 acepten la misma visión.

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

Si no, en su posición, intentaría obtener información de los desarrolladores anteriores, asumiendo que entendieron la tarea, por supuesto.

    
respondido por el XGouchet 03.05.2012 - 09:47
1

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

  • tamaño del equipo
  • normas de la compañía
  • La forma en que el jefe está acostumbrado a trabajar
  • Experiencia diferente entre los miembros del equipo

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

EDITAR: Lo más importante es que es posible que el cliente no sepa que hizo esos requisitos deficientes, y el proceso de recopilación de requisitos es a menudo largo y tedioso, pero es un proceso importante, y si cae en usted porque nadie más lo hace, entonces debe hacerlo. con ellos.

    
respondido por el Mithir 03.05.2012 - 10:07

Lea otras preguntas en las etiquetas