Mi nombre es Alexandra Kamzeeva, he trabajado como analista de sistemas durante 9 años, de los cuales 3,5 años en Lamoda. Leo mucho, analizo la documentación actual y creo una nueva. En mi trabajo siempre estructuro la información y la hago lo más conveniente posible.
Las ventajas de una buena descripción del sistema son:
- le ayuda a encontrar la información que necesita de forma más rápida y sencilla que en una descripción no estructurada;
- reduce el riesgo de fracaso del proyecto;
- facilita la incorporación de los empleados.
Creamos una plantilla para tal descripción que cualquier equipo puede usar. En este artículo, te contaré con ejemplos qué nos impulsó a crear una plantilla de descripción del sistema, el historial de su creación y cómo se usa ahora en Lamoda.
Qué es una plantilla y por qué es necesaria
Para empezar, describiré mi comprensión del patrón. Supongamos que necesito encontrar un coche pequeño en una habitación desordenada. No es un hecho que pueda manejarlo. Pero accidentalmente puedo pisar la parte de Lego.
Ahora imaginemos que todos los juguetes se colocan en su lugar y se clasifican. Puedo ver de antemano en qué caja están todos los autos, encontraré el que necesito más rápido, más fácil y no perderé mis nervios en eso.
Lo mismo ocurre con la documentación. Una plantilla es tal orden. Creamos un marco para describir un sistema que cualquier equipo puede usar.
En que condiciones trabajamos con documentación
Lamoda tiene más de 100 sistemas que automatizan la entrega de pedidos, el centro de contacto, el almacén, el estudio fotográfico y otros procesos operativos y comerciales. Más de 300 ingenieros participan en el desarrollo y el soporte. Cualquiera de ellos puede necesitar una descripción de cualquiera de estos 100 sistemas.
Cada equipo describe de forma independiente su sistema en un espacio separado en Confluence. El líder técnico está necesariamente involucrado en la documentación, porque está obligado a registrar la información. Además, el sistema es descrito por probadores activos y desarrolladores que lamentan perder el conocimiento que han adquirido. Y, por supuesto, analistas, ya que la documentación es una de nuestras principales herramientas.
Puede parecer que esta libertad conduce al caos. Pero esto no es así, porque tenemos una cultura de empresa: una actitud responsable hacia la documentación, el intercambio abierto de conocimientos, el hábito de registrar los artefactos del proyecto y del sistema. Esta tradición se ha desarrollado en parte debido a proyectos fallidos. Los incidentes demostraron a los equipos de desarrollo lo importante que es documentar los procesos y la funcionalidad del sistema.
A continuación, destacaré algunos casos en los que la documentación confusa o la falta de ella provocaron problemas.
Solo agregue dos botones
El primer problema que nos llevó a crear una plantilla: no teníamos una descripción de algunos sistemas, lo que provocó fallas y mejoras.
Teníamos un proyecto de Self Order Management (SOM). Decidimos agregar dos botones a la cuenta personal del cliente: "Transferir fecha de entrega" y "Cancelar pedido". Antes de eso, un cliente solo podía cancelar o reprogramar un pedido llamando al centro de contacto. Está claro que algunos compradores no tuvieron tiempo ni ganas de comunicarse con el operador. Como resultado, el representante de ventas podría traer un pedido innecesario o no encontrar al cliente en casa. En tales casos, Lamoda corre con los costos. El proyecto era necesario e importante.
¡Parecería agregar dos botones! De hecho, había mucha lógica detrás de ellos en los cuatro sistemas. El cambio de orden pasa por el sistema de procesamiento, un enorme monolito donde puedes tocar algo en un lugar y disparar en otro. Desafortunadamente, las sutilezas de su trabajo no se describieron en la documentación, no prestaron atención a esto durante el diseño del proyecto. Después del lanzamiento, los botones no funcionaron como se esperaba y se revertió. Como resultado, en lugar de dos meses-hombre, este proyecto tomó seis meses.
Por supuesto, obtuvimos este resultado no solo por la falta de documentación. Pero si tuviéramos una descripción clara de los procesos de cancelación y transferencia de un pedido, quizás el resultado sería diferente.
Incorporación compleja
El segundo problema que nos llevó a crear una plantilla es la complejidad de la incorporación. Vine a trabajar para el equipo del sistema de procesamiento de pedidos. Para la inmersión, leí la documentación en el espacio del sistema y en tres secciones encontré tres descripciones diferentes de la esencia principal de nuestro sistema: el estado del pedido.
En este caso, no funcionó para facilitar la incorporación. Dicha documentación no ayudó a transferir conocimientos a colegas que no se habían encontrado previamente con nuestro sistema.
Problema de pizarra en blanco
El tercer requisito previo para la creación de plantillas es el problema de la pizarra en blanco. Para cada nuevo sistema, el líder tecnológico debe crear el espacio apropiado desde cero. El jefe de tecnología piensa qué secciones crear. Antes de crear la plantilla, el empleado estudió otros espacios y miró qué secciones se utilizan y serán útiles para su sistema. Esto solía llevar mucho tiempo.
Cómo creamos la plantilla y qué sucedió
Cada semana, los analistas de sistemas celebran una reunión y discuten los problemas que se encuentran en los proyectos y no solo. Y más de una vez los compañeros se han quejado de lo difícil que es encontrar información y entender los espacios de varios sistemas. Como constantemente quemamos a causa de esto, decidimos tomar en nuestras propias manos la descripción de los sistemas a los que estamos apegados. Y entonces quedará claro qué hacer.
Primero, identificamos los atributos de una buena plantilla:
- .
- . , , . , . .
- . , , , .
- .
A continuación, analizamos la descripción actual de varios sistemas e identificamos apartados comunes:
En el apartado de proyectos y funcionalidades, había especificaciones para desarrollar proyectos. Las secciones de desarrollo y control de calidad contenían información específica para desarrolladores y probadores. En el apartado de incidencias se describieron las incidencias ocurridas en el sistema y sus soluciones.
Compartimos la idea de una plantilla con otros compañeros en reuniones informales (almuerzos en la cocina, stand-ups, equipos vecinos con los que conversas periódicamente) y creamos un grupo de trabajo de voluntarios. Eran representantes de diferentes competencias: dos gerentes, tres líderes técnicos y dos probadores. Agregaron las siguientes secciones a la plantilla:
A continuación, probamos la plantilla de descripción del sistema con colegas con amplia competencia: jefes de departamentos de TI, líderes técnicos experimentados y líderes de prueba de grandes proyectos de integración. Terminaron agregando algunas secciones más útiles:
Comprobando la calidad de la plantilla
Verificamos el documento resultante con nuestra definición de una buena plantilla en Lamoda:
- Le ayuda a encontrar la información que necesita de forma más rápida y sencilla. Tenemos una estructura conveniente: me muevo a lo largo del árbol y entiendo qué está ubicado y dónde. Si necesita información sobre los procesos del sistema (por ejemplo, cancelar un pedido), entonces voy a “Descripción de los principales procesos”.
- La información del sistema no se duplica debido a la atomicidad de las particiones. Por ejemplo, puede describir los imprimibles en una sección y luego vincularlos desde la sección “Descripción de los procesos principales” para que la información no se repita.
- . Lamoda, . , -. — .
- . .
Hicimos una bonita plantilla para describir los sistemas Lamoda. Espero que otras empresas también lo encuentren útil. Especialmente quiero destacar los siguientes tres apartados:
Descripción de los principales procesos del sistema . Sí, parece obvio que esta sección es necesaria. Pero por alguna razón, no siempre existe, como hicimos con los botones de cancelación y transferencia. Si hubiéramos descrito los procesos de cancelación y reprogramación con anticipación, se reduciría el riesgo de fracaso del proyecto.
Listas de verificación- una sección que recuerda lo más importante en el proceso regular. Por ejemplo, tenemos una "Lista de verificación para conectar un nuevo método de pago" en la descripción del sistema de gestión de métodos de pago. Dice que debemos coordinar la incorporación o cambio de un método de pago con el departamento de contabilidad, con el contact center, con delivery y con otras unidades de negocio.
Una vez nos olvidamos de informar al contact center sobre el cambio en la forma de pago. Y cuando el cliente llamó a nuestro centro de contacto y preguntó al respecto, el operador no pudo decir nada. Esto provocó un conflicto entre el centro de contacto y el equipo de desarrollo responsable de los métodos de pago. Después de este incidente, creamos listas de verificación para lanzamientos de proyectos clave, conexión de nuevos socios, etc.
Página de inicio de Space- una sección con información sobre por qué es necesario este sistema, sobre la composición del equipo y las partes interesadas. Debemos coordinar los cambios del sistema y los recursos de desarrollo con las partes interesadas. Así que es genial cuando puede obtener esta información con solo mirar Confluence.
Allí mismo indicamos información sobre la composición del equipo para entender a quién contactar si tiene dudas sobre el sistema. También ayuda a los principiantes con la cabeza hinchada. Es genial cuando un nuevo empleado puede espiar con quién acaba de hablar, quién es esta persona, cuál es su función y cómo se llama.
Cómo comencé a usar la plantilla en mi sistema
- En primer lugar, creé las secciones necesarias de la plantilla sin rellenar. Fue fácil y no tomó más de 30 minutos.
- Entonces lo más difícil fue: establecimos reuniones periódicas con el líder tecnológico, en las que comenzamos a analizar la documentación de nuestro sistema. En la primera reunión, dividimos las páginas actuales en tres pilas.
Hemos enviado todo lo irrelevante e innecesario a la primera pila. Eliminamos estas páginas o las enviamos al archivo.
La segunda pila es necesaria, pero irrelevante. Marcamos las páginas como irrelevantes, creamos una tarea en Jira y luego actualizamos esta información de acuerdo con nuestro backlog.
La tercera pila es la más simple. Cuando todo está claro, las secciones son relevantes, simplemente las movimos al lugar correcto.
Antes de estas reuniones, descripciones de procesos y arquitectura, notas de probadores y desarrolladores, las incidencias estaban esparcidas por todo el espacio. Tampoco había una página de inicio.
Durante 6 horas de reuniones obtuvimos un resultado excelente. A partir del caos, hemos formado estructura y orden. Ahora puede averiguar dónde encontrar descripciones de procesos, información sobre la arquitectura y sobre incidentes. Y lo que es más importante, ahora tenemos una página de inicio. Aquí se escribió por qué se necesita un sistema de procesamiento de pedidos y quiénes son sus partes interesadas.
Nuestro gran sistema está presente en casi todas las líneas de negocio. Pero antes no teníamos nuestro propio accionista. Mientras estábamos haciendo la página de inicio, discutimos con el CTO con quién coordinar los cambios del sistema. Así, se determinó un colega, quien priorizó las mejoras. Ahora parece un hecho divertido que la creación de la página de inicio condujo a la aparición de un interesado.
Cómo distribuimos la plantilla
Otros analistas recibieron resultados similares sobre el uso de la plantilla y la implementaron en sus propias direcciones. Por lo tanto, hemos cubierto la mayoría de los sistemas que han participado activamente en muchos proyectos de integración.
Teníamos equipos cuyos sistemas a menudo estaban involucrados en proyectos de integración, pero no había suficiente descripción sobre ellos. Por lo general, se necesitaba documentación, por lo que no era necesario vender la idea.
Hemos demostrado una experiencia exitosa en la aplicación de plantillas a líderes tecnológicos y gerentes de dichos equipos. Algunos equipos, basados en nuestro ejemplo, arreglaron su documentación por su cuenta, otros pidieron la ayuda de analistas.
Comentarios sobre la plantilla
Nuestra plantilla no es una descripción del sistema obligatoria u obligatoria. Los colegas toman la plantilla como base, si la necesitan, y la editan para adaptarla a sus necesidades. Por ejemplo, transfieren intercambios de subsección a sección si el sistema se compone principalmente de ellos.
Todos nuestros sistemas son diferentes en la descripción, pero la estructura general y la lógica general aún se conservan. Ahora podemos encontrar más fácilmente información sobre los procesos que componen el sistema, sobre la arquitectura del sistema, etc.
En Lamoda nos encanta compartir conocimientos. Tenemos grandes proyectos de integración que motivan esto. Enviamos enlaces a descripciones actualizadas de los sistemas y los colegas reciben la información necesaria sin preguntas adicionales a los clientes potenciales de tecnología ya cargados.
2 años después de crear la plantilla, entrevisté a colegas y recibí buenos comentarios de la mayoría. Usan la plantilla, editando la estructura a su gusto.
Pero también hay gente que piensa que no necesitamos documentación ni plantilla. Básicamente, este es el razonamiento de los equipos de aquellos sistemas en los que ahora no hay necesidad urgente de documentar algo.
Trabajan en sistemas que apenas cambian: no hay proyectos de integración, no hay necesidad de contarles a otros compañeros sobre estos sistemas y, por tanto, no hay ganas de documentar.
Creo que antes de comenzar un gran proyecto, nuestra cultura y los grandes baches te recordarán que debes documentar los procesos principales, y ellos cambiarán de opinión.
Consejos para ti y para los que quieran repetir nuestro camino
- , , , , . , .
- . , . , .
- , , . : , , . . , .