¿Cuánta gestión de proyectos se supone que debe hacer un desarrollador de software?

Para no ser demasiado amplio para empezar, la pregunta directa sería:

¿Se espera que un desarrollador deba recordar continuamente a los administradores de proyectos sobre una característica no implementada porque carece de recursos para implementarla?

Las reglas son las siguientes: Tenemos un tablero con tareas en columnas. Un desarrollador elige una tarea en "ABIERTO" y comienza a trabajar en ella. Mientras lo hace, mueve la tarea a "EN CURSO". Cuando termina, la tarea pasa a "DESARROLLO REALIZADO" (luego a pruebas). Pero si algo sale mal, la tarea se debe mover a "COMENTARIOS" donde se debe resolver algo. Tal vez falta el diseño o alguna descripción no está clara...

Bastante simple si me preguntas.
En mi opinión, como desarrollador, cuando una tarea no se puede completar y su ticket está en "COMENTARIOS", es responsabilidad del gerente de proyecto realizar un seguimiento de una función y esforzarse por encontrar una persona que pueda resolver el problema.

Pero lo que sucedió en nuestro equipo: Se envió un ticket a "FEEDBACK" ya que no se implementó la API que se necesitaba. El ticket permaneció allí durante algunos meses (sí, casi medio año en realidad) y luego, en algún momento, uno de los gerentes de proyecto simplemente cerró el ticket porque otro gerente de proyecto informó que envió el problema a otro equipo. Pasa otro mes y de repente aparece esta característica no completada. Ahora, uno de los gerentes de proyecto está furioso y afirma que es nuestra responsabilidad como desarrolladores hacer un seguimiento de esas cosas y que esperaría que tuviéramos algún tipo de lista de cosas que no se han hecho.

¿Es esto cierto? ¿Deberíamos hacer un seguimiento de algunas cosas adicionales al lado del tablero que ya tenemos? Esperaría que una sola placa fuera suficiente para tales cosas y el equipo de desarrollo hizo todo lo posible para evitar tal desorden. Si no es así, ¿tiene alguna recomendación sobre cómo evitar tales problemas o cómo realizar un mejor seguimiento de tales problemas potenciales?

Para dar una historia completa sobre cómo/qué sucedió:

Estamos haciendo una aplicación móvil. Hace unos meses recibimos una solicitud de que en una pantalla específica (rara vez vista por un usuario) se puede recibir un error de la API (debido a alguna situación rara). Ahora, este error específico también informará un código de suberror. Entonces, si ocurre este error, se agregará un sub-error Ao sub-error . BY dependiendo de este suberror, la aplicación debe mostrar screenAo screenB. Pero la API no proporcionó Ani Bla tarea completada no pudo ser validada o probada.

Entonces, el ticket se colocó en "COMENTARIOS" explicando que la API simplemente no está lista para eso. Pero luego comenzó una discusión sobre el boleto sobre ver la pantalla de todos modos solo para verificar el diseño. Entonces, el desarrollador agregó una lógica para mostrar aleatoriamente screenAo screenBe informó esto en el ticket que todavía estaba en "COMENTARIOS".

Pasaron los meses y en algún momento uno de los PM trató de manejar esto. Así que (supongo) informó esto al equipo responsable de la API y comentó en el ticket, algo así como "Nos dijeron que esto es un error de su parte. Mención: theOtherPM, ¿podemos cerrar este ticket ahora?". Y "theOtherPM" luego cerró el ticket. Otro mes después, todo el infierno se desata por esto y estoy confundido por qué es culpa de nosotros los desarrolladores.

Nota: Otra cosa a mencionar es que el otro equipo, que es responsable de la API (entre otras cosas), no es parte de nuestra red y ni siquiera de nuestra empresa. Nosotros, como equipo de desarrollo, no tenemos comunicación directa con ellos. Así que no había otra forma de resolver esto sino a través de nuestra gestión.

¿Existe incluso la posibilidad de una respuesta autorizada a esto? ¿No va a variar esto de un sitio a otro/de un equipo a otro?
@ MarkC.Wallace Espero que no. Creo que hay algunos acuerdos generales sobre las responsabilidades de un cargo y otro que deberían apuntar objetivamente en una u otra dirección. De lo contrario, "Esto debe definirse específicamente dentro de su equipo" también es una respuesta válida, siempre que pueda tener al menos algunos argumentos para ambos lados.
Como gerente de proyectos que también es un desarrollador experimentado, respondería que es responsabilidad de su equipo realizar un seguimiento de las tareas que usted crea para sí mismo o que se le asignan desde el exterior. Ustedes son los que realmente están desarrollando el código fuente y quienes, por supuesto, están íntimamente familiarizados con las complejidades internas de la implementación del software subyacente. Los gerentes de proyecto generalmente se enfocan en un nivel de preocupación más alto y más amplio: "el proyecto en sí". Confían en usted para lograr las minucias de bits y bytes... correcta y visiblemente.
Además: imagínese que son los "expertos en la materia (PYME)" de cómo, exactamente, se está construyendo y depurando esta aplicación para que funcione de manera precisa y completa según las especificaciones. Esa es tu preocupación. Mientras tanto, los gerentes de proyecto buscan, por ejemplo, esa especificación... el entorno en el que funcionará la aplicación... todos los demás proyectos y grupos de trabajo que podrían afectar o verse afectados por su trabajo . en 'qué, no cómo'". ¡ Dos puntos de vista y responsabilidades paralelos pero diferentes, ambos esenciales!
@MikeRobinson Interesante. Suena razonable. Pero difícilmente podría implementarlo en nuestro caso. Quizás sea importante tener en cuenta que el "otro equipo" que maneja la API no es un equipo al que tengamos acceso. Para colmo, ni siquiera son la misma empresa. Así que realmente no hay manera de pasar por alto a nuestros gerentes de proyecto para obtener el recurso que necesitábamos. Así que nosotros, como equipo de desarrollo, les notificamos. De hecho, incluso discutimos esto varias veces con los PM. Y parecía que lo tenían controlado pero en algún momento nuestro ticket se cerró y se perdió información. Y los PM lo cerraron así que...
Esto depende mucho de la cultura de la empresa. Todo el mundo lo hace un poco diferente, por necesidad.
@MaticOblak Ese punto acerca de que el equipo API es un tercero tendrá un impacto bastante grande en las respuestas (por ejemplo, presumiblemente no tienen visibilidad de su tablero Kanban y no se puede esperar que trabajen con Tickets que ni siquiera conocen) existen!), y recomendaría asegurarse de tener una lista de quiénes son los Propietarios de la relación para todos sus Terceros en el futuro, y asegurarse de que asistan al menos a una reunión por semana para recibir y proporcionar comentarios y actualizaciones.
Pregunta retórica: ¿quién cerró el boleto?
¡No es que alguna vez debas "pasar por alto a los gerentes de proyecto para obtener recursos!" Si hay un problema con un equipo remoto, necesitan saberlo ahora mismo. No, no es necesario que conozcan los detalles de bits y bytes, pero esto es algo que está obstaculizando el proyecto. // Obviamente, todo esto se reduce a una falla de comunicación. "Cerrar el ticket" podría haber sido accidental o mal informado. La causa debe investigarse para comprender.

Respuestas (2)

Roles Responsables vs. Responsables en un Sistema Pull-Queue

La pregunta que estás haciendo es realmente un problema X/Y. Tiene un par de otros problemas que en realidad no ha mencionado en su pregunta:

  1. Kanban es un sistema pull-queue , no un sistema push. Por lo tanto, a menos que el equipo de la API sepa extraer de su columna de "comentarios", o a menos que tengan su propio trabajo pendiente para que usted coloque los elementos de trabajo, no está claro por qué se espera que realicen el trabajo (o incluso que sean conscientes de ello). ).
  2. Los marcos ágiles dependen en gran medida de las comunicaciones multifuncionales. Si solo está clasificando tickets en el estado, en lugar de colaborar con las partes interesadas como el equipo de API, entonces su proceso no funciona.
  3. No se realiza un seguimiento de los elementos de trabajo que no están claramente vinculados a un hito o una entrega. No hay forma de determinar solo a partir de su pregunta quién es el propietario dentro del proceso actual de su empresa.
  4. Las distinciones entre los roles responsable y responsable de su proceso no se han definido o se han comunicado de manera insuficiente.

Si tiene gerentes de proyecto tradicionales que son responsables del proyecto, en última instancia, son responsables de rastrear el estado de los elementos de trabajo e informarlos de manera adecuada. Esto es cierto ya sea que deleguen o no parte de esa responsabilidad a los miembros del equipo.

Por otro lado, si tiene un proceso verdaderamente ágil, tanto la responsabilidad como la rendición de cuentas para el seguimiento de los elementos de trabajo deben estar claramente definidas por los acuerdos de trabajo del equipo, tanto dentro del equipo como con otros equipos. No hay una respuesta correcta o incorrecta sobre quién debe rendir cuentas o ser responsable, siempre que satisfaga las necesidades de todas las partes interesadas, incluidas las del propio equipo del proyecto.

El problema con su primer punto es que el equipo de API no es parte de nuestra empresa y es más como un recurso para nosotros. Los equipos de desarrollo no tienen comunicación directa con ellos, por lo que nuestros PM deben reenviar este "error" a cualquier medio que tengan (según tengo entendido, tienen comunicación abierta, incluso reuniones semanales, con la otra empresa). Entonces, este ticket fue retirado por un PM, el proceso se activó, pero el ticket se perdió. Entonces parece como si estuviera implícito que el equipo de desarrollo debería tener otro Kanban que rastrearía algo no implementado. Para mí esto suena extraño.
El segundo punto también tiene un problema similar al primero. Debo estar de acuerdo en que en la mayoría de los proyectos en los que trabajé teníamos colaboración y comunicación directa con otros equipos dentro de un proyecto. Pero no siempre fue así y no estoy seguro de que esto rompa nada. Por ejemplo, hace algunos años estaba trabajando en un control remoto iOS para un dron. Además de otras cosas, necesitaba integrar un marco que fue realizado por otra empresa en el otro lado del mundo. El marco todavía estaba en progreso similar a la API en este caso. Pero nunca conocí al equipo que hizo el marco. ¿Es esto un no-no?
La conclusión es interesante y lleva a lo que más me molesta: los roles no están claramente definidos, pero al mismo tiempo, tan pronto como ocurre un problema, se señala con el dedo. La razón por la que esto me molesta es que el problema en sí no se analiza y no se hace ningún esfuerzo para garantizar que esto no vuelva a ocurrir. Y desafortunadamente, esto ya sucedió dos veces y todavía no tengo idea de cómo abordarlo. Es por eso que recurrí a ustedes en busca de ayuda. Gracias.
Estoy de acuerdo: los dedos apuntan y el proceso de colaboración se rompe. Yo pensaría que los equipos de desarrollo y los gerentes de desarrollo , no los gerentes de proyecto de nivel superior , serían los responsables de las comunicaciones con los contratistas remotos debido al nivel de contexto puramente técnico que se requiere para comunicarse de manera efectiva. "Kaiban" o no, alguien no está hablando con otra persona y ahora mismo te está costando mucho dinero.

Creo que esto tiene una respuesta canónica, al menos desde el punto de vista de un PM tradicional, si no con Agile o Kanban o cualquier otra cosa.

Si un trabajo no pudo ser terminado por cualquier motivo, por el mecánico, el desarrollador, el comerciante, quien sea, entonces el problema recae en la parte del proyecto de PM o control de PM para ser rastreado y resuelto. El personal del proyecto asignado que debía implementar ese trabajo pasa a otro trabajo o incluso abandona el sitio del proyecto. Ese rol ya no podría, y en muchos casos, ya no puede rastrear ni controlar ese problema. La responsabilidad pasa a ser del propietario dentro de los controles de PM y eso puede variar proyecto por proyecto.

Si algo falla en ese proceso y ese artículo se pierde, la responsabilidad de esa pérdida recae en los controles de PM o PM.

En un escenario altamente técnico como este, prefiero decir que el PM es responsable de conocer la existencia del problema y saber que se resolvió oportunamente. Esperaría que los gerentes de desarrollo , que trabajan directamente con el "equipo local", sean los que se comuniquen con los contratistas, proporcionen información constantemente a los PM pero no les pidan que sean intermediarios. (Tengo la sensación de que en la organización del OP se les pide que desempeñen estos roles ...)
Los roles se pueden definir de muchas maneras. Sin embargo, algunas definiciones de roles simplemente no tendrán sentido. Sé que la mayoría de los temas de este intercambio son sobre software, pero a menudo considero otros tipos de proyectos para responder a estas preguntas. Estoy pensando en un plomero en un trabajo de vivienda que se topó con un bloqueador para su trabajo. El plomero informa el problema y luego se va o se va a otra parte de la casa. No puedo imaginar que el plomero sea el responsable de mover el bloqueador. Podría requerir cambio de contrato, cambio de arquitectura, cambio de ingeniería. Fuera del alcance del fontanero.
¿Cuánta gestión de proyectos se supone que debe hacer un desarrollador de software?
RespuestasAquíPolítica de privacidad1y, 0v