En TeamLead este año, Sergey habló sobre cómo Agile se está transformando en una gran organización y, en consecuencia, cómo su entorno (líderes de equipo y equipos) está cambiando y qué nuevos requisitos se les están imponiendo como líderes. Y mostró todo el proceso Agile con fotos.
Empezando con Agile
Si ya tienes Agile, ¿cómo te decidiste? ¿Has decidido por tu cuenta y conscientemente que este proceso (Scrum o Kanban) es lo que necesitas y en qué te ayudará exactamente para resolver tus problemas? ¿Su primer contacto con Agile fue así?
... o pasó esto?
En las grandes organizaciones, la historia habitual es cuando entra un gerente: “¡Eso es todo, mañana todos son Scrum! No hay tiempo para averiguarlo: eres un Scrum Master o un Product Owner ". Además, del estudio "Agile en Rusia" las cifras muestran: cuanto mayor es la escala, más a menudo ocurre esta historia. Pero no importa cómo logró ingresar a Agile, averigüemos a dónde llegó, qué es este entorno y qué requisitos le impone a usted y a sus equipos. Si no entiende esto, muy a menudo la implementación de Agile se convierte en una fábrica de características.
En el pasado, los desarrolladores tomaban boletos de Jira. Ahora hacen lo mismo, pero toman de lo que ahora se llama la acumulación: una acumulación se acumula para usted, usted toma de ella y el transportador continúa. Al mismo tiempo, en algún lugar, sus productos presentan al usuario lo que sucedió al final: usuario y producto, ¡beso!
¿Es realmente ágil? No lo hicimos por eso.
¿Qué es Agile y por qué?
Sabes que Agile es un enfoque sobre cómo ejecutar proyectos ante una gran incertidumbre. Esta es la matriz de confusión de Stacy:
Agile funciona bien en una situación en la que tiene dos grandes incertidumbres:
- lo que debe hacer por sus consumidores para que voten por su empresa y producto con dinero;
o
- no sabes con que tecnologías implementar esto,
entonces te encuentras en un entorno complejo en el que se te ofrece:
- renuncia a la opinión de que sabes lo que necesitan tus usuarios;
- plantear hipótesis;
- realizar una serie de experimentos;
- obtener comentarios del usuario final (al principio insatisfecho, y en el futuro esperamos encontrar una forma de resolver su problema).
Como resultado, sus equipos y, en general, toda su organización tienen dos enfoques:
- ¿Qué es el valor para el cliente? Debe aprender a medirlo trabajando sistemáticamente con el valor del cliente.
- Hazlo rápido. A veces se dice que la resistencia de un equipo se mide por el número de hipótesis probadas por unidad de tiempo.
¿Cómo aterrizar todo esto en nuestras realidades?
¿Cuál es la tarea del líder?
Hay dos actores en el sistema: usted, como líderes, y sus equipos. Considere un ejemplo simple: un equipo fabrica un producto, pero el cliente no está contento. ¿Qué debemos hacer, como líderes, cuál es nuestra tarea en esta historia? Por supuesto, averigüe cuál es el problema: usted, como experto, vaya y resuélvalo. Digamos que el equipo de desarrollo se somete a pruebas el último día, por lo que una gran cantidad de problemas llegan al usuario. ¿Qué haremos ahora?
Ya sabemos cuál es el problema, lo identificamos. Lo más fácil de hacer ahora es venir al equipo y decir: "Escuchen, muchachos, ahora están haciendo esto, ¡no hagamos eso!" Hagámoslo bien ". Esto generalmente se hace con niños. Le digo a mi hijo de siete años: "¡Vladik, no hagas esto, por favor!" Y esto, por cierto, realmente funciona, deja de hacer eso. Es cierto que mi esposa luego me dice que él solo no hace esto frente a mí. Y cuando estoy en el trabajo, todo sigue como antes.
Entonces no funciona. ¿Qué hacemos entonces? Cambiamos el proceso, le hacemos preguntas al equipo sobre lo que se podría hacer para no hacerlo mal. Básicamente, lo único que podemos como líderes es personalizar el entorno que determina el comportamiento de nuestros equipos. Creamos un entorno que hace imposible el comportamiento negativo y motiva a las personas a comportarse de manera diferente:
Por ejemplo, está implementando Scrum. A partir de ahora, es imposible no entregar el resultado al menos una vez cada 2 semanas. No, un desarrollador puede hacer eso, pero recibirá retroalimentación motivadora y estimulante cuando usted, como líder, invite a la gente a revisar el sprint, quienes dirán todo lo que piensen sobre el producto sin dudarlo en expresiones. Poco a poco, por alguna razón, se avergüenza un poco de arrastrar la misma tarea todos los días: todos los días tiene que responder al Daily Scrum lo que hizo ayer, lo que hará hoy, e incluso con la malvada adición "dentro del objetivo del sprint".
Es decir, creas un entorno que cambia gradualmente el pensamiento de las personas y comienzan a comportarse de manera diferente. Nuestra tarea es pensar constantemente en cómo configurar el entorno. En este sentido, no nos convertimos en líderes de personas, sino en mecánicos para configurar el sistema. Imagínese un sistema: los engranajes giran por sí mismos (estos son nuestros especialistas inteligentes) y hay fricción entre ellos. Corre con una lata de aceite y agrega donde algo comienza a agrietarse: configura un sistema que funciona por sí solo.
Y los más geniales lo hacemos para que el sistema, por alguna razón, comience a desarrollarse. Por ejemplo, creas un entorno en el que el equipo sabe mirar los resultados de su trabajo y, como dicen, entrenarse a sí mismos: ¿qué más se puede hacer para ser aún más cool? Sin embargo, si ha configurado un sistema de este tipo, se encuentra en problemas, tristeza (o alegría); este sistema ya no lo necesita (al menos a diario), el sistema comienza a desarrollarse. Esto es lo que se llama un equipo autoorganizado.
Pero, ¿cómo se puede lograr esto?
¿De qué es responsable el equipo Scrum?
Vayamos de abajo hacia arriba: solo tome un equipo Scrum, sin escala todavía. Una pregunta para ti: ¿de qué son responsables los equipos al final del sprint? Cuando termina el sprint, ¿por qué los regañas?
La respuesta habitual es para las funciones. Si un equipo es una fábrica de características, ¿cómo se relacionan las características entre sí? ¿Por qué estamos haciendo estas funciones y no otras? No hay respuesta a estas preguntas, todavía no se ha creado ese entorno. Un ejemplo clásico es el tablero del equipo de Avito hace unos 2,5 años. Se puede ver que al final del sprint muchas tareas aún están sin terminar, solo alrededor del 40% están listas:
averigüemos cuál es el problema. Uno de los problemas más comunes al principio es que los equipos no saben cómo evaluar. Necesitamos enseñarles qué es Story Point, cómo abordarlo correctamente si hay respaldo, frente, etc. en el equipo. Muéstreles cómo hacer esto con el ejemplo.
Hay otro problema: pueden hacerlo todo, pero no tienen ningún enfoque. Luego llevamos al equipo a una retrospectiva y preguntamos: "¿Cuál fue el propósito de su trabajo?" En respuesta, la mirada de una cabra al acordeón de botones y la pregunta: "¿Cuáles son los objetivos del sprint?" Bien, pongamos en un recuadro grande lo que ha estado haciendo durante las últimas dos semanas. Suenan, escribe. Después de eso, todo el mundo pone de forma anónima una calificación en la pegatina: "¿Hasta dónde han logrado ustedes como equipo estos objetivos de sprint?" Es decir, el equipo tiene que responder a la pregunta, revisando todo lo que se ha hecho: miremos
ejemplos.
Objetivos de Sprint - 8
En esencia, estas son tareas comunes. Además, creé un entorno que mostraba que cada empleado tenía su propia meta (tarea). Y cuando otra persona respondió, tomé un rotulador de otro color:
se ve que cada uno tenía su propio trabajo. Y la comprensión del equipo de cómo logramos el objetivo es completamente diferente. Después de eso, se suele hacer la pregunta: "¿Cuánto somos un equipo?" Porque parece que todos cortaron solo su propio trabajo. Probablemente, el tipo que dio un dos realmente estaba llevando a cabo una tarea difícil y, al parecer, nadie lo ayudó. El compañero de los nueve no ayudó especialmente: cortó su tarea y, probablemente, al final del sprint se dedicó al autodesarrollo, aunque en la otra parte del equipo hubo bombardeos y se necesitaba ayuda.
Objetivos de Sprint - 6 piezas
Este es un equipo diferente, pero la situación es la misma. La comprensión de la realidad ya está cerca de 8-9, pero hay un seis. Este es exactamente el líder del equipo: entendió mejor que nadie lo cerca que estaban de la meta:
Objetivos de Sprint - 5 piezas
Comprimir metas. Es curioso, pero ya existe una distribución normal. 3-4-5 y 7-8-9 son dos subequipos de tres personas dentro del equipo, que juntas arrastraron un trabajo, y más o menos lo lograron. Los muchachos del 3-4-5 tuvieron una característica difícil, no la hicieron frente. Pero entienden casi lo mismo lo que refunfuñaron. Los tres seis son los mayores que entienden mejor lo que está pasando porque ayudaron a los jun en ambas partes:
Objetivos de Sprint - 2-3 piezas
¿Y si pellizcas algo? Cuanto menos son los objetivos del sprint, más comprensión de la realidad, lo que realmente hicimos y cuánto lo logramos, comienza a coincidir en la cabeza de la gente:
¿Por qué mostré todo esto? ¿Por qué es genial si el equipo tiene un objetivo?
La importancia del propósito en Agile
Porque Agile se diferencia de los clásicos por esto:
en los clásicos, prometemos un conjunto de características y podemos seguir jugando: invertir más recursos en desarrollo o vender los plazos. Solo existen estos dos parámetros, porque necesita hacer todo el volumen.
En Agile, entendemos de antemano que estamos en una zona de incertidumbre y no sabemos qué conjunto de características necesitan realmente nuestros consumidores: solo tenemos hipótesis. A veces dicen alucinaciones y el mayor experto en ellas es nuestro Product Owner. Alucina dentro de dos límites: los recursos están comprometidos (equipo de tiempo completo, todos asignados al 100%) y el sprint terminará exactamente cuando termine, ni antes ni después. Ambos parámetros son fijos y queremos que el alcance sea flotante. Esto no es algo malo, es una característica interesante: nos gustaría poder cambiar el alcance, recibir comentarios, lo estemos haciendo o no. Pero necesitas un medidor, este es el objetivo. ¿Cuándo más dispara el objetivo?
¿Cuál es el propósito de Sprint Review?
Hay dos opciones para realizar una Revisión de Sprint.
El equipo muestra al propietario del producto un producto funcional al final del sprint. Mira cómo lo mira. Hizo la pregunta más crucial: “Product Owner, envíenos sus comentarios: ¿hasta dónde hemos logrado el objetivo del sprint? ¿Y cómo necesitamos cambiar la acumulación adicional? " El Product Owner tiene una pose cerrada: “¿Qué puedo decirte aquí? Bueno, sí, los botones parecen funcionar ". Surge un desconcierto: ¿cómo puede un propietario de producto dar retroalimentación sobre los botones de trabajo si no hay información real sobre cómo funcionará en los campos, es decir, no hay retroalimentación de los consumidores finales? La
segunda opción es mi historia favorita de uno de los equipos de Avito, que también unos 2 años. Este equipo conecta a vendedores y compradores en Messenger. Tiene dos métricas clave:
- , , , ..
- , .
El equipo dentro del sprint ha implementado una función banal: una pieza redonda, que muestra que en el otro extremo de la línea el comprador o vendedor está ahora en línea: puede escribir rápidamente y él responderá de inmediato. En la revisión del sprint, mostraron los resultados de una prueba A / B, implementando la función en producción para un número limitado de clientes y viendo si realmente se correlaciona con estas dos métricas. No hubo una correlación obvia, y el equipo pidió otra semana para tomar datos y comprender: si esta función aún es necesaria, ¿cómo modificarla?
Estas son dos opciones diferentes. Su objetivo funcionará cuando no solo lo ponga como un eslogan, sino cuando esté formulado en métricas que se puedan medir. De lo contrario, vuelve a ser una profanación.
¿Cuáles pueden ser los objetivos de un sprint?
Puede establecer objetivos basados en hitos: hacer un lanzamiento para tal o cual fecha, etc. De nuevo, hay poca información aquí: ¿cómo mide que esto es lo que quieren sus consumidores?
OKR ofrece un enfoque diferente: establecemos objetivos basados en métricas y específicos del cliente. ¿Cómo interactúa un cliente con su producto? ¿Cómo afecta esto el hecho de que resuelve sus problemas más rápido, mejor, mejor, etc.? y listo para votar por su negocio con dinero? Por lo tanto, debe tener medidores.
Una de las propiedades de un objetivo, como dice el OKR, debería ser un nivel de ambición. Es decir, queremos mejorar la vida del cliente no solo para un sprint, sino en cuánto, hasta un 80%, 52%, etc. Este es el medidor donde quieres saltar:
En pocas palabras: ¿qué tipo de entorno estamos creando?
La cartera de productos es solo un conjunto de hipótesis. Nosotros, como mecánicos de este sistema, a nivel de equipo, debemos cambiar mentalmente la actitud de las personas hacia la cartera de pedidos. Tienes alucinaciones en tu cartera de pedidos. Por lo tanto, siempre haga una pregunta al propietario del producto, a la empresa, etc. - ¿Por qué estamos haciendo esto? ¿Por qué estás seguro de que esto es lo que necesitan nuestros clientes? Si no está seguro, ¿cómo podemos medir que esto es realmente lo que quieren? Cambia la mentalidad tanto del equipo como de los clientes de tu empresa para renunciar juntos a la sensación de que lo sabes todo de antemano.
El equipo está comprometido con el objetivo del sprint. No acepte ningún compromiso de los equipos para determinar el alcance. Así es como esencialmente los empujas a Waterfall, aunque lo llamas Scrum. No se trata de hacer todas las funciones del sprint. No, su equipo dentro del sprint del proceso Scrum puede incluso cambiar su cartera de productos si de repente descubren que lo que alucinó hace una semana no era algo que lo acercara a su objetivo. Por supuesto, dos semanas es un período corto de tiempo y, al final, tal vez no cambie mucho para usted. Sin embargo, cambie mentalmente: a escala, este problema se manifiesta en todo su esplendor.
El producto y la acumulación de sprints es solo un plan para lograr un objetivo. El plan debe comprobarse periódicamente con el resultado y cambiarse en caso de rechazo. Ya dije que en el Daily Scrum debes hacer la pregunta todos los días: "¿Qué estamos haciendo, con el objetivo en general correlatos?" Gradualmente, capacitará a las personas para que piensen más en el objetivo que en el alcance. Pero primero debe repetir esto varias veces para que la gente finalmente comprenda por qué lo hacemos.
La atención se centra más en el resultado final que en la previsibilidad de los plazos de entrega. Nos enfocamos más en cambiar algunas métricas que solo en incorporar funciones. Incluso es posible no terminar algunas funciones: tal vez al completar 2/3 de tu backlog de sprint, lograrás una mejora en las métricas clave para el cliente, y ya no importará que no se hayan completado 2 funciones. El objetivo es otra cosa.
Sprint Review: evalúe su progreso hacia un objetivo en función de los comentarios de los clientes. Además, de clientes reales. Este es un desafío para todos los empleados relacionado con la práctica de ingeniería que utiliza su equipo: Integración Continua, Despliegue Continuo, etc. Esto es lo que ahora está arrasando en otras industrias donde Agile está tratando de aplicar.
Por ejemplo, la empresa siberiana Gurman en Novosibirsk, que fabrica albóndigas, decidió experimentar con el área de incertidumbre: ¿qué pasa si cambia el relleno aromatizante de las albóndigas o la envoltura, cómo afectará esto al poder adquisitivo del producto? ¡Frio! - ahora realizaremos experimentos y recibiremos comentarios. Pero, ¿qué significa experimentar? Vienen al minorista con un nuevo formato de albóndigas, pero el minorista no quiere hacer compras pequeñas y ofrece una gran oferta durante seis meses; así es como el experimento dura un año. Como resultado, Sibirskiy Gurman abrió su propia tienda, donde puede obtener comentarios rápidamente, pero la tienda es una parte completamente costosa del proyecto.
En TI, como ves, todo es más sencillo. Todo ya está inventado. Y en otras industrias, las personas son creativas para obtener comentarios lo más rápido posible. Pero le pasa a todos.
¿Qué pasa en la balanza?
En algún lugar de la imagen está tu equipo. Y comienza: cada equipo tiene su propio backlog, su propio objetivo, entiendes quién es tu cliente, pero por alguna razón mucha gente (contratistas, stakeholders, etc.) vienen corriendo hacia ti que quieren algo más de ti ( por ejemplo, mete tus alucinaciones en tu backlog), y por alguna razón tienes que hacerlo también:
A nivel de síntomas finales, tenemos lo siguiente:
- Una gran cantidad de dependencias.
- A menudo no sabemos de antemano de quién dependemos; esta es la poca transparencia de con quién tengo que negociar para implementar alguna función. Empiezas a hacerlo dentro del sprint y en ese momento te darás cuenta: resulta que no podemos cambiar la API nosotros mismos, tenemos que correr a esa; pero aquí debe acordar las regulaciones, la seguridad de la información, etc. Es decir, no se sabe de antemano a quién acudir.
- , . , . , . .
- — . - , , ? , , , . .
- — . : « , ! !» — « ?» .
¿De dónde viene todo esto a escala y por qué surge? Consideremos el ejemplo de un ejemplo clásico de obtención de un préstamo, de donde surgen todas estas dependencias en el banco.
Lo primero que debe hacer el banco es decirle a la gente que tiene excelentes condiciones de préstamo: alta calidad, rápido, etc. De hecho, trabajar con un cliente comienza con el marketing. Luego hay una evaluación, registro, etc., hasta el cierre completo del préstamo. La empresa cuenta con servicios operativos que atienden directamente al cliente y se comunican con él:
Luego están los sistemas de TI que respaldan, aceleran, automatizan; en general, lo hacen para que el cliente obtenga un préstamo de forma rápida y sencilla. Aquí es donde aparece nuestra gente y nuestra estructura organizativa. Aquí hay un ejemplo artificial: hay 310 desarrolladores en el departamento de TI de Moscú, 30 personas en Estonia y otro proveedor en Estados Unidos (150 personas):
Un verdadero ejemplo sobre mí. Cuando estaba obteniendo mi tercera hipoteca en mi banco favorito, en la etapa # 2 (evaluación rápida de solicitudes) me rechazaron. En la noche del mismo día, mi gerente VIP me llama con la clásica pregunta: “Sergey, ¿está todo bien contigo con nuestro banco? ¿Quizás pueda ayudarte con algo? " Por supuesto, me encuentro con él: “Amigo, ¿qué pasó? Soy tu cliente VIP. ¿Por qué me negaron la hipoteca cuando todo estaba bien para mí? " Pidió un tiempo de espera y me llamó por la noche; no pudo responder de inmediato a la pregunta, porque miró en el CRM y no vio ninguna información allí de que yo hubiera presentado una solicitud.
El motivo fue que en esos años, este banco subcontrató la primera parte de sus servicios operativos a su socio. Es decir, había un banco matriz y un banco asociado que atendía a los clientes en la entrada; en términos generales, no era el banco matriz el que me ama, sino su socio el que me rechazaba. Dado que la responsabilidad de un banco terminó en el cruce con la responsabilidad de otro, la integración se rompió. Un pequeño error hizo que el banco matriz no se diera cuenta de que el banco asociado no trataba muy bien a su querido cliente. En tales cruces, una empresa a menudo pierde a sus clientes y, como resultado, dinero.
¿Por qué estoy haciendo esto? Imagina que tu equipo Scrum (multifuncional en términos de respaldo, frente, etc.) está en algún lugar dentro de esta estructura. La pregunta clave es: ¿Cuán multifuncionales son sus equipos para resolver los problemas de los clientes? Idealmente, la funcionalidad cruzada debe ser tal que pueda ayudar al cliente en cualquier etapa de su ciclo de vida de comunicación con la empresa. ¿Te imaginas cuántas competencias necesitas para encajar en un equipo Scrum, por ejemplo, para 11 personas?
Desafortunadamente, a gran escala, este es el principal problema: el equipo deja de ser multifuncional con respecto al cliente. La solución es la siguiente: juntemos un gran equipo de equipos que juntos serán lo más multifuncionales posible.
Aquí tienes un ejemplo (dos pegatinas rojas). Una pegatina con la inscripción "Hipoteca" significa que estamos cambiando la estructura organizativa de tal manera que aparece una división hipotecaria (arroyo, tribu, tren, etc., en diferentes empresas se llama de otra manera). Combinamos empresas (responsables de las métricas financieras para la emisión de hipotecas) y equipos (en vivo en Moscú y Estonia) para desarrollar sistemas en la primera parte de este flujo, corregir cualquier error de integración, etc.
En mi historia, no se podía arrastrar al proveedor a este tema. Dijeron: "Escríbanos los TOR, lo haremos todo". Pero en cualquier caso, forma una división que mira a su cliente de la manera más amplia posible. A menudo hay un brindis: "Céntrese en el cliente, valor", pero cuente la cantidad de pasos que cierra esta unidad. Cuanto más se cierra, más fresco está, más precisamente, se irá volviendo cada vez más empinado y podrá solucionar todos los problemas del cliente.
¿Por qué digo esto? La tarea del líder no es solo crear un entorno para el desarrollo del equipo. Primero necesitas entender:
- ¿En qué contexto estás?
- ¿Qué pasos y problemas del cliente resuelve su equipo o departamento?
- Quien es tu negocio
- ¿Cuál es el KPI del cliente final para su unidad de negocio? Es decir, en qué mejoras, y no solo a tu equipo, sino a todo el circuito.
Como ejemplo, presento tres opciones para unidades multifuncionales.
Opción 1: por canal con plataforma
Uno de ellos es esencialmente el feed web completo, donde están todos los desarrolladores web. Por ejemplo, para un banco, la principal métrica estará en la atracción, de modo que el cliente intenta calcularlo con una calculadora de préstamos y se convierte en prestatario hipotecario.
Una aplicación móvil (iOS, Android, etc.) que ya cuenta con métricas relacionadas con la activación y el mantenimiento. También puede haber una división de plataforma, es decir, hacer un componente cuyos consumidores sean otras divisiones:
Opción 2: por productos con plataforma
La segunda opción es más fresca: cambia la estructura organizativa de tal manera que cada unidad se vuelve multifuncional con respecto a los canales. Necesitamos arreglar algo en los créditos, lo hacemos tanto en el canal web como en el teléfono móvil, lo mismo con las tarjetas de débito. El departamento puede cambiar completamente cualquier canal. Pero debe hacerlo de manera que las divisiones puedan realizar cambios en la misma base de código.
Esta es una opción más compleja pero más fresca. A la empresa le gusta mucho, porque el flujo de débito está ganando: puedes entender cuánto ganamos, además hay una nómina para los equipos de desarrollo. Como consecuencia, combina ingresos con costos. Tu departamento se convierte en una pequeña empresa dentro de una enorme, porque tiene sus propias P&L y puedes ver cuán efectivo eres como microorganización:
Opción 3: flujo de valor paso a paso
Los casos complejos tienen una gran cantidad de divisiones y cada una es responsable de un conjunto de métricas. En organizaciones grandes, esta es la opción más popular:
¿Qué tipo de entorno creamos a escala?
A escala, creamos el mismo entorno que a nivel de un equipo. En realidad, hace lo mismo, pero estamos creciendo en funciones cruzadas a lo largo de todo el recorrido del cliente. Por tanto, hay un mar de dificultades: comunicación con empresas, otros equipos, ciclos más complejos (no quincenales, sino trimestrales):
Compartir la planificación de objetivos trimestrales: planificación de OKR (planificación de PI)
Bueno. Su equipo ya comprende que no puede ayudar a su cliente en todas las etapas. Pero comprende que existe una empresa con la que debe planificar el cambio de las métricas de los clientes. Verá, todavía hay mucha gente: alrededor de 150 especialistas más (10-12 equipos). Y con quién, al parecer, tendrá que comunicarse, porque depende de ellos, y ellos, de usted.
¿Cómo comunicarse? En todos los enfoques, Agile ofrece una receta simple: "Simplemente habla: tienes una adicción con alguien, ve y habla con él". Los desarrolladores, especialmente aquellos a quienes les gusta comunicarse más con el monitor que con otras personas, dicen: "Bueno, no puedo hacer eso, ¿cómo puedo simplemente hablar?" Por lo tanto, todos los marcos ofrecen compulsión de comunicación: “Está bien, no puedes comunicarte. Ahora te comunicarás, pero de acuerdo con el siguiente algoritmo ".
La planificación colaborativa de OKR (en otro enfoque llamado PI Planning) está ganando popularidad. La idea es que durante un largo período de tiempo (una cuarta parte), juntos, con toda la multitud, entendiendo quién es nuestro negocio y nuestras dependencias internas, planifiquemos objetivos comunes. Este es un evento de dos días, pero algunas personas logran realizarlo en un día si los equipos ya han aprendido a comunicarse entre sí. En términos generales, este es un evento de preguntas y respuestas facilitado de dos días, como:
- ¿De quién dependemos?
- ¿Qué estamos haciendo este trimestre?
- ¿Qué métricas financieras queremos obtener? Negocios, por favor responda.
Es decir, nos aseguramos de que todos lleguen a un acuerdo con todos y averigüen dónde queremos correr al final del trimestre. Estas son fotos reales, cuando hace tres años Sberbank fue el primero en intentar lanzar tales eventos:
La planificación conjunta de OKR o PI Planning se lleva a cabo por etapas.
Instrucciones
Al principio, se requiere una sesión informativa. Las empresas deberían decir: "Me gustaría ver eso para el final del trimestre ..." Y, por ejemplo, aquí arriba está Sberbank hace 3 años, y abajo: GameDev-compañía Xsolla de Los Ángeles. Los estadounidenses, por cierto, contaron una historia simple de que no tienen problemas para activar nuevos clientes: todo está bien con las métricas de activación. Pero hay un problema con las compras repetidas: por alguna razón, el porcentaje de compras repetidas es muy bajo. Y el segundo problema es que por alguna razón no se compran servicios adicionales, el cheque promedio es bajo. Y la empresa preguntó: "Por favor, todas las funcionalidades de este trimestre están orientadas a la repetición de compras y al aumento del cheque promedio (servicios adicionales)":
Esta es una de las formas en que puede verse una buena visión: cuando hablamos de contexto empresarial y métricas financieras. Pero no sabemos de antemano qué se hará en el trimestre. ¿Qué pasa después?
Discurso del arquitecto
En las empresas de TI, definitivamente escuchamos al arquitecto. ¡Una historia interesante para él! - el medio ambiente también está cambiando. En tales sesiones, los arquitectos finalmente entienden quién es su cliente (la mayoría de los arquitectos corporativos piensan que esto es un negocio):
este arquitecto quería informar rápidamente sobre el paisaje “terrible” de Sberbank y huir: “¡Te lo dije todo! Además, dio una arquitectura conceptual de 50-100 páginas. ¿Qué más puedo hacer aquí? Aún es comprensible, pero en todo caso, llame ". Pero después de la presentación, uno de los líderes del equipo le hizo una pregunta:
- ¡Querido arquitecto! El tercero desde el cubo superior derecho: ¿sabía que este sistema aún no está en funcionamiento?
- Por supuesto que lo sé. Yo mismo dibujé estos cubos.
- ¿Sabes que se pondrá en marcha en seis meses?
- Sí, por supuesto.
- Ahora recuerde que estamos en la sesión de planificación por una meta trimestral, y la empresa quiere funcionalidad nuestra, que, en teoría, debería pasar por este sistema.
Aquí el arquitecto comprende cuál es la pregunta. Y el equipo le pidió que se quedara con ellos, para que cuando planifiquen sus funciones, piensen juntos cómo tomar una decisión inapropiada.
Swarming (generación objetivo)
Luego, los equipos partieron hacia la natación libre. Tienen tres horas y deben generar metas de las que estén dispuestos a responsabilizarse trimestralmente. Esto se llama Swarming (enjambre, zumbido). Es una especie de networking, pero en el marco del trabajo:
claro, no todo es tan sencillo. Los niños reciben un algoritmo para alcanzar las metas adecuadas que pueden tomar para el trimestre. Hacen hojas de rotafolio que muestran los retrasos estimados en los sprints con un trimestre de anticipación. Esto es necesario para que luego de que ellos, teniendo en cuenta su disponibilidad, llenen aproximadamente sus backlogs y hablen con otros equipos sobre dependencias (quién, a quién, qué hará / no hará qué), les hagan la pregunta: “Si arrastran todos estos trabajos, qué metas que alcanzará y con qué medida (métrica) puede medir el grado de logro "
Es decir, planificamos los trabajos atrasados, luego formulamos metas para ellos, después de eso rechazamos estos atrasos. Es solo una técnica sobre cómo llegar a una meta adecuada. Bajo ninguna circunstancia piense que los chicos están comprometiendo a todos los equipos para este conjunto de trabajos del trimestre:
- ¡Equipo, proponga un gol!
- ... ¡Eso es!
- ¿Estás seguro de que lo alcanzarás?
- No, solo pediste que se te ocurriera.
No, estamos facilitando, es decir, ayudamos a llegar a metas más o menos adecuadas.
En la foto, representantes de los equipos que se vieron obligados a comunicarse. A veces llegan a esta sesión con la sensación: "Sí, entendemos lo que vamos a hacer, y parece que incluso conocemos las dependencias de otros equipos, porque hablamos con ellos la semana pasada". Pero cuando me pides directamente que diga qué harán los equipos este trimestre, finalmente se revelan las dependencias:
Les damos una herramienta para que, habiendo hablado de sus adicciones, puedan mostrarlas y ver quién depende de quién. Los saltos verticales son sprints dentro del bloque, los saltos horizontales son equipos. En la intersección, el equipo pone qué característica hará, y la dibuja con una flecha roja: "Pero nos prometieron hacerlo un sprint antes de la API, luego haremos un botón en la parte delantera". Este es un protocolo de acuerdo que hemos acordado contigo, quién, a quién, cuándo y qué:
Presentación Product Owners
Más adelante en la presentación, los propietarios de productos muestran los resultados de sus equipos:
el único que está tratando de pegar en el cerebro cómo funcionará el escenario de un extremo a otro es el negocio. Cualquier pregunta al propietario del producto al comienzo del tipo: “¿Qué escenario de un extremo a otro funcionará?”, A menudo queda sin respuesta: “Espere, somos responsables de este componente. Funcionará para nosotros, su pregunta no es para nosotros. Las balas volaron de nuestro lado, busque en otros equipos la respuesta a su pregunta ". Al principio, la empresa no entiende nada, pero trata de pegar esta imagen en su cabeza.
Dependencias externas
Xsolla tiene la penúltima línea de Tech Ops. Los chicos ya entienden que es necesario involucrarse en DevOps, respectivamente, para brindar el apoyo de los entornos dentro de los equipos. Pero en ese momento (hace seis meses) era una unidad externa. El gerente de operaciones también presentó: caminó sobre las pegatinas rojas y confirmó: “Sí, me empujaste aquí que necesitamos implementar tales y tales entornos. Asumo la responsabilidad, lo haremos ":
Es interesante que cuando dijo en una pegatina lo que harían, su equipo corrigió:
- Espera, amigo, no te preguntamos esto, sino algo más. ¿Entendido?
- Entendido.
- ¿Lo harás?
- Lo haré.
- OKAY.
Tuvieron un problema con abogados, marketing, diseñadores: estos tipos estaban en Estados Unidos (en Los Ángeles) y no asistieron a esta reunión. Por lo tanto, se colgaron las dependencias de ellos, pero hubo miedo: tal vez lo hagan, pero hay que llamar por separado, comunicarse, etc. La conclusión para esta empresa fue que también los invitaron a la próxima planificación trimestral.
Tratamiento de riesgo
Existe un cierto algoritmo sobre cómo se manejan los riesgos. Idea clave: creamos un entorno en el que, resulta que la alta dirección puede establecer tareas. Y ni siquiera da miedo, están listos para tomarlos. Ellos miran: “Si arreglo el contrato con nuestros subcontratistas aquí, resulta que podemos hacer más de lo que quiero”, y entonces se involucran.
Estos son ejemplos de resolución de problemas que pueden aceptarse si tiene todo en esta reunión:
Voto de dedo
El último paso es comprobar si los equipos están realmente preparados para asumir la responsabilidad de los objetivos que han desarrollado. Te pedimos que levantes los dedos:
- 5 dedos: rectos, muy seguros de sus objetivos;
- 1 dedo: con goles en general, es un desastre, deben rehacerse.
Miras el panorama general y si ves poca confianza en la empresa, pídeles que miren a tu alrededor: “Mira, parece que tú mismo no crees en tus metas. Ve a rehacerlo, hazlo para que tú mismo creas en tus planes. Nadie los empuja hacia ti (al menos lo intenta) ":
Fin de trimestre retrospectivo conjunto: Revisión de OKR (inspeccionar y adaptar)
Al final del trimestre volvemos a reunir a todos. De hecho, esta es una gran retrospectiva (llamada OKR Review en OKR):
les mostraré lo que está sucediendo allí con un ejemplo real. Los goles que el equipo asumió para este trimestre están escritos. Tienen una evaluación planificada del impacto en las métricas, es decir, en aquellos objetivos que el negocio quería del equipo y de la empresa. Se evalúa el logro real:
Aquí nuevamente dispara: ¿sabe cómo evaluar el hecho del plan no solo como "Creemos que esta característica probablemente influyó", sino si los productos con la empresa recopilaron métricas reales de las pruebas A / B, de algunas opciones? llegar a los clientes.
Otra opción: si el equipo aún no ha configurado al ingeniero, no sabe cómo llegar rápidamente al cliente, evalúan, como en Planning Poker, solo con los dedos: "Nos parece que hemos logrado este objetivo por tanto":
Básicamente, se fijaron un porcentaje de logro: se puede ver que el equipo ha alcanzado el 88% en el trimestre. La idea es que tal métrica muestre:
- Qué tan ambiciosos se establecieron los objetivos de la empresa;
- Con qué suavidad sabes cómo llevarlos:
Al final, hay una retrospectiva periódica y cada equipo trabaja por separado. Punto clave: se sacan problemas comunes: no por separado para cada equipo, sino aquellos que disparan varios a la vez. Por lo general, hicimos el criterio 3+ equipos. Si tienen un problema común, entonces es necesario resolverlo a nivel de toda la unidad:
Resumen. ¿Cuál es el problema del líder?
¿Cuál es el desafío para nosotros en toda esta historia? Parece claro qué hacer. Pero se encuentra en el contexto de un entorno más amplio: otros equipos, el negocio, entendiendo qué partes del recorrido del cliente decide por usted y para qué clientes. De hecho, hay muchos de nosotros, tales clientes potenciales y líderes de equipo:
¿Cuál es el requisito para nosotros en la escala? ¿Cuál es el problema del líder? El hecho de que el tamaño importa ... :)
Cheburashka se transformó en un cocodrilo para una mejor supervivencia en los entornos hostiles de las grandes empresas ... En otras palabras, necesitas desarrollarte. Este es un dicho doloroso, pero de hecho, si no te desarrollas, las personas de abajo tampoco lo harán. Y en una gran empresa, las demandas son implacables sobre qué tipo de líder debes ser. Necesita poder configurar el entorno para una gran cantidad de equipos, es decir, autodesarrollarse muchas veces más activamente.
Qué líderes sobreviven en Agile
Básicamente, debes dejar de administrar personas. Formar entornos en los que las personas sean autónomas. Deja de ser un experto, conviértete en negociador.
Esto es lo que debe verificar qué tan genial se ha desarrollado en todas estas áreas:
Este año celebraremos la segunda TeamLead Conf en Moscú en lugar de la Saint TeamLead Conf en San Petersburgo. Ya el 16 y 17 de noviembre, nos reuniremos en vivo y discutiremos qué ha cambiado durante este tiempo. Ya anhelamos verdaderas conferencias cara a cara. Para que puedas ver el carisma del orador en el escenario y luego pedirle una hora más en la sala. Para beber una norma mensual de café y ver todos los líderes del equipo que conoces a la vez. Y durante un mes más, clasifique los registros con contactos, libros y palabras clave.
, , , , . : , , -, , .
. . . 2019 .