project-management - source - tipos de software para administracion de proyectos

La mejor forma de evitar la propagación del alcance como desarrollador sin gestión de proyectos (15)

Desafortunadamente, esencialmente 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 proyectos en los que he trabajado, hemos logrado cambiarlos

Elaboración de una especificación de requisitos firmada por los interesados
Estimar cuánto trabajo llevará construir lo que se ha especificado
Cada vez que se solicita un cambio, calcule cuánto cambiará la cantidad de trabajo requerido que explica el impacto en el costo y la fecha de finalización causados por el cambio.
Diga no a los cambios que no incluyen un cambio en el programa
Obtenga una aprobación en los cambios aceptados (incluida la aceptación del cambio en el cronograma)
Mantenga un registro de los cambios que se solicitaron y lo que se aprobó.

La administración del cambio en mi experiencia nunca es divertida, lamentablemente, 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 has explicado, o ignorando el proceso con demandas como "hazlo").

Soy desarrollador / as en un pequeño departamento interno de TI dentro de una empresa financiera y he trabajado en una serie de proyectos pequeños y medianos que han tenido poca o ninguna gestión de proyectos. 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 como desarrollador para garantizar que los requisitos de los usuarios se definan antes de que se escriba un código y que las solicitudes de cambio se gestionan correctamente, teniendo en cuenta las demandas y expectativas de los usuarios / gerentes.

Gracias.

En este tipo de situación, el alcance lento es casi inevitable, las partes interesadas no tienen tiempo para ayudar con el análisis por adelantado y no hay un 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.

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 evitar que finalices proyectos.

Lo que puedes hacer :

Comuníquese tanto como sea posible sobre las decisiones que se tomen. Incluso tú crees que tu jefe debería haber hecho esto. Preferiblemente por correo electrónico para que nadie pueda reclamar ignorancia
Si se solicitan nuevas funciones, asegúrese de que todos sepan cuánto tiempo llevará esto. No subestimes. Haga una conjetura 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, junto con un tiempo estimado. De nuevo, asegúrese de que todos los involucrados puedan ver esta lista en todo momento.

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

Pero en general, comuníquese, comuníquese, comuníquese y conviértase en una especie de líder de mini proyectos.

Haga que cada uno de los requisitos que reciba los apruebe un gerente, puede administrar el proyecto usted mismo, pero que alguien más apruebe los cambios antes de implementarlos. Luego puede usar el cierre de sesión como palanca para decir no.

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.

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í.

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.

Mantenga un registro de cuáles son los requisitos actuales. Cuando un cliente acude y solicita nuevas funciones, asegúrese de que sepan que agregar una nueva característica hará que ocurra una de las siguientes cosas:

La fecha de entrega será retirada
Se deberá eliminar el requisito de función para dejar espacio para el nuevo
O bien, su nuevo requisito no puede cumplirse

Como dijo Bob King en su comentario, decir "no" en un asunto profesional no es algo malo.

No tengas 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 tema recoger un libro de gestión de proyectos, leerlo y aplicarlo, incluso si solo lo está aplicando.

Una vez que usted y el cliente se sientan cómodos con los requisitos, enciérrelos 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 quiere 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, debería haber algún margen de maniobra y nunca hay una manera fácil y rápida de descubrir qué debería pasar tras el hecho y qué no, pero agregar una fecha límite difícil y la amenaza de más costos generalmente asegurará que el gran parte de los requisitos están en e inmutables en cierto punto, preservando así algo de su cordura.

Si no tiene un administrador que le haga retroceder cuando se le solicite una funcionalidad adicional, tendrá 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.

La parte más difícil es aprender cómo decirle a la gente NO , pero es algo que tendrá que aprender.

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 tuviera BA y PM y todo el resto del middleware de gestión, podría ir por completo con las declaraciones de requisitos, los formularios de solicitud de cambio, las placas de revisión de cambios, etc. Sin embargo, supongo que esto no es lo que quiere.

Puedes 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 con la que puede salirse con la suya. 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.

No permita que las características cambien o se profundicen que no sean mutuamente aceptables para todos. Si tiene que elegir, deje caer algo más. Las decisiones deberían hacerse a sí mismas.

He estado en la misma situación por 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 descubierto que las personas que quieren software, con demasiada frecuencia, no quieren dedicarle 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 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.

Una vez más, la reconstrucción del infierno se produjo.

Ahora hemos completado el círculo. 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 damos trozos pequeños, a menudo, y les pedimos que los prueben, y firman 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.

Tendrás que hacer un poco de gestión de proyectos tú mismo. Aprenda sobre la gestión de proyectos Agile:

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

Desarrolle un retraso y en lugar de decir sí / no a los cambios o características, ordénelos 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.