Equipo de lanzamiento vs PM

En cuanto a la publicación del código y la separación de responsabilidades, ¿debe ser el director del proyecto o los equipos de publicación los que informen al negocio sobre las publicaciones? Creo que debería ser trabajo de los equipos de lanzamiento. Aquí están mis razones por las cuales.

  • En nuestro ALC, los documentos de liberación se escriben antes de firmar.
  • Hacemos dos lanzamientos a la semana.
  • Ejecutamos múltiples equipos de proyectos (6) y me gustaría una forma estándar de informar al negocio.
  • Requiere menos comunicación entre grupos, ya que el equipo de lanzamiento puede simplemente lanzar en lugar de llamar al PM para asegurarse de que se hayan enviado las cosas, etc.
  • Creo que parte del comunicado es informar directamente a la empresa. Brinda a las personas ajenas a TI una visión más amplia del valor de los equipos.

EDITAR: permítanme agregar algunos detalles, las "actualizaciones de desarrollo": se agregan a los tickets antes de cerrar la sesión, el equipo de lanzamiento solo recopila la información de los tickets. Cuando hay problemas con el lanzamiento, lo revertimos de inmediato. Otro detalle es que el equipo de lanzamiento está sentado con los desarrolladores, los PM y las pruebas se sientan en un edificio diferente.

Respuestas (3)

Responsabilidad versus ejecutores de tareas apropiados

Si bien el gerente del proyecto es responsable de facilitar las comunicaciones efectivas dentro del equipo y entre el equipo y el resto de la organización, esa responsabilidad no significa que el gerente del proyecto tenga que ser el ejecutor de la tarea. Es perfectamente aceptable delegar esa responsabilidad o alentar al equipo a desarrollar nuevos procesos o canales secundarios que aseguren que las comunicaciones de rutina sean lo más efectivas posible.

Depende. ¿Quién informó al negocio antes? Si fueron los equipos de lanzamiento, entonces tiene sentido dejar que lo hagan.

Falta un detalle importante en su argumento. Si otro equipo es responsable del lanzamiento, toda la información en el flujo será al menos de segunda mano, y en caso de emergencia siempre se requerirá un paso adicional . Imagina que algo sale mal durante el lanzamiento. El equipo de lanzamiento puede tener una pista sobre una posible solución, pero definitivamente necesitarán la ayuda de los equipos de desarrollo. Si la empresa envía comentarios, el equipo de lanzamiento los filtrará/modificará, no intencionalmente, por lo que existe una buena posibilidad de aumentar la cantidad de discusiones para aclarar las cosas.

Para seis equipos de proyecto, un equipo de lanzamiento completo parece demasiado, sin embargo, sé que a los clientes les gusta tener un solo punto de contacto (ya sea una persona o un equipo). Sugiero pedirle al gerente de proyecto del equipo responsable de la integración que sea el punto de contacto y hacer que todos los equipos sean igualmente responsables de los lanzamientos.

¡Gracias por el aporte! Esto supone que los comentarios se realizan a través del equipo de lanzamiento, los comentarios aún se realizan a través de la mesa de ayuda y el PM. El equipo de publicación simplemente recopila la información del ticket y la envía. Además, el equipo de lanzamiento es más necesario para el cumplimiento de SOX que por necesidad; sin embargo, al intentar pasar al modelo de implementación continua, ha demostrado ser bastante útil.
Tengo que preguntar. ¿Su equipo de lanzamiento realiza tareas devops?
"desarrolla tareas"? El equipo de lanzamiento solo trabaja en el proceso de lanzamiento y en la automatización del proceso de lanzamiento. También trabajan un poco en el ALC y también lo automatizan.
gracias por ese enlace, fue muy esclarecedor, he leído sobre cuando Yahoo compró Flickr pero nunca antes había oído hablar de DevOps. ¿Me pueden recomendar algún libro sobre este tema?
No conozco ninguno, sin embargo, me dijeron que las reuniones de devops son realmente geniales. Vaya a meetup.com y busque devops cerca de su ciudad/país.

Quien mejor pueda articular qué valor comercial se entregó debe hacer esa comunicación. Los ojos del equipo de negocios se pondrán vidriosos si solo envía una lista de los tickets desplegados. No quieren escuchar el galimatías técnico.

Creamos este rol de Product Owner y está funcionando muy bien. Mi recomendación es que crees este nuevo rol. Aquí hay un enlace que describe el rol del propietario del producto: http://www.scrumalliance.org/articles/44-being-an-efective-product-owner Mientras tanto, asigne esta responsabilidad a la persona que mejor pueda extraer el valor comercial de la lista de tickets y articularlo bien.

Equipo de lanzamiento vs PM
RespuestasAquíPolítica de privacidad1y, 0v