Propósito aplicado. Informe Yandex



¿Por qué se necesitan metas? ¿Cómo deben formularse? ¿Qué problemas pueden surgir? Con motivo de Y. Subbotnik Pro, preparé un informe basado en varios años de experiencia en el establecimiento de metas para equipos en Yandex.



- Te contaré un poco sobre mí, en el contexto de por qué deberías escuchar mi informe. Dirijo un equipo que ahora se llama gestión. He trabajado aquí durante mucho tiempo, he visto muchas cosas: toda la evolución de cómo se organiza la gestión en una empresa tan grande, cómo lideramos los objetivos.



También me encantan las herramientas y metodologías, desde el desarrollo hasta toda la empresa. Y recientemente, entre otras cosas, dirijo el departamento que se dedica a la creación de nuestras herramientas internas.







Descargo de responsabilidad: ¿qué no cubriré en mi charla? No les diré todo tipo de definiciones enciclopédicas: qué son SMART, OKR, KPI. Todo esto ya se ha dicho cien veces en Wikipedia. Probablemente hayas escuchado todas estas cosas tú mismo. Si no, una búsqueda rápida con su motor de búsqueda favorito le dará la respuesta. Está lleno de muy buenos artículos. Lo revisé literalmente esta noche.







¿De qué te voy a contar? Intentaré compartir contigo una experiencia tan personal. Y la experiencia que tenemos en Yandex sobre el establecimiento de objetivos. Le mostraré una serie de buenos ejemplos y trataré de establecer advertencias: qué cosas, me parece, deben tenerse en cuenta y qué rastrillos no deben pisarse.



Esta es una charla experimental en un área que no es muy habitual para mí. Por lo tanto, si hace preguntas, es posible que pueda decirle más y más sustancialmente lo que necesita.



¿Por qué liderar metas?



¿Qué tiene esto que ver contigo? Primero, espero que haya personas entre ustedes que se fijen metas. Y creo que te será útil conocer la experiencia para poder fijarte mejor las metas. En segundo lugar, incluso si usted mismo no establece metas en este momento, sino que simplemente las logra, una comprensión común de la metodología y los principios lo ayudará a lograrlas mejor.



Lo más probable es que el público presente tanto establece metas como las logra. Yo mismo pertenezco a esas personas. Por lo general, la persona en la posición intermedia está involucrada en ambos hilos. Así que espero que sea interesante y útil para todos.







Hablemos un poco sobre por qué establecer metas. Tengo varias citas que escuché en diferentes momentos de diferentes colegas y conocidos: dicen, todo esto es burocracia, en lugar de fijar metas y escribir tareas, hazlo con normalidad y todo saldrá bien. No hay necesidad de inventar nada, no hay necesidad de perder el tiempo en esto.







La segunda sabiduría popular es que solo hay que trabajar muy, muy duro, tomar más y tirar, no te olvides de descansar. Un trabajo tan duro lo triturará todo y no importará cuáles sean sus objetivos. Por supuesto, todo esto es cierto. Pero solo parcialmente.







Incluso si eres un muy buen desarrollador y trabajas muy, muy bien, llegará un momento en el que no tendrás suficientes manos para hacer todo. Y tendrás que responder a la pregunta: ¿qué emprender en primer lugar, qué hacer exactamente ahora? Tengo un intervalo de tiempo finito y es necesario hacer más. Necesitamos priorización.



Segundo: si usted es un líder, entonces surge un problema: se puede hacer lo mismo de muchas formas diferentes. Y debe comprender cómo revisar lo que han hecho sus subordinados.



Tengo una charla sobre nuestro sistema de revisión. Allí hablo con más detalle sobre cómo funciona nuestro RPG interno: con niveles, subidas de nivel, ratings, etc.



Mira el informe


Ciclo vital



Hablemos del ciclo de vida. De hecho, pasaré a una exposición de cómo funciona en nuestro país.







Recogí esas fotos. ¿Qué vemos aquí? Seguramente muchos están familiarizados con las etapas del ciclo de vida de casi cualquier cosa: apuntamos, disparamos, miramos donde golpeamos. Por lo general, en el mundo Agile, esto es como la planificación de un sprint. O retro, o demo, ¿quién puede hacerlo?







Pero me gusta diseñar procesos para que las cosas complejas puedan expresarse a través de fórmulas y principios simples y escaladas fractalmente. La imagen con el fractal de Mandelbrot nos sugiere esto.



¿Que tenemos? Diferentes partes de nuestro proceso fractal. Hay intervalos de revisión de empleados de seis meses.







Cada tres meses: revisión intermedia, donde resumimos los resultados provisionales del período de revisión.







Una vez al mes, hay luces verdes donde los equipos les dicen a los equipos relacionados lo que sucedió en los objetivos. Esto es necesario para que los comandos estén sincronizados entre sí.







Y esos sprints de dos semanas.







Como puede ver, el resultado es una imagen fractal, muy similar a la metodología de apuntar primero, entender lo que va a hacer, hacerlo y luego mirar el resultado.







Esto es muy importante porque las personas que dan los consejos antes mencionados de la sabiduría popular están en el medio de la imagen. Simplemente disparan. Más o menos no apuntan, más o menos no miran donde golpean. Y esto da procesos mucho menos predecibles y controlables que si sigues tres etapas tan simples.



Es como si todo informe tuviera una introducción, un cuerpo y una conclusión. Del mismo modo, toda acción con un propósito debe tener una meta, una ejecución y un resumen.







Para que estos resultados se puedan resumir, para que también se pueda establecer el objetivo, para apuntar correctamente, se necesita una propiedad tan importante como la mensurabilidad.



En la historia sobre mensurabilidad, daré un anti-ejemplo. Tengo un concepto alado (dentro de Yandex): objetivos de "casilla de verificación".



Objetivos de casilla de verificación





Este es un anti-patrón. Lo más probable es que sus objetivos no sean muy buenos si suenan como "hacer una nueva versión del componente X", "iniciar el servicio Y" o "refactorizar Z". ¿Por qué es tan malo?



  • , , . . , , , - : , , , , . , .



    «», — X? ?
  • , . , , . — « X», - .
  • La evaluación del resultado se vuelve más complicada. Por ejemplo, necesita evaluar dos equipos. Sin un proceso de revisión y calibraciones, no podrá encontrar que un equipo ha cometido un error, al estilo MVP, y el segundo lo ha hecho todo bien, durante siglos y con gran detalle.


Por lo tanto, mi recomendación es tratar de evitar los objetivos de "checkboxing", tratar de traducirlos en un plano más medible.



Crear una métrica y definir objetivos es parte de trabajar en un objetivo



Puede surgir la pregunta de que algo es muy difícil de medir. Y a veces tienes que empezar a correr. Ya está claro que se necesita hacer el servicio X o la refactorización Y, pero aún no hay métricas que permitan medir esto. No entendemos qué objetivos queremos fijarnos como imagen objetivo. ¿Cómo ser?



Usamos el patrón de que el proceso mismo de crear métricas y determinar objetivos ya es parte del trabajo en la meta. No es necesario bloquear el comienzo del trabajo en un objetivo si no lo ha formulado completamente.







Le daré un par de ejemplos de nuestros objetivos del mundo real. Yandex tiene un equipo que se ocupa de la llamada Belleza de la hoz, haciéndola más bella. Cuando apareció, solo había una idea general. Aquí tienes tanta gente, hazlo.



El equipo ni siquiera sabía qué es la belleza y cuánto por ciento de esta belleza desconocida se puede cambiar. Sin embargo, empezaron a trabajar en paralelo. Hubo una opinión intuitiva de que algunas cosas son más hermosas, y hagámoslo. Y en paralelo, comenzaron a idear un sistema que mediría esta misma belleza. Y como resultado, obtuvimos un sistema, una métrica, del que Anton Vinogradov habló en su informe "Yandex Beauty: Design for Millions":



Mira el informe


La esencia del sistema: hacemos una comparación lado a lado de la versión antigua y la nueva. Luego calculamos la suma de los cambios positivos de cada una de nuestras implementaciones durante un cierto período de tiempo.



En el primer semestre de trabajo sobre este objetivo, formulamos una métrica. Hicimos una vista como porcentaje, un poco desde el techo. En el próximo semestre, según lo bien que lo hicimos, ya comprendimos cómo se mueve esta métrica, qué implementaciones la afectan, qué es lo que podría querer allí.







El segundo ejemplo en el contexto del trabajo en métricas es uno de nuestros contornos más antiguos, el equipo que se ocupa de la velocidad de las interfaces.



Cuando comenzó, también había un mensaje general: haga que la Sickle se cargue más rápido. Pero, ¿cómo medir si es rápido o no? Hubo quejas como: "Lo estoy abriendo en mi teléfono, algo me parece lento. ¡Los motores de búsqueda de la competencia son más rápidos! " Para comenzar a hacer este trabajo, no fue necesario formular exactamente la métrica. Sabíamos cosas comunes: si envía muchos bytes a través de la red, ejecuta mucho código en JS, llevará mucho tiempo. Comencemos a hacer algo y, a lo largo del camino, recopilemos métricas reales, comprendamos cómo las mediremos.



También hay un informe sobre esto. Andrey Prokopyuk contó todos nuestros detalles sobre cómo se mide la velocidad en usuarios reales y en mediciones sintéticas en el interior:



Mira el informe


Al mismo tiempo, los chicos trabajaron para lograr un objetivo significativo: reducir estos mismos bytes.



Mide lo inconmensurable



La siguiente pregunta que puede surgir es: bueno, queremos medir y está más o menos claro a la velocidad del frontend, hay una regla que nos permite detectar bytes. Pero, ¿cómo se puede medir algo generalmente inconmensurable? Con la belleza que se te ocurrió lado a lado, ¿y si no hay nada? Por ejemplo, necesita medir la felicidad de los usuarios en el desarrollo interno.







Primero, vale la pena pensarlo de nuevo. Como dije, con la misma belleza que parecía subjetiva, pudimos derivar una métrica más mensurable.



En segundo lugar, puede pensar en métricas de proxy. Aquí también te enviaré a tu motor de búsqueda favorito: puedes encontrar muchos artículos sobre qué es una métrica de proxy y cómo seleccionarla. En resumen, la métrica del proxy le permite aproximarse indirectamente a su estado real de cosas, para hacer suposiciones como: "Si seguimos utilizándonos mucho, nuestra interfaz probablemente no sea tan mala".



Está claro que esto tendrá cierto grado de error y permisibilidad. Pero si impone una cantidad suficiente de métricas de proxy, puede terminar con una aproximación suficientemente buena, que no requerirá la creación de una métrica grande y compleja.



Esto último se sugirió en los comentarios de mi informe anterior: siempre se puede reunir un jurado de usuarios o expertos para cualquiera de los temas más inconmensurables y pedirles que los califiquen en una escala. Haz esto con regularidad y así obtendrás un sistema de coordenadas, una métrica reproducible que te permitirá entender si estás progresando correctamente. Incluso esta métrica seguirá siendo mejor que esos objetivos de "casilla de verificación". Como Porthos: "¡Lucho solo porque lucho!"



Un par de palabras clave para ayudar con las encuestas de usuarios: csi nps. Pero creo que la idea es clara.



Métrica Antibug



Otro ejemplo es sobre la métrica antibug. Contamos con un proceso especial que nos permite mejorar la calidad de nuestras interfaces y hacerlas menos bugs.



Ahora te cuento como funciona. En él se pueden ilustrar varios puntos.







Primero, hemos creado gráficos de resumen de la cantidad ponderada de errores para los equipos. Es decir, contamos el número de errores emergentes en la ventana flotante y les asignamos pesos en proporción a su prioridad. Tenemos menores, triviales, normales, críticos y bloqueadores que se diferencian entre sí en un orden de magnitud. El menor y el trivial tienen un peso de 1, el normal tiene 10, el crítico tiene 100 y el bloqueador tiene 1000. El resultado es un gráfico que refleja cuántos errores hay actualmente en el servicio, teniendo en cuenta sus prioridades.



En segundo lugar, comenzamos a crear esos gráficos por separado para los errores que encontraron el equipo y los evaluadores del equipo, y para aquellos que fueron informados por usuarios externos. Luego suspendimos el componente del objetivo, llevamos a cabo el objetivo. Dentro de nosotros, este proceso se denomina política de cero errores. Pero está claro que el cero es un ideal tan inalcanzable, y cada equipo puede tener un cero diferente en un momento dado. Allí se define un umbral: que el peso no supere los 50 o 100.



Si un equipo recién comienza a trabajar en un antibug, decimos que debería reducirse en un 20% cada mes. Hay seis meses en el semestre, cinco meses para una disminución del 20%, más otro mes para mantener este resultado. Por lo tanto, es posible que un semestre alcance el valor objetivo y tenga una pequeña cantidad de errores.



La métrica antibug es 20% basada en el principio de que debería haber más errores encontrados por sí mismos que errores de usuario. Es decir, las pruebas en el proyecto deberían funcionar mejor y los usuarios deberían encontrar menos errores que nosotros.



El último criterio es el cumplimiento del SLA de cierre. Incluso si no tiene muchos errores, pero han estado colgados durante mucho tiempo, esto puede molestar a los usuarios: la cantidad de personas afectadas por un error en producción aumenta cada día hasta que se soluciona este error.



Y aquí hay dos puntos. Además de la metodología de cómo medimos, estimamos este peso y el número de errores, hay otro ejemplo de cómo puede combinar varios criterios diferentes en una métrica.



Simplemente coloque pesos y porcentajes en estos criterios y diga que uno afecta al 40%, el segundo al 20%, el tercero al 40%. Aquí hay un ejemplo, y esta métrica permite que el trabajo más o menos unificado sobre el antibug se distribuya entre decenas de equipos en Yandex.







Volvemos a la palabra clave "saldo". Tienes que intentar encontrarlo. Le hablaré sobre varios equilibrios que debe tener en cuenta al realizar el proceso de establecimiento de metas.



El primero es un equilibrio entre "muy pocos goles" y "demasiados goles". No debería haber pocos goles porque no será lo suficientemente ambicioso para el equipo. Simplemente no utilizará todo su potencial. Demasiado también es malo: a partir de algún momento, la sobrecarga de reconocer y mantener una meta será demasiado grande. Se acumularán en total y te molestarán.







Tenemos un par de ejemplos de este tipo. Por ejemplo, había un equipo que constaba de ocho personas. Tenían unos seis goles. Dijeron: “Como equipo, no podemos realizar un seguimiento de seis objetivos a la vez. Necesitamos seguirlos con luz verde, comprender constantemente si cada uno de ellos está progresando bien con nosotros. Dividámonos en dos equipos de cuatro y distribuyamos estos tres goles a un equipo, los otros tres a otro. Este es un método de trabajo que, en última instancia, le permite enfocar a las personas un poco más en un objetivo específico.



El siguiente equilibrio es el equilibrio entre nuestros deseos y capacidades. Si no hay equilibrio en el equipo que participa en el establecimiento de metas, muy a menudo hay un sesgo en una dirección u otra. Suponga que tiene una alta dirección sólida y él le dice: "Definitivamente tenemos que hacer esto". Y todos los objetivos se establecen a partir de nuestros deseos: queremos que esto suceda, y lo que quieras, "sácalo y déjalo". Tal situación puede estar plagada del hecho de que estos deseos no estarán alineados con la realidad y simplemente no se cumplirán.



Además, el desequilibrio es si los marineros tomaron el poder en el barco. Entonces el equipo intentará formular goles de tal forma que todo esté acertado, garantizado. Como dije, esto está plagado de la subutilización de su potencial. Siempre debería haber un desafío, una forma de salir de tu zona de confort, un punto al que llegar. A través de la tensión se produce la evolución. Es importante que esta tensión no sea tal que te rompa los ligamentos. Debería estar desarrollándose. Y este equilibrio debe buscarse.



También existe un equilibrio entre la denominada anchura y profundidad. Siempre hay una opción, que es mejor: elaborar un objetivo en detalle, pero solo uno, o lograr muchos objetivos, pero al final no tener tiempo para resolver cada uno de ellos, al menos hasta cierto punto. Aquí no hay un consejo universal, porque las situaciones de la vida son muy diferentes. Algunos hilos son muy importantes para soportar al menos de alguna manera, y en este sentido se necesita el ancho. Por ejemplo, cepillarse los dientes, comer, hacer deporte, trabajar son temas igualmente importantes. Aquí es imposible decirlo: déjame cepillarme los dientes muy bien durante el primer mes, tres veces al día, el próximo mes voy a practicar deportes muy bien, etc.



Pero también hay situaciones inversas, cuando es importante para nosotros resolverlo hasta el final, es bueno cerrar algún tema y luego seguir adelante. Y no inicie dos reparaciones al mismo tiempo. Si existe tal oportunidad, primero puede hacer una cosa, invertir bien, seguirla y luego hacer otra.



Es necesario un equilibrio entre las dos formulaciones: "reorientar en el tiempo a la realidad cambiada" y "rendirse a las primeras dificultades". A veces puede comenzar a hacer algo y descubrir que las tareas son más difíciles de lo esperado. O han sucedido factores externos, como coronavirus u otra cosa. Es muy tentador, guiarse por el principio Agile, adaptarse con flexibilidad a la realidad cambiante y, por ejemplo, subestimar tu KPI, renunciar a unos objetivos u otra cosa. Aquí nos encontramos en la misma situación que en el establecimiento inicial de objetivos, solo que en dinámica.



Asegúrese de no darse por vencido ante las primeras dificultades, incluso en la dinámica, cuando continúe cambiando la distribución del peso de los objetivos, pero tampoco golpee la cabeza contra la pared cuando esto ya no dé ningún resultado.



Lo último de lo que quiero hablar en esta diapositiva es el equilibrio entre diferentes objetivos. A veces, las metas comienzan a entrar en conflicto entre sí.



En este lugar en particular, tenemos claras metodologías para intercambiar una por otra. Pero también es importante evaluar el resto, los mismos objetivos en conflicto desde una distancia suficiente. ¿De qué forma se podría intercambiar uno por otro?







Y un par de analogías e imágenes sobre el equilibrio. Este, en la forma en que lo formulo por mí mismo, es de dos tipos:



  1. « ». — , , - — , .



    , . : « , ». , , . , : .
  2. «». , , . . , : - . , , . , , .




Al final, quise reproducir todo lo que dije y volver a mostrarles las diapositivas. Pero no eran tantos y parecen más o menos comprensibles.



Un breve resumen de todo el informe: El establecimiento de objetivos es difícil. Puede encontrar que el establecimiento de metas en sí mismo requiere una cantidad significativa de tiempo. ¡Pero vale la pena! Al menos este es mi juicio de valor basado en mi experiencia personal.



Estoy muy contento de que, en general, hayamos llegado a un sistema con objetivos y sigamos evolucionando y mejorando. Todos estos esfuerzos, me parece, están dando sus frutos.



Podría haber un anuncio de nuestra herramienta o de cualquiera de sus herramientas, porque se puede dar o recibir cualquier herramienta para realizar tareas u objetivos. Simplemente busque en su motor de búsqueda favorito [nombre de su herramienta, espacio, objetivos]. Seguramente encontrará un artículo que describe exactamente cómo hacer esto. Gracias por su atención. Les deseo a todos el mismo éxito en los golpes que en este gif.






All Articles