Nosotros en Promsvyazbank nos estamos moviendo activamente de los equipos de canales en cascada a los equipos de comida de vanguardia. En algún lugar costó un par de conos, en algún lugar ya es posible cambiar el rastrillo ... pero como resultado, hemos acumulado mucha experiencia relacionada con la transformación de bordes. En esta publicación queremos compartir experiencias: de repente descubrirás algo nuevo.
Cómo nace la idea de la transición a Edge
Por lo general, aparece un ideólogo en la empresa que infecta a todos con el virus Edge y habla sobre los valores del trabajo en equipo. Todo será simple y rápido, el resultado sorprenderá a la imaginación, el dinero se derramará en nuestros bolsillos y todos los empleados estarán encantados de revolcarse en otomanas con una taza de café en la mano y un tazón interminable de galletas, promete.
Para reforzar los pensamientos sobre Edge, invitan a expertos que predicen un par de cientos de días de trabajo en el producto y, como resultado, la "descomposición" del producto, su desaparición. Y luego, tal vez, la desaparición de la empresa. Un ejemplo es HTC y Blackberry. ¿Cómo no repetir su destino? Los consultores ofrecen una receta que ha sido utilizada por gigantes como Google, Amazon, Apple, es decir, un ágil flexible.
Lo que suele pasar durante la transformación.
Y ahora ha aprendido todas las frases y frases necesarias para tener derecho a llevar el orgulloso nombre de PMI Agile Certified Practitioner: "stand-up, grooming, demo, team, board, stickers, todo pasó por el bosque con su aprobación". Son profesionales en su campo, saben qué y cómo funciona, conocen todos los nuevos conceptos, eventos y procesos necesarios. Queda por realizar una transformación ágil. Aquí hay una lista de errores comunes.
- Había departamentos de desarrollo e hicieron equipos de vanguardia.
- La interminable cola de tareas para solicitudes de cambio en Jira se convirtió en una reserva de RFC con un simple movimiento de la muñeca.
- Anteriormente, los recursos se asignaban centralmente a una tarea, pero ahora han hecho la distribución de tareas a los desarrolladores.
- “¿Qué hará este desarrollador con nosotros? Y tomemos esta tarea en la cartera de pedidos, él podrá hacerlo ".
- Usted establece una meta para alejarse de la evaluación de tareas en un mes de trabajo. En respuesta, el desarrollador dice: "Bien, comencemos a hacer este sprint y terminemos el siguiente".
- ¿La tarea no está coordinada con el servicio de seguridad y los abogados? Presentemos unas vacaciones normativas e ignoremos este momento.
- ¿Las tareas son asignadas por el jefe? Luego hacemos una arista, una estructura plana, pero "seguiré siendo el jefe".
¿Qué obtenemos al final?
La estructura no ha cambiado. Los jefes establecen tareas para subordinados. La gente tiene una explosión cerebral, muchos líderes, estos líderes establecen simultáneamente diferentes tareas con plazos fijados. Las tareas se midieron simplemente en sprints, no meses.
Qué hacer es incomprensible; cómo hacerlo es incomprensible. ¡Sin documentación! Todo el equipo se sienta en reuniones todo el tiempo, donde acuden tecnólogos y programadores viejos y duros. Miran a los empleados del equipo como si vinieran al zoológico para observar el comportamiento de los gibones en una manada.
El Scrum Master habla sobre la definición de listo y la definición de hecho. Sin embargo, entienden que esto es importante y necesario, ¿por qué los desarrolladores se resisten?
En este momento, llega una desafortunada tarea a pesar de las fechas límite del liderazgo, y el joven, todavía débilmente de pie, ágil, muere bajo el ataque de enemigos y zombis.
Como es necesario
No puede seguir ciegamente los patrones de las empresas exitosas. Aquí es más fácil explicarlo a través de una analogía, por ejemplo, a través del fútbol. Imagina que eres un entrenador, tu equipo está perdiendo, cinco minutos antes del final del partido. Hay un ejemplo de un plan perfecto utilizado por el reconocido entrenador Ernesto Valverde. Según él, el delantero Luis Alberto Suárez irrumpe en el área de penalización, es derribado, el juez designa una penalización. Lionel Messi se acerca al balón y dispara exactamente en la esquina superior más alejada del portero. Plan impecable. Pero tú no eres Valverde, y no tienes a Suárez y Messi en el equipo. Eso es todo. Has perdido
Además, comenzamos a aferrarnos a los procesos, olvidando por qué los implementamos en nuestro trabajo. Por lo tanto, le aconsejaría que formule un objetivo y lo cuelgue en un lugar visible. Cómo establecer metas, todos lo saben. El objetivo debe ser concreto, medible, alcanzable, significativo y con un límite de tiempo. ¿Qué significa todo esto en la práctica?
En la práctica, esto significa que lo más importante en todo este proceso es el Cliente. Por lo tanto, asegúrese de pasar tiempo y averiguar quién es su cliente real, quién le trae dinero. Describe a su persona. No todas las empresas tienen una respuesta obvia a esta pregunta.
Para el cliente que está haciendo el Producto, y de tal manera que después de su uso, el cliente quede satisfecho. El producto debe ser:
- útil, es decir, resolver un problema importante del cliente;
- alta calidad, es decir, cumplir o superar las expectativas del cliente;
- hecho y ofrecido a tiempo, no en un año.
El producto, a su vez, es creado por el Equipo. De hecho, el Producto y el Equipo están estrechamente relacionados. Como dijo el equipo de los ahogados en el naufragio de Piratas del Caribe: "Parte del equipo es parte del barco". Un buen producto no puede existir sin un buen equipo, y viceversa. Y esta es la razón principal por la cual la mayoría de los intentos de transformación de bordes se están desmoronando. Para evitar esta situación, en Promsvyazbank comenzamos a lanzar cada equipo eligiendo una línea de productos y un propietario del producto.
Mucho se ha dicho y escrito sobre cómo debería ser el dueño del producto. Todo esto es cierto, la principal dificultad es encontrar a la persona que necesita. Esto es lo que hace el dueño del producto:
- establece una meta;
- describe la cartera de pedidos de nivel superior;
- piensa sobre KPI, por el cual sería posible monitorear constantemente el enfoque hacia la meta; incluyendo no te olvides de un cliente feliz;
- calcula cómo las tareas acumuladas afectan los KPI.
El propietario del producto no es la persona que sabe cómo traducir de manera efectiva las prioridades del hotel de otra persona, sino la persona que quiere hacerlo. Quiere hacer el mejor producto para el cliente, hacerlo de la forma en que lo ve todos los días.
El equipo de desarrollo son personas responsables que pueden desarrollar el producto de forma independiente e independiente. El equipo debe tener todas las competencias necesarias para lograr el resultado. Las dependencias externas no deben controlarse; deben eliminarse al incluir o capacitar a las personas adecuadas en un equipo. Definitivamente no es necesario formar un equipo con roles redundantes. Para estar de acuerdo, el equipo debe ser lo más pequeño posible. Eliminar mentalmente el rol del equipo; ¿empeoraría sin él?
La mejor pregunta para el equipo al principio: "¿Tienes suficiente para alcanzar tu objetivo?" Y la práctica más efectiva de formar la composición de los participantes es el diseño propio, cuando los propios empleados determinan con quién y con quién trabajar. Intentamos hacer esto ya desde el principio; cuando propusimos hacer la rotación nosotros mismos, funcionó bien.
Ahora que hay un equipo, debe esforzarse por garantizar que al final del sprint haya un aumento en la "bondad" del producto con una clara ganancia comercial.
Una buena alegoría del trabajo en equipo en Scrum es una competencia de bote dragón. El baterista marca el ritmo para sincronizar el remo colectivo, y al comienzo del bote hay un timonel que marca la dirección. En nuestra empresa, el propietario del producto gestiona la visión del área comercial, y el scrum master ayuda al equipo a mantener el ritmo adecuado para el trabajo sincrónico en todos los frentes. Un tambor es un tablero de scrum, un lugar de reunión común para eventos de equipo.
El error principal aquí es un intento de nombrar un maestro scrum o incluso combinar varios roles en una sola persona. Quizás en equipos maduros esto funcione, pero definitivamente este no es su caso. E incluso en equipos maduros, el propietario de un producto nunca puede ser un scrum master al mismo tiempo. Debes encontrar un maestro scrum y no nombrar a alguien de las personas que se acercan. Tal persona ayudará al equipo a ser más cohesionado y efectivo de sprint a sprint.
Para el desarrollo de prácticas de ingeniería, debe crear no un departamento que imponga las cosas correctas como las pruebas unitarias, sino una comunidad de desarrolladores interesados en esto. Si tales iniciativas nacen desde abajo, serán apoyadas en todos los niveles.
El trabajo en equipo debe ser transparente para todas las partes interesadas. Este es el deber del equipo y su ventaja significativa. El equipo construye el proceso de su trabajo por sí mismo, y todos los problemas que puedan surgir también se resolverán de forma independiente en el proceso de crecimiento.
Y el último consejo: use herramientas simples. Cualquier campo y proceso en Jira se reemplaza fácilmente por una placa física con un conjunto de imanes.
¿A qué hemos llegado?
Regularmente tenemos nuevos equipos de productos. No discuten lo ágil, pero hacen una nueva funcionalidad. Gracias a las personas en los equipos, se crean productos que son útiles y convenientes para los clientes, y rentables para un banco.