Se me ha pedido que lidere el desarrollo de productos en un equipo. Este es un viaje algo nuevo para mí porque generalmente estoy acostumbrado a llamarme diseñador web en lugar de gerente de producto o estratega.
La parte más difícil de este trabajo para mí ha sido organizar mis pensamientos. Escribí un resumen ejecutivo para el producto que estamos construyendo, hice una investigación competitiva e incluso desempolví mi limitada educación MBA para un análisis FODA. ¡Oh, sí, ahora parece que sé lo que estoy haciendo!
Muchos de nosotros que leemos Programar Pluscon algún tipo de regularidad probablemente tengamos que pensar estratégicamente para hacer nuestro trabajo, ya sea en diseño, desarrollo o ambos. Lo que he descubierto, sin embargo, es que pensar estratégicamente es muy diferente a actuar estratégicamente. Donde pensar estratégicamente es un proceso interno que permanece en su cabeza, actuar estratégicamente requiere una orquestación cuidadosa y la capacidad de documentar los pensamientos internos de una manera que se pueda compartir y comprender en todo el equipo.
La diferencia entre pensar y actuar estratégicamente nunca fue más cierta para mí que cuando me senté a escribir los requisitos de las funciones para este proyecto. Pensé en compartir lo que había aprendido en mis primeros intentos de redactar requisitos.
Antes de comenzar, quiero decir que no hay escasez de formas de abordar los requisitos de las funciones. Lo que estoy a punto de compartir toma prestados en gran medida fragmentos y piezas que he encontrado rastreando la web en busca de respuestas a mis propias preguntas y reuniéndolas de una manera que funcione para mí.
Reconoce tu sesgo
Lo primero que tuve que aprender a aceptar es que soy parcial en la forma en que abordo los requisitos. Soy diseñador web de profesión y, como tal, mi pensamiento tiende a estar en el lado visual de las cosas. Puedo esbozar wireframes y producir maquetas todo el día, pero no todas las personas del equipo ven o piensan de esta manera.
No hay nada de malo en un sesgo hacia el pensamiento visual, pero vale la pena reconocerlo y recordar que su documentación deberá tener sentido para los demás. En mi caso, me lo pasé genial dibujando diseños y dibujando un montón de cuadrados que representan cómo los usuarios navegan por el producto. Eso me ayudó a sacar mis pensamientos de mi cabeza para poder comenzar el proceso de documentarlos. Su proceso puede consistir en listas con viñetas o diagramas. Use lo que tenga sentido para usted y sepa que necesitará traducir ese trabajo para otros.
Contar una historia
También he aprendido que pensar en las características como historias ayuda mucho.
Piénsalo: una historia tiene un protagonista (el usuario) que se encuentra en una situación (el flujo de usuarios) antes de llegar a un incidente incitante (la tarea a completar) para encontrar una solución (el resultado esperado). ¿Quién sabía que Stephen King era un maestro en la escritura de requisitos de funciones todo este tiempo?
Mi proceso hasta ahora ha sido hacer una lista de todas las características clave del producto y luego contar una historia desde la perspectiva del usuario final sobre cómo están usando cada característica. Nuestro equipo está llamando a estas historias de usuarios, y cada función puede tener una sola historia y hasta una docena, según los casos de uso.
Las historias de usuario son geniales porque te obligan a pensar desde la perspectiva de un usuario y a centrarte en los resultados esperados. Digamos que estamos escribiendo los requisitos para la creación de cuentas. Así es como hemos estado enmarcando cada historia de usuario:
| Como… | Eso espero… | De modo que… |
|---|---|---|
| [Identify the user] | [Describe the task] | [Explain the anticipated outcome] |
Digamos que estamos escribiendo los requisitos para la creación de cuentas. Así es como se podría escribir una historia de usuario:
| Como… | Eso espero… | De modo que… |
|---|---|---|
| Cualquier cliente nuevo | Puedo usar mi cuenta existente de Google o Facebook para registrarme | Puedo registrarme más rápido y administrar menos cuentas |
Interrumpiré aquí para decir que este ejercicio requiere que usted tenga una muy buena comprensión de quiénes son sus usuarios. Claro, el ejemplo anterior es bastante genérico porque está dirigido a “cualquier cliente nuevo”, pero pensar en quiénes son sus usuarios, documentar sus personalidades e incluso darles nombres le permitirá ser más específico y contextual al escribir historias de usuario. . MailChimp tiene un artículo maravilloso sobre su proceso para crear personas de usuario que fue muy útil para mí.
Flujos de usuarios de documentos
Si una historia de usuario ayuda a establecer expectativas para un requisito de función, entonces un flujo de usuario proporciona un contexto de cómo el usuario llegó allí y dónde termina después de completar la tarea.
Volviendo a mi sesgo personal por el pensamiento visual, para mí tiene más sentido ver esto en un diagrama. Sin embargo, sé que no todos piensan como yo, por lo que he estado delineando los pasos requeridos que toma un usuario para realizar la tarea y usando un diagrama para ilustrar flujos más complejos.
Así es como mi I podría escribir un flujo para la historia de usuario que usamos anteriormente para el inicio de sesión social en una función de creación de cuenta:
| ID de flujo de usuario | Descripción |
|---|---|
| UF-1 | El cliente responde a una llamada a la acción en el sitio de marketing para crear una cuenta |
| UF-2 | El cliente elige registrar una nueva cuenta usando una cuenta de Google o Facebook en la pantalla de registro de cuenta |
| UF-3 | El cliente selecciona Facebook o Google |
| UF-4 | Se solicita al cliente que autorice el uso de su cuenta seleccionada para registrar una cuenta verificando su identidad |
| UF-5 | Cliente ya sea:
|
Observe cómo a cada paso se le asigna una identificación y cada identificación puede dividirse en subtareas. Los ID son útiles para poder hacer referencia a puntos específicos de la documentación cuando se analizan con otros miembros del equipo. Ciertamente, esto puede resultar complicado, que es donde un buen diagrama puede ser útil.
Un ejemplo de diagrama de flujo de usuarios
Requisitos de documentos
La parte loca de aprender a escribir requisitos es la cantidad de previsión que se requiere antes de comenzar realmente a entrar en los requisitos.
Una vez que se ha identificado la función, se escribe una historia de usuario y se describe el flujo, paso a los requisitos reales, utilizando el mismo formato que se utilizó para los flujos de usuario.
Nuevamente, volviendo a nuestro ejemplo de inicio de sesión social, algunos requisitos simples podrían ser:
| ID de requisito | Descripción |
|---|---|
| RQ-1 | Un embudo de Google Analytics para medir conversiones y caídas |
| RQ-2 | Integración OAuth |
| RQ-3 | Opciones para Facebook y Google |
Puede ser tan detallado como necesite. Intento errar por el lado conservador y escribir tantos como sea posible, mientras trato de no ser definido demasiado rígidamente que sofoca la licencia creativa durante el diseño y el desarrollo.
Sea transparente con las suposiciones
Aprendí que cada decisión que tomo se basa en suposiciones. Es difícil estar al tanto de todo, pero reconocer cualquier cosa que pueda estar dando por sentado es importante porque brinda una ventana al proceso de toma de decisiones. Documentar las suposiciones permite que otros comprendan su lógica y brinda la oportunidad de impulsar una mayor discusión.
Documentemos algunas suposiciones en nuestro ejemplo en ejecución:
| ID de suposición | Descripción |
|---|---|
| AS-1 | Los inicios de sesión sociales valen la pena. MailChimp redactó un argumento convincente en contra de su uso, pero que data de 2012 y luego reconocieron que puede ser útil, dependiendo del sitio. |
| AS-2 | Este informe de TechCrunch de 2015 sigue siendo válido en el sentido de que Google y Facebook son los inicios de sesión sociales más utilizados y otros son demasiado marginales para que los consideremos para el lanzamiento inicial. |
| AS-3 | Almacenaremos esta información y mantendremos a un usuario conectado siempre que esté conectado a la cuenta social que seleccionó. |
| AS-4 | Querremos fomentar esta opción antes que la opción de correo electrónico porque puede ahorrar tiempo. |
Créame, ¡no me di cuenta de que una tarea aparentemente simple podría conllevar tantas suposiciones! Esto puede ser muy útil.
Tenga en cuenta las posibles restricciones
Una restricción es una limitación que puede estar fuera de su control. Tratar de precisarlos temprano ayuda a otros miembros del equipo a planificar. También me ha resultado útil preguntar a otros si pueden ayudar a identificar las limitaciones porque a veces no sabes lo que no sabes.
| ID de restricción | Descripción |
|---|---|
| CT-1 | Límites de Google OAuth 2.0 |
| CT-2 | Pautas de Facebook para permisos web |
Documento de muestra
Reuní un documento de Google que reúne todos estos conceptos. Siéntase libre de usarlo como punto de partida cada vez que se le asigne la tarea de escribir requisitos de funciones.
Ver documento
Terminando
Espero que esto sea útil para cualquiera que esté buscando a través de los requisitos de las funciones. Como se mencionó anteriormente, nada aquí está destinado a ser prescriptivo. Esto es solo lo que encontré útil en mi viaje inicial hacia el desarrollo de productos.
Dicho esto, es posible que algunos de estos recursos adicionales le resulten útiles:
- Descubrimiento práctico del diseño: escribe Dan Brown que proporciona una guía completa en A List Apart sobre cómo dividir los requisitos de diseño en principios de resolución de problemas en los que un equipo puede reunirse.
- Escribe un guión: Chris escribió este dato en respuesta a una publicación de Jeremy Keith y sirve como un buen recordatorio de que los requisitos del código pueden ser narrativas escritas que sigan la estructura del código.
- Sketch vs Figma: Christian Krammer comparó las dos aplicaciones para wireframing y me convenció de probar Figma.