Cómo definir una ‘característica’ de un software de forma precisa y efectiva

Una “característica” se puede definir como:

“Una pieza discreta de funcionalidad deseada por las partes interesadas”

Con este concepto definido, podemos explorar más a fondo lo que esto significa.

En primer lugar, es bueno entender quiénes son los interesados, para ahorrar repitiéndome y duplicando datos, puede ver mi respuesta aquí:

La respuesta de Oliver Dolan a ¿Quiénes son sus partes interesadas en los proyectos ágiles?

Con la comprensión de lo que son las partes interesadas, podemos comenzar a abordar la parte de la “pieza discreta de funcionalidad” de la definición.

En general, cuando los requisitos para un sistema se conceptualizan por primera vez, su nivel es muy alto. Esta persona a menudo no comprenderá los intrincados detalles de cómo funciona el sistema a nivel de implementación.

Así que tenemos una desconexión aquí, alguien entiende lo que quiere pero no tiene la responsabilidad, el acceso o el conocimiento para lograr lo que necesita.

La idea es el primer paso para crear una solicitud de función.

Dependiendo de cuál es la idea y de dónde se origina, afectará en gran medida la prioridad y la probabilidad de convertirla en un valor funcional.

Para que la idea se convierta en una característica, es probable que deba presentarse a otras partes interesadas y gerentes de proyecto del producto. Esto puede tomar una variedad de rutas, quizás a través de un gerente de ventas, representante de servicio al cliente o directamente al equipo de administración del proyecto si es una solicitud interna.

Cuando la idea se haya presentado a los gerentes de producto y propietarios de productos, será necesario analizarla para varios criterios. Por ejemplo, un buen PO o PM buscará cosas como estas:

  • Cuán valiosa es la idea para los clientes de alta prioridad
  • Cuán valiosa es la idea para muchos clientes
  • Cuánto costará implementar la idea
  • ¿Está alineado con los objetivos del negocio?
  • ¿Tenemos capacidad para emprender el trabajo?
  • ¿Cuál es el impacto si no hacemos el trabajo, etc.?

Dependiendo de los resultados de esta exploración, determinaremos en última instancia si la idea es sólida y de valor en este momento o si se puede registrar y retrasar para más adelante.

Si se considera que la idea es importante para el negocio en relación con otras ideas. Debe priorizarse en consecuencia y luego ser evaluado por el equipo que lo implementará con mayor detalle.

Antes de que un equipo pueda priorizar y evaluar la idea, debe convertirse en una historia de usuario si es lo suficientemente pequeña o muchas historias de usuario si es un concepto bastante grande.

Puedes ver mi publicación aquí sobre cómo escribir buenas historias de usuarios aquí:

La respuesta de Oliver Dolan a ¿Cómo escribo buenas historias de usuarios y criterios de aceptación para proyectos basados ​​en la web?

Y también este para un desglose del proceso de convertir una idea en una entrega:

La respuesta de Oliver Dolan a ¿Qué pasos sigo para desarrollar un software?

Lo que necesita entender de toda esta información es que es muy difícil saber todo por adelantado. Es por eso que lo que he sugerido es usar metodologías ágiles. Este proceso de descubrimiento e iteración lo llevará al mejor y más rápido valor para sus partes interesadas con respecto a su función entregada.

Entonces, para responder a su pregunta, es muy difícil en proyectos basados ​​en el conocimiento, como un producto de software, definir una característica con precisión.

Por lo tanto, diría que se ha demostrado a través de la experiencia que es mejor para todos los involucrados iterar de manera colaborativa hacia la mejor solución utilizando ciclos cortos de retroalimentación incremental.

Espero que esto ayude

Buena suerte

Oliver Dolan

Una “historia de usuario” es la forma ampliamente aceptada de hacerlo. Existen varios criterios que se pueden usar con las historias de los usuarios para determinar si están bien escritas y son efectivas. Uno es el criterio de INVERSIÓN:

  • Independiente : las historias deben ser lo más independientes posible
  • Negociable : una historia no es un contrato. Una historia es una invitación a una conversación.
  • Valioso : si una historia no tiene un valor discernible, no debe hacerse
  • Estimable : una historia debe poder estimarse o dimensionarse para que pueda priorizarse adecuadamente
  • Pequeño : las historias deben ser lo suficientemente pequeñas para que sean precisas y sin ambigüedades y puedan completarse en un solo sprint
  • Comprobable : cada historia debe ser comprobable para poder “terminar”

Chuck Cobb
Autor de “La guía del administrador de proyectos para dominar Agile”
Echa un vistazo: Academia de gestión de proyectos ágil