Habilidades DevOps para la vida: Comprensión y gestión del proceso de adquisiciones
En un blog anterior, hablé sobre por qué es importante adoptar un enfoque de "pensamiento sistémico" para la entrega de aplicação , operando más como una fábrica bien ajustada y optimizada para una entrega de valor eficiente. Para llegar allí es necesario evaluar las herramientas en las que usted confía, así como el proceso mediante el cual las selecciona y las adquiere. La eficiencia requiere priorizar patrones reutilizables siempre que sea posible, así como seleccionar herramientas y procesos que sean consistentes en todos los equipos y entornos. Eso tiene sentido en teoría para la mayoría de las personas, especialmente cuando las herramientas en cuestión están relacionadas con la infraestructura o la seguridad, con un impacto mínimo en la función de la aplicação . Sin embargo, a menudo existe una barrera poco apreciada que impide la construcción de dichos patrones: El proceso de proveedores y adquisiciones.
En la actualidad, no es inusual que los ingenieros de DevOps utilicen herramientas nativas de la nube, soluciones de código abierto u otros tipos de recursos económicos (o gratuitos) que no requieren una inversión significativa ni interacción con el equipo de adquisiciones. ¿Pero qué sucede si necesita defender una inversión en TI más rica para impulsar las eficiencias necesarias y garantizar una mejor seguridad y rendimiento para sus aplicaciones?
Argumentos a favor de la inversión en TI
A continuación se presentan algunas cuestiones que los profesionales de DevOps deben tener en cuenta mientras navegan por las aguas desconocidas del proceso de adquisiciones.
- Centrarse en el valor
Si está leyendo este blog, es probable que prefiera centrarse en las capacidades tecnológicas de lo que se necesita, pueda hablar de API todo el día y esté obsesionado con la optimización. Pero adivina qué: a tus colegas que son responsables de firmar los grandes cheques probablemente no les importe nada de eso. Es por eso que lo más importante que puede hacer para respaldar la compra de una nueva herramienta o recurso es articular, en sus términos, el valor comercial que aportará.
Muchas veces, esto comienza con identificar lo que falta o lo que falta actualmente. Pedir que se compre una herramienta nueva simplemente porque ya está disponible no es tan convincente como destacar una falla o responsabilidad significativa, describir las formas en las que esa falla crea problemas (ralentiza la producción, expone vulnerabilidades, etc.) y luego proponer una herramienta nueva que lo resolverá todo.
Los tres elementos clave en los que hay que centrarse son el coste, el valor y el riesgo. Es importante hablar de esto en términos comerciales: cómo una solución específica resuelve el problema identificado por:
- Reducir costes a corto, medio o largo plazo
- Cómo puede la empresa aumentar la agilidad, acelerar el tiempo de comercialización o atraer nuevos clientes
- Cómo se reduce el riesgo empresarial con un mejor cumplimiento normativo, un menor riesgo de ataque o incluso algo que reduzca la exposición competitiva
En todos ellos, es muy importante cuantificar cada uno lo mejor posible. Nadie quiere opiniones puramente cualitativas. Los datos duros son importantes.
Para sus colegas de Compras (y más ampliamente, de los equipos de Finanzas), todo tiene un costo y un valor. Esto incluye el costo de no hacer nada (frente a problemas conocidos), así como el valor de liberar a los trabajadores de tener que lidiar con esos problemas. Simplemente tenga en cuenta que, si bien NetOps puede encontrar valor en eliminar tareas mundanas simplemente porque hace que el trabajo sea menos tedioso, los equipos de finanzas ven valor en liberar a esos mismos ingenieros para que se concentren en iniciativas estratégicas generadoras de ingresos.
Will Marken, gerente de soluciones técnicas de F5, sugiere “ posicionarse como un solucionador de problemas; mientras se concentra en brindar valor, vincule la solución propuesta con las aspiraciones corporativas; esto demuestra que puede interactuar con la gerencia en sus términos y hablar de sus necesidades”.
- Conozca la jerga: CapEx vs. suscripción
- Sé persistente
- Romperlo en trozos
- Formar equipo
Es posible que su equipo esté totalmente interesado en comprar una solución a través de un modelo de suscripción y luego descubra que su organización está alineada con grandes gastos de capital y carece de un proceso para financiar inversiones en TI mediante suscripción. En ese caso, tienes que hacer algo de trabajo adicional. Quizás le resulte más fácil cambiar a una solicitud de presupuesto de gastos de capital (por ejemplo, una única compra grande que se amortizará con el tiempo). Por otro lado, incluso las empresas que han tardado en adoptar modelos de suscripción están descubriendo cómo respaldarlos. Es posible que necesites dedicar algo de tiempo adicional mientras tus colegas de Finanzas resuelven sus propios desafíos en el proceso organizativo.
Aunque pueda parecer un cliché, este es realmente uno de esos casos en los que lo importante es el viaje, no el destino. Justificar grandes compras a menudo requiere varios intentos. De hecho, su solicitud puede muy bien estar compitiendo con otras que han estado circulando a lo largo de dos o tres ciclos presupuestarios, refinando el enfoque y reuniendo apoyo en el camino. No te rindas cuando escuches un “No”. En lugar de eso, planifíquelo, acéptelo cuando llegue y avance con ajustes a partir de ahí.
Aborde la adquisición como lo haría con cualquier otra tarea en su flujo de trabajo ágil. Identificar problemas; resolverlos uno por uno; e iterar, iterar, iterar.
Para solicitudes con grandes presupuestos, a menudo es útil dividir el proyecto en partes más digeribles. Esto puede ser útil por dos razones: a) es más fácil crear una prueba de concepto (POC) plausible e identificar valor en el mundo real cuando hay un enfoque más específico; y b) es simplemente más fácil para los responsables aprobar solicitudes más pequeñas.
Hay todo tipo de razones por las cuales es una buena idea solicitar ayuda a otros miembros de la organización. Para empezar, sus colegas directos o de otros equipos pueden estar más familiarizados con el proceso de adquisiciones en general (y con el valor de las soluciones de F5 en particular) y, por lo tanto, pueden ayudarlo a formular la solicitud (y evitar riesgos conocidos). También puede reducir el riesgo percibido mostrando cómo la solución propuesta impactará positivamente en múltiples departamentos. Por último, no es raro (especialmente en organizaciones muy grandes) descubrir que otro grupo ya ha intentado una solicitud similar a la suya (en cuyo caso puede aprender de ellos) o incluso puede haber comenzado a implementar una solución similar (en cuyo caso puede asociarse con ellos).
Una nota sobre la estructura
Al asumir la creación de una solicitud presupuestaria, puede confiar en muchas de las mismas tácticas que usaría para crear documentos más típicos para su campo, como documentos técnicos y hojas de datos. Esto comienza con encontrar la plantilla adecuada para que sepa que su solicitud se verá y se leerá como otras solicitudes con las que el gerente está familiarizado. También incluye ejecutarlo con varios colegas para recibir aportes y comentarios durante todo el proceso. Jon Gross, gerente de desarrollo de productos de F5, agrega que “ al igual que con las hojas de datos y los documentos técnicos, el éxito a menudo depende de la descripción o el párrafo inicial”. Él sugiere “ buscar arquitecturas de referencia y casos de uso existentes que puedan apuntalar su hoja de ruta de implementación con puntos de datos del mundo real”.