¿Cómo puedo persuadir a los desarrolladores de mi equipo para que adopten "Lo construyes, lo ejecutas"?

¿Cómo puedo persuadir a los desarrolladores de mi equipo para que adopten "Lo construyes, lo ejecutas"? Por eso, tengo en mente esta cita de Werner Vogels :

Otorgar responsabilidades operativas a los desarrolladores ha mejorado enormemente la calidad de los servicios, tanto desde el punto de vista del cliente como de la tecnología. El modelo tradicional es que llevas tu software a la pared que separa el desarrollo y las operaciones, y lo arrojas y luego te olvidas de él. No en Amazon. Lo construyes, lo ejecutas. Esto pone a los desarrolladores en contacto con la operación diaria de su software. También los pone en contacto diario con el cliente. Este ciclo de retroalimentación del cliente es esencial para mejorar la calidad del servicio.

Estoy pensando específicamente en un conjunto de desarrolladores que:

• Fueron contratados para un rol de desarrollador, con poca o ninguna mención de tareas relacionadas con operaciones.
• Tradicionalmente, ha "arrojado código sobre la pared" a un equipo de operaciones.
• Tradicionalmente tienen un horario de trabajo de 9 a 5, y son activamente hostiles a la idea del "deber de buscapersonas", participando en la recuperación de desastres, escribiendo autopsias, etc., especialmente fuera del horario comercial normal. (Nota: solo tengo en mente interrupciones muy poco frecuentes para esto; no estoy proponiendo que agreguemos atención al cliente fuera del horario laboral a la carga de trabajo de este equipo).
• Actualmente no son responsables de escribir / apoyar el monitoreo o las alertas en sus aplicaciones.

Supongamos que hay un equipo que está desarrollando rápidamente nuevos microservicios en la nube con un perfil que será tal que entregar estos servicios a un equipo de operaciones es subóptimo porque no pueden mantenerse al día con respecto a obtener un conocimiento profundo de los servicios que se requieren para administrarlos y monitorearlos de manera efectiva. "Lo construyes, lo ejecutas" funcionaría mejor para este equipo porque las tareas podrían delegarse a cada miembro responsable del equipo. Por lo tanto, este equipo comenzaría a participar en el diseño de la infraestructura, el monitoreo / alerta de herramientas para los servicios y (con muy poca frecuencia) responder a los eventos de interrupción.

Me interesan específicamente las metodologías, respaldadas por ejemplos del mundo real. ¿Cómo se ha implementado con éxito en otros lugares de trabajo, y si hay pasos canónicos a seguir al implementar esto? Cualquier enlace a las redacciones que puedan admitir respuestas sería muy útil.

Creo que la forma más fácil es cambiar sus objetivos de rendimiento para que se basen en la confiabilidad y en la entrega de código. Véndalo ya que la compañía no puede tener éxito sin ambos, entonces, ¿por qué los desarrolladores solo deben medirse en uno? La mejor manera para que puedan cumplir sus objetivos de desempeño es participar en las operaciones.

En última instancia, debe convencerlos de que esta es la mejor manera para que la empresa tenga éxito y, por lo tanto, para que tengan éxito. Eso es difícil y no puedes esperar que estén a bordo desde el principio. Necesitan ser vendidos en el valor también.

Cuando se trata de afectar la cultura empresarial, la mejor manera es probablemente a través del conocido método "hervir la rana". Tienes que presentar estas tareas a los desarrolladores lentamente, porque sé que yo mismo (como desarrollador) me negaría a tener toda esta nueva responsabilidad a la vez.

Primero, comience introduciendo una o dos tareas nuevas que solo se realizarán durante el horario comercial normal. Necesitan aprender a hacer devops, lo que podría ser un proceso de aprendizaje para un desarrollador de código (hasta este punto) y podría requerir cierta supervisión. También es probable que sean hostiles a la idea de cambiar su equilibrio trabajo-vida ya que mencionas que están acostumbrados a 9-5. En este punto, registre datos sobre los nuevos procesos para su uso posterior (pídales que escriban este código, los datos siempre son útiles).

Más tarde, cuando se esté quedando sin nuevas tareas devops-y para introducir (por lo que los puntos primero, segundo y cuarto están casi completos), presente las primeras tareas que ha presentado como candidatos para realizar fuera de las horas de trabajo estándar . Puede ver una reacción violenta en esto e incluso puede ver algo de desgaste dependiendo de qué tan fuerte empuje esto y cuán fuertemente esté arraigada la cultura del trabajo a los cinco años. Para defenderse de esto, es de esperar que sus datos respalden la idea de que trabajar más allá de las horas estándar será raro, solo ocurrirá en situaciones extremas y beneficiará enormemente tanto al negocio como al cliente. Si sus datos no son compatibles con esto, será mejor que esté listo para lidiar con las consecuencias de esta elección.

Incluso con los datos, puede que aún sea más fácil tener los desarrolladores a escribir el seguimiento / alertar código (de modo que se conviertan en dev ops aunque sigue siendo principalmente dev) y mantener el equipo de operaciones alternativo como soporte de primera línea (como algunos otros han sugerido). Como dije, pequeños cambios son importantes para evitar la reacción violenta. Integrar el trabajo para los desarrolladores más allá de las horas estándar será un desafío, ya que pueden saber que pueden buscar empleo en otro lugar si no les gusta, ya que el mercado para los desarrolladores es fuerte en este momento, especialmente si ya tenían habilidades de desarrolladores. Advertencia emptor!

Mirando fuera de DevOps específicamente, si está hablando de entornos empresariales grandes (ish), entonces la metodología SAFe tiene una forma bastante buena de fomentar este tipo de comportamiento.

Esencialmente se reduce a unas pocas etapas clave:

• los proyectos comienzan como trenes de lanzamiento. La intención (y la expectativa de quien sea que lo esté financiando) es que sea a largo plazo. Estoy hablando durante años, nada de esto es "poner en pie a un equipo durante 3 meses y luego desestimarlos".

• En el transcurso de un proyecto, el tren de lanzamiento inevitablemente acumulará más personas a medida que se cumplan más los requisitos de los nuevos proyectos basados ​​en las oportunidades comerciales recién realizadas, así como el impuesto continuo del trabajo de estilo de mantenimiento.

• Casi siempre veo que los trenes ejecutan su primer incremento como equipos 100% de proyecto / cambio, el segundo incremento asignan un porcentaje de tiempo para ejecutar el trabajo. La administración del tercer incremento se da cuenta de que están a punto de tener un problema y comienza a agregar equipos para tratar de manejar el desbordamiento de ejecución para darles a sus experimentados desarrolladores e ingenieros tiempo para seguir trabajando en los nuevos requisitos.

• si se alcanza el equilibrio correcto de que los equipos del proyecto puedan seguir entregando los resultados del proyecto sin verse empantanados en mucho trabajo de mantenimiento y no se espera de inmediato que los nuevos equipos que se unen al tren sean solo equipos de soporte al 100%, sino que en cambio buena parte del trabajo de cambio que iba a ser manejado, entonces terminas con equipos de entrega que son dueños de los productos que están construyendo de manera predeterminada, no es necesario que los veas todos de una vez que ahora son un equipo Run, en cambio, se integra lentamente en sus actividades diarias.

Donde este modelo obviamente tiene algunas debilidades es en el precio de un negocio. En general, esperaría pagar mucho más por un recurso de cambio que por un recurso ejecutado, por lo general, los contratos ejecutados con los principales proveedores tienen un precio fijo y la intención es que ganen dinero con la mejora continua y, por lo tanto, con el ahorro de costos.

Dicho esto, no es tan difícil considerar que los equipos de cambio se pusieron de pie como parte de un tren de lanzamiento para simplemente ofrecer mejoras continuas. Si hay algo que pueden construir o hacer que mejorará su capacidad de enfocarse en las entregas de nuevos proyectos y se preocupará menos por el trabajo de "negocios como de costumbre", entonces eso debería retrasarse y priorizarse en función de los beneficios percibidos por quien tenga el dinero para el liberar tren.

En mi humilde opinión You build it, you run itno debe tomarse literalmente. Para empezar, casi suena como un castigo;)

Ninguna persona sola o incluso un pequeño equipo de desarrolladores puede admitir razonablemente una herramienta o un conjunto de herramientas utilizado en el proceso de desarrollo de software (es decir, ¡en producción!) Durante largos períodos de tiempo. He estado allí, hecho eso :)

Las tareas de soporte tienden a expandirse a medida que crece la base de clientes de la herramienta (conjunto). Si asume esos deberes exclusivamente, el equipo de desarrollo podría terminar brindando mayormente apoyo, con poco / ningún tiempo restante para el desarrollo en el futuro. Efectivamente un callejón sin salida: ¿cuántos desarrolladores querrían quedarse en ese entorno?

Tener un equipo profesional de primera línea de soporte es crucial para evitar la frustración, el estrés y otros efectos de la exposición a largo plazo a las tareas de soporte sobre los miembros de su equipo de desarrolladores.

El equipo de soporte de primera línea, por supuesto, recurriría al equipo desarrollador (nuevamente, ¡equipo, no una sola persona!) Por problemas que no pueden cubrir directamente. Sí, puede ser difícil al principio, pero las cosas mejorarán. Debería ser una colaboración, eso es parte de lo que se trata DevOps.

Esto depende en última instancia del tamaño y la estructura de la empresa. Realmente hay tres etapas en las que puede estar su empresa:

1. La etapa de inicio (menos de 150 ingenieros). Por supuesto, los desarrolladores necesitan ejecutar su propio software. Todos lo hacen en una startup. Puede que ni siquiera tenga un equipo de operaciones para empezar, pero incluso si lo tiene, es pequeño y la velocidad de progreso es tan rápida que no hay forma de pasar el conocimiento requerido para ejecutarlo con éxito en otro equipo lo suficientemente rápido como para que puedan tener éxito.

2. La empresa mediana (más de 150 ingenieros, pero un solo equipo de operaciones). En esta etapa, la rotación de la empresa comienza a ser demasiado alta, los ingenieros que crean software no necesariamente se quedan para ejecutarlo. Ya no conoce a todos y es difícil comunicarse de manera efectiva para que todos estén en operaciones. Comenzaría a convertirse en un caos. En esta etapa, desea recurrir al modelo de Google, donde cada equipo tiene que poner en funcionamiento su software, pero no necesariamente operarlo. Lo operarán al principio, pero una gran parte del software de construcción es reducir el costo de operarlo hasta un punto, donde la carga es lo suficientemente pequeña como para que el equipo de operaciones pueda iniciar sesión ejecutándola. Solo entonces se considera hecho.

3. Gran empresa con múltiples unidades de negocio (donde cada uno tiene su propio equipo de operaciones): en esta etapa, puede volver al modelo de Amazon, donde cada equipo esencial desarrolla y opera sus propios servicios. Cada una de las unidades de negocio tiene que ser lo suficientemente pequeña como para que todos se conozcan entre sí, por lo que hay menos de 150 ingenieros y usted opera esencialmente como una startup. Amazon tiene cada servicio de AWS operando más o menos por separado y funciona para ellos.

Tiene que averiguar en qué etapa se encuentra su empresa y / o en dónde se mudará y actuar en consecuencia. No existe una solución de "talla única".

Mi opinión sobre esto (si me enfrentara a ese mandamiento, o como sea que lo llames), sería algo así como " What else would you expect?!?!". Porque, accidentalmente:

• Ni siquiera podría vivir sin eso, y
• Me encanta comer mi propia comida (de perro).

Déjame explicarte un poco más ...

Mi negocio / hobby / pasión es scm , más específicamente en entornos mainframe . Y donde quiera que vaya (para ajustar las cosas a las necesidades de los clientes), el primer requisito que impongo (en mi contrato), es que cualquier ajuste realizado al sistema que implementamos, es a través de ese mismo sistema. Y al hacerlo (es cierto, eso lleva unas pocas horas, digamos medio día como máximo), obtenemos estos beneficios (lista incompleta):

• Casi no documento nada de lo que hice para que el sistema funcione. Si se hacen preguntas, solo consulto el sistema (y enseño al cliente cómo consultar el sistema sin mi ayuda).
• Si me llaman en X meses / años (¿para actualizar a una nueva versión?), Quiero saber (recordar) qué he estado haciendo antes (y lo único en lo que confío es en lo que el sistema me dice, también conocido como me recuerda a)
• Solo necesito preguntar al cliente una vez acerca de cómo hacer cosas específicas en su sitio (las convenciones de nomenclatura son difíciles de recordar), o convencerlo de que otorgue los permisos requeridos para "el sistema" (no para mí ...).
• Estás continuouslyprobando QA tu propio sistema ... en producción. Es probable que experimente errores, errores lógicos o características faltantes (y lo que no). Y esos son extremadamente motivadores para abordarlos lo antes posible ... por ejemplo, para ser más productivos.
• ... y si quieres puedo agregar otra docena de razones ...

Sin embargo, antes de intentarlo en casa, tenga en cuenta algunas trampas que debe evitar:

• desea que todos se unan a la fiesta (use el sistema), porque solo 1 "excepción" (¿también conocido como el gerente / propietario de la empresa?) puede arruinar la fiesta (pensaría que puede confiar en su sistema, pero alguien hizo algo sin preguntar / usar el sistema). Esos casos pueden costarle días para descubrir ...
• los nuevos usuarios pueden quejarse de que al usar este (nuevo) sistema, les lleva más tiempo hacer su trabajo (en comparación con lo que usaron antes). Y donde sea que tenga sentido, lo usarán como una excusa de por qué llegan tarde para completar su trabajo. En ese punto, es mejor que la gerencia superior lo cubra, porque de lo contrario su proyecto / sistema podría ser el culpable.
• asegúrese de conocer su propio sistema y cómo configurarlo para satisfacer sus necesidades. Como muestra (en mi caso): desea configurar el sistema para que use el entorno operativo para entregarlo a su entorno experimental, y no al revés ... He visto que eso sucedió en el pasado ... usando (abusando) el sistema de prueba para entregar a entornos altamente seguros.