DevOps: 5 consejos para derribar el Muro de la confusión

DevOps: 5 consejos para derribar el Muro de la confusión

En el pasado, una vez fui administrador de sistemas asignado a un equipo de proyectos de desarrollo de software que trabajaba en la implementación de una nueva aplicación de planificación de recursos empresariales. Mi trabajo consistía en ayudar al equipo de desarrollo en cualquiera de sus necesidades de administrador de sistemas, como la instalación de software, la ampliación de un sistema de archivos o la aplicación de un parche; si era una necesidad de administrador de sistemas en ese proyecto, yo era el tipo. Nuestro trabajo era entregar la nueva aplicación a tiempo y dentro del presupuesto.

No es que todo fuera excelente todo el tiempo. Como era la práctica de la compañía con la que estaba, las personas que trabajaban en proyectos especiales fueron reubicadas físicamente en otro edificio o área de trabajo para que todos en el equipo pudieran sentarse juntos. Sin embargo, en este caso, todos fueron reubicados a excepción de mí, según lo acordado entre mi gerente y el gerente del equipo de desarrollo de software. Como resultado, pasaría partes de mi día de trabajo con el resto del equipo del proyecto y las otras partes en mi área de trabajo habitual. Si bien pude atender muchas de las necesidades de los administradores de sistemas durante mis viajes diarios a la sala de equipo del proyecto, hubo otras ocasiones en las que el equipo de desarrollo necesitó de mi apoyo y yo no estaba en la sala con ellos.

Pero en general, el arreglo funcionó en su mayoría. Fui miembro del equipo de operaciones y trabajé directamente con los miembros del equipo de desarrollo.

Quizás estábamos “DevOps” antes de que se empezara a utilizar ese término.

Mi punto es que no había un “muro de confusión” entre el equipo de desarrollo y yo. A medida que aprendí más sobre DevOps, uno de mis conocimientos es que DevOps intenta abordar el “muro de confusión” que existe entre los equipos de desarrollo y los equipos de operaciones.

¿POR QUÉ ES TAN CONFUSO?

¿De dónde viene un “muro de confusión” semejante? ¿Se debe a la falta de procesos o herramientas integradas, como sugieren algunos de los libros que he estado leyendo? Quizás. De vuelta en el día, estaba usando diferentes herramientas y tenía diferentes privilegios de acceso que el equipo de desarrollo. Hubo privilegios de acceso que el equipo de desarrollo tuvo que yo no tuve. Pero no estaba confundido sobre lo que debía hacerse y sobre a quién debía apoyar.

¿Es por los diferentes objetivos entre el equipo de desarrollo y el equipo de operaciones? Tal vez. Pero eso no es “confusión”, es falta de claridad sobre las metas y objetivos. Cuando era administrador de sistemas para el proyecto, aunque le informé a un gerente diferente, era claro para mí cuáles eran mis prioridades.

Yo diría que si existe un “muro de confusión” entre un equipo de desarrollo y un equipo de operaciones es porque está permitido hacerlo. De acuerdo, puede haber herramientas dispares, procesos sobre o sub-diseñados entre los dos equipos, o diferentes líneas de reporte que pueden resultar en algunos desafíos para hacer las cosas. Pero si las metas y los objetivos se comunican claramente, las acciones de gestión coinciden con las palabras, y si los equipos tienen una actitud de “sí podemos”, no entiendo por qué existiría un “muro de confusión”.

NOS NECESITAMOS EL UNO AL OTRO

Entonces, ¿por qué la adopción de DevOps (o insertar su metodología favorita aquí) hace que el muro se derribe? La respuesta es que no lo hará. Si bien puede señalar el problema, como todo, es la forma en que nosotros, como individuos, decidamos comportarnos, marcará la diferencia. Si existen actitudes de “nosotros contra ellos”, no hay una metodología que lo arregle. Siempre se reduce a una elección personal.

El hecho es que Dev y Ops siempre se han necesitado mutuamente. Los conmutadores de red, servidores y dispositivos de almacenamiento son solo colecciones de basura sin aplicaciones y software. Entonces, el software o el código de la aplicación son simplemente desperdicios de esfuerzo si no hay una infraestructura subyacente.

DERRIBA EL MURO

Si el “muro de confusión” existe en la organización, es porque permiten que así sea. Y puedes derribarlo:

Establece cuál es el objetivo.
Esto significa que debe haber un diálogo abierto entre los operadores y los equipos de desarrollo. A menudo los equipos se estancan porque los miembros del equipo no tienen claro cuál es el “objetivo”.

Sé genuino y públicamente agradecido.
Cuando un miembro del equipo hace un esfuerzo extra y hace que algo suceda, reconoce sus esfuerzos. Las palabras tienen significado; las palabras tienen poder cuando se expresan de una manera pública y genuina. “Gracias” es una palabra poderosa que se pueden decir a un compañero de equipo.

Comprometerse a ser un aprendiz.
Cada uno de nosotros tiene talentos y fortalezas que, cuando se agreguen al equipo, impulsarán al equipo hacia adelante. Comparte abierta y proactivamente lo que sabe y aprende de los talentos y fortalezas de los demás en el equipo.

Los errores tienen que ser “oportunidades de aprendizaje”, no invitaciones a críticas y dudas.
Reconócelo: las personas son humanas y los humanos cometen errores; alguien que nunca comete un error es alguien que nunca ha intentado algo nuevo o diferente.

Siempre encuentra formas de avanzar.
Cuando los desafíos y obstáculos se presenten (y lo harán), no te esconda detrás de todas las razones por las cuales algo no se puede hacer. Desafíos y obstáculos a menudo resultan en formas innovadoras para resolver un problema. Como resultado, se entregan soluciones y el equipo mejora entre sí.

Al final del día, TI tendrá éxito o fracasará como equipo. Ninguna metodología o marco solo hará que el éxito sea una realidad. El éxito depende únicamente de las actitudes y los comportamientos de las personas. Si existe un “muro de confusión”, es porque la gente permite que exista. La elección es tuya: elige no permitir que la confusión se interponga en el camino del trabajo en equipo y el éxito.

Tipos de plataformas low-code

En el siguiente blog analizamos diferentes desafíos que atraviesan las empresas y los tipos de herramientas low-code que pueden ayudarte.

Transformación digital con ayuda de Low-Code

La transformación digital implica muchos desafíos, pero con ayuda de Low-code podemos superar estos problemas y abrir el camino para el cambio

5 consejos para elegir la suite de Gestión de Procesos de Negocio (BPM)

El enfoque de suite de gestión de procesos empresariales ayuda en el ciclo de vida de mejora de procesos como analizamos en este blog.

Plataforma de código abierto low-code, qué es y cuáles son sus ventajas

En el siguiente blog exploramos la definición de las plataformas de código abierto low-code, sus ventajas y desventajas

Plataformas no-code frente a los problemas de TI

Ingresa en nuestro blog para aprender cómo las plataformas no-code ayudan a resolver los problemas en los departamentos de TI

Características de los sistemas de low-code qué los hace mejores

En el siguiente blog hablamos sobre el impacto de los sistemas low-code en el desarrollo de aplicaciones y sus ventajas en los negocios

6 puntos clave para elegir la plataforma RAD adecuada

El siguiente blog analizamos el desarrollo de aplicaciones RAD y las características que debe tener para tu negocio.

No-code: qué es y cómo aplicarlo en el desarrollo sin código

Con la llegada de la programación no-code, diseñar las soluciones que tu empresa necesita es más fácil, descubre cómo lograrlo en este post

Los 6 principales desafíos en adquisiciones que enfrentan las empresas

En este blog analizamos los principales problemas en el área de adquisiciones que enfrentan las empresas de todos los tamaños

7 beneficios de implementar el desarrollo ciudadano

Con el desarrollo ciudadano tu empresa puede eliminar los cuellos de botella y reducir la carga de trabajo de TI. Descubre más en este blog