mejor manera de evitar la corrupción del alcance como desarrollador sin gestión de proyectos

Question

Soy tan/w desarrollador en un pequeño departamento de TI interno dentro de una empresa financiera y han trabajado en una serie de proyectos de tamaño pequeño o mediano que han tenido poca o no gestión de proyectos en todo. Esto parece siempre dar como resultado un aumento de alcance y, por lo tanto, no cumplir los plazos y tener que sacrificar un buen diseño/código para satisfacer a los usuarios/gerentes en el corto plazo.

¿Qué puedo hacer yo como desarrollador para asegurar las necesidades del usuario se clavan abajo antes de cualquier código está escrito y que las solicitudes de cambio se gestionan adecuadamente, teniendo en cuenta las demandas y expectativas de los usuarios/administradores.

Gracias.

Answer 1

Si no tiene un administrador para hacer retroceder cuando se solicita una funcionalidad adicional, vas a tener que hacerlo usted mismo. Yo publicaría un calendario de lanzamientos y agregaría características adicionales a las fases futuras del proyecto, para que no se demore en todo el proyecto debido a estas características adicionales. Permita que las personas sepan cuánto tiempo agregarán estas características adicionales al proyecto y cuándo pueden esperar verlas.

Lo más difícil es aprender a decirle a la gente NO, pero es algo que tendrá que aprender.

Answer 2

No tenga miedo de decir "NO". Cortés y profesionalmente, por supuesto. No te comprometas con nada que no sea justo de inmediato es imposible. No te comprometas inmediatamente con nada de lo que no estés seguro.

Además, no tenga miedo de tomar un libro de gestión de proyectos, leerlo y aplicarlo, incluso si sólo se va a aplicar a sí mismo.

Answer 3

Haga que cada requerimiento que reciba firmado por un administrador, puede administrar el proyecto un poco de-lo, pero que otra persona aprobar los cambios antes de implementar. Luego puede usar el cierre de sesión como palanca para decir no.

Answer 4

En este tipo de situación, la corrupción del alcance es casi inevitable, las partes interesadas no tienen tiempo para ayudar con el análisis por adelantado y no hay ningún contrato formal. Recomiendo elegir una metodología ágil que te permita ajustar constantemente los objetivos y las expectativas. Algo así como scrum. Los ciclos cortos ayudarán a los interesados ​​a ver los resultados anticipadamente y a ajustar los requisitos a medida que comprendan mejor el problema y lo mantendrán alejado de la locura, ya que el ciclo de esprint le permitirá adaptarse a estos cambios.

Answer 5

La clave es la documentación y la visibilidad. Tenemos un sistema de seguimiento de problemas fácil de usar que los creadores de requisitos usan para incluir sus solicitudes de funciones. Nunca se desalientan de hacerlo, pero luego las reuniones se pasan revisando las solicitudes después de que hayamos swagged las estimaciones para codificarlas. Si hay un tiempo limitado, ahora los solicitantes tienen que competir por el tiempo de codificación entre ellos, no solo esperando que se haga. Nosotros, como codificadores, estamos protegidos del creep ya que tienen que discutir cómo se afectan entre sí.

Answer 6

Mantenga un registro de cuáles son los requisitos actuales.Cuando un cliente llega y pide una nueva funcionalidad, asegúrese de que saben que la adición de una nueva característica hará que una de las siguientes cosas ocurra:

1. La fecha de entrega será movido hacia atrás
necesitará requisito
2. Característica que dejarán de hacer espacio para la nueva
3. O, su nuevo requisito no se puede cumplir

Como dijo Bob king, en su comentario, diciendo "no" en un asunto profesional no es una mala cosa.

Answer 7

Lea un libro sobre Scrum e implemente la práctica en su oficina. Efectivamente cambia las tornas en la administración, haciendo que prioricen lo que quieren lograr. Con demasiada frecuencia, a los desarrolladores se les presenta una enorme lista de requisitos y una línea de tiempo corta. Con Scrum, divide esos requisitos en tareas, determina cuántas horas puede trabajar durante un tiempo específico y luego, al comienzo de ese tiempo designado, tiene una reunión para determinar cuál es la prioridad de este "sprint". También hay mucho más, pero el verdadero genio, además de la gestión de sus gerentes es que elimina los requisitos de "Cutesy" porque la prioridad tenderá a ser la verdadera carne de la aplicación. Mi vida como desarrollador ha sido mucho más agradable desde que la implementé en mi organización.

Answer 8

Es prácticamente imposible tener una especificación completa antes de comenzar a codificar. Especialmente en pequeñas empresas. Un enfoque ágil funciona mejor, pero esto no debería impedirle terminar proyectos.

Lo que puede hacer:

• Comunicar lo más posible sobre decisiones tomadas. Incluso tú crees que tu jefe debería haber hecho esto. Preferentemente por correo electrónico para que nadie pueda reclamar ignorancia
• Si se solicitan nuevas características, asegúrese de que todos sepan cuánto tiempo va a tomar . No subestime. Haga una estimación educada de y multiplique el número con un factor de riesgo , según el riesgo de la función.
• Cuando un proyecto está llegando a la línea de meta, haga una lista de las tareas que aún deben realizarse, juntas con un tiempo estimado. De nuevo, asegúrese de que todos los involucrados puedan ver esta lista en todo momento.

Básicamente lo que debe hacer es asegurarse de que todos sepan lo que está haciendo. Esto no necesariamente hace que los proyectos terminen a tiempo per se, pero sirve como espejo para los gerentes, para que vean cuáles son las consecuencias de sus decisiones.

Pero, en definitiva, comuníquese, comuníquese, comuníquese y conviértase en una especie de líder de miniproyectos.

Answer 9

Hay dos tipos de fluencia del alcance. Uno proviene de no obtener buenos requisitos por adelantado. Esto da como resultado tareas inesperadas para entregar lo que se espera. Si este es el problema, entonces es posible que desee tomar más tiempo por adelantado en la recopilación de requisitos y documentar estrictamente lo que se espera en cada período. Una vez que tenga esto, puede crear una cantidad de tareas de bajo nivel y estimaciones de tiempo. Si hay un exceso de tiempo, al menos sabrá con anticipación.

El segundo tipo proviene de pequeñas características que se agregan en el medio del ciclo de desarrollo. Aquí es donde tienes que aprender a decir no. No siempre puedes decir que no, pero tienes que elegir tus batallas. Y recuerde, este tipo de fluencia del alcance no proviene de una cosa grande. Proviene de una gran cantidad de cosas pequeñas. Es muerte por mil recortes de papel.

Answer 10

Una vez que usted y el cliente se sientan cómodos con los requisitos, conéctelos con un documento de requisitos firmado. Cualquier cosa después de eso es una solicitud de cambio que cuesta más dinero.

Esto no funciona si el cliente nunca desea cerrar la sesión. Vea si puede establecer algunos plazos razonables en su contrato, tales como "plazo de solicitud de créditos blandos" y "fecha límite de solicitud de recursos".

Obviamente debe haber algo de margen de maniobra y nunca hay una manera fácil y rápida de averiguar qué debe pasar tras el hecho y qué no, pero agregar un plazo difícil y la amenaza de más costos generalmente asegúrate de que la gran mayoría de los requisitos estén dentro e inmutables en cierto punto, preservando así algo de tu cordura.

Answer 11

Desafortunadamente, usted tendrá que hacer la gestión del proyecto y aprender un poco sobre la gestión del cambio. Lo mejor sería que recogiera un libro de Gestión de proyectos accesible (no el PMBOK) y lea todas las secciones sobre gestión de cambios.

En de proyectos que he trabajado, hemos logrado el cambio por

1. La elaboración de una especificación de requisitos que se firmado por las partes interesadas
2. La estimación de la cantidad de trabajo que se necesita para construir lo que se ha especificado
3. Cada vez que se solicita un cambio, calcule cuánto va a cambiar la cantidad de trabajo requerido que explica el impacto en el costo y la fecha de finalización causados ​​por el cambio
4. Diga no a los cambios que no incluyen un cambio en el programa
5. Obtenga una aprobación en los cambios aceptados (incluida la aceptación del cambio en el cronograma)
6. Guarde un registro de los cambios solicitados y lo que se aprobó.

La gestión del cambio en mi experiencia nunca es divertida, desafortunadamente, y hay muchos lugares donde las cosas pueden salir mal. Lo más común que he escuchado son las expectativas poco realistas sobre la precisión de los estimados y las demandas poco razonables de las partes interesadas (simplemente rechazando las implicaciones de un cambio que usted ha explicado, o ignorando el proceso con demandas como "simplemente hazlo")

Answer 12

Scope Creep se trata de cambios no aprobados. Al leer sus preguntas, parece que sabe la respuesta, necesita requisitos, solicitudes de cambio y aprobaciones.

Si tenía BA y PM y todo el resto del middleware de gestión, podría ir por completo con las declaraciones de requisitos, formularios de solicitud de cambio, placas de revisión de cambios, etc. Sin embargo, supongo que esto no es lo que quiere.

Puede hacer todo esto simplemente. Primero determine quién es el patrocinador del proyecto. Quién lo pateó y quién lo posee. Esto necesita ser una persona que aprueba el presupuesto y la programación de su proyecto. Ambos necesitan un proceso similar al siguiente en el que ambos puedan ponerse de acuerdo.

A continuación, en Excel, cree una hoja para su registro de requisitos. Enumera todos los requisitos.Dé a cada uno una breve descripción y deje una columna para una descripción más larga cuando sea necesario. También se incluyeron columnas para quién solicitó el requisito, cuándo y si se diseña una solución y si se entrega una solución. Siéntese con su patrocinador y acuerde que esta es la línea de base.

Ahora crea una hoja de registro de cambios. Esto necesita una columna para una breve descripción, una para una descripción más larga, una fecha, una columna para el impacto y una para la fecha aprobada y aprobada por. La columna de impacto es la más importante. Cada vez que alguien solicita un cambio necesita averiguar cómo ese cambio afectará su alcance, presupuesto o cronograma. Una característica adicional puede agregar 5 días y $ 5,000. Si necesita realizar entregas antes de Navidad, debe eliminar el elemento de requisito 1,2,3.

Una vez que tenga sus requisitos y un método para comunicar el cambio y el impacto, la parte más difícil es que no puede realizar un cambio sin la aprobación de su patrocinador. Esta aprobación puede ser un correo electrónico o lo que sea. Pero necesita decir explícitamente "Apruebo el número de cambio 12". Sin el paso de aprobación explícita también puede no molestarse.

Esta es la cantidad mínima de documentación/proceso que puede realizar. El objetivo principal es garantizar que el impacto de cada cambio sea comunicado, aceptado y rechazado por la persona adecuada. Esta persona no es usted y generalmente no es la persona que realiza la solicitud de cambio.

Answer 13

No permita que las funciones cambien o se profundicen que no sean de mutuo acuerdo para todos. Si tiene que elegir, deje caer algo más. Las decisiones deberían hacerse a sí mismas.

Answer 14

He estado en la misma situación durante muchos años. Mi experiencia fue un poco diferente sin embargo. Originalmente en mi compañía, yo era el lobo solitario. Las reuniones de requisitos fueron todas dirigidas por mí. Después de reunir los requisitos, construía la aplicación, y he aquí, no era lo que los usuarios querían. Reconstruye el tiempo, con once mil millones de cambios. Qué proceso tan horrible Todo el mundo se enojaría con eso, mi gerente, para mí, para los usuarios.

Lamentablemente, he encontrado que las personas que quieren software, con demasiada frecuencia, no quieren dedicarle un tiempo para ayudarlo a diseñar una solución que resuelva los problemas comerciales a los que está buscando una solución. Serán constantemente vagos y no querrán comprometerse con nada.

A medida que crecimos, contratamos a algunas personas para que fueran gerentes de proyectos instantáneos, a pesar de que nunca antes habían manejado un proyecto de desarrollo de software, y tenían poca o ninguna experiencia técnica. Esto resultó en obtener especificaciones "concretas" que todo el mundo, menos yo, el desarrollador, estuvo de acuerdo.

Por supuesto, los resultados fueron casi tan malos como en la situación original, pero al menos tuvimos la aprobación de la administración para hacer cumplir las especificaciones. Desafortunadamente, estas especificaciones de concreto estaban llenas de deseos ridículos y, a menudo, verdaderamente imposibles.

Después de luchar por la cordura en la aplicación, se construiría. Nueve de cada diez veces, los usuarios seguían molestos porque invariablemente, junto con los gerentes de proyecto, diseñaron soluciones estúpidas que no funcionaron bien para ellos.

De nuevo, sobrevino el infierno de la reconstrucción.

Hemos completado el ciclo. Todos los gerentes de proyecto se han ido, y hemos tenido algunos despidos bastante pesados, así que una vez más soy responsable de todo el ciclo. Afortunadamente, hemos aprendido de nuestros errores y la administración todavía está dedicada a hacer lo que se necesita para hacer cumplir los acuerdos. También hemos cambiado un poco en la forma en que les damos a los usuarios una aplicación.

Les ponemos trozos pequeños, a menudo, y les solicitamos que los prueben, y firmen que la sección es lo que quieren y necesitan.Si no es así, los cambios que desean se agregan al final del proyecto, y todos están informados sobre cómo cambiará el cronograma. Pequeños cambios y caprichos, desaparecen rápidamente, cuando el resultado final se ve afectado de manera demostrable.

Answer 15

Usted mismo tendrá que hacer algunas gestiones de proyectos. Más información sobre los proyectos de gestión ágil:

http://agilesoftwaredevelopment.com/blog/artem/scrum-under-10-minutes-video

Desarrollar una cartera de pedidos y en lugar de decir si/no a los cambios o características, ordenar por prioridad. Las cosas "buenas" para hacer que las cosas sean perfectas siempre se pueden diferir hasta versiones posteriores, y dejar en claro que este es el plan. Concéntrese en los mínimos para obtener un producto funcional primero.