No tenemos un acuerdo sobre cómo llevar a cabo este proceso.
Las características de lo que estamos construyendo:
Dada esta situación, soy de la opinión de que nos sentemos juntos (puede ser por un día o dos) y generemos una matriz de problemas comunes que enfrenta el negocio (creo que llamamos a este caso de negocios) y anotemos sus soluciones. - es decir, la solución comercial tradicional (con sus pros y sus contras), la solución de nuestro producto al problema (con sus pros y sus contras). Podemos congelar esto haciéndolo revisar con las partes interesadas.
Publicar esto podemos comenzar la tarea de crear historias de usuario, wireframes, etc.
Sin embargo, en realidad nos dedicamos a construir las historias de usuario con algunos casos comerciales que, en general, no logran convencernos sobre la aceptación del sistema, o dan una suposición falsa de aceptación.
¿Cuál es la forma real de hacerlo?
Todos estos proyectos deben comenzar con un Business Case (BC). El BC debe indicar el problema que desea resolver o la oportunidad que desea aprovechar. Debe indicar el costo de emprender el proyecto (en términos de recursos y efectivo) y los beneficios que la empresa cree que surgirán de emprender el proyecto. En su caso, dado que la naturaleza del producto no está definida, sugiero un pequeño proyecto preliminar, con su propio presupuesto, para hacer un análisis del cliente y del producto para determinar cómo podría ser el entregable y qué características debe contener. El entregable del proyecto de análisis de requisitos debe ser el BC para el proyecto de implementación.
Todos los BC deben ser revisados, aprobados y firmados por la empresa. Son su aprobación para proceder y la asignación de presupuesto para realizar el trabajo. Una vez que esté allí, estará en una gestión de proyectos sencilla. La forma en que elige entregar el proyecto (y, por lo tanto, el Producto y otros entregables) depende de sus preferencias locales (es decir, Agile/Waterfall/algún otro modelo)
Comience por construir un BC que se acumule (es decir, le brinda más beneficios a su empresa que el costo de completar el proyecto; en términos simples, genera más dinero de lo que cuesta construirlo).
Luego, y como parte del BC general, fije las características del proyecto y, si es posible, sepárelas utilizando MOSCÚ, es decir, debe tener, debería tener, podría tener.
Obtenga su presupuesto. Ejecute el proyecto. Entregar el producto. Gana dinero (o mide la realización de tus beneficios)
Desde mi experiencia en la gestión del desarrollo de nuevos productos, creo que el primer paso debería ser encontrar un cliente de lanzamiento.
Sin cliente de lanzamiento = sin caso de referencia, sin conocimiento interno, producto impulsado por TI, difícilmente tendrá éxito en un mercado saturado.
En su caso, recomendaría encontrar al menos dos clientes de lanzamiento que estén dispuestos a gastar tiempo y dinero, ya que la combinación de requisitos varía demasiado y, de lo contrario, podría encontrar una solución específica para el cliente. Alternativamente, puede optar por una persona que tenga conocimiento interno de la industria, que haya trabajado con clientes potenciales, y que tenga habilidades de gestión de productos y esté dispuesto a compartir.
El resto es solo construir un caso de negocios con MoSCoW, ágil o lo que sea, pero siempre lanzando clientes como socios a bordo. ¡Buena suerte!
Para mí, parece que lo que está luchando es que realmente no tiene un propietario de producto definido para este software. Al desarrollar software, incluso si está escribiendo software orientado al mercado, alguien tiene que representar el rol de propiedad del producto a medida que desarrolla su software. De lo contrario, está desarrollando sin rumbo y, en última instancia, no tiene forma de saber si su código proporciona valor a alguien, incluidas las personas que lo desarrollan. La propiedad del producto es un aspecto crítico del desarrollo de software: una vez que establezca eso, personalmente consideraría usar algún tipo de metodología de desarrollo ágil para que pueda responder de manera más flexible a las necesidades del propietario del producto.
InfoQ tiene una buena discusión sobre de qué es responsable el propietario del producto, aquí: Patrones del propietario del producto
Una de las cosas críticas de las que debe estar seguro es que tiene una acumulación de productos priorizada. Sin un rol de propiedad del producto, no hay forma de esperar tener una acumulación de cosas en las que trabajar que son importantes.
Como recurso general para las prácticas de desarrollo, también recomendaría este blog, escrito por el personal de ingeniería de Etsy: Code as Craft