¿Cuáles son las mejores prácticas para que una persona no técnica se comunique con los desarrolladores?

1. Comunique sus requisitos claramente y por escrito, siempre. Como dijo Scott Danzig, explique solo su necesidad y no la solución.

2. Establezca expectativas realistas para el trabajo: establezca una fecha límite mediante consultas mutuas y luego multiplique eso por 2 (o, a veces, 3). Puede reprender a un desarrollador por deslizarse en un plazo acordado, pero tenga en cuenta que es muy difícil predecir cuánto tiempo llevará algo en el mundo del software y es raro que el deslizamiento se deba a la pereza.

3. Establezca reuniones regulares de 2 minutos de “base táctil” para mantenerse actualizado sobre su progreso. Esto evita sorpresas desagradables.

4. Siéntese con los desarrolladores y obtenga “casos de uso de extremo a extremo” que desee que funcionen. Cuando el desarrollador afirme que ha terminado, siéntese con ellos y revise cada caso de uso para asegurarse de que esté funcionando. Esto debe hacerse por escrito, preferiblemente con diagramas, si corresponde.

5. Deje en claro que desea mantener este código y, por lo tanto, debe documentarse / comentarse adecuadamente. Puede hacer que uno de sus amigos codificadores lo revise antes de cerrar la sesión si le preocupa esto.

6. Si encuentra un error o algo inesperado, escriba una lista completa de pasos de principio a fin, y luego indique tanto el resultado esperado como el real. Sea muy explícito y mencione cada paso detallado . Esto puede parecer extraño y exagerado para una persona no técnica, pero es la mejor manera de llegar a una solución rápida incluso en errores aparentemente “fáciles de solucionar”, etc. Ahorrará mucho dolor de cabeza.

Algunos puntos extra:

– Si esto es parte de un equipo de inicio o producto, deje que los desarrolladores tengan un poco de creatividad y diseño parte del producto. No es necesario que sea grande, pero dejar que los desarrolladores tengan una salida creativa y una mano (aunque sea pequeña o grande) en el diseño puede ser de gran ayuda para motivarlos. Si se trata de un trabajo por contrato o algo similar, haga exactamente lo contrario y sea muy explícito sobre lo que quiere.

– A veces un desarrollador encuentra un gran problema inesperado cuando intenta implementar algo “fácil”. No podrían haber anticipado esto, y probablemente tendrán que dedicar muchas “horas” gratuitas para que funcione. Aprecia esto. Pregúnteles cuánto tiempo tardó, deles un regalo / dinero extra / una nota de agradecimiento. No te arrepentirás de esto.

– En lugar de decirles simplemente “Quiero esto”, explíqueles la motivación detrás del producto / característica. Probablemente enfrentarán decisiones que no se mencionaron explícitamente en los requisitos, y si saben quién usará el producto (y para qué), pueden tomar estas decisiones fácilmente y no tiene que preocuparse por suposiciones inválidas de su parte.

Gracias por A2A. Depende del nivel y del alcance: un CIO de una empresa de $ 500 millones / año habla con el Arquitecto Jefe, o el propietario de una pequeña empresa habla con un desarrollador de iOS sobre una aplicación.

Sin embargo, algunas reglas comunes se mantienen:

1. Habla solo de lo que sabes. Digamos que sabes bases de datos? Si no, no uses la palabra.
2. Separe lo que es de importancia crítica para usted de cómo cree que podría lograrse. Desechar la segunda parte.
3. Aclare lo que debe lograrse con detalles suficientes pero abstractos. En su mente, agregue “todo lo que se ajuste a la descripción será bueno”
4. No dude en afirmar criterios de éxito, incluso de manera informal como “me va a gustar el diseño”
5. Cuantifique lo que pueda, especialmente cuando se le acerque con palabras de moda o detalles técnicos. Alguien le vende “mayor agilidad”: insista en describirlo en sus términos y en obtener algunos números.
6. Insista en una revisión temprana, en un enfoque interactivo que le dará confianza justificada de que todo está en el camino correcto.
7. Como de costumbre, no firme documentos que no entienda. Especialmente si el documento se llama “Especificaciones de diseño” y tiene más de 500 páginas para un proyecto pequeño.

Actuando como facilitador, generalmente logro más arriba usando modelado a nivel empresarial con Sparx Enterprise Architect: podría haber otras formas, sin embargo, mi empresa ha estado capacitando a personas para usar ese software en particular durante más de una década. Mi mercado son empresas más grandes, así que empiezo con el Modelo de Motivación Empresarial, luego produzco el Modelo de Información Comercial, que es una entidad muy básica o un diagrama de clase. Luego definimos capacidades, y quizás procesos de negocio. Luego, refine el Modelo de Motivación a Objetivos cuantificados.

Para proyectos más pequeños, a veces todo lo que necesita es un conjunto de maquetas de Balsamiq.

¿Más detalles?

Deje que los requisitos del usuario final hablen. Al ser una persona no técnica, la mayoría de las veces representará a los usuarios finales, por lo que su necesidad estará casi alineada con las expectativas reales de la aplicación que el equipo está desarrollando. Antes de discutir con un desarrollador, intente comprender claramente el requisito. La parte técnica que discutirá con su desarrollador podría tener un impacto muy limitado en el requisito, pero lo ayudará a establecer claramente su punto en la discusión y obtener aclaraciones.

Diga lo que necesita, no cómo hacerlo. Si no entiende, dígalo de inmediato. Intente hablar con ellos por correo electrónico o mensajería instantánea, o durante sus descansos. No asumas con seguridad lo que no sabes, y si te piden algo, no asumas que no es importante. Haga un poco de solución de problemas no técnicos primero, antes de nada de esto, si algo no funciona.

¡Hola! Creo que todo es posible si realmente pones tu corazón en ello y lo haces. El valor es todo lo que se necesita. Creo que puede investigar compañías que son desarrolladores con los que desea asociarse / trabajar y concertar un horario para reunirse con el gerente o simplemente ingresar a su oficina y decir ‘oye, estoy interesado en saber más sobre el desarrollo, etc.’ Probablemente el mejor hablar en persona para obtener información y conversaciones de calidad que valgan su tiempo. Totalmente depende de usted si desea enviarles un correo electrónico o hablar con ellos por teléfono. ¡Buena suerte!

Somos bastante fluidos en nuestra lengua materna.