Un resumen de las ganancias y pérdidas del TL técnico de cuatro años de Ali: cómo ser un líder de equipo técnico

Autor | Xu Xiaobin "Maven Actual Combat" Autor
Fuente | Cuenta oficial nativa de Alibaba Cloud

El Zi dijo: Mi día es para reflexionar sobre mi cuerpo, y la reflexión es una habilidad extremadamente preciosa que los humanos han desarrollado. Llevo más de cuatro años al frente del equipo en Ali. Es necesario resumir aquí las ganancias y pérdidas. Además, hace unos días charlé con un compañero que acababa de empezar a dirigir el equipo. Sentía que el El cambio de rol fue un gran desafío para él, así que quería hacerlo. No es un resumen maduro y lo comparto. Por supuesto, el primero de este artículo no significa que sea necesariamente un gerente maduro; el segundo no significa que mi resumen sea universal (de hecho, los métodos de gestión de muchas personas son contrarios a los métodos que admiro, pero si se evalúan desde el perspectiva de promoción, estas personas tienen más éxito); en tercer lugar, no tengo la ambición de responder a todas las preguntas. El resumen es solo para ayudarse a uno mismo a convertirse en un mejor gerente a través de la reflexión, y compartir es ayudar más o menos a otros gerentes.

Este artículo se centrará en mi comprensión personal del reclutamiento, la gestión de objetivos, la comunicación en equipo y la cultura de la ingeniería. La razón principal para elegir estos temas es que durante el período de tiempo que lidera el equipo, creo que estos elementos son el núcleo de la eficacia de combate a largo plazo y la capacidad de innovación del equipo. No es fácil para mí entender esto. Hay muchos libros complicados en el mercado (especialmente en las librerías de los aeropuertos) que intentan decirle qué es el liderazgo. La empresa también tiene introducciones de capacitación relacionadas. Hay muchos TL para informarle a diario palabras y hechos. ¿Cómo lo hicieron? Pero creo que muchos de los conocimientos de los alrededores no son válidos y muchos más están equivocados. Por ejemplo, TL se sienta en la oficina hasta la medianoche y sale del trabajo todos los días, lo que ejerce una gran presión sobre el equipo para que trabaje horas extras. En la superficie, parece ser una lucha. De hecho, hará que todos tiendan a pagar más atención a la duración del trabajo, lo que reduce su pensamiento sobre el valor del trabajo; por ejemplo, cuando los compañeros de equipo cometen errores, correlacionan fuertemente las fallas con el desempeño. En mi opinión, esto no solo no ayuda a todos a pensar profundamente en la solidez de la sistema, pero también fomenta la responsabilidad y sofoca la innovación; un ejemplo más común puede ser que TL sea reporte positivo, prometiendo exceder la capacidad de entrega de la responsabilidad del equipo, lo que resulta en que el equipo ignore completamente la cultura del ingeniero, la pérdida gradual de talentos sobresalientes tiempo, y las capacidades generales de investigación y desarrollo del equipo en realidad se están debilitando.

Muchas cosas son fáciles de saber y difíciles de hacer. La práctica técnica de TL lo es aún más. Después de eso, puede aprender, implementar y reflexionar continuamente para mejorar gradualmente. Si los compañeros de mi equipo dejan este equipo durante cinco o diez años y piensan en este período de tiempo, suspirarán de emoción: "Qué gran equipo teníamos en ese momento, todos hemos hecho muchas cosas interesantes juntos". Entonces mi tecnología TL Work, incluso si se hace bien.

Reclutamiento

El primer principio de la contratación es preferir no invadir. Todos estarán de acuerdo con eso, pero la implementación real a menudo se deforma debido a la presión a corto plazo, especialmente cuando el reclutamiento es cada vez más difícil. Después de conocer finalmente a un compañero de clase que se ve similar, inevitablemente será un poco de corazón. eso, recluta primero. En realidad, esto es muy peligroso, porque una vez que se contrata a las personas equivocadas, el tiempo de gestión requerido para TL se duplicará, lo que podría haberse dedicado a un tiempo más importante. Lo que es más peligroso es que la persona equivocada puede tener un impacto negativo en el equipo en su conjunto, como requerir que otras personas ocupen puestos constantemente o discutir con otros, lo que consume la energía de todos.

Por tanto, el reclutamiento debe ser estrictamente obligatorio, no entraré en detalles sobre cómo realizar la entrevista, por lo general prestaré atención a los siguientes aspectos, que son básicamente indispensables:

• capacidad de codificación

• Pasión por la tecnología

• Puede comunicarse de manera concisa

• Positivo y optimista

• Reconocimiento de los objetivos del equipo

La contratación es un asunto a largo plazo y, por lo general, es muy difícil encontrar personas solo en la ventana con HC. Cuando conozco a la persona adecuada, seguiré comunicándome con él durante mucho tiempo para comprender el estado laboral de la otra persona. En realidad, esta es una relación que genera confianza continuamente. Cuando la oportunidad sea la adecuada, la otra parte definitivamente le dará prioridad.

Cuando un candidato elige una oportunidad, qué tipo de persona es el TL del equipo debe ser una de sus consideraciones clave. Por lo tanto, TL debe ser una voz técnica. Ya sea para participar en proyectos de código abierto, escribir artículos técnicos o dar un discurso en una conferencia técnica, es una oportunidad importante para reflejar plenamente la capacidad técnica personal de TL, el pensamiento técnico y las características personales. .

objetivos

La razón por la que un equipo es un equipo es que estas personas tienen un objetivo común. Si no tienen un objetivo común, estas personas son rezagadas. No pueden colaborar entre sí y no pueden lograr un gran valor. Los objetivos del equipo son definidos y claros principalmente por TL.

Recientemente, es más popular hablar de OKR. Creo que esta es una forma de coordinar al equipo para enfocarse en la meta. Establecer la dirección O (Objetivo) y establecer el número objetivo KR (Resultado clave) significa que se espera que el equipo se reúna, trabaje en una dirección común y se comprenda y apoye mutuamente. Los indicadores cuantitativos (KR) se utilizan para orientar la dirección y exponer problemas. Me opongo más a usar KR u otros indicadores cuantitativos para evaluar a los ingenieros de manera simple y grosera. Si se usan indicadores digitales para la evaluación, fácilmente conducirán al abandono. Por ejemplo, algunas personas completaron el 200% de KR pero cavaron muchos pozos; mientras que alguien completó el 50% de KR, resolvieron el problema complicado y el código era sólido. Inevitablemente daré un buen desempeño a los segundos y un pobre desempeño a los primeros.

Definir los objetivos del equipo es realmente muy difícil, porque la definición de este objetivo requiere que responda:

• ¿Se ha comunicado completamente con sus usuarios / clientes, ya sea que comprenda lo que realmente necesitan, qué problemas puede resolver por ellos y cómo cambiará su trabajo debido a su equipo?

• Si puede colaborar con colaboradores ascendentes y descendentes, para cumplir con el valor que prometió a sus clientes, ¿en quién confiará para lo que hace? ¿Quién necesita participar contigo? ¿Estas partes dependientes y colaboradoras están de acuerdo con sus objetivos?

• ¿Son sus objetivos y valores definidos coherentes con sus propios objetivos de TL o los objetivos de su propio departamento?

• En el equipo técnico, ¿considera la competitividad técnica en la definición de su objetivo? El desarrollo continuo de la competitividad tecnológica no solo puede ayudar al equipo a desarrollarse mejor a largo plazo, sino que también puede ayudar a atraer talentos más destacados.

Por supuesto, si este objetivo es un poco idealista, tanto mejor. Los ingenieros son tan fáciles de sentir atraídos por el idealismo. Después de tener un objetivo de equipo claro, es necesario comunicarse continuamente con el equipo, para que todos puedan entender claramente el objetivo, no tener miedo a la repetición, no tener miedo a las palabras.

El siguiente paso es descomponer los objetivos del equipo en los objetivos de todos, que es esencialmente arquitectura de producto o arquitectura técnica. ¿Por qué dices eso? Cuando hacemos diseño de software, todos hablamos de alta cohesión y bajo acoplamiento, hablamos de diseño orientado a contratos. Cuando las personas colaboran, también esperamos que los objetivos de todos sean lo suficientemente claros (compare la definición de funciones de entrega de software o la medición de indicadores no funcionales) y que los límites de colaboración entre personas sean claros (en comparación con contratos de sistemas de software). Por lo tanto, debemos seguir pensando en la estructura del producto del que es responsable el equipo, y seguir discutiéndolo y perfeccionándolo con los compañeros hasta que la estructura y los objetivos estén lo suficientemente claros. Por supuesto, hay algunos objetivos horizontales, o objetivos de gestión de proyectos, que deben ser asumidos por los estudiantes. Esto no es un problema, pero le recomiendo encarecidamente que no permita que un estudiante pase más de la mitad del tiempo en el equipo de I + D para realizar un trabajo horizontal porque la tecnología no lo hace, la profundidad no se puede discutir como la amplitud.

comunicación

Si sus compañeros de equipo se acercan a usted, responda lo antes posible. La respuesta inmediata significa que si tiene tiempo en este momento, comuníquese con él de inmediato; si está lleno durante el día, comuníquese con él por la noche; si está realmente ocupado por la noche, programe inmediatamente una reunión para mañana. invitación. Si los estudiantes no piensan en cosas importantes, no tomarán la iniciativa de comunicarse con sus supervisores. La respuesta inmediata es una forma importante de generar confianza en los estudiantes. Si tus compañeros de clase no te responden una o dos veces, o la respuesta es lenta (parece que te ignoran), entonces muchas cosas lentamente no te encontrarán. En el peor de los casos, el compañero de clase puede ser transferido a otra publicación cuando te encuentre la próxima vez.

Trate de hacerlo uno a uno con sus compañeros de clase tanto como sea posible. Si es un gerente a tiempo completo en un país extranjero, debe hacerlo uno a uno como un trabajo diario muy serio con un alto frecuencia, como una vez cada dos semanas. En Alibaba, la TL técnica no suele tener tanto tiempo, porque además de la gestión, las responsabilidades de la persona también deben aportar tecnología y proyectos. Pero aún debe hacer la comunicación diaria 1 a 1, no solo durante la temporada de presentaciones. La frecuencia ideal es una vez al mes. En 1-a-1, por un lado, debes dar una retroalimentación muy específica, como por ejemplo:

• El plan x que hiciste está muy bien diseñado, teniendo en cuenta la colaboración con el equipo de al lado.

• Su código reciente no ha hecho lo suficiente en la cobertura de UT.

• Veo que el proyecto que estás impulsando no avanza como se esperaba, ¿hay algún problema? ¿Cómo puedo ayudar?

Además de la retroalimentación 1 a 1, lo más importante es escuchar ¿Están los estudiantes en buenas condiciones cuando expresan su trabajo? ¿Dónde encontró un problema y qué ayuda puede proporcionar como TL? _En realidad, muchas veces, aunque no puedas ayudar mucho por el momento, es muy importante que los alumnos escuchen los sentimientos de los compañeros con una actitud seria. Ya sea que el estado de ánimo esté lleno de entusiasmo, depresión o confusión. . _Cuando hago 1 a 1, haré un registro simple y lo guardaré para la próxima revisión 1 a 1 y seguimiento.

Cultura de ingeniería

Para formar un equipo de lucha, una excelente cultura de ingeniería es esencial. ¿Qué es una excelente cultura de ingeniería? Eso es tener suficiente respeto por la calidad y los detalles del código, la prueba, el diseño, el producto y el resultado de todos estos ingenieros. Por qué se dice que una buena cultura del ingeniero es indispensable, lo explicaré a través de los siguientes puntos:

• Desde la perspectiva del desarrollo a largo plazo de los productos del equipo, solo asegurando una calidad excelente se puede garantizar que el producto tenga una iteración continua, eficiente y a largo plazo. Si el diseño es desordenado, la calidad del código es deficiente y no hay cobertura de prueba, la energía de todos se consumirá gradualmente en varios problemas de "producción segura". Poco a poco, la realización online de una demanda ha evolucionado de unas pocas horas a unos pocos días o incluso semanas.

• Solo un equipo con una excelente cultura de ingeniería puede atraer excelentes ingenieros. Excelentes ingenieros, sinceramente consideran la programación como un oficio y se enorgullecen de su oficio. Si el equipo de TL no cree que este sea un oficio del que debería estar orgulloso, todo el mundo considerará gradualmente las cosas como lo mismo que mover ladrillos, la diferencia es solo el nivel de salario. En tal atmósfera, la composición de talentos del equipo debe ser de segunda o incluso de tercera.

Construir una cultura de ingeniería es alentar a todos a hacer Revisión de código, escribir UT, hacer CI bien y compartir conocimientos. Estas cosas suenan fáciles, pero la parte difícil es cómo cumplirlas cuando el proyecto está bajo una gran presión. Además, es necesario reconocer la existencia de deuda técnica. Después de que el producto esté en línea por un período de tiempo, inevitablemente habrá muchas “soluciones temporales”. Como TL, es necesario crear espacio para el equipo y fomentar que se tomen tiempo para pagar la deuda técnica.

La cultura de la ingeniería es la base del equipo técnico, lo que permite que todos tengan una referencia correcta, lo que es correcto, lo que se debe aprender y lo que se debe observar. Podemos ver cuántos equipos que han perdido la cultura de la ingeniería evolucionaron hacia qué tipo de estado, escribiendo ppts que parecen ser iguales, todos los días el tirón empujará esto y aquello, y cuando encuentras problemas, no investigas los fundamentos y Descubrir los principios Es atraer grupos, formar reuniones, comunicarse ... Gradualmente, los talentos técnicos de dicho equipo se agotarán gradualmente y el resto seguirá sobreviviendo con sus habilidades no técnicas.

TL se dijo a sí mismo

Además de externamente, a menudo me digo a mí mismo:

• ser uno mismo

• Que no cunda el pánico！

• Se paciente

Sea fiel a sí mismo . Cada uno tiene sus propios rasgos de personalidad, aunque la personalidad de una persona cambiará debido a la experiencia de la vida, las cosas más esenciales de una persona no cambiarán en poco tiempo. O gentil y elegante, o estrechamente arrogante, o activo y diligente ... "No finjas ser verdad" es uno de mis valores favoritos en los valores de Ali. Es fácil fingir por un tiempo. Durante años para fingir ser una especie de persona estarás muy cansado. En segundo lugar, los compañeros no son tontos. Tarde o temprano verán la hipocresía. Una vez que un TL hace que las personas se sientan hipócritas, no hay forma de hablar sobre el establecimiento de la confianza. Por supuesto, el autoanálisis y conocerse a uno mismo no es un asunto sencillo, hay tantos libros sobre análisis psicológico y me gusta leer algunos en la oscuridad de la noche.

¡Que no cunda el pánico ! TL enfrentará una variedad de presiones, cambios en las metas, dificultad para lograrlas, evaluación del desempeño, conflictos entre personas y conflictos entre equipos. En este momento, todos están observando cómo los maneja. Bajo tanta presión, la reacción natural de las personas es la ansiedad o incluso el pánico. Sabemos que durante el ejercicio y el habla, la ansiedad excesiva puede provocar una deformación del movimiento, e incluso la imposibilidad de rendir a un nivel normal. En este estado, es más probable que TL haga juicios erróneos y la ansiedad grave se transmite fácilmente a todo el equipo. Cuanto más este tipo de momento, mejor podremos estabilizarnos y trabajar duro para hacer los juicios más razonables en condiciones limitadas. Debemos admitir que no importa cuán inteligentes y diligentes seamos, solo somos personas comunes, no superhéroes de Marvel.

Ten paciencia . Los programadores pueden ser el grupo de personas más impaciente. Cuando se escribe el código, se espera que la máquina dé retroalimentación primero, y luego se espera que la máquina dé retroalimentación inmediatamente. Sí, todavía hay un error. Todo debe ser claro y llanura. Pero cuando el rol de los programadores cambió a gerentes, todo cambió dramáticamente. Es posible que algunas personas recuerden las metas que promueve al equipo y otras no, los problemas que les señaló a sus compañeros de clase pueden no ser capaces de cambiar durante meses y medio, o él no quiere cambiar en absoluto; la cultura de ingeniería que se quiere construir en el equipo, parece que el progreso es muy lento, y está demasiado lejos de las expectativas. De hecho, todo esto es normal. El cerebro humano acepta y transforma información, a menos que sea información vital, de lo contrario la eficiencia es muy baja. Una persona ha acumulado décadas de patrón de comportamiento, incluso si realiza cambios sutiles. Mucho tiempo . Por lo tanto, no se moleste en decir información importante tres veces o más; y cuando señale amablemente el problema a sus compañeros de clase, no espere que la otra parte lo acepte y lo cambie de inmediato. Es normal que no lo haga. realizar cambios. Pero esta no es una razón para que no hagamos lo correcto. Si uno o dos de los diez compañeros de clase rompen algunos de sus propios cuellos de botella en sus carreras debido a su orientación, ya es un gran logro que TL puede lograr.

Otras lecturas

Yang Jiang tiene una oración que me gusta mucho. En una respuesta a los jóvenes estudiantes, escribió esta oración:

Su problema es principalmente que no lee mucho y piensa demasiado.

En mi opinión, lo que mucha gente ve hoy en su trabajo, las llamadas innovaciones, las llamadas ideas, es todo un alboroto por no estudiar mucho, sino pensar demasiado. Lo mismo es cierto para ser un líder técnico: la experiencia y el pensamiento son necesarios, pero si solo confía en su propio pensamiento y experiencia, a menudo tomará muchos desvíos o incluso irá por el camino equivocado. Así que te sugiero que leas algunos libros relacionados. Estos son algunos de los que he leído y recomiendo a todos.

• La "victoria" de Jack Welch : la eliminación final forzada 361 de Alibaba se puede aprender aquí

• "Cómo definir una empresa" de Google : el talento es esencial.

• "Drive " : además de utilizar el dinero, cómo motivar a las personas.

• "El secreto detrás de la puerta" : Por qué la comunicación 1 a 1 es tan importante y cómo hacerlo bien 1 a 1.

• "Comunicación no violenta" : Todo el mundo puede hablar bien, pero mucha gente no sabe hablar bien. Las personas que saben escuchar son aún más raras.

Sobre el Autor

Xu Xiaobin, autor de   "Maven in Action ", es responsable de la arquitectura de microservicios , la plataforma de aplicaciones nativas en la nube y sin servidor y otros trabajos relacionados en Ali.