Startups: ¿Cuáles son algunas formas creativas de escribir especificaciones de software cortas pero eficientes?

Answer 1

Daré un par de respuestas:

1. una “mini-especificación” funciona en muchos entornos donde se necesita un documento para cumplir con los requisitos contractuales o para satisfacer a los grupos de TI corporativos. Esto es simplemente una especificación de software abreviada de 5 a 25 páginas que contiene un resumen de requisitos, suposiciones, restricciones, etc. según las necesidades del proyecto y el cliente. Las claves son brevedad, revisiones periódicas con las partes interesadas del proyecto para mantenerlo actualizado y relevante, y una estricta política de gestión de alcance y orden de cambio para hacer cumplir un proceso de entrega incremental. Esto se complementa con prototipos, interfaces y modelos de datos abreviados de manera similar, etc. Sin magia, solo procesos de software tradicionales de manera muy abreviada. Esto generalmente funciona bien para clientes corporativos tradicionales que se sienten cómodos con dichos documentos de grandes proyectos.
2. Como sugieren otras respuestas, para clientes no tradicionales (startups para herramientas web, pequeñas empresas con administración más joven y audiencias técnicas), los documentos gráficos e interactivos pueden funcionar de manera efectiva. Esto podría ser un wiki, un sitio web o herramientas más sofisticadas como Trellis, DebateGraph u otras herramientas similares.

Para mí, el resultado final es ajustar las entregas con las limitaciones del proyecto, las expectativas del cliente y el nivel de comodidad del cliente con aplicaciones modernas y la voluntad de adoptar nuevos enfoques.

Answer 2

En primer lugar, debemos distinguir aquí lo que quiere decir con especificaciones. A menudo la gente mezcla dos cosas aquí:

• Las especificaciones funcionales , que conciernen a la funcionalidad de un software, independientemente de su implementación o cualquier detalle técnico
• Las especificaciones técnicas , que se ocupan de los aspectos de implementación específicos de la tecnología.

Asumiré que estás hablando de especificaciones funcionales aquí. Entonces, la mejor manera de crear especificaciones funcionales cortas pero eficientes es siguiendo la Metodología ágil y más específicamente aquí usando el concepto de User Story.

Este concepto es muy simple, debe entrevistar a los futuros usuarios de su software para recopilar Historias de usuarios atómicas, lo que significa cómo interactuarán con el software, siguiendo este prototipo:

Como ___________, quiero ___________, para que ___________.

Por ejemplo :

Como vendedor, quiero ver un resumen de todas las ventas por día, para poder optimizar el negocio.

Eso es tan simple como eso y aún mucho más eficiente que escribir fríamente las especificaciones largas y detalladas a la antigua usanza. El punto principal aquí es que está involucrando completamente a los futuros usuarios en el diseño del software, que es la razón por la cual este método es más creativo porque involucra a todos en el proceso.

Todas las Historias de usuario atómicas forman lo que llamamos el Backlog del producto. Luego, las Historias de usuarios siguen un ciclo de vida específico durante el desarrollo del producto, por lo que, de hecho, utilizando este método, las especificaciones no se escriben una vez al comienzo del proyecto, sino de manera continua durante el proceso de desarrollo, como se explica en este esquema:

Por lo general, siguiendo esta metodología, ni siquiera tiene que escribir explícitamente las especificaciones como un documento formal. Su Backlog en sí es las especificaciones y eso es suficiente.

Sin embargo, si realmente necesita un documento formal también, que puede justificarse en algunos casos, como por ejemplo, si el equipo se extiende geográficamente, esta publicación explica un enfoque bueno y creativo para hacer eso:

Una especificación funcional ágil – its-all-design.com

Answer 3

Sospecho que esta no es una respuesta muy creativa, pero trello.com, google keep y servicios como ese son un buen conjunto de lugares para obtener una lista de tareas pendientes. Si sigue prácticas lean, comience con una presentación. Haga diapositivas que promuevan su idea y luego trabaje en implementar esas diapositivas. Si la presentación se vuelve demasiado compleja, es hora de pasar a un administrador de listas, después de que el administrador de listas se vuelve demasiado complejo, es hora de pasar a un rastreador de errores (o algo similar) como JIRA / Confluence, Target Process o un sistema similar.