Cómo hacer que sus dólares de DevOps vayan más allá durante una crisis

La tentación durante cualquier crisis financiera importante (o sin precedentes) es reducir los costos de manera masiva o gastar dinero para sacarlo del agujero particular en el que se ha encontrado. Estudio de Harvard Business Review de 2010 descubrió que las empresas que recortan costos rápidamente en una recesión tienen muchas más probabilidades de quedarse atrás de la competencia que sale de ella.

El estudio también encontró que las empresas que eran progresistas, que buscaban la eficiencia operativa por encima de la reducción de costos inmediata, fueron significativamente más exitosas, con un mayor crecimiento de los ingresos y menores despidos que otras.

Esto se aplica a crisis pasadas, presentes y futuras, especialmente cuando se aplica al desarrollo de software. En una encuesta que mi empresa realizó en mayo de 2020 a profesionales de TI en todo Estados Unidos, más del 60% informó que había visto despidos y el 36% informó una reducción en el gasto.

De manera alentadora, encontramos que el 34% informó un cambio a procesos más ágiles y el 28% informó la eliminación de los procesos que se interponían en el camino, y eso es precisamente en lo que quiero que se concentre, tanto con los problemas que enfrenta hoy, e incluso cuando su organización se está disparando.

… y eficiencia para todos

Cuando las cosas se ponen difíciles, es fácil identificar las cosas que van mal en lugar de averiguarlo. por qué van mal.

Estás produciendo una aplicación y el equipo de diseño es lento para sacar algo por la puerta, y tienen que seguir haciendo revisiones, todo porque la persona que escribe la copia no les está obteniendo todo lo que necesitan cuando lo necesitan.

Su equipo de desarrollo tiene que esperar a que TI tenga todo listo para lanzar la aplicación, y todos son íntimamente conscientes de los dos plazos que enfrentan. y cualquier crisis en particular que esté ocurriendo en ese momento.

Es el cliché del desarrollo en silos: todos están atrapados en sus propios mundos, comunicando cosas según el funcionamiento de su equipo, entregando las cosas de una manera que tenga sentido para ellos.

Este es un ejemplo clásico de desarrollo en serie, donde cada equipo prepara su pieza cuando el otro equipo les dice que su pieza está lista, lo que lleva a un atasco en el momento en que algo sale mal.

Estos no son necesariamente problemas específicos de DevOps, pero son el tipo de cosas que pueden atascar la capacidad de una organización para ofrecer un excelente software. Y si se mira detenidamente, son problemas totalmente organizativos que se pueden solucionar de una manera relativamente sencilla y, sin embargo, hacen que la gente se sienta miserable, molesta e incapaz de enviar el producto.

Fundamentalmente, son algo que puede solucionar sin gastar dinero.

Derribando muros

Una gran organización de software debería poder trabajar en paralelo, con cada parte de un equipo enviando un producto capaz de obtener lo que necesitan sin tener que esperar a otra parte.

Para que esto funcione, se requiere una evaluación de cómo se comunican sus equipos, si ciertas partes de su organización están ayudando o agravando los problemas, o incluso si ciertas herramientas se interponen en el camino.

Por ejemplo, su equipo de software está lanzando un sitio web de comercio electrónico para una marca de calzado. El equipo de desarrollo web necesita SKU, fotos de productos, precios y otra información específica. cada vez desarrollan una plataforma de comercio electrónico y, por lo tanto, estas son cosas que su organización debería haber solicitado y entregado mucho antes de que comience el proyecto. De esa forma, el equipo de desarrollo web no se verá retenido por el cliente.

De manera similar, el equipo de desarrollo web puede establecer un estándar para el tipo de copia que necesitarán con anticipación, por lo que el redactor no estará esperando dónde colocar las cosas. Su equipo de TI sabe que se va a crear un sitio web de comercio electrónico y que el lanzamiento es en un día en particular, y tiene todo listo.

Estos parecen obvios, pero tener un flujo de trabajo estandarizado, bien comunicado y establecido (por ejemplo, en una wiki interna) para un tipo de proyecto en particular significa que hay menos errores y hitos claramente comunicados que alcanzar.

La noción de trabajar en paralelo permite a su equipo hacer todo lo que pueda por separado, mientras todos trabajan hacia el mismo objetivo y, en última instancia, entregan mejores productos más rápido.

Esta organización armónica y paralela también puede requerir que considere lo que realmente funciona para un proyecto en particular sobre lo que parece importante. Esto puede ser tan complejo como la forma en que su equipo de TI está poniendo su sitio en producción, o tan simple como las herramientas de comunicación que está utilizando para mantener un proyecto en marcha.

Para ser sincero, si algo se siente como un dolor en el trasero por hacer, ahora es un buen momento para preguntar por qué lo está haciendo, qué beneficio le brinda y quién lo está usando.

Tener una comunicación clara sobre los obstáculos que existen en un proyecto no es solo un buen negocio, es una excelente manera de crear camaradería entre las diferentes partes de una organización: todos sufren juntos y se fortalecen juntos.

Es posible que alguien no comprenda el propósito de una herramienta en particular (y se resienta de tener que usarla), o que todos tengan la misma queja sin expresarla.

En última instancia, la eficiencia del desarrollo proviene de la comprensión de todos (y de todo, en el caso del software) las fortalezas y debilidades centrales y la construcción en torno a ellas.

Es probable que ya tenga las piezas que necesita, pero simplemente debe brindarles a todos los flujos de trabajo y fomentar los tipos de comunicación que hacen las cosas de manera rápida y eficiente.

Me gustó este artículo? Luego únete a nuestro evento en línea, TNW2020, para explorar las últimas tendencias y las mejores prácticas emergentes en el desarrollo de productos.

Publicado el 15 de septiembre de 2020-08: 00 UTC

Deja un comentario

Cart
Your cart is currently empty.