La solución de desarrollo se apresuró antes del acuerdo sobre los requisitos: ¿es esta una gestión de proyectos saludable?

He estado trabajando durante 4 años en el campo de TI (como desarrollador y líder de control de calidad) y me incorporé a esta empresa en septiembre de 2018 como analista de sistemas.

Aquí hay algunos antecedentes de la empresa y el proyecto que estamos haciendo en este momento:

  1. La empresa cuenta con la certificación CMMI Nivel 3.
  2. El equipo está formado por desarrolladores que acaban de unirse a la empresa hace 2 meses, mientras que el PM ha estado trabajando para la empresa durante 8 años.
  3. Proyecto iniciado hace 2 meses.
  4. Este proyecto no tiene conceptos fundamentales / base para la demostración.
  5. El equipo está practicando metodología ágil (Mi primera vez con ágil)

Esto es lo que noté sobre el flujo de trabajo/SOP actual del equipo:

  1. Todos los requisitos de los usuarios no se han documentado ni aprobado correctamente hasta el momento.
  2. Después de recopilar los requisitos, el PM instruyó a los desarrolladores para que codificaran la solución (de acuerdo con la idea/visualización del PM), mientras que las soluciones aún no se han documentado y discutido con el cliente para su confirmación.
  3. Si bien las soluciones aún se encuentran en la etapa de desarrollo o se han completado para la demostración, PM envía el flujo de proceso diseñado al cliente para su revisión. Comentarios del cliente con cambios (a veces menores, a veces importantes) y PM solicitó al equipo que modificara de acuerdo con los comentarios dentro de las próximas horas / días.
  4. PM siempre recibió una llamada del cliente, después de la llamada, el 90% de las veces habrá algunos cambios (modificar funciones existentes o agregar nuevas funciones) en el sistema y, a veces, el equipo debe hacerlo en las próximas horas / días.
  5. Hoy, el PM discutió esta Idea A conmigo y los desarrolladores. Lo he documentado y enviado a PM para revisiones. Después de los próximos días, cuando mencionamos la Idea A, el PM cuestionará por qué estamos usando la Idea A si es incorrecta y nos pedirá que cambiemos a la Idea B.

¿Es esta una gestión de proyectos saludable? Expresé mis preocupaciones al PM de que deberíamos tener la documentación adecuada (URS, FRS, etc.) y firmar para evitar cambios frecuentes de ideas/solicitudes y ganar tiempo para los desarrolladores, pero el PM dijo que este cliente no se preocupa por y no seguirá los procedimientos. ¿Qué debemos hacer para manejar estos escenarios?

¿Cual es tu papel? ¿Cómo te está afectando este tema? ¿Por qué es tuyo este problema para resolverlo?
¡Hola, Todd! Mi papel aquí es un analista de sistemas. Este problema me estaba afectando porque tenía experiencia en el método de cascada durante los últimos 4 años trabajando en una empresa anterior. En esta empresa/entorno actual, no hay estandarización/SOP definidos como el equipo recién incorporado. He hablado con el primer ministro sobre esto porque me temo que si estos escenarios continúan existiendo, afectarán el rendimiento del equipo. También me afectará pensar si debo seguir trabajando en este tipo de ambiente.

Respuestas (3)

Ciertamente no parece saludable como se describe :/. No puedo hablar de todos los puntos, pero de una sola pieza:

  • Si está trabajando en funciones sin haber probado nada, esto no es genial. No estoy seguro de que necesite más documentación, pero sí necesita entrar en un ciclo repetible de "Construir una pieza de trabajo, mostrársela al cliente, decidir en colaboración la siguiente cosa más importante para construir".

    Si quieren cambios después de verlo, muy bien, deben priorizarse con el resto de los elementos de la lista.

Si no está llegando a un software que funcione o se pueda demostrar antes de que el cliente o el PM soliciten cambios, O si los cambios siempre son la máxima prioridad, entonces nunca alcanzará el ritmo de entrega de software que funcione y el proyecto será predecible. frágil y estresante. :(

El rápido tiempo de respuesta exigido para los cambios y las adiciones también es incompleto: es imposible entrar en un ciclo de desarrollo sensato si cada nuevo capricho es la máxima prioridad.

Estoy seguro de que otros pueden contribuir con una visión más específica, aunque la mejor de las suertes. No se preocupe demasiado por la documentación, pero insista en un ciclo de desarrollo sensato, requisitos priorizados y demostraciones frecuentes.

¡Hola Taylor! ¡Gracias por dejar tus opiniones! He leído información sobre la metodología ágil hoy y estoy de acuerdo con usted con respecto a la documentación. Estaba preocupado porque estaba practicando en cascada anteriormente y todavía estoy tratando de adaptarme a un entorno ágil. No estoy seguro de por qué la compañía no tiene una versión de demostración, pero creo que están asumiendo un gran riesgo para poder aprovechar las oportunidades de hacer este proyecto.

El equipo está practicando metodología ágil (Mi primera vez con ágil)

Agile no es realmente una metodología. Es un enfoque para hacer desarrollo de software que incluye valorar la respuesta al cambio sobre el seguimiento de un plan.

Parece probable que esté siguiendo un marco ágil, posiblemente Scrum o Kanban . Si está trabajando en sprints, es probable que esté usando Scrum. Valdría la pena obtener más información de su organización sobre qué marco están siguiendo, ya que esto nos permitirá responder de una manera más específica a su pregunta.

Hay algunos problemas con el enfoque actual:

el PM instruyó a los desarrolladores para que codificaran la solución (según la idea/visualización del PM)

Esta no es una práctica ágil. Por lo general, alentamos a las personas que realizan la implementación a que produzcan el diseño.

Comentarios del cliente con cambios (a veces menores, a veces importantes) y PM solicitó al equipo que modificara de acuerdo con los comentarios dentro de las próximas horas / días.

Los comentarios de los clientes son valiosos y son una parte muy importante del enfoque ágil. Sin embargo, es inusual responder a todos los comentarios de inmediato. Un enfoque común sería recibir los comentarios, revisarlos, priorizarlos (junto con otros requisitos existentes) y luego llevarlos a la próxima sesión de planificación si es necesario.

PM siempre recibió una llamada del cliente

No es inusual tener un punto principal de contacto con el cliente. Sin embargo, suele ser muy valioso que los miembros del equipo de entrega también hablen con ellos. Ciertamente no tendría sentido poner barreras a la comunicación entre el equipo de entrega y la persona que proporciona los requisitos/retroalimentación.

el PM cuestionará por qué estamos usando la Idea A, ya que es incorrecta, y nos pedirá que cambiemos a la Idea B

Esto es claramente una disfunción. Valdría la pena reunir al equipo de entrega y hablar con el director del proyecto. Sugiera un enfoque diferente, en el que el equipo se apropie más del desarrollo. Si tiene un entrenador ágil en su organización, esta sería una buena oportunidad para involucrarlo.

¡Hola Barnaby! ¡Gracias por su valiosa información! Estuve de acuerdo con la implementación para el diseño. Pero, ¿no es mejor si redactamos las soluciones y las presentamos al cliente antes de que los desarrolladores comiencen la codificación? No estoy seguro de si esto es aplicable en ágil. ¡Espero que me puedas aconsejar!
También le sugerí al PM que permita que los desarrolladores se apropien más del desarrollo, por ejemplo: déjelos decidir/planificar cómo deberían funcionar las funciones/base de datos, ya que saben qué es lo mejor para ello. Pero el primer ministro parece dudar de sus capacidades e hizo que el equipo diseñara según la sugerencia del primer ministro. A veces, siento que el PM está cruzando la línea al microgestionar los aspectos técnicos. De vez en cuando, el dev. Las soluciones del equipo parecen complicadas (querían asegurarse de que la codificación base tenga escalabilidad en el futuro), pero el PM insistirá en simplificar las cosas.
No hay nada de malo en hacer un diseño inicial. Sin embargo, es importante darse cuenta de que las personas generalmente son mucho mejores para dar retroalimentación sobre una aplicación que funciona que sobre un diseño. El truco es encontrar el equilibrio adecuado para su equipo: suficiente diseño inicial para comenzar, pero también dejando espacio para los cambios resultantes de los comentarios una vez que el cliente ve la aplicación. De eso se trata ágil: anticipar y adaptarse al cambio.
Para intervenir en la pregunta de "diseñar antes que codificar": hay un eslogan ágil, "Construir lo incorrecto rápido" (yo agregaría, "y barato"). La idea es que lo primero que construya inevitablemente no sea del todo correcto y que, en general, sea más rentable construir algo rápidamente que las personas puedan usar y sobre lo que puedan brindar comentarios significativos, de modo que la próxima iteración esté más cerca de lo que quieren. .

"Lo creas o no, la respuesta del mundo real podría ser: tal vez no, pero tenemos que hacerlo de todos modos".

"Ágil", en primer lugar, es un ideal. (Una perspectiva valiosa y útil, pero "un ideal" al fin y al cabo.) Como tal, contiene ciertos supuestos simplificadores -que pueden o no ser ciertos- tanto con respecto al "cliente" como con respecto a las circunstancias en las que "el cliente" podría estar tratando. Afortunadamente, su equipo tiene un PM que tiene "8 años de experiencia en esta empresa". ("Aleluya.")

El software de computadora es muy exigente y lleva mucho tiempo ($$$!!) desarrollarlo. Por lo tanto, el equipo podría ser enviado hacia adelante en una dirección particular antes de que esa dirección se entienda por completo, sabiendo que el resultado será una reelaboración. Se puede actuar sobre los requisitos del cliente antes de que el cliente (!) sepa completamente cuáles serán los requisitos finales, o haya tomado (o se haya enterado de) las decisiones comerciales finales que los determinarán.

Lo que está sucediendo aquí, y esto es algo que una metodología realmente es demasiado simple de entender, a pesar de sus méritos, es una serie de conjeturas informadas que se realizan simultáneamente en varios niveles diferentes, tanto dentro como por encima del equipo.

La "programación de computadoras" exige necesariamente "certeza absoluta" ya que la máquina en cuestión solo conoce el 1 y el 0 , pero esta "adivinación" se está aplicando para igualar el esfuerzo contra la incertidumbre comercial del mundo real con, esperamos, el menor desperdicio y reelaboración posible. posible.

Además, "una vez que se finalice el software, será fijo y, por lo tanto, mucho más difícil de cambiar". Este es otro argumento a favor de la "fluidez" que las metodologías de programación tienen tanta dificultad para entender. La empresa podría comprometerse con ciertos aspectos del proyecto general, por así decirlo, especulativamente, sabiendo que algunas partes necesitarán ser reelaboradas pero no todas.

La solución de desarrollo se apresuró antes del acuerdo sobre los requisitos: ¿es esta una gestión de proyectos saludable?
RespuestasAquíPolítica de privacidad1y, 0v