¿Cuál es la mejor manera de escribir funciones de software?

Si pregunta cuál es la “MEJOR” forma, le daré mi opinión:

Como propietario de un producto, la mejor manera de proporcionar funciones a la ingeniería es a través de la interfaz de usuario. La interfaz de usuario se convierte en los requisitos. NO es algo que se crea después de que los requisitos se escriben en alguna parte.

Esto es lo que quiero decir. En algún momento de tu carrera, voy a asumir que has visto esto antes:

Si tienes las habilidades, aquí hay una excelente manera de evitar esto.

Lo primero es que después de hacer su tarea y comprender realmente el problema que está tratando de resolver desde un punto de vista conceptual y práctico. Debe conocer su alcance general sin hablar con nadie. (Por supuesto, consígalo con su equipo de diseño e ingeniería), pero al final del día, USTED debe comprender qué problema está tratando de resolver desde una perspectiva conceptual y práctica.

Por ejemplo: ¿Es una nueva sección o solo una página? ¿Sigue la misma interfaz de usuario que otras secciones o es algo nuevo?

Una vez que lo entienda en ese nivel, vaya directamente a la creación de prototipos. Sugeriría usar algo como Axure, Invision, Figma o algo por el estilo. Simula y crea un prototipo en el que puedas hacer clic para que puedas guiar a las personas. A menudo hago esto primero y luego lo muestro al equipo de UX y a la ingeniería.

Hay una práctica común para escribir características / epopeyas / historias / requisitos en una hoja de cálculo. Mucha gente tiende a escribir requisitos que son bastante vagos, a pesar de sus mejores intenciones. (Seamos realistas: como propietario de un producto, debe conocer su interfaz de usuario y también debe saber leer y escribir en la guía de marca y estilo de su producto).

Las hojas de cálculo están abiertas a interpretaciones que generan preguntas o, en el peor de los casos, una oportunidad para que sus desarrolladores interpreten mal los requisitos. ¿Ves esa imagen allá arriba? Eso es lo que sucede.

Al construir la IU inicial, te obligará a pensar de manera integral sobre lo que estás tratando de hacer. ¿Quieres poner un menú desplegable? ¡Excelente! ¿A dónde se vincula? Ahora tienes que pensarlo. ¿Quieres hacer un gráfico brillante? ¡Excelente! ¿Pero de dónde provienen esos datos? Estará mucho más preparado para presentar esto a su equipo UX o su equipo de ingeniería haciéndolo de esta manera.

Es posible que no lo haga bien las primeras diez veces, pero su equipo inmediatamente tendrá algo en lo que hundir sus dientes y tendrá un contexto sobre el problema que está tratando de resolver. También encuentro que también acelera la conversación y evita no solo la pregunta de “¿qué es exactamente lo que estás tratando de hacer?” Sino que evita ese escenario que está pintado en el diagrama de arriba.

Puede que no haya una sola “mejor” forma. Al observar proyectos que lo hacen bien, ve algunas actividades comunes:

1. Involucrar a un cliente (o múltiples) temprano – para revisar y refinar durante todo el proceso.
2. Usando imágenes. Dibuja la interfaz de usuario. Use diagramas de flujo para capturar rutas de decisión.
3. Agrupando características en “áreas funcionales” – y define claramente el objetivo para cada área funcional. Sea claro por qué el área de características vale la inversión.
4. Califique por importancia: para cada función en un área funcional, califíquela por importancia (esencial, importante, agradable, etc.). No todo es esencial.
5. Intente regularmente reducir la lista de características. Las listas de funciones se cargan con cosas que suenan importantes, pero que realmente no harán una gran diferencia para el cliente final. Programe sesiones regulares de investigación / poda.
6. Creación de bucles de retroalimentación: entre las primeras compilaciones de características y clientes. Las especificaciones de características nunca son 100% correctas, a lo sumo son 80%. Los circuitos de retroalimentación ayudan a encontrar y cerrar esa brecha.
7. Priorice entre velocidad de implementación o completitud de especificación. es decir, codifique, cree e implemente características ‘tal como se describen’ o espere hasta que todas las características estén documentadas antes de codificar. Algunos proyectos quieren velocidad (por ejemplo, startups), por lo que documentan las características muy a la ligera (aún utilizando los puntos anteriores) y crean solo las tareas de trabajo para los desarrolladores. Otros proyectos quieren todas las características especificadas primero antes de implementar cualquier cosa (generalmente entornos corporativos), en cuyo caso se crean documentos de especificaciones funcionales y luego se ‘entregan’ al desarrollo. Es una elección de velocidad vs riesgo. Aquí también comienzas a ver algunas de las diferencias conceptuales entre Agile y Waterfall.

También hay otras actividades, pero esta lista es un conjunto básico de cosas que verá. Puedes debatir sobre el punto 7, por eso lo pongo al final. Realmente tomas esta decisión primero, deliberadamente o no.

Hola,

No soy desarrollador, pero trabajo con muchos. Tuve el placer de participar en sesiones de lluvia de ideas sobre software, funciones y desarrollo. Ni siquiera estoy cerca de escribir una sola línea de código, pero por lo que he visto, puedo decirte que las características nacen en dos pasos:

• Ideas : al creador se le ocurre una idea, una solución a un problema determinado. Este problema crea algunas expectativas, requisitos. Indica lo que debe hacerse para superar EL PROBLEMA, y obliga a los desarrolladores a resolverlo creando funciones.
• Comentarios : la versión beta de su software puede permitirle obtener algunos comentarios valiosos. Vea qué funciona y qué debe cambiarse. No se aferre a algunas respuestas. Sé paciente y recuerda que todos somos diferentes.

Trabajar en equipo. No seas un “héroe de un solo hombre”. Incluso si funciona al principio, podría volverse en su contra eventualmente.

Cuando se trata de la toma de decisiones, intente con la vieja democracia. Y recuerde las necesidades de los usuarios: después de todo, el software que crea es para atenderlos.

Espero haber ayudado 🙂