Análisis de requisitos: cómo usar este enfoque amigable para el inicio + un estudio de caso

En nuestras publicaciones de blog anteriores, explicamos por qué decidimos desarrollar la aplicación de insignias y cómo evaluamos la viabilidad de nuestra idea en OpsGenie:

Como descubrimos que vale la pena desarrollar nuestra idea, el siguiente paso es analizar los requisitos.

El análisis de requisitos, un área muy bien estudiada de ingeniería de software, es el proceso de determinar las expectativas del usuario para un producto, o definir brevemente el alcance del producto. Hay toneladas de recursos disponibles sobre metodologías de análisis de requisitos, características de buenos requisitos y requisitos de seguimiento. En lugar de repetir la literatura, vamos a resumir los puntos críticos en una forma de pensar de inicio.

Sabemos que a los tipos de startups generalmente no les gustan los términos como "proceso", "prueba de concepto", "requisitos", "alcance", "calendario", "diseño", "documentación" o "mantenibilidad". Generalmente son impacientes y solo quieren codificar y liberar. Aceptamos que la agilidad es vital en nuestro mundo y tenemos que intentarlo, fallar y recuperarnos rápidamente. Pero beneficiarnos de la herencia del mundo del software nos ayudará en el camino hacia el éxito. El punto clave es mantenerlo ágil.

Seguir un proceso no es un objetivo, es una herramienta que nos ayuda a alcanzar nuestros objetivos. Entonces, veamos cómo podemos adoptar enfoques clásicos de nuestro mundo en el contexto de la gestión de requisitos.

El Triángulo de gestión de proyectos es un modelo de las limitaciones de la gestión de software. A pesar de que es un concepto antiguo de la década de 1950, creo que sigue siendo relevante.

En resumen, el triángulo de gestión del proyecto dice que la calidad del trabajo está limitada por el presupuesto, los plazos y las características del proyecto. Hay una compensación entre estas tres limitaciones para lograr la calidad necesaria del proyecto. Entonces podemos decir que el desarrollo de software es un problema de optimización de objetivos múltiples.

El Triángulo de Gestión de Proyectos (Imagen de Wikipedia)

No nos gusta limitarnos a los enfoques clásicos, así que adaptemos el antiguo Triángulo de gestión de proyectos al nuevo mundo de inicio. Recuerde los factores de éxito de inicio que mencionamos en la publicación Análisis de viabilidad.

Así es como mapeamos estos factores de éxito al triángulo clásico de gestión de proyectos:

Como se muestra en la tabla anterior, todos los factores de éxito de inicio se relacionan con varias restricciones de triángulo de gestión de proyectos. Dado que estas tres restricciones son una compensación, podemos decir que mantener el alcance ordenado es vital para el éxito de una startup.

Para definir un alcance ordenado, tenemos que realizar un buen análisis de requisitos antes de comenzar el desarrollo. Tenga en cuenta que esto no significa que vamos a realizar un análisis de requisitos completamente detallado tal como se define en el proceso en cascada. Lo haremos de manera ágil.

Consejos para el análisis de requisitos

En esta sección, le proporcionaremos consejos importantes que debe tener en cuenta:

Inspeccione productos alternativos / similares en profundidad

Como siempre, no reinventes la rueda. Verifique lo que otros hacen para cumplir sus objetivos. Incluso puede terminar dándose cuenta de que su producto no parece tener un impacto comercial que estaba pensando antes.

Esta es una buena señal para impulsar su idea. Puede parecer un fracaso, pero recuerde, tenemos que fallar lo más rápido posible.

Documente sus requerimientos

No tiene que usar una herramienta de gestión de requisitos como IBM Rational DOORS. Pero un breve documento de requisitos con viñetas ayudará a negociar con las partes interesadas.

Mantenga a sus clientes (potenciales) al corriente

Creo que esta es una de las cosas más importantes sobre el desarrollo de requisitos. Una capacidad que cree que es asesina puede no tener sentido para los clientes.

Para mantener a sus clientes potenciales informados, debe seguir un enfoque iterativo. Puede hacerlo enviando una versión inicial de su producto, Producto mínimo viable (MVP), y evolucionando de acuerdo con los comentarios de los clientes.

Por ejemplo, el equipo de Amazon Web Services utiliza este enfoque con frecuencia. Envían un servicio con capacidades mínimas y lo desarrollan en función de los comentarios de los clientes.

Otro enfoque es desarrollar aplicaciones simuladas que solo proporcionen una interfaz de usuario ficticia (UI) para ayudar al cliente potencial a comprender las características del producto y dar su opinión. Puede usar productos como InvisionApp para producir estos simulacros.

La gestión de requisitos es un proceso continuo

No tiene que pasar meses para el análisis de requisitos al comienzo de un proyecto, y no lo haga, no es la forma ágil.

Al principio, su objetivo es definir los límites del sistema, negociar con el equipo y otras partes interesadas, y preparar la definición del Producto Mínimo Viable. Los requisitos deben ser detallados o incluso pueden evolucionar durante las iteraciones del desarrollo.

Agrupe sus requerimientos

Después de crear una lista de todos sus requisitos, agrúpelos (divida y conquiste) para formar conjuntos de características relacionadas. Los requisitos de agrupación para grupos de características facilitarán su vida durante la fase de desarrollo e incluso pueden ayudarlo a definir contextos limitados, arquitecturas de microservicios, etc.

Piensa en UX

Ya no es necesario decir que la experiencia del usuario (UX) es un factor muy importante en el éxito de un producto; hoy es tan obvio. Pero aún debemos recordar que la experiencia del usuario no se trata solo de interfaces de usuario sofisticadas.

Como su nombre lo indica, se trata de la "experiencia" y es difícil mejorar la experiencia de usuario de un sistema después de que se desarrolla.

Piense en UX a partir del análisis de requisitos, incluso podría ser una motivación durante la fase de análisis de factibilidad para desarrollar un nuevo producto si las alternativas disponibles en el mercado carecen de una buena UX.

La experiencia del usuario afecta los requisitos comerciales. Por ejemplo, si está desarrollando una aplicación de comercio electrónico, diseñar un sistema de atención al cliente de respuesta rápida se trata de mejorar la experiencia del usuario.

Sea agnóstico de las tecnologías de implementación tanto como sea posible

Por supuesto, esto no es aplicable si está desarrollando una infraestructura o una biblioteca para una tecnología específica :)

No caigas en la trampa "Si todo lo que tienes es un martillo, todo parece un clavo". Encuentre nuevas herramientas y utilidades en lugar de limitar las capacidades del producto a las tecnologías con las que está familiarizado o con las que disfruta jugar.

En las empresas empresariales, el análisis de requisitos generalmente lo realizan ingenieros que no son de software y que generalmente se conocen como analistas de negocios o ingenieros de sistemas. Esta separación tiene algunas desventajas, especialmente en términos de transferir requisitos a los equipos de desarrollo, pero creo que también tiene algunas ventajas.

En mi opinión, la mayor ventaja de los equipos de análisis independientes es que son independientes de las tecnologías que se utilizarán durante el desarrollo.

Pero en el mundo de las startups, muy probablemente como miembro del equipo (o incluso como fundador), debe usar múltiples sombreros: analista, desarrollador, gerente de contratación o roles aún más interesantes que no estaba imaginando cuando se cruzó en este camino. . Entonces, si está usando el sombrero de analista en este momento, trate de ser independiente de las tecnologías que planea usar durante la implementación.

Siempre escuchamos expresiones como "pero Spring Framework no admite ..." y "Esto causa mucho trabajo en el front-end" durante el análisis de requisitos.

Tener en cuenta este tipo de limitaciones al principio degrada la calidad del producto final. Definamos la capacidad máxima y evolucionemos durante el desarrollo si es necesario.

La capacidad final es el objetivo final a alcanzar, puede implementar una forma más simple cuando comience y evolucione en futuras versiones. Pero conocer el punto al que queremos llegar nos ayudará a definir nuestra visión para el crecimiento del producto.

Por ejemplo, piense en la capacidad de "pellizcar para hacer zoom" de los teléfonos móviles. Parece una capacidad trivial, pero fue una revolución cuando Steve Jobs lo demostró por primera vez. Si los diseñadores de iPhone no pensaran de manera inmediata y se apegaran a las tecnologías y métodos disponibles, hoy no tendríamos esta gran funcionalidad. Sabemos que es un ejemplo exagerado, pero el punto principal es que no permita que la tecnología que le gustaría usar lo limite, puede pasar a otras tecnologías si esto lo ayuda a crear un producto de nicho.

Análisis de requisitos para la aplicación de insignias

Realizamos análisis de requisitos de acuerdo con las prácticas que resumimos anteriormente:

  • Definimos un conjunto inicial de requisitos.
  • Compartimos los requisitos con nuestro cliente inicial, el equipo de OpsGenie, y los actualizamos de acuerdo con los comentarios del equipo.
  • En OpsGenie, utilizamos JIRA de Atlassian para el seguimiento de problemas. Para realizar un seguimiento de los requisitos, creamos un problema con el tipo de "Nueva función" para cada requisito en JIRA.
  • Agrupamos los requisitos relacionados con JIRA Epics. Algunas de nuestras epopeyas son Operaciones de usuario, Operaciones de grupo, Operaciones de distintivos, Endoso e Integración de herramientas de terceros.
  • En otros pasos de desarrollo, creamos problemas detallados para las tareas diarias, como recomiendan las prácticas ágiles. Vinculamos cada tarea con uno o más requisitos para mantener la trazabilidad de las actividades de desarrollo con los requisitos.
  • Cada epopeya contiene un conjunto de requisitos (como una nueva función), tareas de desarrollo y errores.
Requisitos de seguimiento con tareas de desarrollo

¿Desea seguir nuestra aplicación de insignias, o mejor, recomendar nuevas funciones y ayudarnos a refinarla? ¡Únete a la comunidad de aplicaciones de insignias!

Otras lecturas: