Entre los desarrolladores hay quienes desean no solo escribir código hermoso, sino también crear prácticas efectivas que simplifiquen el trabajo en equipo. Después de recibir los atesorados laureles tímidos, sumergirse en una vorágine de comunicaciones constantes, resolver problemas cotidianos y, oh Dios mío, haber perdido la oportunidad de escribir el mismo hermoso código, algunos están deprimidos. Y nuestro invitado de AppsCast, Sergei Boishtyan, tomó un camino diferente y, después de probar las realidades de la vida del líder del equipo, regresó a las filas de ingenieros. Por qué el timidismo no es para todos y por qué el crecimiento no siempre es una nueva "pequeña cosa" en la manga, en diálogo con Sergey.
Alexey Kudryavtsev: Hola a todos. Sergey, dime algunas palabras sobre ti.
Sergey Boishtyan: Por el momento, soy un desarrollador senior, era un experto principal, técnico y solo un desarrollador. Yo trabajo en Avito, antes de eso en Tinkoff.
Daniil Popov: Primero aclaremos quién es el desarrollador, qué tipo de responsabilidad tiene y qué hace en el trabajo.
Sobre el rol de desarrollador
Sergey Boishtyan: El desarrollador es principalmente un rol, no una posición específica. Hay muchas personas en TI que pueden desarrollar y realizar simultáneamente otras funciones.
Al comienzo del viaje, el especialista se enfoca en el desarrollo y luego desarrolla la responsabilidad: asiste a reuniones con probadores, diseñadores, toma decisiones arquitectónicas.
Desarrollador: una función en la que un ingeniero ayuda a implementar las características del producto.
Este es un producto para el usuario final o directamente para desarrolladores. Por ejemplo, durante el último año y medio, he estado fabricando productos para desarrolladores dentro de la empresa.
Daniil Popov: ¿De qué es responsable el desarrollador?
Sergey Boishtyan: la práctica de CI / CD está ganando popularidad y es responsabilidad del desarrollador tomar la función, implementarla de forma independiente, probarla utilizando herramientas de automatización o estar en contacto con la persona que la está probando y controlar su lanzamiento.
Daniil Popov: En resumen: lleva la tarea en Jira de ToDo a Cerrado a través de los 500 estados.
Sergey Boishtyan: Si vas de lo contrario, entonces los desarrolladores no son aquellos ingenieros a los que no les importa su característica. Dichas personas envían solicitudes de extracción, pero no están interesadas en lanzar funciones, no desean modificar el código o eliminar conflictos.
Sobre la importancia del equipo
Daniil Popov: la tarea del desarrollador es garantizar que los usuarios disfruten de la calidad y la eficiencia del código. Entonces, ¿qué es un equipo, qué tareas resuelve? ¿Distingues entre tipos de equipos?
Sergey Boishtyan: Puede considerar equipos en los que las personas difieren en sus responsabilidades funcionales y los equipos en los que las personas difieren en su nivel de responsabilidad.
Soy fanático de los equipos universales, donde todos tienen cierta experiencia, pero saben cómo hacer todo, y los cuellos de botella están automatizados. En tales equipos, las personas son iguales, se comunican constantemente y conjuntamente toman decisiones.
Hay equipos donde cada uno tiene su propio bloque de responsabilidad. En ellos, el desarrollador primero escribe el código y, en segundo lugar, si es necesario, apoya al probador, quien es responsable de la calidad del producto.
Alexei Kudryavtsev: Escuché que esto no es ágil.
Sergey Boishtyan: En principio, esta puede ser una historia normal que se ha desarrollado históricamente. Pero personalmente, me gusta cuando hay personas en el equipo con responsabilidades similares y la responsabilidad se mezcla dependiendo del sprint en particular. Ahora nuestro equipo tiene más de diez servicios en desarrollo, cada uno necesita su propia experiencia y conocimiento. En un sprint, haces una cosa, en otra otra, y en cualquier caso tienes que comunicarte, ya que hay un intercambio continuo de conocimiento y desarrollo. Cuando solo eres un desarrollador, probador o diseñador, profundizas en una sola dirección.
Daniil Popov: Personalmente, no me gusta el concepto de "código común - responsabilidad común". Parece que esta práctica lleva al hecho de que nadie es responsable. Que piensas
Sergey Boishtyan: Recientemente me encontré con una frase en el libro: "Si hay más de un equipo responsable o no lo son, entonces no pasará nada, ya que nadie quiere asumir la responsabilidad".
Me gusta el enfoque cuando todo está en común, pero tienes un enfoque claro durante una semana o un mes.
Cuando planificamos un sprint, cada persona es responsable de su parte, la desarrolla y se da cuenta de que debe hacerlo. Por supuesto, con cambios frecuentes de los responsables, se puede dedicar mucho tiempo a cambiar de contexto. Al mismo tiempo, siempre hay un OUNER de una determinada funcionalidad que gestiona la acumulación. La duración de esta responsabilidad dependerá del producto.
Alexei Kudryavtsev: Creo que compartir la responsabilidad no funciona. Si alguien viene con la iniciativa en la búsqueda de aquellos que quieren ponerse manos a la obra, no los encontrará, ya que todos pensarán que alguien más lo hará.
Sergey Boishtyan: Para finalmente enterrar la responsabilidad común, daré un ejemplo de la vida. Por lo general, hay una solicitud de extracción que "toca" algún tipo de módulo. Si este módulo no tiene responsabilidad, entonces todos los revisores, pensando que el otro dejará un comentario más útil, mirarán brevemente dentro. Como resultado, el código se convierte en un hash. Y las respuestas a las preguntas "por qué es así" aparecen: "Lo hice, nadie me respondió nada, decidí que era efectivo", y luego evolucionó a la frase "sucedió así, no lo toques".
Sobre los deberes básicos de un líder de equipo
Daniil Popov: Nos estamos acercando gradualmente al concepto de "plomo" como una persona que concentra esta responsabilidad dentro de sí mismo. ¿Cuáles son las responsabilidades de tal persona?
Sergey Boishtyan: El plomo también es un papel. Sus responsabilidades varían según el equipo en el que esté. Si hablamos de un equipo en el que todos son iguales, entonces el líder guía a los miembros del equipo, ya que a menudo les resulta difícil llegar a un consenso. Entonces, la tarea principal del líder es llevar cualquier disputa a un final productivo, cuando surja una pregunta, cerrarla de la manera más rápida y eficiente posible. El plomo ayuda a otros a expresar sus opiniones y se mantiene imparcial dado que también tienen experiencia. Desde el exterior puede parecer que los scrum-masters pueden desempeñar este papel. Según tengo entendido, el scrum-master generalmente está del lado y puede facilitar las reuniones, pero quiero que este rol permanezca con el líder del equipo.
Si las funciones en el equipo están claramente separadas, el líder del equipo se convierte también en la persona propietaria del proceso. En cada etapa, comprende quién hace qué y qué es responsable.
A menudo me dijeron que el líder del equipo es una especie de paraguas entre una empresa y un equipo, porque todos conocen solo su bloqueo, pero quiero tener una persona que sepa sobre el estado actual del producto.
Alexei Kudryavtsev: Tengo la impresión de que el líder hace todo. Eres un arquitecto, un maestro de scrum, y tienes que encontrar personas y poder facilitarlas. Esta es una gran colección. Este no es un rol, sino varios. ¿Dónde está la verdad aquí?
Daniil Popov: Lo más importante es que no programes al mismo tiempo.
Alexei Kudryavtsev: Bueno, lo estás intentando.
Daniil Popov: La palabra clave es "intentar". Escribí tres líneas, te distrajeron y eso es todo.
Sergey Boishtyan: El plomo es una persona que tapona agujeros en un equipo. Cada equipo, independientemente de su formato, tiene problemas, y la responsabilidad de ellos debe ser transferida a alguien.
Alexei Kudryavtsev: Me parece que el líder trabaja con las personas y su motivación, pero hay un arquitecto independiente que es responsable del código.
Daniil Popov: Distingo entre los conceptos "jefe de equipo" y "equipo técnico". Tehlid es la persona responsable del aspecto técnico del producto: qué bibliotecas, patrones usar, qué infraestructura aplicar. Timlid trata sobre la gestión de personas. Estos roles no se superponen. Puede intentar combinar estos roles, pero es muy difícil seguir la arquitectura y 1: 1 en paralelo.
Timlid es el líder del equipo que lo dirige hacia un futuro brillante y fácil de usar.
Sergey Boishtyan : Volvamos a la definición de "equipo", donde mucha gente hace una cosa. Para hacer algo de manera eficiente y seguir siendo un equipo, necesita un líder de equipo que esculpe un solo conjunto de ingenieros dispares, que permita realizar el potencial de todos, para mejorar el producto.
Daniil Popov: Si hubiera una tímida en una fábula sobre un cisne, un cangrejo de río y un lucio, lo habrían arrastrado a donde debería.
¿De dónde vienen los tímidos?
Daniil Popov: Es interesante entender cómo se convierten en líderes de equipo. Tiré de cuatro maneras. Primero: el líder del equipo nombra al mejor desarrollador. Segundo: nombrar a los más experimentados. Tercero: nombrar por otros méritos, pero no surgió para qué. Bueno, la cuarta opción, cuando el desarrollador mismo va a la cabeza. ¿Cuáles de estas opciones crees que son viables?
Sergey Boishtyan: Comenzaré con mi experiencia. En algún momento, quería tener más responsabilidad e influir en lo que estaba sucediendo. A menudo ofrecía algo y finalmente me di cuenta de que no puedes ofrecer, pero de inmediato lo haces, por otro lado. Me dijeron que pensaba a tiempo, desde que comenzó el proyecto y me dieron la oportunidad de probarme como líder de equipo. Había una hipótesis de que yo, como desarrollador responsable, sería un buen líder de equipo.
De sus opciones, puede dejar dos: cuando la iniciativa proviene de usted y cuando proviene del exterior. En mi caso, ella vino de mí, pero vi la situación opuesta en los equipos vecinos. Tomaron un desarrollador experimentado del equipo, argumentando que él ya conoce la cultura, sabe cómo comunicarse. Nadie se negó, ya que ofrecieron a quienes entendieron que si no él, entonces nadie más.
Daniil Popov: Tengo la experiencia opuesta. El líder de mi equipo se fue y me hicieron líder del equipo. Se cree que un desarrollador experimentado se convertirá en un buen líder de equipo, pero esto es una suposición fundamentalmente errónea. Recientemente leí la idea de que al convertir al mejor desarrollador en un líder de equipo, se pierde al mejor desarrollador y se obtiene un mal administrador. Estas de acuerdo
Sergey Boishtyan: Suena como la verdad. No he conocido a tantos buenos líderes de equipo. Como personas, me gustaron todas, pero a menudo no estaba contento con la forma en que desempeñaban su papel. Me pareció que puedo hacerlo mejor. Ahora que sé que no puedo, he formado criterios claros para una buena pista.
Si puedes escuchar a las personas, saber cómo ser de mente abierta y cómo transmitir los pensamientos de otras personas, entonces esto ya está a medio camino. El resto viene con práctica. Debido al estrés constante, aprende a administrar el tiempo y priorizar las tareas.
Si una persona sabe cómo comunicarse, resaltar el enfoque y tiene buenas habilidades técnicas, entonces definitivamente le aconsejaré que se pruebe en el papel de líder del equipo.
Problemas de crecimiento
Daniil Popov: ¿ Y dónde avanzar más timlidu? Jefe de dispositivos móviles, CEO, CTO?
Sergey Boishtyan: ¿Por qué mudarse a algún lado?
Daniil Popov: En nuestro espacio postsoviético, existe la opinión de que siempre hay que crecer en algún lugar. Si no creces, entonces la vida ha vivido en vano. Y solo puede crecer con un aumento de posición, con la recepción de una nueva cadena. También lo pensé antes, y luego me di cuenta de que este es un camino opcional. ¿Qué significa el crecimiento para ti?
Sergey Boishtyan: Una vez leí sobre la clasificación de las esferas de influencia de una persona, donde el crecimiento significaba un aumento en una de las esferas de influencia: profesional, financiera, social, familiar y de salud. Hace seis meses, aprendí sobre el
cuestionario de valor de Schwartz . Entonces no pude entender si quiero ser un líder o no. Busqué cuestionarios y pruebas, tratando de darme cuenta de cuáles áreas son importantes para mí. Si quiero ser un desarrollador famoso o un gran salario, o quiero un equilibrio entre el trabajo y la vida, y no me importa en qué nivel estoy.
Según el cuestionario de Schwartz, resultó que era importante para mí ser profesional, tener reconocimiento y una familia. Me di cuenta de que disfruto trabajar en una tarea técnicamente desafiante, hacer una presentación o grabar en un podcast, pero si necesita elegir pasar el tiempo preparándose para un discurso o hacer una tarea en el trabajo, elegiré la última.
Es importante entender que estos valores son dinámicos. No sucede que quieras ser un profesional genial toda tu vida. En algún momento, llegará al punto, vuelva a realizar la encuesta y resulta que ahora su prioridad es la familia.
Necesitas crecer y desarrollarte para ser feliz.
Es solo que las personas a menudo crecen y se desarrollan en la dirección equivocada, porque no se dan cuenta de lo que es realmente importante para ellos.
Alexei Kudryavtsev: Resulta que lo más importante es entender dónde estás creciendo.
Sobre los pros y los contras del liderazgo del equipo
Daniil Popov: Veamos qué te gustó de tu papel y qué no.
Sergey Boishtyan: Primero, explicaré un poco más por qué quería ser un líder. Cuando llegué al desarrollo, me sorprendió lo que obtuve. Luego ingresé al equipo y comenzaron los problemas con las solicitudes de extracción debido a malentendidos y falta de comunicación. Una conversación racional no funcionó, pero dentro había un deseo de hacer todo de manera eficiente. En tales situaciones, pedí ayuda, pero no fue suficiente para todos.
Comencé a pensar que el equipo debería tener principios generalmente aceptados, prácticas creadas por el equipo o el líder. Pensé que para el papel de líder de equipo, se me ocurrirán prácticas que a todos les gustarán, todos estarán de acuerdo rápidamente, dejarán de entrar en conflicto. Con tal pensamiento en mi cabeza, comencé a leer libros sobre negociaciones, me encontré con
Schopenhauer . Hubo una buena idea de que las personas no pueden escuchar argumentos y deben llegar a conclusiones de forma independiente. Al imponer su opinión, solo causa un deseo de defenderse.
Entonces aprendí a hacer preguntas, en primer lugar a mí mismo. Decidí que una de las tareas divertidas del líder es ayudar a las personas a responder preguntas que no se hacen a sí mismas. Estaba seguro de que, al convertirme en líder, continuaré escribiendo código, solo crearé prácticas y todo estará bien.
Alexei Kudryavtsev: Entiendo que querías escribir código, pero como quieras.
Sergey Boishtyan: Quería escribir código rápidamente.
Daniil Popov: Me parece que esta es una posición normal de motivación y liderazgo, si ofreces algo, y la gente está de acuerdo contigo. Lograste transmitir tus pensamientos al público, ella te aceptó, te subió a un automóvil blindado y ahora estás listo para hacer avanzar a la gente.
Sergey Boishtyan: ¿Qué problemas he encontrado? Tuve la suerte de no tener que desplazar a nadie ni pelear. Acabo de llegar como líder en un nuevo proyecto, recluté personas para el equipo, aceptaron mis principios, pero en algún momento aparecieron en el equipo personas que no estaban muy de acuerdo conmigo.
Daniil Popov: ¿Los has contratado?
Sergey Boishtyan: Sí, sucedió. Aprendí a hablar y comunicar, pero no desarrollé en mí mismo la autocrítica y la objetividad a mis propias ideas. Llegué a la conclusión de que no deberíamos promover nuestros pensamientos, sino entender qué pensamiento es correcto y promoverlo. No fue facil. Constantemente tuvimos disputas. Había una persona en el equipo con los pensamientos correctos que no podía transmitir, y mi tarea era transmitirlo por él, y por supuesto tenía mi propio ego y punto de vista.
A partir de aquí surgió un conflicto interno, cuando, por un lado, parecía que si se podía transmitir un pensamiento, entonces es correcto, y por otro, simplemente se sabe hablar mejor que los demás. Me tomó un tiempo darme cuenta de esto. En este punto, el equipo creció y perdí el tiempo escribiendo código. Me preguntaba por qué estaba haciendo todo esto.
Tomo pensamientos racionales de las personas, ayudo a transmitirlas y no hago nada por mí mismo. ¿Qué tan útil es esto? ¿Quizás es más útil para mí darme cuenta de estos pensamientos como desarrollador?
Luego pensé en lo que era más importante para mí, comencé a anotar en comunicaciones, a asumir las tareas de infraestructura de automatización. Mientras hacía esto, los conflictos comenzaron en el equipo. Además, comencé a notar que mi hundimiento técnico había comenzado. Cuando no escribe el código durante mucho tiempo, parece que está detrás de la industria: se publicó un artículo, pero no lo leyó, se celebró una conferencia y no tuvo tiempo de irse. Comenzó a aplastarse. Llegué a la conclusión de que hasta que me convierta en un ingeniero que sepa mucho y entienda, no seré un líder de equipo.
De vuelta a los desarrolladores
Alexei Kudryavtsev: ¿No te asustó que, dejando a los líderes en los desarrolladores, perdiste la perspectiva de crecimiento, que serás un desarrollador senior hasta el final de tus días?
Sergey Boishtyan: No tenía dudas y pensamientos largos. Esto se acumuló, y en algún momento sentí que el liderazgo del equipo no era un placer. Pensé de qué manera, quién podría ser, me di cuenta de que solo podía ser desarrollador y acepté esta idea.
No intenté resolver todo de una vez, pero intenté regresar al estado cuando estaba feliz.
Daniil Popov: Dijiste que te convertiste en un líder de equipo porque querías ser el maestro de las decisiones. Cuando volviste a ser desarrollador, volviste a ser actor. ¿Todavía te molesta?
Sergey Boishtyan: Fue una gran incomodidad. Había dos opciones: reconciliarse con lo que se le decía o aprender a contarle a los demás para que le escuchen y cambien de opinión. Nuevamente comencé a desarrollar las cualidades que desarrollé en el papel de líder de equipo, pero ahora no con el objetivo de llegar a un consenso, sino con el objetivo de comunicar la opinión para que puedan escucharla y comprender la motivación de la persona.
El problema con mi equipo era que el líder del equipo no sabía cómo transmitir sus pensamientos, y me di cuenta de que mi tarea era ayudarlo a transmitirme el significado de sus palabras y sugerir otras soluciones con razón.
Alexei Kudryavtsev: ¿Cómo desarrollaste estas habilidades de escucha y te entendiste a ti mismo?
Sergey Boishtyan: Hay un libro
llamado "Black Rhetoric" sobre cómo manipular a las personas y reconocer las manipulaciones de los demás. En general, leo mucho, y no sobre el diálogo y las negociaciones, sino sobre la capacidad de comprender a los demás, para tener en cuenta que las personas no son solo lógica y racionalismo, sino también emociones.
¿Pero qué hay del salario?
Alexei Kudryavtsev: El liderazgo también es un salario más alto. ¿Cómo volver a ser desarrollador sin perder dinero?
Sergey Boishtyan: Entiendo que en este mundo siempre habrá personas que ganen más que yo.
No tiene sentido perseguir solo dinero. Personalmente persigo que mi trabajo fue pagado de acuerdo con el mercado.
Es una pena si los desarrolladores de su nivel reciben un pago y usted es más bajo.
Daniil Popov: la motivación monetaria dura de tres a seis meses, y luego se detiene.
Sergey Boishtyan: No he escuchado tal hecho, pero estoy de acuerdo.
Alexei Kudryavtsev: Cuando se cierren las necesidades monetarias, surgirán necesidades más importantes, a las que prestará atención. Por ejemplo, proyectos más frescos.
Sergey Boishtyan: Vi un video en TED, donde el
orador dio ejemplos de experimentos que confirmaron diferentes tipos de motivación . A algunas personas se les prometió dinero para alguna tarea, mientras que a otras se les dio la condición de encontrar una solución única para esta tarea. Resultó que el primero hizo la tarea más lentamente que aquellos que tuvieron el desafío de encontrar una nueva forma. El orador, autor de libros de motivación, explicó que las personas modernas están motivadas por la responsabilidad y la libertad. No tuve ninguna idea sobre el dinero durante la transición al desarrollo. Pagar a nivel de mercado es una confirmación de que eres un buen programador y te aprecio. Comparar con una pista no es para mí.
Alexei Kudryavtsev: Es incómodo para muchos degradar cuando se pasa de una ventaja que paga mucho. ¿Cómo vivir con la idea de que pierdes en dinero?
Sergey Boishtyan: Hay dos opciones: encontrar un lugar donde la posición del desarrollador se paga más alto o encontrar otra forma de ganar dinero.
Acerca de los planes
Alexei Kudryavtsev: Ahora que eres desarrollador de nuevo, ¿cómo ves el desarrollo en este rol?
Sergey Boishtyan: No sé qué valores tendré en primer lugar en cinco años, pero hasta ese momento estaré cómodo en mi papel, aunque en un año, por supuesto, puedo decir algo completamente diferente. Tengo un plan estratégico a largo plazo y, en diez años, si sigo siendo un buen ingeniero, puedo convertirme en un buen representante de la TI más importante.
Alexei Kudryavtsev: ¡ Pero la tecnología se está volviendo obsoleta!
Sergey Boishtyan: Díselo a tu CTO.
Alexei Kudryavtsev: CTO no es un ingeniero, sino una dirección principal.
Sergey Boishtyan: Me
sumergí en el liderazgo y entiendo qué habilidades se necesitan, qué ser un líder. .
, — developer advocate.
, .
, . , , , , , .
, , , , .
: , CTO , .
: , , .
— : - .
: .
, , , , - .
, , , .
: , , ?
: . . , , . , . , . .
Consejos
: . , , — , , — .
: , . , , , .
— : , , , .
, , . , .
— , , .
- , , . , , .
: : , .
Saint AppsConf CI/CD. , soft skills , . , , .