¿Cómo animar al cliente a hacer algunas pruebas de control de calidad en casa?

14

Actualización / Aclaración Mi cliente entiende la necesidad de sus pruebas internas y siempre jura que "harán mejor" (es decir, harán algo) pero simplemente no sucede No tienen el presupuesto para pruebas externas. Supongo que estoy preguntando (vagamente, reconozco) qué podría inculcar una "prueba temprana, prueba a menudo, prueba en el espíritu de las máquinas objetivo".

Pregunta: cómo animar a los usuarios a tomarse el tiempo para probar e informar explícitamente los problemas con las nuevas versiones, no para hacer "pruebas sobre la marcha" en proyectos de producción.

Antecedentes: tengo un pequeño cliente para el que he escrito un conjunto de herramientas de presentación multimedia. Son un buen cliente y tenemos una buena relación. El proyecto está en marcha, agregando características a medida que avanzamos.

Hay dos problemas que tengo:

  1. La definición de la función se realiza sobre la marcha, a menudo por teléfono, sujeta a cambios, revisión, revocación. (un poco como el de Kennedy: "Iremos a la luna y haremos las otras cosas". Siempre me han divertido las "otras cosas" que forman parte de eso)

  2. Prácticamente no se realizan pruebas de control de calidad en su final.

Puedo lidiar con el # 1, más o menos. Este no es un cliente que incluso lea una especificación antes de una reunión, y mucho menos que escriba una. Estoy acostumbrado a eso. Es el elemento # 2 con el que tengo el problema: no prueban o no prueban nuevas versiones. Lo que hacen es usarlos para la producción, de modo que cuando surjan errores, encuentren una solución y no informen, o tengan tanta prisa por seguir adelante con el proyecto, que los informes de errores son vagos.

Hemos tenido muchas discusiones sobre todo esto, pero solo he podido empujarlos un poco (por ejemplo, usamos github para el seguimiento de problemas, aunque principalmente lo uso). Las razones de raíz son dobles: son una pequeña empresa de consultoría y no tienen (o no creen que tengan) los recursos para las pruebas (ni el presupuesto para subcontratarla). Y cultural: aunque se consideran a sí mismos como "desarrolladores", en realidad solo son usuarios de un paquete de software multimedia. (Por ejemplo, no tienen la neurosis obsesiva al detalle de los desarrolladores "reales").

Esto me afecta como es de esperar: sin comentarios, no puedo saber si una función está completa (ver # 1), o si hay otras consecuencias. También me está volviendo un poco perezosa.

    
pregunta No Grabbing 10.12.2015 - 20:41

4 respuestas

18
  

no tienen nada de la neurosis obsesiva atención a los detalles de los desarrolladores "reales"

Prefacio : el tipo de lenguaje que usaste aquí es típicamente una bandera roja para mí. Cuando escucho a la gente hablar sobre desarrolladores "reales" o la (una y la única) manera "correcta" de hacer las cosas, empiezo a pensar en un túnel visualizado desarrolladores de carga-culto .

Ahora, no estoy diciendo que definitivamente seas uno de estos desarrolladores (no tengo pruebas suficientes para afirmarlo), pero si lo eres, entonces podrías beneficiarte de esta respuesta.

Responder

Parece que usted y su cliente están optimizando para diferentes cosas. Es un hecho desafortunado en la ingeniería de software que a menudo las necesidades del negocio y los deseos de los desarrolladores no se alinean necesariamente.

Los desarrolladores de software suelen ser personas apasionadas con un enfoque en la mejora. Les gusta mejorar el rendimiento del software, el proceso de desarrollo, los procesos empresariales, los métodos de comunicación, etc. Y eso es genial. Centrarse en estas cosas es lo que separa a los artesanos y artesanas de los aplastadores de llaves sin mente.

Pero, su cliente no es un artesano de software. Su cliente es un negocio con un conjunto de prioridades completamente diferente. Y, a veces, esas prioridades nos parecen ridículas a los expertos en software ... pero eso es solo porque estamos optimizando para diferentes cosas.

Las empresas a menudo desean optimizar para cosas como el lanzamiento temprano al mercado y los ahorros de costos a corto plazo. Al hacerlo, es posible que tengan que sacrificar cosas como control de calidad, experiencia de usuario, ahorros de costos a largo plazo y otras cosas que hacen que los desarrolladores se sientan atraídos.

¿Eso es algo malo? Bueno, no necesariamente. No puedo hablar por todas las empresas, pero según mi experiencia, mis clientes hacen estas cosas para aumentar su propio ROI (retorno de la inversión). Hacer cosas como control de calidad, refinamiento de UX y planificación a largo plazo les ofrece un ROI más bajo. Lo que es peor, muchas empresas tienen estructuras de inversión que solo recompensan los beneficios a corto plazo en lugar de los enfoques sostenibles y los beneficios a largo plazo.

Entonces, mientras podría tratar de vender la idea de control de calidad a su cliente, puede estar perdiendo el tiempo y forzando su relación con ellos. En el mejor de los casos, conseguirás a alguien que quiera probar tus ideas (poco probable). En el peor de los casos, tendrá que convencer a toda la compañía para volver a trabajar sus estructuras de incentivos para que las inversiones a largo plazo, como el control de calidad, sean recompensadas. En cualquier caso, sus probabilidades de éxito son bajas.

    
respondido por el MetaFight 10.12.2015 - 22:11
10

La pregunta interesante es cuándo le pagan, no si su cliente realiza alguna prueba por su cuenta.

  • si le pagan en función de su tiempo, no hay problema.
  • si le pagan por adelantado, no hay problema.
  • si le pagan cuando el cliente declara que el proyecto está "hecho", gran problema.

El problema es cómo saber cuándo el cliente acepta el software y le pagará. Esto claramente no funciona cuando el cliente modifica continuamente el proyecto con nuevas solicitudes vagamente definidas. Si esto significa que el día de pago siempre se aplaza, y se vuelve más improbable por cada solicitud, esto se vuelve insostenible para usted.

Un contrato fijo que especifica cuidadosamente todas las características y define en qué condiciones el cliente aceptará estas características es claramente muy incómodo, pero le permite planificar el proyecto por adelantado (también el próximo proyecto). También garantiza que obtendrá su dinero para el software que entregó, si cumple con las especificaciones. En tal escenario, la única responsabilidad de un cliente es durante la fase de definición del contrato, y al final para pruebas de aceptación .

Las pruebas de aceptación realizadas por un cliente son independientes de otras formas de prueba:

  • pruebas unitarias
  • pruebas de integración del sistema
  • pruebas de usabilidad
  • pruebas de carga
  • pruebas de prelanzamiento

En la medida de lo posible, anticiparía las pruebas de aceptación y las realizaría usted mismo antes de entregar la funcionalidad para evitar cualquier vergüenza. Además de las pruebas de aceptación (que solo miden cumplimiento de contratos , no calidad de software ), todo el Aseguramiento de la Calidad es su responsabilidad. En particular, su cliente no necesariamente tiene una mentalidad de control de calidad, los antecedentes técnicos necesarios o la obligación contractual de hacer control de calidad. Además, encuentro que la búsqueda de errores de outsourcing para el cliente es bastante poco profesional.

Eso no quiere decir que los errores no sucedieran. Suponiendo que tenga una relación basada en el proyecto con su cliente, querrá recorrer una línea entre ser cortés y proporcionar soluciones rápidamente, y explicar que han aceptado la versión actual como suficiente para sus necesidades: los grandes cambios requieren un nuevo contrato. Si tiene un contrato de soporte continuo, por supuesto, deberá cumplir con el nivel de servicio acordado.

En un entorno ágil, responder a las necesidades del cliente se valora más que atenerse a la letra del contrato, pero aún así querrá que le paguen. Por lo tanto, muchas metodologías de proyectos de orientación ágil valoran la interacción cercana con el cliente, hasta el punto de que el cliente puede formar parte del equipo. A continuación, siempre puede hablar con este "propietario del producto" para aclarar los puntos necesarios. Dado que la orden de compra tiene la autoridad de otorgarle el tiempo para trabajar en cualquier característica que considere valiosa, esto puede funcionar incluso cuando se comienza con necesidades vagas de los clientes. Si no tiene una comunicación tan cercana, deberá seguir un enfoque más formal.

  • Cuando descubra las nuevas necesidades de los clientes, trabaje con ellos para traducirlos a los requisitos. Esto ayuda al cliente a obtener lo que realmente quiere.
  • Los requisitos se pueden medir objetivamente, ya sea que se cumplan o no. Esto ahorra al cliente la mitad de las soluciones que solo funcionan.
  • Todas las solicitudes de los clientes se deben proporcionar por escrito para que pueda facturarlos. Esto evita que se le facturen las cosas por las que simplemente desea trabajar, como volver a escribir toda la interfaz cuando solicita que un botón se alinee de manera diferente.

    Se puede hacer mucha comunicación en persona o por teléfono, pero al final querrá una hoja de papel para documentar que el cliente quería que trabajara en estos requisitos. En casos simples, podría ser suficiente para recapitular una llamada telefónica y enviarles un correo electrónico para verificar lo que le pidieron que hiciera.

Los informes de errores son siempre difíciles. Si sus clientes son desarrolladores, eso debería ayudar, ya que pueden entender sus necesidades: tener pasos claros para reproducir. Una forma sencilla de obtener una visión poderosa es habilitar el registro en el software implementado. Siempre que se puedan resolver los problemas de privacidad de los datos, exigir que cada informe de error tenga el registro actual adjunto no solo garantiza una comunicación escrita, sino que también le informa lo que realmente hizo el usuario (en contraste con lo que pensaron que estaban intentando hacer) .

    
respondido por el amon 10.12.2015 - 22:18
2

La forma de fomentar la comunicación de errores es fomentar la comunicación frecuente y granular de características. Si entrenas a una empresa para que puedan pedir cualquier cosa con ceremonia cero, también usarán esa característica para los errores menores. Renuncie a cambiar al flujo de trabajo de su cliente a menos que estos cambios les faciliten la vida.

Lograr que su cliente realice pruebas internas es difícil, pero lograr que informen realmente sobre errores no es tan difícil como parece. La forma de obtener más comentarios es reducir la fricción del usuario ... incluso si eso significa transferir algo de esa fricción a ti mismo.

  1. Use herramientas más simples, incluso si esas herramientas son inadecuadas e inapropiadas. Por ejemplo, BaseCamp es un rastreador de errores bastante horrible (porque está diseñado para la gestión de proyectos), pero la gente realmente está dispuesta a usarlo.

  2. Como los rastreadores de errores que estábamos usando no admitían copiar y pegar imágenes, escribí un programa trivial que copia la imagen actual del portapapeles en el disco (como Guid), luego copia el Guid en el portapapeles. Después de un entrenamiento mínimo, un usuario podría adjuntar imágenes del portapapeles a problemas simplemente presionando la pantalla de impresión, haciendo clic en un botón y luego pegando en el cuadro de diálogo de selección de archivos de la herramienta de envío de errores.

Una captura de pantalla (posiblemente editada en MS Paint con anotaciones) y 1-2 oraciones es suficiente para identificar la mayoría de las características / errores.

Ambas sugerencias apuntan a los puntos de fricción que experimentó I , y ambas sugerencias aumentaron el informe en un factor de más de 10. Sin embargo, deberá apuntar sus propios puntos de fricción.

    
respondido por el Brian 11.12.2015 - 13:56
1

Facilite las pruebas para su cliente, pero haga que sea realmente difícil para su cliente usar cualquier característica nueva en una versión no probada en producción. Esto se puede lograr de la siguiente manera:

Cada vez que se entrega una nueva característica, se implementa primero en una "versión beta", claramente marcada con un signo "no para producción". Usted pone esta versión beta a disposición del cliente para su prueba. También proporciona la última "versión de producción" que utilizará para la producción real (sin las nuevas funciones, pero con las últimas correcciones de errores), y se niega a transferir las nuevas funciones beta a la versión de producción hasta que reciba la respuesta de alguien en el lado del cliente al menos lo ha probado primero.

Si el cliente comienza a usar la versión beta en sus datos de producción reales, aunque siempre muestra un gran mensaje "No es para uso de producción" cada vez que inicia el programa, no puede ayudarlo, pero al menos lo dejó claro. pierde el trabajo de producción porque usó la versión beta para propósitos incorrectos y es claramente su culpa. Si el cliente no aprende de eso, puede considerar desactivar la capacidad de su cliente para usar la "beta" en producción desactivando algunas funciones cruciales como guardar los resultados en el disco en la "beta", si es necesario.

Proporcionar una "versión beta" por separado lo obligará a establecer una gestión de configuración / control de versión adecuada, para que pueda administrar una rama de producción y una rama de prueba beta lado a lado sin problemas. Pero como estás trabajando con Github, supongo que ya usas algo como GIT, lo que hace que este tipo de gestión sea muy simple.

    
respondido por el Doc Brown 11.12.2015 - 06:41

Lea otras preguntas en las etiquetas