Cómo las estrategias chinas ayudan en el trabajo

Nuestro trabajo diario es a menudo como una serie de confrontaciones. "Luchamos" con los clientes y otros equipos, con evaluadores y colegas, y los departamentos dentro de la empresa compiten entre sí. Luchamos por los salarios, tomando decisiones técnicas convenientes, plazos y miles de otras cosas. En esta serie de conflictos, el líder del equipo es el líder de una pequeña unidad de combate, el equipo. Él conoce las fortalezas y debilidades de cada "ordinario", coordina y organiza su trabajo para lograr objetivos con pérdidas mínimas.

Si observa el trabajo del líder del equipo desde este punto de vista, entonces la planificación estratégica y el trabajo posicional dentro del equipo y más allá es importante. Al mismo tiempo, no te olvides de las tácticas. Inesperadamente, el conocimiento de las antiguas estratagemas chinas ayuda a planificar una estrategia y reaccionar tácticamente.



Alexey Zolotykh ( zolotyh ) - líder del equipo en Infobip. Alexey usa en su trabajo las reglas de guerra de la antigua China. A partir de un artículo basado en su informe sobre Saint TeamLead 2019 , aprenderá cómo las estratagemas ayudan en la vida de un líder de equipo: cómo hacer las paces con un desarrollador dentro de un equipo, cómo ganar credibilidad entre colegas, cómo defender su opinión, por qué sacrificar una ciruela, regañar una acacia, pretender estar loco y vencer en la hierba

Estratagemas

Una estratagema es una secuencia calculada de acciones destinadas a resolver un problema específico.

Estas son reglas, movimientos estratégicos y tácticas para lograr diferentes objetivos. Se usaron estratagemas en las hostilidades. Básicamente, se describen en los libros "Treinta y seis estratagemas" y "El arte de la guerra", que se atribuyen a Sun Tzu. Este estratega y pensador chino vivió alrededor del año 500 a. C. Pero el concepto de "estratagema" ha estado viviendo en la cultura de China durante 3.000 años, por lo que podemos suponer que el autor de los tratados es todo el pueblo chino.

Pero surge la pregunta: ¿somos tímidos, de dónde viene la guerra? No peleamos, no peleamos con nadie y no capturamos, ¿por qué necesitamos estratagemas?

Sistema de controles y balances.

En el libro de Ray Dalio "Principios" hay una idea importante: cualquier empresa o equipo es un sistema de controles y equilibrios. Una empresa está congelada en conflictos y confrontaciones.

Lo explicaré con un ejemplo. La empresa "Resumen" tiene dos departamentos: probadores (QA) y desarrolladores. El objetivo de los desarrolladores es llegar a la producción lo más rápido posible y lanzar el producto a tiempo, porque tienen KPI para esto. Los probadores tienen diferentes prioridades: es importante que encuentren tantos errores como sea posible, porque tienen KPI de calidad. Dos departamentos abstractos en una empresa abstracta están constantemente entrando en conflictos abstractos y confrontaciones entre sí.

Existe una situación similar entre los recursos humanos y los propietarios de la empresa. En pocas palabras, el objetivo de Recursos Humanos es contratar a la mayor cantidad de personas posible. Pero para esto tendrá que inflar el presupuesto, porque ahora las personas en TI son caras. Los dueños de empresas quieren contratar personas más baratas. De nuevo, conflicto y confrontación.

Los conflictos en las empresas entre diferentes departamentos, empleados, equipos, gerentes y subordinados ocurren constantemente en el formato de manifestaciones, diálogos y discusiones. Pueden considerarse como una especie de confrontación militar, y los consejos sobre la guerra serán simplemente útiles.

Veamos esas estratagemas que pueden usar timbales. Las estratagemas están escritas en lenguaje poético, y esto no es una coincidencia, ya que son fáciles de recordar.

El general es lento porque está considerando la victoria.

Es necesario prepararse para cada rally. El Capitán Evidencia aparece aquí, pero no, espera ...

“No es el que sabe jugar con todas las reglas gana. El ganador es el que sabe cómo abandonar todas las reglas en el momento adecuado, imponer sus propias reglas en el juego que son desconocidas para el enemigo y, cuando sea necesario, abandonarlas ". Esta es una explicación de la estratagema de un libro sobre ellos. Si se aplica a TI, entonces dice que el que establece las reglas al comienzo del rally y gana .

En 2017, hablé en una conferencia. Uno de los objetivos de mi presentación fue "vender" el lenguaje Dart a la audiencia. Este es un YP bastante extraño, no convencional, pero lo amo mucho. Está claro que la audiencia en la conferencia no está lista para él, así que se me ocurrió un "truco militar".

Llamé a un "jurado" de tres personas al escenario para expresar ciertas características de JavaScript, TypeScript y Dart y comparar estos tres idiomas. Pero yo mismo establecí el formato de la competencia y se me ocurrieron las reglas. Como líder y principal en el escenario, dije:
- Según mis estimaciones, en TypeScript la escritura es de 5 puntos sobre 10, en JavaScript no lo es en absoluto, y en Dart es 10 sobre 10.

¿Quién, además de Chuck Norris, aún elegiría TypeScript con tales argumentos? Esto no es lógico, nadie quiere ser "no como todos los demás". Por lo tanto, el jurado simplemente no tuvo la oportunidad de elegir un ganador diferente al formato que le pregunté. Predeciblemente en esta "batalla" Dart derrotó porque me preparé.

Solo espera un enemigo cansado

Una gran estratagema ilustrada por dos historias.

"Reescribamos todo en ..."

Como líder de equipo, tengo relativa libertad para elegir tecnologías, por lo que mis compañeros de equipo a menudo acuden a mí (no uso la palabra "subordinados", creo que esto está mal). Usualmente dicen algo como esto:
- ¡Lancemos TypeScript y reescribamos todo en Flow!

O:
- Hay algo genial: GraphQL. Hiciste un informe sobre ella y estás haciendo campaña por ella. ¡Vamos a implementarlo!

Salí de esta situación muy simple:
- Realmente me gusta GraphQL. Pero, ¿puede escribir un plan de implementación para seis meses, teniendo en cuenta las dos docenas de servicios que ya hemos implementado, y luego hacer un informe al respecto?

Tenemos un formato de presentación los viernes. Por extraño que parezca, se lleva a cabo los miércoles, porque cargar a los colegas con algo nuevo el viernes no es muy bueno.

Si una persona es responsable, motivada y está segura de que tiene razón, lo más probable es que termine el proyecto. Pero si solo quiere hablar y discutir, ni siquiera mirará en esa dirección: tendrá que comunicarse con alguien, buscar, preparar una presentación y trabajar adicionalmente.

Así que mato dos pájaros de un tiro:

• No callo a una persona y luego no escucho en cada reunión sobre GraphQL cómo va a resolver todos nuestros problemas, etc.
• Sin embargo, si una persona completa el proyecto, se convertirá en un buen líder de equipo en el futuro, y tendremos algo nuevo y genial.

"Soy demasiado vago para escribir, vamos en voz"

Este truco de la vida me dijo un buen amigo. Imagine que recibe una solicitud de extracción y necesita realizar una revisión, encontrar algunos errores. Usted comprende que en esta solicitud de extracción, la raíz del mal está profundamente arraigada: el desarrollador no comprende absolutamente lo que está haciendo, por lo que todo está escrito incorrectamente y usted lo informa. El desarrollador no está de acuerdo (se espera), viene a ti y te dice: "Escucha, soy demasiado vago para escribir, hablemos así".

¡No te conformes con eso! Si la gente viene a hablar contigo, entonces "hablar" es gratis. Puedes decir una hora y no te cuesta nada. Tenemos toda la correspondencia en inglés, y cuando tiene que responder, a veces es más rápido rehacer que ir al Traductor de Google. Hay menos disputas: la persona ya está cansada, no le interesa pelear.

Sacrificar una ciruela para salvar un durazno

Hay situaciones en las que puedes dar algo pequeño a cambio de lo principal. Por lo tanto, antes de comenzar las negociaciones es importante comprender qué es importante para nosotros y qué es secundario.

Llegamos a negociaciones con una posición preparada.

Scrum cerebral

Hay dos opiniones condicionales en Infobip: algunos dicen que Scrum y Agile son geniales, mientras que otros sugieren escribir más código y menos chat. En las reuniones, la segunda posición se expresa en el hecho de que una persona se lleva una computadora portátil y se tropieza con ella: no se puede obtener nada de ella.

En este caso, nos comunicamos con el empleado:
- Hagámoslo de esta manera: puede que no vengas a un rally de Scrum, pero debes conocer los resultados. Pero si todavía viniste, quita la computadora portátil y trabaja con nosotros.

Una persona entiende que si se pierde la reunión, tendrá que ponerse al día, y nadie sabrá su opinión. Sacrifiqué la presencia de un empleado, y esto hiere el orgullo, y al final él viene de todos modos. El problema está resuelto.

Señalando a un árbol de moras, regañar acacia

Grigory Bakunov tiene un buen informe en el que sugirió que cualquier desarrollador está en el proceso creativo característico de niños de 5 a 7 años. Según él, cualquier desarrollador de 5 a 7 años (condicionalmente), y necesita hablar con él como un niño .

Tengo un hijo, él tiene casi año y medio. Leí libros especializados sobre paternidad y cuidado de niños. En uno de los libros aprendí a "engañar" a un hombrecito para que coma gachas: contarle a un cuento de hadas que hay estómago y que se siente mal cuando su boca no le da papilla, y todo esto es un ejemplo de un niño .

¿Cómo aplicarlo en desarrolladores? Anteriormente, cuando quería dar retroalimentación a alguien, lo decía directamente:
- Oleg, aquí y aquí te equivocas. Para mejorar las cosas mañana, haz esto y aquello.

En la mayoría de los casos, esto socava la autoestima: una persona pone excusas y dice por qué tiene razón o por qué no podría hacerlo de otra manera. Ahora voy al otro lado:
- Imagina que eres un líder de equipo y tienes esa situación. Que vas a hacer

Lo puse en mi lugar y le pregunté qué haría en esta situación. El orgullo del desarrollador está en orden, y se está acostumbrando al papel de líder de equipo y está buscando formas de resolver el problema.

Pretende estar loco, manteniendo tu mente

Pretende ser un tonto mi truco de vida favorito. El principio es simple: si tiene una pregunta técnica, pregunte. No sé sobre ti, pero no soy la persona más inteligente del equipo y soy muy consciente de esto.

Hacer preguntas es normal.

En una de mis compañías anteriores, una persona trabajaba en un puesto bastante alto de vicepresidente de ingeniería (CTO). Él seguía repitiendo:
"No entiendo su material técnico, explíquelo en ruso".

O:
- Esto conducirá a la confusión del código. ¿Y con qué nos amenaza esto? Por qué Como?

Los CTO como yo tienen 30 personas más. La única forma de entender lo que está sucediendo es preguntar una y otra vez.

Cuando una persona responde a su pregunta "estúpida" en palabras simples, entonces comprende dónde hay vacíos en su lógica. En este momento, hace preguntas aclaratorias y descubre dónde algo está yendo mal: la subestimación entre los argumentos, los posibles problemas que pueden desencadenarse. Así que no tengas miedo de hacer preguntas estúpidas.

Si cree que de esta manera pierde su "autoridad" y "rostro profesional", recuerde a Richard Feynman . Este es un premio Nobel, coautor de la teoría de la electrodinámica cuántica, uno de los desarrolladores de la bomba atómica, un artista y cracker de cajas fuertes. En la década de 1960, Feynman pronunció sus conferencias en Caltech, que luego se emitieron en tres volúmenes de Feynman Lectures on Physics. Hasta ahora, esta es una de las explicaciones más comprensibles y populares de los fenómenos físicos, desde la mecánica hasta la física cuántica.

Según regalia, parece que esta es una persona respetable y seria. Pero por el contrario, no tenía miedo de parecer torpe. Una de las características de Feynman es una mente viva y auto-ironía. Constantemente hacía preguntas estúpidas , no trataba de parecer "sólido" y buscaba explicar cosas complejas en palabras simples. Una de sus citas: "Si eres un físico cuántico y no puedes explicar brevemente a un niño de cinco años lo que estás haciendo, eres un charlatán".

Si los premios Nobel pueden parecer estúpidos, entonces aún más.

Atraer al techo y quitar las escaleras.

Encontré un problema en el equipo: hay una gran característica que tomará una cantidad de tiempo indefinida. Los gerentes constantemente me preguntan cuándo se terminará la función, y los desarrolladores no saben el "cuándo" porque no pueden determinar los requisitos. En algún momento, dije:

- ¡Para! ¿Qué necesitas para entender el tiempo?
- Esto, esto y aquello.
- Luego realizaremos un mitin el 1 de octubre. A estas alturas, comprendamos si estamos a tiempo o no.
"Pero ¿qué pasa?" Tal vez comienza el huracán, el autobús no llega, alguien se enferma, ¿cómo tenemos esto en cuenta?
"Sí, y Godzilla atacará ... Simplifiquemos la tarea: decidimos que no encontraremos nada, y si lo encontramos, simplemente se lo diremos a la gerencia". Pero para el 1 de octubre, esto debería hacerse.

Lo más importante, pregunté a todos si está de acuerdo con la fecha del 1 de octubre. Si no estoy de acuerdo, sugerí proponer una fecha diferente, justificándola y decirlo hasta arriba. Brevemente, la estratagema se describe en una frase.

Quita las rutas de escape.

Si quieres atrapar algo, primero déjalo ir

Dale la oportunidad de salvar la cara

Vine con un líder de equipo a un equipo ya establecido. Naturalmente, lo primero que decidí hacer fue "vender" mi autoridad.

En una de las revisiones de código, tuve una gran discusión con un desarrollador sobre arquitectura. Decidí averiguar quién tiene razón y quién no: pedí a todos los líderes de la industria una opinión objetiva sobre el código sobre el que estábamos discutiendo. Todos los que estaba interesado en evaluar confirmaron que tenía razón.

Le expuse todos estos resultados a mi "rival" con la esperanza de que él fuera consciente de su error y que todo se calmara. Pero todo resultó de manera diferente. Mi oponente se dio cuenta de que estaba perdiendo credibilidad. Ahora no está interesado en el producto y, de todos modos, quién tiene razón y quién no es importante para salvar la cara. Después de eso, todas mis decisiones se encontraron con un fuerte rechazo. El desarrollador no pensó en el proyecto, pensó en cómo demostrar que es más inteligente. Todo terminó con una transferencia dolorosa de una persona a otro equipo (despido). Tenía razón, pero no dejé que la persona salvara su rostro. Aún me arrepiento.

Dale al enemigo la oportunidad de salir de la situación con dignidad.

Incluso si tienes toda la razón, el oponente debe mantener su dignidad. Si pisa el callo, ganará al enemigo.

Sitio como un tomate

Escuché otro ejemplo divertido en una conferencia de Ludwig Bystronovsky, director de arte de Lebedev Studio. Imagine un diseñador que se ofrece a hacer un sitio web como un tomate. No está claro cómo se verá esto, y lo más importante, ¿por qué? Pero al diseñador le gusta y promueve su "idea" solo porque se le ocurrió.

Por supuesto, uno no debería estar de acuerdo con tales ideas. Devolver al hombre a la tierra:
- Entiendo que eres un gran diseñador, pero esta idea no eres tú, no funciona ahora.

Este es el mismo principio de conservación de la cara, pero en el caso en que una persona asocia su decisión consigo misma. Esto también debe tenerse en cuenta y trabajar con él.

Desafortunadamente, esto sucede no solo en un entorno creativo. He visto casos en los que los desarrolladores se asociaron con GraphQL o con MongoDB, por ejemplo. Intenta separar las ideas de la persona, ya me quemé por eso.

Batir la hierba para asustar a la serpiente

Cuando reciba un gran proyecto a largo plazo, le aconsejo que implemente MVP: un proyecto mínimo con todos los chips, problemas, errores, que ayuda a evaluar adecuadamente la línea de tiempo. Si MVP simple construye condicional 2 semanas, entonces está claro lo que sucederá después.

Este es un buen consejo y funciona en todas partes. Ahora me opongo a un enfoque diferente, ya en esto he recibido un callo. Deje que el desarrollador haga mejor el MVP y algo específico por el código que trabajará en un proyecto grande de alguna manera diferente.

Escape es la mejor estratagema

Evitar conflictos no es una pérdida.

Como dijo Sun Tzu, hay tres opciones.

• Haz un compromiso. Esta es una decisión poco entusiasta: tanto ganar como perder.
• Reconoce la derrota.
• Para salir Pero esto no es una pérdida, sino una oportunidad de regresar y corregir.

¡No te entrometas en el conflicto! Mejor no pelear, sino vivir en paz.

“Pelear cien veces y ganar cien veces no es lo mejor de lo mejor. Lo mejor de lo mejor es conquistar un ejército alienígena sin luchar ".

Sun tzu

Todo lo que se discutió en el artículo hasta la última estratagema es la manipulación. No todos quieren ponerse en contacto con ellos, pero necesita saber sobre ellos por dos razones: a veces todavía tiene que usar manipulaciones en su trabajo , desafortunadamente, y siempre es mejor saber cuándo está siendo utilizado que no saberlo.

Intenta tener menos conflictos y no te dejes manipular.

En esta nota positiva, le recuerdo que puede enviar una solicitud de informe a la próxima conferencia para líderes de equipo para el final de la semana, es decir, el 22 de diciembre. Y una semana después saldremos de cientos (sospecho que para entonces habrá aún más) de las aplicaciones que elegimos los oradores del febrero TeamLead Conf para que ya no dude de la necesidad de comprar un boleto para la conferencia.