Siguiendo con la calidad "partida"

Respecto a los ítem c y d que menciona Raúl, como testers hemos observado (y sufrido) muchas veces las consecuencias de estos aspectos (que son sólo unos pocos de los muchos que pueden dificultar el éxito de nuestro trabajo):

• Características de calidad no especificadas o no cuantificadas con metas claras.
• Dificultades para lograr que el cliente o su representante definan cuáles son los requerimientos, casos de uso o escenarios funcionales prioritarios para su aplicación, según la especificación de la que se parta.
• Dificultades para lograr que el cliente o su representante entiendan la necesidad y conveniencia de priorizar los defectos para su corrección, y la lleven a cabo oportunamente.
• Escasa o total ausencia del cliente o su representante hasta que el producto es finalmente entregado para aceptación.

Esto resulta en mayores riesgos en el proyecto, mínimamente respecto a:

• Poder pensar, planificar y luego controlar, qué conviene probar del producto de software dado, para mitigar adecuadamente los riesgos identificados en relación al producto, a su contexto y a su devenir.
• Ajustar los planes a lo importante y a las restricciones existentes.
• Poder negociar alcance (y no tener que hacer recortes / "negociación" de la calidad).

Inclusive, dado que "riesgo" no es una palabra bien recibida en muchos casos, ... "de eso mejor no hablar en este proyecto o con este cliente".

Muchos de estos aspectos afectan también a quienes lideran proyectos, diseñan, analizan y desarrollan específicamente, ya que se encuentran con muchas indefiniciones, y pueden tomar decisiones incorrectas o inconvenientes que afectarán a lo esperado por el cliente y a los resultados del proyecto.