project management - steps - ¿Cómo cierro la brecha entre los desarrolladores y los equipos de soporte de producción?

project management steps (8)

Algunas ideas iniciales:

El equipo de producción son partes interesadas, por lo que deberían participar desde el primer día. ¿Su sistema es compatible? ¿Publica eventos de alerta en el sistema / panel de soporte? ¿Se requiere algún proceso manual (por ejemplo, rebote de fin de semana)? Al hablar con el equipo de soporte al inicio del proyecto, habrá creado los comienzos de una relación de trabajo.
En la medida de lo posible, involucre soporte de producción tan pronto como sea posible "produciendo" su sistema. Es decir, intenta que tus compilaciones Smoke, QA y UAT se gestionen como si fueran sistemas de producción. No siempre es posible para construcciones de humo, pero debería ser posible (incluso requerido) para QA / UAT.
Entrenamiento y documentación. Eduque al equipo de soporte de producción y bríndeles una buena documentación.
Asegúrese de contar con un proceso de soporte de segunda o tercera línea, es decir, que el equipo de soporte de producción pueda ponerse en contacto con un desarrollador cuando lo necesiten.

Para aclarar mi pregunta, permítame definir los términos del título:

Los equipos de soporte de producción son los recursos que mantienen las aplicaciones de software que están actualmente en uso. Los desarrolladores son los codificadores que escriben las aplicaciones de software de los requisitos.

A menudo, al menos en mi experiencia laboral, estos dos equipos se reúnen solo una o dos veces en el mejor de los casos para hablar sobre el próximo lanzamiento de producción. Se asume que los equipos de soporte de producción comprenderán los riesgos potenciales sin mirar los requisitos o documentos de diseño o sin reunirse alguna vez con los clientes o el interesado. Se espera que de una reunión de uno a dos con los equipos de desarrollo, los equipos de soporte de Prod comprendan, mitiguen y resuelvan los posibles riesgos de este lanzamiento.

Siendo este el problema, tengo la tarea de elaborar una guía para cerrar la brecha entre los Equipos de Soporte de Producción y los Desarrolladores. ¿Cuáles son tus ideas? ¿Qué preguntas deben hacerse cuando los dos equipos se unen?

Basándose en Elie, Tim y 17 de 26:
Haga un ciclo del 25% -33% de cada equipo dentro y fuera de cada lanzamiento. Quien ha estado allí por más tiempo; y no me importa cuál es el título de tu trabajo (arquitecto senior del hemisferio norte o peón). El soporte es efectivamente dogfooding la aplicación, ellos saben todos los gotcha (y se asegurarán de que estén corregidos - esto me ha estado molestando por 3 ciclos # $% # $% # $%), el desarrollo conoce mejor la última versión, por lo que son los mejores para la solución de problemas (oh, por supuesto, ese problema estará en la función XYZ).

Haga que la gente gire entre los dos equipos por un momento. De esa forma, cuando regresan a su equipo original, tienen una mejor comprensión de los problemas que enfrenta el otro equipo.

He tenido un gran éxito al tener los desarrolladores y los equipos de soporte sentados juntos, o al menos pasando algo de tiempo juntos. De esa forma, las ideas y suposiciones se transmiten temprano y algunos problemas pueden resolverse mucho antes.

La integración real solo puede venir del trabajo conjunto en el mismo proyecto.

Lo mejor es que el equipo de soporte participe en el desarrollo, por ejemplo, un equipo de 4 elementos, cada semana una persona está haciendo mayormente soporte mientras que los otros hacen desarrollo. Eso significa que el chico de apoyo puede descansar 3 semanas antes de volver a apoyarlo.

Esto hace que las personas caigan en el proyecto como "propias" y eviten volverse locas con las preguntas tontas y las tareas sin cerebro que a veces pueden ser compatibles.

Recuerde también que el equipo de soporte normalmente conoce mucho mejor a los usuarios y la forma en que usan el sistema. Por esa razón, están en la mejor posición para mejorarlo.

El equipo de soporte de producción debe tener acceso a los requisitos o documentos de diseño y participar para mantenerlos actualizados.

Para mí, trato de pasar el rato con la gente de PSG tanto como sea posible, tanto en el trabajo como fuera. Además, si tienen un problema, me levanto y les ayudo de inmediato si puedo. Cuanto más los conozcas, cuáles sean sus problemas y molestias en la vida, etc., mejor podrás configurarlos para ellos.

Tener dos equipos es un error desde el principio.

He visto esto (dos equipos distintos) en otras compañías y siempre me sorprendió que esto se haya hecho realmente en el mundo real.

Sugiero solo un equipo de desarrolladores, y algunos tienen la tarea de soporte, y algunos están haciendo un nuevo desarrollo, pero no hay una delineación clara.

Por un lado, no existe un ciclo de retroalimentación natural (positivo o negativo) para que los desarrolladores del nuevo código lo puedan mantener. Simplemente lo tiran al otro lado de la pared para que los mantenedores puedan manejarlo.

También lo he visto crear división, en lugar de cohesión. No veo nada positivo / bueno sobre el escenario, mientras que veo que un solo equipo de producto tiene muchos beneficios.

No puedo entenderlo

Estoy de acuerdo con otros, ya sea rotando o haciendo UN equipo.

EDITAR:

Entonces, para aquellos sin la capacidad de rotar a través de equipos, o formar un equipo:

Debe haber visibilidad en ambos lados en los problemas que surjan. Es decir, los comentarios de la producción deben llegar a los equipos de desarrollo.
Como sugiere, involucre al equipo de producción en las fases iniciales de diseño y planificación y recopilación de requisitos.
Los equipos deben poder tener fácil acceso el uno al otro

EDITAR:

Trabajé en una empresa que tenía un pequeño equipo que estaba prestado por el resto del equipo de desarrollo. Lo llamaron el equipo "swat". Construirían funcionalidades específicas para algunos clientes grandes o por una tarifa y el código se colocaría en una sucursal específica. Si bien son similares, realmente salieron del grupo de desarrolladores.

Tomaría la sugerencia de Elie un paso más allá y diría que siempre se rota a la gente. No conozco a ningún desarrollador que esté satisfecho únicamente con el trabajo de mantenimiento en el código que otras personas han escrito.

Por otro lado, los desarrolladores que solo escriben código nuevo nunca sentirán el dolor del mantenimiento y, por lo tanto, no aprenderán cómo escribir código que se pueda mantener.

Editar:
Idealmente, estoy de acuerdo con Tim: no debería haber equipos separados y es una práctica terrible. Asumía que no tendrías el poder de hacer ese cambio radical, pero tal vez lo hagas :).