Cada líder de equipo tiene su propio cementerio de empleados con errores de gestión. Todos los días se publican nuevos artículos: "5 errores de un desarrollador novato", "7 ejemplos de cómo no es necesario administrar los procesos", "100 y 1 forma de cumplir con los plazos". ¡Y esto es asombroso!
El rastrillo de otra persona te ahorra tiempo, te pone audaz, te palmea el hombro y deja en claro que no eres el único que "me hizo", y todo esto pasó.
Un error según Ozhegov es una incorrección en los pensamientos o acciones, y, posiblemente, al mismo tiempo. Pero, ¿cómo puede un novato con una nueva gama de responsabilidades prescindir de ellas? Quizás nada, pero puedes intentar suavizar los golpes. En mi ejemplo, hablaré sobre esos errores que no pude evitar en el proceso de convertirme en líder. Espero que cada historia te sonría, porque te recordarás en infancia al comienzo de tu viaje, o te hará pensar en cómo evitar pisar un rastrillo tú mismo.
Antecedentes
Los últimos 6 años he dedicado pruebas, cambiando varias compañías y equipos para obtener un conocimiento relevante y confiable sobre cómo crear un producto de calidad y qué papel pueden desempeñar los probadores e ingenieros en este proceso. A veces, la razón para irse fue la falta de la oportunidad de aprender de colegas fuertes de probadores (y esto es necesario al comienzo del camino), porque simplemente no existían. Probé mi fuerza tanto en pruebas manuales como automáticas. Y fue precisamente después de que introduje la automatización que tuve la oportunidad de probarme como probador principal con un entrenador ágil experimentado.
Para mí, es como si el mundo se volcara en ese momento. El hábito de proponer soluciones e implementarlas independientemente se fortaleció y no quería dejarme. Resultó que el estilo de trabajo del ingeniero de automatización no encaja con el nuevo papel del líder de un pequeño grupo de personas. Pasemos a los detalles.
Errores
Gerente No. 1 "Aquí y ahora"
Fui mejor resolviendo problemas puntuales "aquí y ahora", pero esto no siempre acerca al equipo a su objetivo declarado.
Considera un ejemplo. Al comienzo de la formación del nuevo formato de control de calidad en Dodo, después de conocer cómo se organizan las pruebas y el deseo de todos de comenzar la automatización ayer, decidí que debería iniciarse en el futuro cercano. (La forma en que cambiamos los procesos se puede encontrar en el informe "Alicia en el país de control de calidad" ). Todos realmente queríamos salvar a los muchachos de la rutina diaria de las pruebas de regresión manual en 9 países.
Siguiendo el principio de "resolver problemas aquí y ahora", organizamos una reunión con los evaluadores, elaboramos un mapa de acciones, establecimos prioridades, asignamos tiempo para que cada evaluador se automatice y establecimos la implementación de tareas desde el mapa. En primer lugar, decidimos sobre la herramienta y presentamos nuestro plan para acelerar la regresión en la reunión general de TI. Los probadores se regocijaron con las pruebas que aparecieron y creyeron en una eliminación temprana de la rutina manual.
Sin embargo, resultó que cubrimos con pruebas lo que consumió mucho tiempo del probador, pero al mismo tiempo prácticamente nunca fue modificado por los desarrolladores y tuvo poco efecto en los procesos comerciales.
Que hacer Consejos de tapa
Para comprender el problema más profundamente, buscar causas, no consecuencias. Es muy probable que sus expectativas de que los evaluadores sean el principal almacén de conocimiento sobre el sistema desde el punto de vista del usuario, estén exageradas. Vale la pena llamar a varios representantes de la compañía de TI a las primeras reuniones, pidiendo ayuda para facilitar la reunión con el scrum-master, habiendo discutido previamente con él qué resultado le gustaría recibir.
N. ° 2 Gerente "Ingeniero experimentado"
Mi segundo archivo es el "límite" de un ingeniero experimentado. Todas las tareas más difíciles vinieron a mí.
La formación de PageObject, la implementación del conjunto básico de métodos para trabajar con nuestro sistema, los scripts de lanzamiento en CI / CD. Decidí tomarlo por costumbre. No comencé a delegar la comunicación con equipos de productos, ingenieros de infraestructura, entrevistas y textos de vacantes. Según el mentor, nuestro equipo de control de calidad era "verde" (recién llegados) en todos los sentidos. Por supuesto, decidí primero educar a los muchachos lo que yo sé, observando su trabajo para compartir mis tareas con el tiempo.
El problema es que con la cantidad de reuniones (reuniones generales, reuniones de equipo, capacitación interna, 1 y 1, entrevistas, días de prueba) que cayeron sobre mis hombros, dejé de trabajar en mis horas de trabajo. Ocho horas al día no eran suficientes, y comencé a compensar esto con mi tiempo libre, que dedicaba a la codificación, los textos y la preparación para entrevistas con los candidatos. El resto del precioso reloj que pasé con los chicos en conjunto con el objetivo de entrenar y el desarrollo gradual del proyecto con pruebas automáticas. Mi cambio de contexto cada hora o dos nos retrasó en todos los frentes: automatización, comunicaciones de control de calidad con comandos y más. La baja tasa de formación de ingenieros de control de calidad y la automatización de procesos me llevaron a trabajar el fin de semana para hacer un plan de cinco años en un par de meses.
Que hacer Consejos de tapa
No tengas miedo de delegar tareas. Todo el mundo tiene derecho a cometer un error y no debe eliminarlo, sin importar cómo esté hipnotizado por los líderes de otros equipos o el mentor. Tus propios chicos deberían querer confiar en ti y seguirte, siempre experimentar. Reúnase, determine cuáles de los procesos pueden mejorarse, cuáles de los muchachos están listos para promoverlos, y tal vez algunos de ellos puedan transferirse fuera de su equipo. Un facilitador experimentado ayudará a garantizar que las soluciones elegidas juntas no sean solo en papel. Un equipo eficaz e independiente es lo que cada líder debe luchar.
Gerente No. 3 "El reverso de la microgestión"
Otro error es a menudo la microgestión. Tuve que enfrentar su otro lado: control estricto implícito.
Intentando evitar monitorear cada paso de los niños y limitar el frente del trabajo, comencé a "imponer" las posibilidades "ilimitadas" a los niños: planes de desarrollo, tareas de investigación, discursos, cursos, organización de reuniones, visitas a otras empresas y otras actividades. Buenas intenciones: entrenamiento, habilidades de bombeo y perfeccionamiento, ampliación de los horizontes, nuevas relaciones en el ámbito profesional. Esto es todo lo que me faltaba cuando comencé a trabajar como probador. El problema es que el equipo quiere el derecho a elegir: hablar o no, mirar o no, pero los conduje a un marco estricto.
- Chicos, estamos haciendo un mitap. Necesitamos los siguientes roles, regalos, habrá tales oradores. Sin su ayuda, no podemos hacer un evento memorable.
- Chicos, en diciembre habrá Heisenbug. Ya pedí una transmisión en línea para nosotros, reservé una sala de reuniones, y el sábado transmitiré desde la computadora de mi casa. Todo para?
- Chicos, esta semana vamos a visitar Odnoklassniki para conocer cómo se construye la automatización.
Estas oportunidades se percibieron como limitaciones, lo que a todos no les gusta. Mi iniciativa parecía indiscutible y, lo más importante, no fue tan efectiva como se esperaba.
Que hacer Consejos de tapa
El cuidado excesivo del niño lleva al hecho de que crece infantil o comienza a hacer lo contrario a pesar de los padres. Parece que lo mismo se puede decir sobre el cuidado del líder sobre su equipo. Motivar, no forzar, reunir un tema sobre el tema "¿Cómo podemos ampliar nuestros horizontes en TI?" y escuche atentamente a sus colegas, no comience desde el umbral para nombrar todas las formas que conoce. Y lo más importante, no corras detrás de tus colegas con una propuesta para hablar en una conferencia y llegar a una clase magistral interesante. Anuncie la oportunidad, eso será suficiente.
No. 4 Gerente "En todas partes lo hicieron"
Quizás algunas de las soluciones que trabajaron para usted anteriormente en otro equipo / compañía no encontrarán soporte en las nuevas condiciones y la idea de un colega que esté lejos del campo de las pruebas de software, pero que tenga un desarrollo genial. El argumento de que su decisión fue respaldada y continúa desarrollándose activamente sobre la base de la comunidad es poco probable que convenza a alguien de hacer lo mismo, pero en la pila de tecnología local.
Que hacer Consejos de tapa
Lo principal es no comenzar a oprimirse por el hecho de que sus habilidades y conocimientos profesionales se cuestionan y no se tienen en cuenta al tomar decisiones. Busque argumentos valiosos que encuentren el apoyo del equipo o esté de acuerdo con el equipo.
№5 Gerente "Histérico"
Un mentor juega un papel importante en el proceso de convertirse en usted como profesional / maestro de su oficio. Pero hay una advertencia, su percepción de la ayuda de un mentor. Si entre ustedes desconfían el uno del otro, es poco probable que el efecto de las actividades conjuntas complazca al equipo y a todos los que lo rodean.
Consejos, recomendaciones, enfatizando las fortalezas y debilidades de las decisiones tomadas: este es el principal valor de trabajar con un maestro para mí. Sin embargo, los entrenadores a menudo usan un formato de entrenamiento diferente: organizan una situación difícil para usted sin previo aviso, por ejemplo, un conflicto en un equipo basado en una elección de tecnologías, se lavan las manos y observan sus acciones. Para mí, todo terminó con el hecho de que el proyecto con pruebas automáticas se convirtió en responsabilidad de los equipos de desarrollo debido al alto umbral de entrada en el que insistió el entrenador. Esta alineación se adapta a todos, y no tendría sentido continuar la batalla por la simplicidad.
Que hacer Consejos de tapa
Será importante aprender este momento: gritos, tirar papeles, borrar el código del otro, la presentación de usted y el mentor de diferentes visiones de la estrategia y los pasos tácticos, las lágrimas no ayudarán. Por lo tanto, solo arrastra el proceso de acercarse a la meta, y tal vez retrocederá constantemente, porque tendrá miedo de tratar, sentarse en el mismo piso, dudar de la solidez de sus ideas. Trate de no tomar decisiones rápidas, descubra por qué el entrenador necesitaba este conflicto, por qué es débil y cómo resolver la situación sin explotar por nada.
Para resumir
Arriba, describí 5 puntos de gestión débil de un ingeniero de automatización experimentado. Puede encontrar las dificultades descritas anteriormente, y qué tan exitosa será su batalla y cuán unido y fuerte su equipo dependerá de su preparación y carácter. Mi historia terminó con el logro del objetivo.
Los probadores ahora son parte de los equipos de desarrollo, los muchachos son muy independientes y pueden tomar decisiones sobre la implementación técnica, la cooperación con otros equipos. Escriben guiones por su cuenta, seleccionan nuevos evaluadores, mantienen mitaps y mucho, mucho más. Sí, fuimos a esto durante más de un año, pero nadie prometió que administrar personas es fácil.