Formación de ingenieros de Alibaba: ¿Cómo cuantificar el KPI del personal técnico?

Prefacio

Para los técnicos, la tecnología es el "núcleo" del crecimiento. Sin embargo, en la colaboración laboral real, la importancia de la tecnología a menudo se ve eclipsada por los negocios, lo que provoca el fenómeno de los negocios primero y luego la tecnología. Exploren y comuniquen juntos.

¿Por qué necesitamos KPI técnicos?

En el equipo técnico empresarial, hay una mala tendencia de que el equipo está consiguiendo más y más negocios, cada vez menos técnicos. Todo el mundo habla de negocios, la conferencia de tecnología habla de negocios, la reunión semanal es de negocios y el informe semanal es de proyectos comerciales ...

Lo único que rara vez se discute es la tecnología en sí. Esto no quiere decir que el negocio no sea importante, sino que comprender el negocio y controlar las necesidades del negocio es la base del personal técnico, no todo.

Pagará

Esta falta de gusto técnico es una lástima para el equipo técnico, y no favorece el crecimiento y desarrollo del personal técnico. Porque es difícil imaginar que un equipo sin objetivos técnicos pueda desarrollar un sistema robusto, fácil de mantener y escalable. Por el contrario, este tipo de apilamiento de códigos comerciales puede ser "más rápido" para lograr las necesidades comerciales a corto plazo, pero a la larga, el aumento de este tipo de sistema defectuoso obstaculizará enormemente el desarrollo del negocio, formando una aplicación de agujero negro. Y los ingenieros están atrapados entre las necesidades comerciales y los malos sistemas, exhaustos y exhaustos.

Esto conducirá a la corrupción del sistema y a una mayor deuda técnica, que consumirá toda su energía como un tumor.

No soy un dios de la medicina, y solo puedo intentar ofrecer una fiesta, es decir, sin afectar el negocio (especialmente un negocio relativamente estable, rechace la inversión de tiempo del lado comercial), Tech Story debería ser tan importante como User Story Es necesario abordar la refactorización y la optimización como una prioridad igual a las necesidades del negocio. No solo somos responsables de las necesidades comerciales, sino también de la calidad de la aplicación y el mantenimiento del sistema.

Debido a que nuestros técnicos son padres de solicitud (algunos son padres biológicos, otros son padres adoptivos), si no los cuidas o los tratas, se enfermarán, ¿soportas ver tal situación?

La negligencia del director técnico (TL)

Para esta situación, nuestros responsables técnicos y nuestro TL deben asumir la principal responsabilidad. Si un TL nunca presta atención a la arquitectura y el diseño del sistema, nunca escribe código, no tiene entusiasmo por la tecnología y no aprende, e incluso su propia tecnología es mala, entonces ¿cómo puede el equipo técnico bajo la dirección de este TL tener un gusto técnico? ¿Cómo pueden progresar y crecer los miembros?

Hoy en día, muchos TL se mezclan en varias reuniones todos los días, muy ocupados, haciendo varias cosas de comunicación y coordinación, pero ¿realmente necesitamos tantas reuniones y tanta comunicación?

Si el resultado de la comunicación es solo el negocio y la comunicación de PD al equipo, no hay innovación comercial, no se utilizan tecnología ni datos para resolver sistemáticamente los problemas comerciales, no hay dirección técnica y orientación de arquitectura para el equipo, y no hay ayuda práctica en la optimización del sistema. El equipo mejora la eficiencia ¿Qué valor aporta esta comunicación al negocio y qué valor aporta al equipo? Simplemente cálmate y lee más libros, incluso libros no técnicos. Escriba más código, incluso código que no tenga nada que ver con los negocios.

Por tanto, tenemos que volver a la tecnología en sí. No necesitamos tantos gerentes técnicos de "alto nivel" y "mundo señalador", pero debemos ser capaces de profundizar realmente en el sistema, entrar en los detalles del código y traer cambios reales al equipo.

Cuantificación de KPI técnicos

Mejorar la atmósfera técnica y construir una cultura de ingenieros no solo puede ser verbal, sino que puede combinarse con ciertos medios obligatorios, como vincular los intereses de los técnicos. Esta vinculación requiere que podamos realizar una descomposición y cuantificación relativamente equitativas de las contribuciones técnicas.

KPI técnico

Con base en esto, descompongo el KPI del personal técnico en tres partes principales: contribución comercial, contribución técnica y contribución del equipo. Los detalles son los siguientes.
● 业务贡献: Incluye control de demanda, proyectos empresariales e innovación empresarial.
● 技术贡献: Incluyendo refactorización del diseño, influencia técnica, revisión de código, mejora de la innovación y la eficiencia y calidad del código.
● 团队贡献: Incluyendo contratación, formación de recién llegados y ambiente de equipo.
Entonces, ¿cómo entendemos estas dimensiones de la contribución técnica? No voy a decir mucho sobre la explicación. Usemos algunos casos en nuestro trabajo para describirlo.

应用质量：

1. La puntuación de calidad de la aplicación de la que es responsable o conjuntamente responsable (se puede investigar a partir de las dimensiones de la tasa de repetición del código, la complejidad ciclomática y la racionalidad de las capas).
2. ¿Qué trabajo ha hecho para mejorar la calidad de la aplicación?

Refactorización de diseño:

1. En el proyecto de comunicación con el cliente, modelé y diseñé el dominio de ventas CRM con una abstracción razonable.
2. Descubrí que la clasificación de paquetes en Infraestructura no era razonable, así que la rediseñé y refactoré.
3. Descubrí que los códigos de error en el sistema son bastante confusos, resolví una nueva especificación de código de error y completé la reconstrucción del código.

Influencia técnica:

1. Comparte 10 productos secos en el equipo, con 1000 me gusta.
2. El equipo compartió el modelo de estrategia, que fue bien recibido por los estudiantes.
3. Acepté la invitación y compartí la arquitectura SOFA en la conferencia de la industria.

Revisión de código:

1. Cuando revisé el código de XX, descubrí que puede haber un peligro oculto de inseguridad en el hilo.
2. Cuando estaba revisando el código de XX, encontré que había un diseño irrazonable, el uso de la cadena de responsabilidad aquí puede resolver el problema con elegancia y tiene un cierto grado de escalabilidad.

Innovación y eficiencia:

1. Descubrí que iniciar PandoraBoot para pruebas locales es una pérdida de tiempo, así que escribí un TestCon-tainer para mejorar en gran medida la eficiencia de la autoprueba.
2. Descubrí que hay algunos códigos repetitivos que no necesitan escribirse, por lo que se lleva a cabo el soporte de anotaciones para el bloqueo optimista y la paginación, lo que simplifica el código.
3. En cierto proyecto o punto técnico, realicé una patente: configuración empresarial basada en modelo de dominio.

Calidad del código:

1. La cantidad de errores después de la prueba, la cantidad de fallas en línea (el sistema puede extraerlo, no es necesario que lo complete)
2. He perfeccionado la prueba unitaria del módulo XX y he encontrado problemas en la regresión automática muchas veces.

Preguntas y respuestas sobre KPI

La mayoría de los estudiantes técnicos están de acuerdo con los KPI anteriores. Por supuesto, hay muchas dudas. Aquí elegiré algunas respuestas típicas.

P: ¿Los KPI técnicos harán que los estudiantes técnicos se concentren solo en la tecnología y no realicen proyectos comerciales?
R: En cuanto al desempeño, debe ser una mirada integral a la contribución empresarial, la contribución técnica y la contribución del equipo. Pero como referencia importante y veleta, los KPI técnicos son positivos.
P: ¿Cómo cuantifica la reconstrucción de su diseño?
R: Esto es difícil de estandarizar con el sistema y más depende de la capacidad profesional de TL para puntuar, pero aun así, es mejor que nada antes. Al menos al transmitir un mensaje, fomentamos el buen diseño y la refactorización y optimización continuas.
P: Nuestras necesidades comerciales actuales ya se están acumulando y los estudiantes de primera línea no tienen tiempo para refactorizar y optimizar.
R: De hecho, esta pregunta ya se dijo al principio. ¿Quiere seguir atascado en los requisitos comerciales y el código incorrecto, o tomarse el tiempo para mejorar y respaldar el negocio más rápido? Esta compensación no debería ser difícil de hacer, la clave es mirar la determinación y la capacidad. Para muchas empresas, no he visto escenarios comerciales que afecten el panorama empresarial después de unos días de posposición. Por lo tanto, como equipo técnico, debemos agregar nuestra Historia técnica a la Historia de usuario para completar los requisitos comerciales y refactorizar el sistema. Como nuestra misión principal