Contenido
1. Período de prueba y pago de horas extras
2. Reclutamiento
3. Defensa mensual y defensa regular
4. Certificación de examen creíble
5. Persona de interfaz
6. Lista de problemas y defectos
7. Revisión del código
8. Desarrollo funcional
9. Viaje al extranjero
1. Período de prueba y pago de horas extras
El período de prueba generalmente dura de 3 a 6 meses y los salarios y bonificaciones se calculan de acuerdo con los estándares de los empleados regulares. La única diferencia es: los empleados en el período de prueba no pueden transferir horas extras a los fines de semana, lo que equivale a trabajar horas extras en vano. Por lo tanto, PL (Líder del programa) no pedirá a los empleados en período de prueba que trabajen horas extras los fines de semana a menos que estén más ocupados. Si tienen que trabajar horas extras, se les dará tiempo libre para salir por negocios.
Si trabajas horas extras ambos fines de semana, recibirás el doble de salario durante 4 días, lo que equivale a un aumento del 80% del salario base, que está cerca del doble. Por supuesto, este tipo de trabajo continuo de horas extras los fines de semana también consume mucha energía, no importa lo fuerte que sea tu cuerpo o lo joven que seas, al final debes admitir: tu vida está en juego. Hoy en día, las horas extras de fin de semana todavía se calculan como salario doble, pero no se pagarán el próximo mes, sino que se acumularán para usted y no se le pagarán de manera uniforme hasta que cambie su número de trabajo o renuncie una vez cada ocho años. . Además, las horas extras realizadas los fines de semana también requieren la aprobación del supervisor y ya no se calculan directamente en función del tiempo de registro.
2. Reclutamiento:
Cuando me gradué por primera vez, escuché que Huawei reclutaría estudiantes siempre que fueran 985/211 estudiantes y aprobaran el examen de programación, casi sin depender de su experiencia personal. Huawei establecerá un conjunto completo de sistemas y procesos basados en la desconfianza hacia los empleados para permitirles hacer bien su trabajo. Las personas que no puedan soportar la presión serán eliminadas, pero aquellos que puedan soportar la presión y seguir el sistema y los procedimientos podrán sobrevivir. Sobre esta base, las personas con un coeficiente intelectual e inteligencia emocional particularmente altos obtendrán dinero.
En Huawei, los empleados que no pertenecen a RR.HH. también tienen que participar en la contratación, lo que casi se ha convertido en una obligación para ellos en sus carreras en Huawei. Según el grupo de talentos existente, llamarán uno por uno para preguntarles sobre su disposición a trabajar y los guiarán para que respondan preguntas de entrevistas, programación en línea y participen en entrevistas individuales con entrevistadores.
El presupuesto de contratación almacenado no es suficiente, por lo que la contratación generalmente tiende a contratar empleados de OD/WX. El ID de empleado de OD comienza con 300 y el ID de WX comienza con WX. Ambos empleados no se consideran empleados regulares de Huawei. Entre ellos, los empleados de OD son relativamente mejores y se dedican principalmente al trabajo de desarrollo. Los empleados que comienzan con WX básicamente sólo pueden realizar trabajos de prueba. Siguen los documentos de prueba paso a paso y verifican si cumplen con las expectativas. La gran mayoría de los empleados de WX no saben por qué hacen esto y qué significan los resultados esperados, porque no calificado Al participar en el diseño y discusión de la solución, ningún TDE (Test Design Engineer, un empleado de Huawei responsable del diseño de casos de prueba) estuvo dispuesto a explicárselo.
Debido a la gran rotación de personal subcontratado, la tarea de contratación es muy pesada. Al mismo tiempo, tienden a contratar empleados de OD/WX, por lo que la contratación será muy difícil. En resumen: las personas capaces miran con desprecio a OD/WX y las personas incompetentes no pueden aprobar la programación en línea y otras evaluaciones.
3. Defensa mensual y defensa a tiempo completo
Durante el período de prueba, habrá una defensa mensual cada mes. Deberá hacer un PPT para describir en detalle lo que ha hecho y aprendido durante este mes y responder las preguntas de los jueces. en el instante. Cuando se convierte en empleado de tiempo completo, debe preparar una defensa y resumir el trabajo durante todo el período de prueba.
Durante el proceso de defensa los jueces te escucharán atentamente y después de pensarlo te harán algunas preguntas, este ambiente es bastante bueno. De hecho, la defensa no juega un papel particularmente importante en el rendimiento, porque todos pueden ver lo que haces habitualmente y estimar su peso.
El papel más importante de la defensa es evitar que los nuevos empleados sean holgazanes. Cuando un empleado ingresa a la empresa, habrá un breve período de tiempo antes de que esté completamente familiarizado con el proceso y se convierta en un empleado ocupado. En esta etapa, como no sabes nada, nadie acudirá a ti y nadie podrá asignarte tareas. En este momento, si sabes que necesitas informar sobre tu progreso laboral y de aprendizaje cada mes, tendrás suficiente motivación para integrarte al equipo lo antes posible. Después de completar la defensa para convertirse en un empleado de tiempo completo, usted es básicamente un tornillo estándar. En este momento, ya no necesita defenderse, simplemente puede motivarse a través de la evaluación del desempeño.
4. Certificación de examen de confianza
Para el desarrollo, todos deben aprobar el examen de confianza. El examen de credibilidad se divide en nivel profesional y nivel laboral. Hay cuatro cursos y cuatro exámenes en total. Muchas veces es más fácil para los nuevos empleados aprobar porque tienen más tiempo, mientras que los antiguos no tienen tiempo para estudiar y casi todos toman el examen. examen desnudo, excepto que la Materia 1 es programación en línea, y otras materias son conocimientos teóricos, que cubren el alcance de la sintaxis y las técnicas del lenguaje de programación, las especificaciones del lenguaje de programación, el análisis de requisitos, las líneas rojas de seguridad, los patrones de diseño, el desarrollo ágil, etc. Estas experiencias se resumen en un lenguaje conciso y se inculcan en el cerebro de cada empleado a través de la idea de promover la formación a través de exámenes.
5. Persona de interfaz
En realidad, pasan casi dos meses desde el momento de su incorporación a la empresa hasta la salida del mentor. La tarea más importante es aprobar el examen de certificación confiable. Después de dos meses, comencé a encargarme de algunas tareas simples, modificar el ticket de emisión o emprender algún desarrollo de funciones simples. Pero en algunos departamentos, a menudo se le asignará una tarea aterradora en este momento: la persona de interfaz.
En términos generales, un producto se dividirá en varios módulos y cada equipo mantendrá varios módulos. Cuando la prueba encuentra que un módulo que pertenece a un determinado grupo tiene un problema, o que las partes de otros módulos que dependen de este módulo no funcionan correctamente, necesitan que alguien les ayude a descubrir la causa. Esta persona se llama persona de interfaz. .
Hay alrededor de 10 personas en un equipo y la cantidad de código de módulo del que son responsables oscila entre decenas y millones de líneas. A primera vista, se podría pensar que como persona de interfaz se debería elegir a un empleado con experiencia, alguien que tenga un conocimiento claro de los módulos responsables del grupo, situaciones históricas, etc. Pero, de hecho, ayudar a otros a ver los problemas y encontrar las razones es un trabajo ingrato, porque los líderes no pueden verlo y los colegas que los rodean no pueden sentirlo.
En algunas empresas, el supervisor suele ser la persona de interfaz, realizará un análisis simple del problema y luego seleccionará a la persona adecuada para analizar el problema en función de las áreas de especialización y las condiciones de carga de los miembros del equipo. En Huawei, una posición similar es PL, por el bien del rendimiento, no pueden perder el tiempo en esto todos los días. Al mismo tiempo, todos los miembros del grupo están extremadamente ocupados y las personas más familiarizadas con el campo pueden estar completando tareas urgentes y no tener tiempo para analizar. Por lo tanto, PL generalmente encuentra colegas jóvenes en el grupo para que actúen como interfaces y los roten según un período fijo.
La cantidad de código mantenido por un grupo no es pequeña, dejar que los nuevos empleados sean personas de interfaz, se llama "ejercicio", pero en realidad es para permitirles resistir la presión. Como persona de interfaz, el requisito de PL es no molestar a otras personas del equipo tanto como sea posible. Todos los problemas, a menos que sean realmente errores, no se pueden someter a prueba. Tal solicitud puede parecer simple, pero los nuevos empleados muchas veces ni siquiera entienden lo que quieren decir cuando se trata de preguntas de prueba y consultoría. Además, existen varias razones históricas y circunstancias especiales en el diseño. Es confuso. ¿Quiere ayuda de un colega experimentado? Está bien si el proyecto no es demasiado estresante, pero cuando el proyecto se vuelve tenso y todos hablan por teléfono con los auriculares puestos, es posible que no los veas inactivos durante varias horas. Y la prueba tiene requisitos en cuanto a tu tiempo de respuesta. ¿Por qué no das una explicación clara en el plazo de una hora? Luego tome el conocimiento de embarque.
Por ejemplo: Estás analizando la causa del problema A y leyendo código completamente desconocido, y otras dos pruebas te dejan mensajes para consultarte sobre los problemas B y C. Escaneó brevemente las preguntas B y C. No son áreas con las que esté familiarizado. Se necesita tiempo para leer el código y comprender el diseño para saber si es un problema, por lo que no respondió por el momento. Dos minutos después te llamaron los dos testers respectivamente, estabas molesto y no quisiste contestar el teléfono, pero siguieron llamando y te dijeron en sus mensajes que harían el pedido si no contestabas el teléfono. Solo puede levantar el teléfono e intentar persuadirlos, decirles que ahora están muy ocupados y solo puede pedirles que se registren primero y esperen en la fila para saber de usted. No mucho después, leíste una parte de la lógica del código en la pregunta A que no podías entender y querías encontrar a alguien a quien preguntar. Cuando miraste hacia arriba, todos en el grupo estaban hablando por teléfono. Así que aprieta los dientes y confirma la lógica del caso de prueba con el probador de A, mientras ignora parte del código incomprensible para adivinar la lógica posterior. En este momento, las pruebas de B y C te dicen que no puedes esperar más. Los superiores te instan a que solicites el conocimiento de embarque. Solo puedes dejar el código temporalmente y explicar nuevamente, darles una oportunidad razonable. plazo y pedirles que lo acepten. De repente, el teléfono volvió a sonar. Era una llamada de conferencia. El problema era muy grave. Cuatro o cinco desarrolladores en línea estaban discutiendo el tema juntos y necesitaban su confirmación. TDE le instó a que echara un vistazo rápidamente. Si no está seguro, puede señalar fuera. Rápidamente escribe la pregunta A y, mientras lee el fenómeno de la pregunta D, responde estas preguntas de desarrollo según su comprensión. La pregunta D no es muy difícil, pero involucra muchas condiciones y variables, y la lógica es muy complicada. Tienes que resolverlo. Mientras lo haces, el TDE de la prueba A te dejó un mensaje enojado: Yo Lo he estado viendo durante dos horas, ¿por qué no ha salido todavía? Es necesario un conocimiento de embarque.
Si realmente no puede resolverlo y la prueba no puede esperar a recibir un conocimiento de embarque, normalmente tendrá que hablar con el PL. Pero como nuevo empleado, debes estar mentalmente preparado, porque inevitablemente te regañarán en este momento. Porque PL siempre está extremadamente ocupado. Tiene planes que discutir, diseños que hacer y muchas tareas dentro del grupo. Ya está abrumado. No solo no puedes ayudarlo a compartir la carga, sino que también le dices que sí. No entendía un problema existente y también estaba muy destrozado. Pero la reprimenda a menudo vale la pena, porque PL rápidamente le indicará la dirección, porque si el posicionamiento está mal, rápidamente corregirá su dirección.
6. Orden de problemas y defectos
El "conocimiento de embarque" mencionado muchas veces hace un momento se refiere a la orden de problemas. Las preguntas formuladas en la prueba generalmente indican que hay un error en el funcionamiento de un determinado módulo.
Para el seguimiento de pedidos problemáticos, Huawei cuenta con un sistema llamado DTS para probar el conocimiento de embarque, el proceso de desarrollo y resolución es aproximadamente el siguiente:
El empleado de subcontratación de pruebas crea un ticket de problema en el sistema DTS y completa el producto, la versión, la descripción del problema y otra información.
La hoja de problemas se envía al TDE de prueba (un empleado oficial de Huawei) responsable de este módulo para su revisión.
El TDE de prueba envía el ticket del problema al PL del grupo responsable del desarrollo del módulo.
Luego, el PL dentro del grupo envía el problema al equipo de desarrollo que necesita resolverlo.
El desarrollo resuelve el problema, envía el código, completa el análisis de la causa raíz y envía el ticket del problema al PL dentro del grupo.
Al mismo tiempo, el desarrollo debe concertar una cita con el TDE de prueba y comunicarle la causa del ticket del problema y el impacto de la modificación.
Una vez que se complete la discusión de PL dentro del grupo y la última compilación contenga el ID de confirmación desarrollado, el ticket de emisión se enviará al TDE de prueba.
El TDE de prueba envía el ticket del problema al empleado de subcontratación de pruebas para su verificación.
Después de seguir tal conjunto de procedimientos, siento como si me hubiera mudado de capas de piel. El líder superior no necesita conocer los detalles, solo necesita preguntar el número objetivo de tickets problemáticos para un grupo. Por ejemplo, hoy a todo el grupo le quedan 40 tickets de preguntas, mañana la solicitud es 35, y pasado mañana son 30...
Por lo tanto, para lograr el objetivo, PL estaba muy disgustado con la hoja de problemas que llegó a la cabeza de su grupo. Algunos tickets problemáticos implican la coordinación entre módulos. Al probar el conocimiento de embarque, el problema se encontró en el módulo A. Sin embargo, después de investigar el módulo A, se descubrió que el problema real radica en el módulo B, del cual depende el módulo A. Módulo B es administrado por otro grupo Mantenimiento, así que comuníquese con la persona de interfaz del módulo B. En este caso, incluso si se determina básicamente que el problema está en el módulo B, el PL y la gente de interfaz del módulo B intentarán por todos los medios retrasar el momento en que el ticket del problema se envíe al módulo B. Solo aceptarán el problema después de localizar la causa raíz del problema y modificar el plan, camine hasta el módulo B. Después de todo, ¿dónde está el objetivo de la hoja de problemas diarios y tener uno más en la cabeza es una carga pesada? En este momento, el PL del módulo A definitivamente no quiere que el problema esté en su propio grupo, por lo que ahora depende del PK entre los dos PL. Como PL, han estado trabajando en Huawei durante al menos varios años. y todos tienen sentimientos de camaradas, entiéndanse, déjenlo a ustedes esta vez, déjenmelo a mí la próxima y no se destrocen.
En este proceso, el paso que más disgusta a los desarrolladores es la conversación de prueba. La intención original de este diseño es buena: le preocupa que el impacto de sus cambios no se pruebe claramente, por lo que no podrá probar los escenarios afectados. Pero, lamentablemente, esta regulación es demasiado rígida y la mayoría de las conversaciones cruzadas no tienen sentido: solo es necesario realizar una prueba para reproducir la escena original y comprobar si el problema está resuelto.
El diseño del ticket de problema es tan complicado que aún muestra desconfianza hacia los empleados. En otras empresas, el proceso es mucho más sencillo:
Cree un ticket de prueba y complete el producto, la versión, la descripción del problema y otra información.
Los tickets de emisión se envían a los desarrolladores que necesitan resolver el problema.
El desarrollo resuelve el problema, envía el código, completa el análisis de la causa raíz y los escenarios que requieren pruebas clave y transfiere el pedido nuevamente a las pruebas para su verificación.
La simplificación de los pasos requiere una alta calidad de los empleados. Tomemos como ejemplo la interacción entre las hojas de problemas y las pruebas. Generalmente, los desarrolladores sienten que el impacto de este cambio es relativamente grande. Cuando necesiten concentrarse en probar algunos escenarios, lo indicarán en las hojas de problemas; de manera similar, si el evaluador conoce los cambios del desarrollador que son riesgosos, o si no comprende el análisis de la causa raíz del desarrollador, también tomará la iniciativa de comunicarse con el desarrollador.
El proceso de Huawei es complejo y su lógica básica es: confiar en empleados antiguos como DE/TDE que han trabajado en Huawei durante mucho tiempo, y los nuevos empleados no son dignos de confianza. Los incentivos de apoyo también tienden a ser PL/DE/TDE, lo que hará que los nuevos empleados se sientan frustrados, pero no importa, porque siempre habrá un grupo de personas que pueden soportar la frustración y están dispuestas a seguir las reglas y sigue trabajando duro.
El complejo proceso ha llevado a un problema: las pruebas de TDE están increíblemente ocupadas. Debido a que un TDE de prueba a menudo es responsable de múltiples módulos, es decir, correspondientes a múltiples desarrolladores, cuando hay muchos tickets de problemas, es fácil formar un cuello de botella de un solo punto. Por ejemplo, supongamos que un TDE tiene 10 empleados de pruebas subcontratados y se detectan 10 problemas respectivamente. Estos 10 problemas corresponden a 8 desarrolladores. Después de que estos 8 desarrolladores solucionen los problemas, se pondrán en contacto con los empleados de pruebas subcontratados. Las conversaciones cruzadas no cuentan. y el TDE debe hacer cola para las conversaciones cruzadas, formando así un cuello de botella de un solo punto.
Estaba tan ocupado probando TDE que no pude encontrar nada que hacer, por lo que, naturalmente, mi temperamento no era muy bueno. Los desarrolladores no se atreven a ofender a los evaluadores en absoluto. Si TDE no está satisfecho con usted, si no dice nada más, solo lo criticará en la discusión o pondrá fin a la discusión, lo que ralentizará enormemente la discusión. tu progreso en el trabajo y entusiasmo.
7. Revisión de código
Revisión de código, también conocida como Revisión de código. Después de que cada desarrollador escribe el código, debe enviarlo para su revisión antes de fusionarlo en la rama principal.
En otras empresas, los desarrolladores suelen buscar dos desarrolladores que estén más familiarizados con este campo para revisarlos y, después de obtener dos Aprobaciones, se fusionan fácilmente.
En Huawei, la integración de código requiere teóricamente los siguientes pasos:
Seleccione dos
vistas de desarrollo. Una vez aprobada la revisión, seleccione un confirmador para
la revisión. Una vez aprobada la revisión, seleccione una persona con permisos de fusión para fusionar.
Generalmente, un comprometidor es un empleado senior de un equipo, tiene fuertes habilidades y trabaja con cuidado y conciencia.
En otras empresas, los pasos de integración del código se simplifican para:
Seleccione una revisión de desarrollo
. Después de pasar la revisión, busque un confirmador para revisar y revisar antes de fusionarse.
El número de Comprometidos es muy pequeño y representa alrededor del 20%. Si 100 personas quieren integrarse en el código, deben encontrar a estas 20 personas para revisar el código. Estas personas son básicamente DE (Ingeniero de Diseño), responsables principalmente de tareas como el diseño de programas y la resolución de problemas difíciles, al mismo tiempo que también ayudan a un gran número de compañeros a revisar el código. Entonces la mayoría de ellos están demasiado ocupados para encontrar a Bei.
Por un lado, estos Committers son responsables del trabajo que es beneficioso para su futuro en proyectos como el diseño de soluciones. Por otro lado, revisan el código de todos. Si hay algún problema, se les explicará pacientemente (si no). Si no lo explica claramente, no será aprobado), por lo que el progreso será rápido. La mayoría de los nuevos empleados son solo ejecutores y no tienen idea del plan general, los principios básicos, etc. Es imposible para ellos pedirle al Committer que les explique con paciencia. Solo pueden aprender algo al revisar el código, pero también es poco a poco. .de.
Desde entonces, la brecha entre los nuevos empleados y los antiguos empleados (Committers) se ha ampliado. El resultado final es una brecha en el conocimiento. Los nuevos empleados se pierden fácilmente porque sólo pueden estudiar por su cuenta después de un trabajo tedioso. Los empleados antiguos no tienen tiempo para enseñarles; al mismo tiempo, reciben relativamente pocos incentivos a menos que trabajen duro para ascender a la posición de Commiter ubicación, de lo contrario el desarrollo futuro será escaso.
8. Desarrollo funcional
Cuando surge un requisito, es necesario evaluar el tiempo para completarlo. Pero esto es sólo una referencia: cada nivel encontrará formas de acortar el tiempo. Como resultado, es casi una tarea imposible alcanzar el nivel de desarrollador.
Por ejemplo, para una tarea, se estima que el desarrollo y las pruebas involucradas en el diseño toman 12+4 días, y el requisito de versión es 10+3 días, sin embargo, cuando la tarea realmente se asigna al desarrollo y las pruebas involucradas en el implementación, es posible que solo queden 6 días +1,5 días.
¿A dónde se fue el tiempo intermedio? De arriba a abajo, los líderes de todos los niveles están preocupados por no completar sus tareas, por lo que quieren reservar un poco de margen. Así, el tiempo pasa de 10+3 días al nivel inferior a 8+2,5 días, y gradualmente desciende hasta 6+1,5 días. Por tanto, el desarrollo de funciones es sumamente urgente y es casi imposible completarlo en el tiempo señalado.
Al principio estaré muy ansioso porque no puedo completar la tarea. Luego descubrí que nadie podía completarlo y la portería fue colocada allí como adorno, aunque comencé a apresurar la portería cuando se acercaba el momento, de hecho, no importaba si no podía terminarla. Sin embargo, la persona que te insta tiene un resultado final en su corazón, este resultado final es la solicitud que le hicieron sus superiores, pero nunca te lo dirá.
9. Ir al extranjero
. Ir al extranjero generalmente se refiere a ir a la primera línea para vender productos Huawei en el extranjero. Hay muchos lugares para elegir, en casi todo el mundo. Pero si se eligen países con buenas condiciones en Europa, los subsidios son muy pequeños. Si se eligen países de África con malas condiciones, los subsidios son muy poderosos.
Hay una cuota para la cantidad de personas que necesitan viajar al extranjero cada año y casi todos los equipos necesitan enviar a alguien. Excepto por un número muy pequeño de amigos que están dispuestos a abandonar a sus familias e hijos para trabajar en el extranjero, la gran mayoría de la gente no está dispuesta a ir. Por lo tanto, pedirle que se vaya al extranjero es similar a obligarlo a dimitir: es básicamente una forma de eliminar personas.
Huawei también cuenta con empleados relativamente experimentados a quienes se les pide que vayan al extranjero. Aunque no son tan trabajadores como los Comprometidos, han acumulado mucho conocimiento en aproximadamente cinco años y pueden considerarse empleados clave. Desafortunadamente, debido a esta regla rígida, tuve que optar por dejar el puesto de desarrollo.
Estos empleados que han trabajado durante unos cinco años deberían estar muy familiarizados con los módulos en los que han trabajado. Fue necesario mucho esfuerzo para alcanzar este nivel y adaptarse a la intensidad de trabajo de Huawei. Debería ser el mejor momento para brillar, pero Huawei les pidió que fueran al extranjero y reclutaran nuevos empleados para pasar por el doloroso proceso de aprendizaje y adaptación.
De hecho, el conocimiento de estos desarrolladores no es muy útil para las ventas en el extranjero: usted domina un determinado módulo en el producto del que es responsable su grupo, que contiene cientos de estructuras y miles de campos. Puede comprender cada uno de los significados de los campos. y por qué fueron diseñados. ¿así que lo que? ¿así que lo que? En el momento de la venta, el cliente no está interesado. Para el contenido que interesa a los clientes, aún debe participar en la capacitación en ventas como un recién llegado, entonces, ¿por qué no dejar que el recién llegado haga las ventas?