18_08_2023
Ambos documentos son importantes para guiar el desarrollo de un proyecto. Por un lado los documentos de diseño (SDD) describen detalladamente como desarrollar una parte del proyecto que puede ser una característica o una parte de la arquitectura, es un documento técnico a diferencia del documento de producto (PRD) que describe como debería ser el producto que se va a crear, en este caso es una aplicación.
El documento de producto proporciona una idea clara de hacia donde hay que ir, describe el producto que tenemos que crear. El documento contiene los criterios de éxito, una explicación sobre el potencial del producto (argumento de ventas) y los requisitos del producto incluyendo historias de usuario, es un documento para entender y explicar como es la aplicación que se quiere crear, por eso es de ayuda en el diálogo con el cliente y el resto de personas involucradas como los equipos de marketing y diseño.
Los documentos de diseño describen todo el proceso de desarrollo de una característica desde un plan con cronograma y puntos de control hasta los pros/contras del desarrollo y si es posibles diagramas que ayuden a comprender lo que se quiere crear.
La creación de estos documentos nos ayuda sobre todo en la comunicación entre el equipo y con el cliente, en caso de no tener un equipo o cliente estos documentos nos siguen ayudando a planificar y a poner nuestras ideas en claro sobre lo que queremos hacer, en general nos ayudan a programar. Desde otro punto de vista estos documentos nos permiten asegurarnos de estar haciendo las cosas bien obligándonos a pensar en el diseño y en todo lo que implica crear una aplicación o característica, a todo esto le podemos sumar que, sin ser el objetivo principal en un futuro servirán como documentación.
No hay una plantilla estándar para escribir estos documentos, pero si existen algunos puntos que se sugieren incluir en cada documento, junto con estas sugerencias también se recomienda mantener un lenguaje simple porque no es un documento académico sino algo que debería comprender cualquier persona sin malentendidos.
-
Encabezado: Título, nombre del autor, nombre de las personas que revisaron el documento y la fecha de la última actualización.
-
Resumen: Breve descripción de lo que se quiere crear ¿Qué hace la aplicación?
-
Implementación actual: Describir la actual implementación de la aplicación, esto si es un proyecto heredado.
-
Criterios de éxito: ¿Cuándo consideramos que la aplicación es un éxito y se llegó a donde se quería?
-
Los requisitos de la aplicación: Puedes incluir historias de usuario y prototipos de diseño (wireframes).
-
Un cronograma estimativo del desarrollo de la aplicación: Es recomendable establecer puntos de control, dividir todo el desarrollo en partes.
-
Sugerencias: Un lugar para plantiar decisiones polémicas, opiniones o sugerencias a futuro.
-
Encabezado: Título, nombre del autor y la fecha de la última actualización.
-
Resumen: Breve descripción de lo que se quiere desarrollar.
-
Contexto: El contexto de porque se quiere crear lo que se quiere crear.
-
Objetivos: Describir los objetivos, el impacto que puede tener y como se podría medir el éxito usando métricas al igual que los objetivos que no se cumplen.
-
La solución actual: Si existe alguna hay que describirla al igual que agregar ejemplos de alto nivel como historias de usuario.
-
La solución propuesta: Describir la solución que se propone, se pueden incluir historias de usuario, diagramas o subsecciones.
-
Impacto tiene en el equipo: ¿Aumenta la carga? ¿Cuánto dinero costaría? ¿Provoca regresiones? ¿Expone vulnerabilidades de seguridad? ¿Cómo se comunicaría al cliente? ¿Tiene consecuencias negativas o efectos secundarios? Todas estas preguntas pueden ayudarte a escribir esta sección.
-
Preguntas abiertas: Un lugar para sugerencias a futuro, opiniones o decisiones polémicas que puede haber.
/// https://www.linkedin.com/pulse/qu%C3%A9-es-el-documento-de-requerimientos-producto-product-beyer?utm_source=share&utm_medium=member_android&utm_campaign=share_via https://hlung.medium.com/prd-is-not-enough-we-need-sdd-83a3cc9d70df https://www.joelonsoftware.com/2000/10/02/painless-functional-specifications-part-1-why-bother/ https://leadershipreadme.substack.com/p/que-es-design-doc-rfc-o-prd https://www.freecodecamp.org/news/how-to-write-a-good-software-design-document-66fcf019569c/ https://www.joelonsoftware.com/2000/10/03/painless-functional-specifications-part-2-whats-a-spec/ https://historiadelaempresa.com/documento-de-diseno https://www.lucidchart.com/blog/es/como-crear-documentos-de-diseno-de-software ///