En nuestras Especificaciones de requisitos de software (SRS) tenemos una cláusula que establece que el usuario debe poder realizar notificaciones automáticas desde el sitio web a los dispositivos móviles.
¿Deberíamos informar al cliente sobre las limitaciones de la característica? Por ejemplo:
¿Debo informar al cliente que se limitará a 128 caracteres en los mensajes push, con una traducción de 1 a 2 oraciones en el mejor de los casos?
Cual es mejor:
Actualmente estamos en el punto en que enviamos correos electrónicos al cliente al menos una o dos veces al día, y a veces incluso tres de cuatro.
La respuesta corta es sí.
Absolutamente desea mantener al cliente informado de las limitaciones u otras trampas en el proyecto. Rara vez conocerá la historia completa y, por lo tanto, carecerá de la perspectiva para saber si esto tendrá un impacto importante.
Una respuesta más larga necesita profundizar en cómo llegaste a donde estás. Ben, Miles y CodeGnome mencionan esto en sus respuestas. Reduciría esto a dos puntos clave.
1- Dedique más tiempo a diseñar con el cliente: incluso en Agile, debe dedicar algo de tiempo a comprender lo que se hará con el cliente. El requisito "debería poder enviar notificaciones automáticas desde el sitio web a los dispositivos móviles" es extremadamente vago. No hay ningún caso de uso aquí. ¿Qué estará empujando el cliente? ¿Con qué frecuencia? ¿Qué tan crítica es la misión? Si comprende cómo se utilizará la función, podrá diseñarla mejor. Si usa Scrum, tener al cliente en sus reuniones de planificación de Sprint significa que puede responder preguntas en tiempo real.
Como mínimo, debe documentar cuál es la prueba de aceptación para esta característica. ¿Cuál es la medida de "hecho"?
2- No tengas miedo de comunicar demasiado. En cambio, acéptalo como parte del proyecto. Establece reuniones periódicas con tu cliente (por ejemplo, demostraciones de Sprint) en las que puedas revisar el producto. No solo puede compartir limitaciones, sino que también puede mostrarles cómo va el proyecto. Puede resultar que realmente pensaron que querían una GUI azul, pero al verla se dieron cuenta de que realmente necesitaban una verde.
Haga de este tipo de comunicación una parte regular de su proyecto. Descubrirá que está mucho menos sorprendido en el camino.
Parece que le falta un plan de comunicaciones , que es un aspecto esencial de la mayoría de los proyectos. Este plan incluiría detalles como lo que las partes interesadas deben saber y cuándo deben saberlo.
Desde una perspectiva más ágil, una mejor pregunta es si los detalles de implementación impiden o no que el equipo alcance el objetivo. Por ejemplo, si el Sprint Goal para una iteración es:
Habilite las notificaciones push desde el sitio web a los dispositivos móviles.
generalmente depende del Equipo de Desarrollo cómo se debe implementar el objetivo. Hay muchas soluciones técnicas a los problemas de protocolo y transporte; las preguntas generalmente se reducirán a:
No creo que su ejemplo sea tal caso, pero ciertamente hay ocasiones en las que una función o un objetivo no se puede implementar a tiempo, dentro del presupuesto o con las habilidades o los recursos disponibles para el equipo del proyecto. Esos tipos de bloqueadores deben abordarse absolutamente con las partes interesadas de una manera apropiada para el marco. Esto permite que los patrocinadores del proyecto tomen decisiones estratégicas informadas y es una responsabilidad clave que pertenece al gerente del proyecto o propietario del producto.
Determinar si algo es realmente un bloqueo, o si es simplemente un desafío que debe resolverse, es el diferenciador central en cómo comunicarse de manera efectiva sobre un problema. La forma en que tome esta determinación dependerá mucho de su marco de gestión de proyectos, su plan de comunicaciones y (en última instancia) el nivel de habilidad y la experiencia encarnada por el liderazgo del proyecto. Por lo tanto, su kilometraje variará mucho.
Mantener informado al cliente nunca es malo.
Dicho esto, la forma en que comunique esto debería depender del impacto de la restricción descubierta.
En el caso de que una restricción signifique que no se puede entregar un requisito específico, lo comunicaría temprano, preferiblemente cara a cara, junto con (cuando sea posible) algunas opciones sobre cómo proceder para cumplir con el requisito (tal vez deba ponerse de acuerdo más tiempo, costo gastado en diferentes tecnologías, etc.).
Para las cosas descubiertas que no comprometen directamente un requisito, puede comunicarlas con menos urgencia a través de canales preexistentes (por ejemplo, como parte de una reunión de estado regular o un informe de riesgo/problema).
Otra consideración podría ser lo fácil que es cambiar de dirección más tarde. Sea más activo al comunicar cosas que serán difíciles de revertir en una fecha posterior.
Desarrollar los medios y niveles de comunicación al principio del proyecto es un detalle importante de PM. Algunos clientes querrán todos los detalles, otros solo querrán comunicación sobre temas específicos. Si esto no se ha establecido, puede ser una buena idea hablar con el cliente sobre la frecuencia de la comunicación y ver si está satisfecho con el statu quo o si desea que los problemas no urgentes se incluyan en una comunicación diaria o semanal.
Como específico de esta situación, está creando la funcionalidad según sea necesario y no puede ajustar las restricciones del sistema Android o iOS, por lo que esto no es urgente, a menos que la redacción de la cláusula implique una funcionalidad que no puede ofrecer.
¡Bienvenido a PM SE!
Bjarke Freund-Hansen