La fluencia del alcance puede transformar fácilmente un buen proyecto en uno angustiado. ¿Cuáles son los métodos para minimizar la expansión continua de los requisitos del proyecto?
He estado lidiando mucho con un aumento del alcance en los últimos 2 años. Creé una lista de cosas que es imprescindible tener en cuenta para minimizar el impacto negativo en el proyecto.
Al principio, ¡debe darse cuenta de que ocurrirá un desplazamiento del alcance!
Debería:
Centrarse en el valor del cliente. El hecho de que el cliente piense en una nueva función no significa que la que estás escribiendo en este momento haya perdido su valor.
Trato de seguir estas pautas: - Reduzca la velocidad. No saltes a las cosas nuevas de scopy. El alcance original fue analizado y considerado cuidadosamente. El nuevo visor probablemente acaba de aparecer. De ninguna manera se conocen todos los requisitos e implicaciones. Dale tiempo a la idea para que madure. Mientras trabaja en el alcance original. - Una vez que esté fuera del modo de 'saltar a ello', capture el nuevo alcance en requisitos, historias de usuarios, etcétera. - Comprueba cómo encaja y si tu visor original ya proporciona parte de este nuevo visor. Y mientras estás en eso; Solicite un caso de negocio para el nuevo alcance. ¿Cómo va a recuperar el dinero el cliente?
Muchas ideas fallan en esta etapa porque ya son posibles, o no están lo suficientemente cerca del hogar para escribir las especificaciones.
Para las ideas que sobreviven, todavía me gusta ejecutar el programa en Operation primero. Echa un vistazo a 'producto mínimo viable'.
Cuando su programa esté en funcionamiento real, tendrá discusiones significativas: ¿Agregamos las cosas que pensamos originalmente (alcance original)? ¿O prefiere que construyamos esa nueva idea primero? ¿Qué idea agrega más valor en este punto?
Cuando haces esto bien, la palabra 'desplazamiento del alcance' pierde su significado.
La mejor manera de minimizar el aumento del alcance es una planificación cuidadosa y un proceso de gestión de cambios estructurado. Tener un plan y un cronograma de proyecto claros y no dejar que los cambios se descontrolen desde el principio es la mejor manera de evitar el avance del alcance. Puede hacer ajustes al plan del proyecto, pero tendrá que evaluar cómo afectará su presupuesto, cronograma y alcance. Una obligación en cada proyecto es también documentar el alcance en una declaración de alcance, este documento lo ayudará a justificar sus medidas a su cliente y sirve como prueba al final del proyecto de que ha cumplido con los requisitos del contrato.
En primer lugar, no debe intentar minimizar los requisitos de expansión. El cambio ocurrirá y debería ocurrir y no debería haber presión para inhibirlo. Lo que se necesita es un proceso de control de cambios, uno que pueda procesar cambios tanto prospectiva como retroactivamente, siendo este último utilizado mínimamente. Por lo tanto, cuando los requisitos cambian o se identifican nuevos, procesa el cambio rápidamente, incorpora el nuevo alcance al proyecto, obtiene tiempo y dinero y sigue trabajando.
El cambio es bueno. Hace que el producto sea más valioso para el cliente y, en el caso de los vendedores, aumenta los ingresos.
En términos de criterios de aceptación para solicitudes de cambio, el proceso debe facilitar la responsabilidad compartida y el enfoque en el cliente. Por ejemplo:
La sabiduría general para evitar el desplazamiento del alcance es algo como esto:
Requerir que el solicitante del cambio de alcance complete un formulario o describa formalmente el cambio.
Registre el formulario (como lo hace con todo lo demás).
Determinar el impacto del cambio solicitado.
Revise el cambio con el cliente/propietario de la empresa/equipo del proyecto y apruebe o rechace la solicitud.
Actualice los documentos del proyecto y notifique al equipo de cualquier cambio.
Mi truco es básicamente mover el paso 3 hacia arriba como un componente del paso 1 e incluir un breve cuestionario sobre el impacto del cambio sugerido allí mismo en el formulario de solicitud inicial. También solicito que el cambio se asigne, de manera cuantificable, si es posible, a una de las métricas/objetivos comerciales clave establecidos en los requisitos comerciales del proyecto.
Referencias
EN MI HUMILDE OPINIÓN,
Proyectos vagamente definidos : si el proyecto no se define correctamente junto con su éxito, el equipo no tendrá nada en qué basarse.
Posibles indicadores:
Sigues recibiendo referencias a otras aplicaciones/sitios . Creo que, en la mayoría de los casos, la "idea" está sobrevalorada. La mayoría de los nuevos empresarios simplemente están tratando de crear el éxito de otra persona. No tendrán una visión definida en su propia cabeza con respecto a lo que están tratando de lograr, como resultado, siempre se apartarán del camino que se propusieron lograr en primer lugar.
Te quejas de - MUCHO - Solo están tratando de recrear el éxito de otra persona y siempre encontrarán su logro por detrás de sus expectativas sin saber realmente lo que están tratando de resolver. Simplemente están detectando una oportunidad sin definir adecuadamente el problema y el éxito.
Solución posible- Tener una buena unidad de atención al cliente (no necesariamente tiene que ser una entidad separada sino un grupo que puede incluir personas que trabajan en diferentes capacidades). Agile fomenta los cambios y desalienta los contratos, pero eso no significa que esté obligado a brindarle a alguien una herramienta de evaluación de salud financiera de aprendizaje automático completa cuando inicialmente se propusieron lograr un libro de registro financiero. Será responsabilidad de la unidad mantener el enfoque en el cliente y el objetivo siempre debe ser tener proyectos definidos. Es posible que necesite buenas habilidades de negociación y organización para lograrlo. Sin embargo, si ya ha cometido el error de no definir el proyecto, intente corregirlo en la medida de lo posible a partir de ahora.
La solución no funciona para el problema : muchos gerentes de proyecto a veces confían mucho en el cliente para cumplir con los requisitos. Cuando alguien llega con una idea de proyecto, presumiblemente está tratando de solucionar un problema determinado. Debe haber un análisis de requisitos y una visión adecuada con respecto a cómo el equipo abordará la solución. Es injusto por parte del cliente que un equipo espere soluciones del cliente y claramente esto nunca llega bien. Es como ir al médico y aconsejar al paciente cómo debe abordar el tratamiento. Hablando en términos generales, por ejemplo. Quiero construir un software para mi café. El problema es subjetivo y la declaración tiene múltiples significados.
Podría estar tratando de solucionar el problema con mis empleados y su gestión de nómina O
Podría estar intentando crear un software que me ayude a optimizar mi gestión de inventario O
Podría estar tratando de crear un software que ayude a mis clientes a realizar sus pedidos en línea.
Por lo tanto, las soluciones, el diseño y la experiencia del usuario variarán según lo que realmente estoy tratando de lograr. La forma en que se presentarán los resultados de manera significativa podría ser completamente diferente para cualquiera de los conjuntos mencionados anteriormente. Por lo tanto, el análisis de requisitos debe abordarse de manera subjetiva y las conclusiones deben definirse adecuadamente para crear una visión/directrices que seguirá el equipo. Obviamente, esto no hace falta decir que debe ser de naturaleza participativa, teniendo en cuenta los aspectos más importantes para mantener contentos a los interesados y motivados en el equipo de trabajo.
Posibles indicadores:
Sigues revisando la misma función : el cliente sabe que la solución no funciona para el problema y sigue regresando con una solución que cree que podría funcionar, pero en realidad no es así.
Una especie de ciclo de cambio se repite con cada sprint : el cliente, sin saberlo, podría estar tratando de volver a alinearlo con la solución que realmente funciona para ellos.
Posible solución : lo más probable es que el cliente sepa cuál es su problema y sabe que la solución que le brindó no aborda su problema principal. Intentarán encontrar una solución que, de nuevo, puede funcionar o no. Para poner las cosas en perspectiva, supongamos que estoy tratando de realizar un seguimiento de mis finanzas, entonces probablemente me gustaría visualizar datos con KPI, es posible que el cliente ni siquiera sepa qué es KPI. Como proveedor de soluciones, depende de nosotros proponer ideas que realmente puedan resolver su problema. Después de todo, de eso se trata la innovación. El equipo debe permanecer en todo momento motivado para lograr el éxito que debe definirse. Si el equipo comprende el problema y si sus soluciones están alineadas, tanto el avance lento como el cambio de alcance no serán costosos.
Definir correctamente el proyecto y su éxito. Esto es lo más importante, independientemente de la inclinación filosófica de su organización, la organización debe tener un proceso unificado e inequívoco para definir realmente el proyecto y sus criterios de éxito.
Dibujó
nathan cooper