¿Cómo alentar al cliente a hacer algunas pruebas de control de calidad internas?

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

Pregunta: cómo alentar a los usuarios a que se tomen el tiempo para probar e informar explícitamente los problemas con las nuevas versiones, no para "probar 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 curso, agregando características a medida que avanzamos.

Hay dos problemas que tengo:

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

2. Prácticamente no se realizan pruebas de control de calidad por su parte.

Puedo lidiar con el n. ° 1, más o menos. Este no es un cliente que incluso leería una especificación antes de una reunión, y mucho menos escribir una. Estoy acostumbrado a eso. Es el elemento # 2 con el que tengo el problema: no prueban o no probarán nuevas versiones. Lo que hacen es usarlos para la producción, de modo que cuando surgen errores, encuentran una solución alternativa y no la informan, o tienen tanta prisa por continuar 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 fundamentales son dobles: son una pequeña empresa de consultoría y no tienen (o no creen que tengan) los recursos para realizar pruebas (ni el presupuesto para externalizarlo). Y cultural: aunque se consideran a sí mismos como "desarrolladores", en realidad son solo usuarios de un paquete de software multimedia. (por ejemplo, no tienen la atención obsesiva de la neurosis al detalle de los desarrolladores "reales").

Esto me afecta como era de esperar: sin comentarios no puedo decir si una característica está completa (ver # 1), o si hay otras consecuencias. También me está haciendo un poco vago.

no tienen la atención obsesiva de la neurosis al detalle de los desarrolladores "reales"

Prefacio : El tipo de lenguaje que usó aquí suele ser una señal de alerta para mí. Cuando escucho a la gente hablar sobre desarrolladores "reales" o la (única) forma "correcta" de hacer las cosas, empiezo a pensar en desarrolladores de culto de carga con visión de túnel .

Ahora, no estoy diciendo que definitivamente eres uno de estos desarrolladores (no tengo suficiente evidencia para afirmar eso), 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 necesariamente se alinean.

Los desarrolladores de software a menudo son personas apasionadas con un enfoque en la mejora. Les gusta mejorar el rendimiento del software, el proceso de desarrollo, los procesos comerciales, 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 pulsadores de teclas sin sentido.

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

Con frecuencia, las empresas desean optimizar para cosas como el lanzamiento temprano al mercado y el ahorro de costos a corto plazo. Al hacerlo, pueden necesitar sacrificar cosas como control de calidad, experiencia del usuario, ahorro de costos a largo plazo y otras cosas que hacen que los desarrolladores funcionen.

¿Es eso algo malo? Bueno, no necesariamente. No puedo hablar por todas las empresas, pero en 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. Peor aún, muchas empresas tienen estructuras de inversión que solo recompensan las ganancias a corto plazo en lugar de los enfoques sostenibles y las ganancias a largo plazo.

Entonces, si bien podría tratar de vender la idea de QA a su cliente, puede estar perdiendo el tiempo y forzando su relación con ellos. En el mejor de los casos, obtendrá a alguien ansioso por probar sus ideas (poco probable). En el peor de los casos, tendrá que convencer a toda la compañía para que reelabore sus estructuras de incentivos para que las inversiones a largo plazo como QA sean recompensadas. En cualquier caso, sus probabilidades de éxito son bajas.

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 el proyecto "hecho", gran problema.

El problema es cómo puede saber cuándo el cliente acepta el software y le paga. 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 difiere, 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ómodamente estricto, pero le permite planificar el proyecto por adelantado (también el próximo proyecto). También garantiza que obtendrá su dinero por 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 de las pruebas de aceptación .

Dicha prueba de aceptación realizada por un cliente es independiente de otras formas de prueba:

• pruebas unitarias
• pruebas de integración de sistemas
• 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 vergüenzas. Además de las pruebas de aceptación (que solo miden el cumplimiento del contrato , no la calidad del software ), toda la Garantía de calidad es su responsabilidad. En particular, su cliente no necesariamente tiene una mentalidad de control de calidad, la formación técnica necesaria o la obligación contractual de realizar el 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 sucedan. Suponiendo que tiene una relación basada en el proyecto con su cliente, querrá caminar en 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 tendrá que cumplir con el nivel de servicio acordado.

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

• Cuando conozca las nuevas necesidades del cliente, trabaje con el cliente para traducirlas a los requisitos. Esto ayuda al cliente a obtener lo que realmente quiere.
• Los requisitos son medibles objetivamente: se cumplen o no. Esto salva al cliente de soluciones a medias que solo funcionan.

• Todas las solicitudes de los clientes deben proporcionarse por escrito para que pueda facturarlas. Esto los protege de que se les facture por cosas en las que simplemente tenía ganas de trabajar, como reescribir toda la interfaz al pedir 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á un pedazo de papel para documentar que el cliente desea que trabaje en estos requisitos. En casos simples, puede ser suficiente recapitular una llamada telefónica y enviarles un correo electrónico para verificar lo que le pidieron que haga.

Los informes de errores siempre son difíciles. Si sus clientes son desarrolladores, eso debería ayudar, ya que pueden comprender sus necesidades: tener pasos claros para reproducirse. Una manera simple de obtener una visión poderosa es habilitar el inicio de sesión en el software implementado. Siempre que los problemas de privacidad de datos se puedan resolver, requerir que cada informe de error tenga el registro actual adjunto no solo garantiza una comunicación escrita, sino que también le dice lo que el usuario realmente hizo (en contraste con lo que pensaba que estaba tratando de hacer) .

La forma de fomentar la comunicación de errores es fomentar la comunicación frecuente y granular de características. Si capacita a una empresa para que pueda pedir cualquier cosa con ceremonia cero, también utilizará esa función para errores menores. Renunciar a los cambios en el flujo de trabajo de su cliente a menos que estos cambios hagan su vida más fácil.

Lograr que su cliente realice pruebas internas es difícil, pero lograr que realmente denuncien 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 transferirse algo de esa fricción a usted 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á destinado a la gestión de proyectos), pero la gente está realmente 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 un Guid), luego copia el Guid en el portapapeles. Después de un entrenamiento mínimo, un usuario puede adjuntar imágenes del portapapeles a los 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 propuestas están apuntando puntos de fricción que he experimentado, y ambas de estas sugerencias aumento de notificaciones en un factor de más de 10. Sin embargo, tendrá que orientar sus propios puntos de fricción.

Haga que las pruebas para su cliente sean fáciles, pero 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 entregas una nueva función, la implementas primero en una "versión beta", claramente marcada con un signo "no para producción". Esta versión beta está disponible para que el cliente la pruebe. También proporciona la última "versión de producción" que usará para la producción real (sin las nuevas características, pero con las últimas correcciones de errores), y se niega a transferir las nuevas características beta a la versión de producción hasta que reciba un comentario de que alguien en el lado de los clientes 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, entonces no puede ayudarlo, pero al menos dejó en claro que cada vez que pierde la producción funciona porque usó la versión beta para fines equivocados, ya que claramente es su culpa. Si el cliente no aprende de eso, puede considerar deshabilitar 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 "beta" por separado lo obligará a establecer un control de versión / administración de configuración adecuado, de modo que pueda administrar una rama de producción y una rama de prueba beta lado a lado sin problemas. Pero dado que está trabajando con Github, supongo que ya usa algo como GIT, lo que hace que este tipo de administración sea muy simple.