En el artículo, hablaré sobre mi experiencia como líder de equipo en una empresa de desarrollo de sitios. Para que sea más útil y más fácil de leer para todos, el artículo está dividido en capítulos, cada uno de los cuales trata sobre un problema separado y su solución. Aunque, si es posible, se preservará la cronología de los eventos.
Espero que la experiencia que se describe a continuación se convierta en el rastrillo de otra persona, y en los comentarios, yo mismo extraeré algo de colegas más experimentados.
Pero no hay nombres, empresas, clientes, nombres de colegas. Acuerdo de no divulgación, todas las cosas.
Antecedentes ¿Cómo y dónde me convertí en líder de equipo?
Esta es la primera compañía en la que vine inmediatamente con un líder de equipo. Para mí fue un salto cuántico en términos de crecimiento profesional. Llegué al último trabajo (1,5 años) como intermediario y crecí allí hasta el último año. Pero las gradaciones de los desarrolladores son demasiado subjetivas y, a menudo, dependen solo de la empresa donde trabajan. Durante un tiempo estudié mucho la cuestión de evaluar a los programadores y, básicamente, todo se redujo al hecho de que si "tomaron el nivel medio / superior / superior, me convertí en medio / superior / superior". Cuando comencé a buscar trabajo, habría tenido suficiente de una posición superior (y lo estaba buscando), pero la oferta de timidismo me superó y me sentí un poco halagado.
En realidad, cuando buscaba vacantes, el segundo día me atrajeron a una empresa metropolitana que desarrolla sitios en Bitrix (de modo que todo sucede en el contexto del desarrollo de sitios en Bitrix). Por el contrario, durante mucho tiempo soñé con dejar Bitrix, pero la oportunidad de cumplir mi potencial con una nueva calidad y un buen salario no me dejó ninguna posibilidad de rechazar.
Dato curioso: la única condición para contratarme era que yo mismo pudiera elegir la pila tecnológica, pero en ningún caso debería rechazar Bitrix si el cliente insiste en ello.
En un nuevo lugar
En el nuevo lugar había un muy buen jefe técnico, un gerente pobre, junio, medio y varios proyectos realmente grandes en Bitrix. Es una situación bastante extraña y todavía no entiendo cómo se desarrolló y no colapsó de inmediato. Pero tal vez me invitaron solo para poner las cosas en marcha.
En los primeros días, muchos problemas "infantiles" fueron sorprendentes:
- La información del proyecto se almacenó en la cabeza de una o dos personas y en ningún otro lugar. Tampoco había instrucciones y documentación, y para descubrir cómo funcionaba esto o aquello, era necesario torturar a quien lo hizo, si es que lo creamos.
- no existían sistemas y procesos establecidos, todo se hizo "de alguna manera", "por costumbre". Por lo tanto, vanidad, confusión, incumplimiento de los plazos, estrés.
- las tareas fueron consideradas en palabras. Los rastreadores solo tenían los nombres de las tareas, solo para poder reservar tiempo en algún lugar (había que escribir 40 horas a la semana)
- el desarrollo en sí tampoco fue tan bueno:
- en algún lugar, algo se estaba desarrollando incluso fuera del gita
- En algún lugar, los programadores se turnaban para editar archivos en un servidor
- en algún lugar había sitios de prueba, pero en otro lugar no estaban (pero en cualquier caso no ayudaron mucho)
- Además, en todas partes había un muy, muy govnokod. Anticipando los comentarios, el propio Bitrix, desafortunadamente, no tiene nada que ver con eso.
- Toda la comunicación tuvo lugar en Skype. Pero solo tengo una aversión personal por él
En general, todo es obviamente malo, las mejoras pueden comenzar de inmediato, sin realizar estudios preliminares. Esto incluso me hizo feliz hasta cierto punto, ya que puedes influir en los indicadores desde los primeros meses. Realmente aún no se han considerado, pero debido a Pareto, esto aún no es importante.
Para mi decepción, los procesos se movieron bastante lentamente durante los primeros meses. En primer lugar, tuve que trabajar en las tareas del cliente durante 8 horas al día, como programador, porque simplemente no tenía suficientes manos. En segundo lugar, en las condiciones de tal presión de tiempo, era bastante peligroso hacer grandes cambios que pudieran generar confusión y pérdida de código o tiempo.
Ahora vamos directamente al artículo y a la resolución de problemas. Lo primero en la nueva compañía era orientarse de alguna manera.
Extraer información de los objetivos de los empleados.
Cuando llegué, no sabía absolutamente nada sobre proyectos o clientes, y esta información no se almacenó.
en ninguna parte en forma de texto. Por lo tanto, lo primero que comencé a extraer información de los objetivos de los colegas en los textos.
Esencialmente, una empresa de desarrollo tiene 2 grandes subconjuntos de textos importantes y / o útiles:
- instrucciones, reglamentos, artículos, descripciones funcionales, historias de usuarios, ...
- Tareas con su nombre, descripción, comentarios, registros de tiempo, firmas para confirmar, comentarios en el código, autotest, ...
Al principio, solo pedí a mis nuevos colegas que escribieran para mí cosas específicas del primer párrafo, pero, por supuesto, todos eran vagos, especialmente porque escribir instrucciones no es una característica para cortar. Pero como al principio todavía tenía un aspecto completamente para no fumadores y tuve que estudiar los proyectos, viéndolos por primera vez, comencé a traducir mi investigación en texto, creando así instrucciones y descripciones de la funcionalidad.
También fue una suerte que, al mismo tiempo, la compañía comenzó a moverse activamente hacia scrum (solo una coincidencia), el software de trabajo estaba cambiando (también una coincidencia), respectivamente, los procesos comerciales se crearon desde cero. Y por alguna razón, inicialmente tenía una gran autoridad a los ojos de mis colegas. Por lo tanto, comencé a escribir las reglas yo mismo (dentro de la competencia) y reconstruir a los chicos sobre ellas, es decir, solo dictar las reglas y ser un ejemplo de su implementación.
La solución al problema con la formulación y gestión de tareas se retrasó más de un mes. Esto resultó ser un cuello de botella y en los capítulos siguientes plantearé este tema más de una vez.
Al comienzo de mi trabajo, el gerente estableció tareas terriblemente. Ejemplo: el nombre de la tarea es "Solucionar el error en el sitio" y eso es todo: sin descripción, sin capturas de pantalla, solo el nombre y la referencia al proyecto. Por supuesto, hubo intentos de transmitir los principios de SMART y la importancia de describir las tareas al gerente, pero todos los compromisos se desglosaron en "No tengo tiempo para pintar tareas".
En un momento traté de tomar parte de la responsabilidad de establecer tareas, pero es irónico que tampoco tuve suficiente tiempo para esto, ya que escribí código casi todo el tiempo.
Pero el problema relacionado de obtener el estado actual de las tareas en cualquier momento, decidimos omitir, a través de llamadas de coordinación y planes para el día.
Reposición de personal, integración de equipo
Casi al principio estaba claro que la gente carecía mucho (yo mismo escribí el código de tiempo completo, pero aún no teníamos tiempo).
Los primeros decidieron tomar la delantera, porque ambos progers en la compañía eran backs (y también me identifiqué más con el backend), y había suficientes tareas, especialmente en el diseño, y las tareas sobre la reacción y la visión comenzaron a aparecer en el horizonte.
Tuve mucha suerte de tener (y tener) un frente de amigos, que al mismo tiempo comenzó a pensar en dejar el trabajo independiente, por lo que pudimos llenar rápidamente la vacante, y recibí un bono por traer a un empleado (otro plus a las autoridades, antes de eso). visto hr-awards).
Casi inmediatamente después del frente, se encontraron 2 becks. Y en algún lugar al mismo tiempo, el joon se fue (cuyo código me asomó unos meses después de su partida).
En total, se desarrolló la siguiente situación:
- un "viejo"
- yo
- tres principiantes absolutos
- el trabajo aún no se ha establecido
- ya se pierde algo de conocimiento
Es natural que decenas de preguntas de los recién llegados llovieran inmediatamente sobre mí, como líder del equipo. Básicamente, se trataba de preguntas sobre el ciclo de vida del código (dónde escribir el código, cómo mostrar dónde enviarlo más tarde, cómo recopilar la versión), sobre la gestión de tareas (cómo llevar las tareas al trabajo, cómo mostrar el estado, cómo determinar las prioridades) y cómo trabajar con git . Además, los chicos todavía intentaban hacer las preguntas "¿Cómo funciona A?", "¿Tenemos una B en nuestro sitio?", Pero casi todo en ese momento se redujo solo a la necesidad de estudiar el código.
En primer lugar, era importante dar a los programadores la oportunidad, en principio, de trabajar y escribir código por su cuenta. Llevé a cabo conversaciones introductorias con ellos, respondiendo a sus preguntas, luego, por supuesto, decidí reducir todas las preguntas y esquemas a un artículo, que luego se convirtió en una conferencia y luego en un esquema de trabajo completamente nuevo en la empresa, que discutiremos en el próximo capítulo.
Aquí vale la pena decir algunas palabras sobre el proceso de contratación en nuestra empresa, que todavía está funcionando.
Proceso de contratación
En primer lugar, tenemos una bonificación por atraer a un empleado, lo cual es una práctica bastante buena.
En segundo lugar, decidimos no organizar un examen en la entrevista, sino dar una tarea muy voluminosa, cercana a las nuestras. Esto es conveniente porque el tiempo dedicado a la contratación se reduce solo hasta la búsqueda de currículums adecuados y una entrevista fácil con los solicitantes para verificar la idoneidad y una historia sobre la tarea de prueba y, por supuesto, verificar directamente la tarea.
De hecho, June puede resolver el problema en un par de noches, voluminoso hace que tenga mucha libertad de implementación, mejoras y chips obvios. Es esta flexibilidad de implementación la que nos ayuda a evaluar el nivel del solicitante. Inmediatamente decimos que lo más importante para nosotros es cumplir con los plazos para resolver el problema (el ejecutor se llama a sí mismo) y al final mostrar el código de trabajo en el repositorio. No estipulamos el uso de enfoques y tecnologías, son elegidos por el artista intérprete o ejecutante, pero para conocer y dar consejos, enumeramos posibles mejoras en la lista, como tareas con un asterisco, por ejemplo, trabajar a través de Ajax, ext. validación posterior, protección contra spam, diseño de módulos, uso de D7, ...
Total:
- Según el resumen y la entrevista, podemos juzgar la naturaleza de la persona.
- para la fecha límite para completar la tarea, el hecho de que el código funciona y el uso del gita, tomamos la decisión de contratar
- Por calidad de rendimiento, determinamos el nivel y, en consecuencia, el salario que podemos ofrecer
- Además, ya en la tarea de prueba, mostramos qué tareas tendrán que resolverse en un nuevo lugar
Establecimiento de un sistema de desarrollo y entrega de código.
En ese momento, teníamos varios proyectos que se desarrollaron al azar:
- en algún lugar de la batalla había un maestro, en otro lugar una rama
- en algún lugar había sitios de prueba, en algún lugar no
- y si hubiera, entonces las direcciones de todos son diferentes
- git, en principio, se usó débilmente y con un crujido
- cambios manuales en la base de datos
- ...
Al principio, traté de corregir la situación en pequeñas porciones, de modo que los programadores necesitaran menos para volver a aprender y, en consecuencia, me confundí. Por ejemplo, saqué la carpeta bitrix de debajo del gita, cambié el nombre de la rama principal a master.
Pero cuando nos llegó una gran reposición, la situación se volvió crítica. Tuve que explicar mucho, recordar y escribir instrucciones ilógicas, ya que la estructura de desarrollo actual no era del todo intuitiva.
No soy fanático de las instrucciones como tales, creo que su presencia es un indicador del problema en sí mismo, por lo que se decidió crear un sistema común para todos los proyectos que debe entenderse una vez y que, por su propia estructura, elimina muchos problemas y preguntas.
El sistema es el siguiente:
- cada desarrollador tiene una plataforma de trabajo personal remota donde trabaja
- hay una plataforma donde se acumula funcionalidad para la próxima versión
- si es necesario, hay una plataforma de demostración para demostrar todos los inicios de la funcionalidad
- todo el código para una tarea se mantiene en una rama separada, donde el nombre de la rama es igual al nombre de la tarea en el rastreador
- para completar el código en una plataforma común, solo necesita mantener la rama en algún lugar y presionar
- los cambios en las bases de datos se almacenan como archivos de migración en la rama de tareas
Di una gran conferencia sobre el tema de este sistema, y comenzamos una transición piloto a él en un proyecto, donde acabamos de lanzar al senior recién adquirido.
El proceso de transferir todos los proyectos a este sistema, por supuesto, se retrasó (por ejemplo, en un proyecto no pudimos pasar místicamente al maestro la primera vez), y aún continúa, pero como resultado obtuvimos al menos:
- la capacidad de liberar solo las tareas necesarias y no liberar la funcionalidad inacabada junto con un código útil
- hacer una liberación de tarea sin involucrar a un autor de código
- trabajo paralelo en un proyecto entre artistas
- no pierdas el código
- probar la funcionalidad aislada de otra y no detener el trabajo del programa
Todo esto simplemente no existía antes. Además, no necesita explicar los detalles adicionales de trabajar con git o sitios de prueba a nuevos programadores ahora, ya que todo es universal e intuitivo.
Scrum, comunicaciones, regulaciones
Por supuesto, en el artículo tenía la intención de hablar sobre cómo ayudé en el desarrollo de la empresa como líder de equipo, pero no puede hablar sobre el desarrollo de nuestra empresa sin mencionar a nuestro jefe y su iniciativa, de lo contrario no será del todo honesto.
En primer lugar, introdujo scrum, y en el momento de mi llegada, los procesos en la empresa comenzaron a rehacerse activamente. También en ese momento la transfirió de Bitrix24 a Jira.
Scrum ciertamente trajo más ritmo a la compañía y redujo el caos. La capacitación de los gerentes, su ejecución de las llamadas de coordinación, la apertura / cierre / planificación de los sprints fue supervisada por el propio jefe, como el principal en este enlace.
También trabajó mucho en los gerentes mismos, especialmente en cómo se comunican con los clientes y programadores, ya que la mayor parte de su trabajo (pero, por supuesto, no limitado a) consiste en comunicarse: aislar a los programadores de los clientes, transmitir los deseos del cliente a tareas en el trabajo atrasado y en sprints, encontrar y volver a contar historias de usuarios. Todo esto resultó en una gran cantidad de regulaciones: en la comunicación con los clientes, en el establecimiento de tareas, en trabajar con una acumulación, en aceptar errores en el trabajo. Se hizo especial hincapié en la comunicación y el vínculo de gestión realmente mostró progreso.
La transición al scrum en sí, por supuesto, es muy difícil y al momento de escribir este artículo, aún no nos hemos convertido en sus profesionales, aunque todo esto se debe a eso. Y estoy muy contento de haber recibido muchos conocimientos nuevos sobre las metodologías y productos flexibles de Atlassian.
Nuevo gerente. Textos, configuración de tareas, trabajo atrasado
En algún momento, otra persona vino a ayudarnos a dar un salto cuántico: un nuevo gerente (antes teníamos uno).
No esperaba este momento, ya que no teníamos tantos proyectos y programadores y en teoría solo un gerente debería haber sido suficiente. Este vínculo era un punto débil en la empresa, pero tratamos de resolver este problema desarrollando el personal existente. Dio la casualidad de que un excelente gerente, a quien conozco bien, decidió cambiar de trabajo, mi jefe se enteró de esto, cuando de repente entrevistó a nuestros contratistas y mencioné este divertido incidente, y la llamamos para nosotros. Otro premio)
Al principio, el nuevo gerente repitió parte de mi camino, ya que se enfrentó a los mismos problemas (no sabe nada y no tiene dónde leer) y comenzó de nuevo, pero con la diferencia de que no tocó el código, la infraestructura de desarrollo y las habilidades del programa, sino que trabajó con estableciendo objetivos, comunicándose con los clientes, limpiando el trabajo atrasado, y también extrajo diligentemente información del jefe del antiguo gerente. En particular, lo primero que saqué es la lista de contactos de clientes y contratistas.
El equipo ya la conocía, ya que una vez la invitamos como conferenciante para contarnos sobre la gestión del tiempo. Además, las tareas de acero comenzaron a plantearse con más detalle, ella no agregó negatividad y no la transmitió desde el cliente, el estado de las tareas se hizo más relevante en cualquier momento. Por lo tanto, inmediatamente pusimos grandes esperanzas en ella.
Durante las primeras semanas, él y su jefe limpiaron el trabajo atrasado en un proyecto, en particular, encontraron un período vencido de 2 meses y una epopeya que aún no había comenzado. Además, en principio, surgieron muchas tareas que debían hacerse hace un mes. Es bueno, por supuesto, que se haya limpiado el trabajo atrasado, pero se hizo demasiado tarde.
Ella misma realmente "colgó" del desastre e intentó repetidamente irse, pero mejoramos el vínculo administrativo de una forma u otra. Es menos probable que las tareas se pierdan en el trabajo atrasado, los programadores tienen menos probabilidades de volver a preguntar.
La moraleja de la historia estará al final.
La crisis
Casi medio año después del comienzo del trabajo, tuve que irme de vacaciones. Por cierto, acepté unas vacaciones incluso cuando solicité un trabajo, ya que estaba planeado como una luna de miel, por lo que el período de mi ausencia se conocía con mucha anticipación. Pero de todos modos, por supuesto, estaba nervioso hasta el final, porque recientemente dejamos de trabajar "por desgaste".
La semana antes de las vacaciones, terminé de delegar tareas, enseñé a personas seleccionadas a realizar tareas específicas fuera del código, asigné a cada programador la responsabilidad de un proyecto específico, completé o transferí todas mis tareas actuales (todavía estaba programando la mayor parte del día). Nada anunciaba desastres a mediados de julio.
Y en los primeros días de vacaciones, tampoco, nada auguraba problemas.
Y luego hubo una crisis.
En un proyecto, el cliente se quedó sin paciencia debido a que sus expectativas de tareas (plazos, lista, prioridades) no se correspondían con el caso. Nosotros mismos notamos esto no hace mucho tiempo con el procesamiento completo del trabajo atrasado y la comunicación activa con el cliente (capítulo sobre el nuevo gerente), pero ya era demasiado tarde.
Y en el segundo proyecto, finalmente aceptaron una tarea muy grande y muy esperada, completaron las pruebas y la lanzaron. Pero la nueva funcionalidad de repente golpeó el sitio de la batalla bajo una gran carga, y el medio y el medio frontal no pudieron hacer nada al respecto durante una semana. .
, . , . , , .
vue, ( , ).
— , , , - , “ / / / ”.
, , , , .
, , , , , .
, . , - . , - .
. ( ), - :
- , - , - , . .
, . , , , .
. , , , . , , .
, vue, .
, - 5. -, . , .
, : , , , .
, - , - . , , , , , .
.
. , , , - , , .
, , , 1 , - , , , , , . , .
,
. .
, , 3-4 “ 3 ”, 40.
, , .
/ — ( ). , . , . , , -, 8 .
. :
- :
( ), :
— . :
:
, . , .
, . .
—
, , , , , “ ” , .
, , “” - .
, , , , , 2 . , , .
, , / , . , , .
, . , , / - , , - .
(, )
- . , , , , , , , .
, , . , , .
: , , , , . , .
, - , . , .
:
, , , .
, , , ( ), , , .
, ( , 2 , ).
, , . “ ”, :
, .
Parte 2
Este artículo cubrió aproximadamente seis meses de mi trabajo en un nuevo puesto. En la segunda parte, me gustaría hablar sobre cómo avanzamos hacia los objetivos con la ayuda de:
- pruebas automáticas que recién estamos comenzando a implementar. Extraño, pero por alguna razón no hay ejemplos dignos en Bitrix.
- deshacerse de la herencia en el código
- acelerar y simplificar aún más el desarrollo
- lo que aprenderé de los comentarios
- muchas otras cosas secretas (de repente mis chicos me leen)
Gracias a todos por leer. Me gustaría mucho comentar, especialmente si conoce formas más óptimas de resolver los problemas que encontramos.
¡Buena suerte y alegría a todos en el trabajo y en la vida!