Loading...

DevOps, ¿Cómo arrancar?

En todo negocio, sin importar el ramo hay 2 objetivos que se deben cumplir:

1.      Responder rápidamente al cambio competitivo del mercado

2.      Ofrecer y proveer un servicio estable, confiable y seguro a los clientes.

En empresas de tecnología es aún más rápida la adaptación que tenemos que ofrecer. Y es donde entra un problema podría llamarse “Generacional” y poco a poco, con nuevos procesos o metodologías, se ha ido avanzando en brindar soluciones.

No alt text provided for this image

Quisiera contarles una historia, les voy a presentar a Pepito, María y Fernando.

(Ficticio) Sith Technologies, es una empresa de tecnología que ofrece soluciones SaaS a sus usuarios. Existen 3 áreas principales en IT: Desarrollo, Operaciones y Seguridad.

Pepito es el encargado de seguridad de la información en la empresa, María es la directora de desarrollo y Fernando director de operaciones de TI.

La regla de la empresa es hacer deployments a producción cada semana, en horarios establecidos.

Es importante que los roles de Dev y Ops, juegan y buscan 2 objetivos (por naturaleza) distintos:

Dev “Responder rápidamente al cambio competitivo del mercado”.

Ops “Ofrecer y proveer un servicio estable, confiable y seguro a los clientes”, esto incluye que a no existan riesgos que pongan en peligro el servicio ofrecido al cliente.

Adicional. Seguridad busca que todo cumpla lineamientos y políticas de seguridad, gubernamentales o de industria.

No alt text provided for this image

La competencia de Sith, Jedi Technologies, ofrece los mismos servicios SaaS, pero ellos brindan actualizaciones a sus clientes 1 vez al día.

Su lema es: “Siempre hay algo que mejorar”.

En la junta directiva, Daniela, la directora de la empresa, lanza 2 preguntas al cómite:

¿Cómo logra Sith technologies agilizar la cantidad de mejoras sin impactar a sus clientes?

María, Pepito, y Fernando, júntense, platiquen y la siguiente reunión nos ayudan: ¿Cómo TI nos puede apoyar para solucionar esto?

En muchas empresas, no sólo en Sith, existen áreas de poder. Roles y responsabilidades bien establecidas y en algunos casos, mal manejadas. Es por eso por lo que responder las preguntas previas puede ser algo complicado, pero hay que agarrar al toro por los cuernos e intentaremos responderlas.

Sin duda, el primer paso es conocer la operación, tener un tablero con los proyectos y de esta forma, alcanzar el primer objetivo: conocer que deuda técnica existe en la organización.

No alt text provided for this image

Cómo deuda técnica podemos llamar pobre documentación, proyectos fantasmas, mala identificación o agrupación de proyectos, retrabajo que no se mide.

Para esto es necesario identificar los proyectos que las áreas están trabajando, y después los recursos. ¿Por qué deberíamos preguntarle a la gente en que proyectos está trabajando? Debería saberlo su gerente.

Bueno… pues en muchos casos, existe el recurso que le está ayudando a otra área a obtener información de la base de datos o le ayuda a marketing a crear funnels de la información de los sistemas. Y estos no están documentados, no puedes medir lo que no conoces.

Debemos generar un tablero con los proyectos, recursos y actividades que genera cada recurso. Y después marcar con un color rojo, que actividades del listado son críticas para agilizar los deployments. Y marcar en amarillo (u otro color que te guste) las actividades que usualmente fallan, entre ellas que falte información relevante para el despliegue de las operaciones en los documentos, o que se omita los resultados de las pruebas en el proceso. Una común, es que no se coloquen las configuraciones necesarias del contenedor o índices, columnas o vistas requeridas en la BD para que la solución funcione correctamente.

Esas actividades, en caso de que falten o se omitan, entran a un proceso de retrabajo administrativo. Y debe ser identificado, ya que puede parecer común que un deployment tome 5 horas. Pero tocando el tema que hablé el día de ayer, el lead time es de 5 horas, y el process time es 1, esto debido a que para configurar y validar todo, toma demasiado tiempo por el retrabajo administrativo.

Una vez identificando estás actividades de retrabajo, se puede estimar con mayor certeza el tiempo de las instalaciones.

Ya con esto cumplimos algo muy importante: Visión 360 de los recursos, áreas, proyectos.

No alt text provided for this image

El siguiente paso es conocer que recursos son los que se vuelven un bloqueo, por carga de trabajo o incluso por equivocaciones en las instalaciones. Esto puede deberse al alto número de responsabilidades, y es un riesgo que el conocimiento se quede únicamente en una persona. Por lo que, en este paso, es debilitar los bloqueos. ¿Cómo? Las actividades que hace la personas más especializada de la empresa, deben poder ser realizadas por alguien con un nivel parecido. Siempre debe existir un respaldo, sino el bloqueo (1 persona) afecta el trabajo de toda la organización.

No alt text provided for this image

Y, por último, es catalogar los proyectos en los siguientes tipos:

Proyectos de negocio (hacia el cliente), proyectos internos (donde nuestro cliente es otra área de la organización, no el usuario de la solución), retrabajo o proyectos fantasma. Es esa métrica donde se va gran parte del trabajo.

Con estos 3 puntos identificados (OJO, puede llevar un buen tiempo completarlos), Pepito, María y Fernando, pueden comenzar a brindar soluciones de manera más ágil. No porque ahora conozcan o sepan, simplemente porque tienen la información necesaria para tomar las decisiones pertinentes.

“It’s magic!”

No alt text provided for this image

Después, y solamente después se podrá automatizar para poder lograr deployments diarios.

Pero ese es otro capítulo en la vida de Sith Technologies.

0

You might also like