Escrito por Tim Ward
Artículo original.

I. Elimina la ambigüedad. Si puedes llegar a más de un entendimiento o conclusión, lo más probable es que así lo interprete también el desarrollador e ingeniero de pruebas.
II. Cuando utilices terminología, no asumas que todos tienen el mismo entendimiento. Obtén confirmación inmediata para evitar malos entendidos. Un glosario de términos y alias relacionados es muy útil.
III. Promueve la comunicación clara y directa y el uso de un lenguaje común cuando describes situaciones de negocio, reglas, normas, procesos, datos, etc. Si es necesario documentar algo en argot de negocios o TI entonces parafrasea su verdadero significado en lenguaje llano.
IV. Cuando utilices términos de negocios o TI para describir algo, siempre confirma su definición (ejemplo: cuando decimos “transferir” significa…)
V. No pidas permiso, pide absolución
VI. Entiende las diferencias culturales dentro o entre las entidades organizacionales de negocio y TI. Ayudará a seguir otros mandamientos.
VII. Los requisitos describen lo que algo es, así como lo que no es.
VIII. Cuando elicites requisitos, realiza preguntas de aclaración para confirmar que los requisitos están siendo claramente registrados
IX. Cuando elicites requisitos, es importante identificar la audiencia afectada (ejemplo: líneas de negocio, productos, tipos de planes, etc.)
X. Cuando documentes requisitos, decisiones o resolución de asuntos, es igualmente importante documentar el “porqué” tanto como el “quién”, “qué”, “cuándo”, “dónde”, y “cómo”. Si no lo haces, lo más probable es que nadie recordará después porque se fueron por cierto camino.
XI. Cuando definas requisitos, recuerda que tienen que ser comprobables. Si no lo puedes probar adecuadamente, entonces el requisito no está definido de forma adecuada.
XII. No hay supuestos, solo un entendimiento actual de los hechos. El uso de los supuestos solo promueve el crecimiento de características anatómicas indeseables.
XIII. Cuando escribas (o hables), ponte en los zapatos de los lectores (o escuchas). ¿Pueden realmente entender lo que estoy tratando de comunicar basado únicamente en las palabras que escrito o hablado? ¿Existe alguna expectativa de que la audiencia tenga algún conocimiento implícito en comprender el tema?
XIV. Trata a tus desarrolladores y equipo de trabajo de soporte técnico como deseas ser tratado: como un aliado confiable y buen amigo
XV. Entiende que las personas que requieren de tus servicios como analista de negocio no siempre saben lo que quieren y/o están en posibilidad de articular efectivamente sus necesidades. Es por esto que Dios invento a los analistas de negocio.
XVI. Como experto confiable en el tema, las personas usualmente creerán lo que dices como un hecho, especialmente si eres bueno comunicando claramente. Estando en esa posición de confianza, existe un riesgo inherente que algunas veces te equivoques en tu entendimiento (y no estés consiente). Sin embargo, eres lo suficientemente persuasivo para convencer a todos de esa verdad. Necesitas confiar en otros para estar en posibilidad de detectar la transmisión de falsas verdades antes de que sea demasiado tarde.

No olvides dejar tus comentarios.