Oh, mi código: cómo convertirse en un líder de TI

Cómo convertirse en un director técnico, qué hacer en situaciones de emergencia, cómo lograr mayores salarios y crecimiento profesional, así como también cómo funciona el desarrollo de Am.ru, hablamos de esto en la decimocuarta edición de programas de entrevistas para programadores "Oh, My Code".


El anfitrión del programa es Pavel Shcherbinin, director técnico de proyectos de medios, invitado - Alexander Melnichuk, director técnico de Am.ru.

Cuéntanos un poco sobre ti.
Me gradué de ITMO. Trató de estudiar en la escuela de posgrado, participó en la difracción de rayos X de ángulo pequeño. Entonces comenzó la era de Internet, todos comenzaron a hacer portales. En 2009, un amigo mío llamó y dijo que su amigo Oleg quería comenzar su proyecto y formar un equipo en San Petersburgo. Nos conocimos en el metro. Desde entonces he estado trabajando en am.ru. Durante la primera reunión, Oleg contrató de inmediato a dos personas: yo, luego el gerente de desarrollo, y Sergey, el desarrollador principal. Es decir, escribimos las primeras líneas de código.

"Ven a nuestro director técnico?" - "¿Y cuántas personas tendremos en sujeción?" "Hasta ahora, solo tú".
Nadie habló sobre el director técnico entonces. "Director técnico" es generalmente una posición muy extraña. Por un lado, este es un tipo de gestión, por otro, un especialista técnico. Hay diferentes variaciones. Por ejemplo, cuando un CTO escribe mucho código. De hecho, este es un desarrollador líder. Entonces, por lo general, tiene un serio descontento por diversos trabajos de gestión. En mi caso, lo contrario es cierto. Administro equipos el 100% de mi tiempo. Dejé de escribir código desde 2009, porque simplemente no hay tiempo para esto. Puedo escribirlo, pero luego tengo que enviarme al equipo enemigo.

Pero aún así eres el director técnico. Debe estar al tanto del desarrollo de la tecnología, saber cómo se están desarrollando el frontend y el backend.
Constantemente leo, miro, me comunico con los desarrolladores. Entiendo lo que se hace y cómo. Y luego, antes de eso durante 8 años, yo mismo escribí algo. Por supuesto, esto no era ciencia espacial. Pero ahora puedo leer el código.

¿Cómo convertirse en director técnico?
En primer lugar, debes querer convertirte en uno. Esto no quiere decir que un CTO sea algo súper genial, mejor que cualquier otra cosa. Todas las profesiones son buenas. Puedes ser un desarrollador feliz y disfrutarlo. Necesitas ser un director. Rastrillar tareas gerenciales es una cierta habilidad. Debe comprender que en la mayoría de los casos no escribirá código. A veces, en vacantes, indican que necesita un director técnico con conocimiento de Symfony, e incluso de forma remota. En general, algún tipo de infierno. Estas personas se engañan a sí mismas. Y a veces un arquitecto se entiende como un "director técnico", y esto también es bastante común.

¿Cuántas personas hay en su equipo ahora y cuál es su estructura?
43 personas. La estructura es plana, es decir, todas estas personas están subordinadas administrativamente a mí. No tenemos gerentes de proyecto y líderes de equipo. Pero una estructura lógica suficientemente desarrollada de 5 equipos separados, tanto de perfil estrecho como de perfil ancho, que participan en varias áreas a la vez. Todos los equipos son completamente independientes y trabajan en los sitios de sus proyectos. Tienen autogobierno, y esto es muy bueno.

¿Las tareas pasan por ti o directamente al equipo?
Por supuesto, directamente al equipo. Si me atravesaran, probablemente habría muerto hace mucho tiempo, porque el flujo de tareas es enorme. Mi función es reducir las comunicaciones al mínimo necesario. Si una persona necesita algo, debe saber dónde obtener este conocimiento, con quién hablar directamente.

Seguramente muchos de nuestros lectores tendrán una pregunta: ¿por qué te necesitas? Las tareas van directamente al equipo, los equipos son geniales, autoorganizados. Parece que el director técnico ni siquiera existe.
Un amigo mío dijo una vez que la tarea del director es crear trabajo en equipo para que pueda ser despedido fácilmente. Estamos luchando por esto, pero aún no lo hemos alcanzado.

Un impulso interesante de ser despedido.
Sueños, sueños ...

¿No cree que muchos aspiran a los puestos de líderes y directores con el objetivo de trabajar menos?
Ayer salí del trabajo unas 22 horas. Al ser un CTO, a menudo envidio a los desarrolladores. Esto es maravilloso: ha llegado, tienes una tarea que te gusta, la elegiste tú mismo, lo hiciste, viste el efecto. Todo es super Cansado - bebió café, jugó, descansó. Si tiene alguna dificultad, hable con sus colegas y complete la tarea. Puedes ponerte los auriculares, escuchar tu música favorita y hacer tu trabajo. Si te sientes mal, puedes trabajar en casa, puedes pensar en algo por la noche.

El director técnico está completamente equivocado. Mi día habitual comienza con una hoja de papel A4, donde escribo lo que quiero hacer hoy. Lo escribí abajo. Entonces todavía esto, esto, luego tomo la segunda hoja, luego la tercera. Borro las tareas durante el día. Hay muchos de ellos, son pequeños, están en constante cambio. Cuando haces una cosa, surgen lo siguiente y lo siguiente.

A veces resulta que en la noche tienes que terminar algo, y una hora antes de eso, aparecen nuevos mensajes introductorios. Y necesitas repetir todo. Este es un mundo que cambia constantemente. Este es el principal problema. No tengo ninguna tarea grande, tengo una gran cantidad de tareas pequeñas para las que necesito tomar decisiones constantemente. Esto es complicado

¿Puedes hablar sobre las tareas que se repiten con más frecuencia o, por ejemplo, algo interesante de ayer? ¿Qué se incluye en tus tareas principales?
La tarea principal es que todo funcione, que se nos libere sin demora, a tiempo, para cumplir con las tareas establecidas por la administración del producto, de modo que los proyectos se entreguen a tiempo. Cómo lo haré es mi dificultad. Las dificultades son muy diferentes. Por ejemplo, las personas acudieron al centro de datos para descargar los servidores, y el cargador no estaba autorizado porque tenía un pasaporte sospechoso. O los oficiales de seguridad solicitan información y usted necesita encontrar a alguien que le brinde esta información. O el producto está cambiando, respectivamente, aparecen nuevas tareas y fechas límite, debe integrar de alguna manera estas tareas en el plan y resolverlas.

¿Cómo encaja Agile en su sistema de desarrollo?
Vivimos completamente en Agile. Tenemos equipos trabajando en Scrum, y hay equipos trabajando en Kanban. Ni siquiera sé cómo podríamos haberlo hecho sin él. Érase una vez, cuando todavía no conocía este término, tratamos de construir un sistema similar, pero no lo logramos porque era una iniciativa sin un libro de texto, con un estilo. Por ejemplo, durante mucho tiempo ha habido una "alergia" a los gerentes de proyecto y las personas que deben entregar tareas y pintar sobre cuadrados. Nunca he tenido gerentes de proyecto.

¿Cómo funciona el equipo?
Tenemos un CPO (propietario del producto en jefe. - Ed. Aprox.) Común que dice cómo se desarrollará el producto. Además, hay una serie de APO (propietarios de productos de área. - aprox. Ed.), Que son responsables de sus áreas. De hecho, la estructura organizativa es un poco más complicada, pero describo la lógica. Cada dirección tiene un equipo separado. Los equipos toman tareas de APO y, a veces, se establecen. Las tareas se agregan a la reserva general, luego se forma la reserva de Sprint y luego se completan.

Al comienzo de cada sprint, se realiza la planificación. Por separado en todos los equipos. Surge la pregunta: "¿Qué pasa con la coordinación de objetivos comunes?" Existe una planificación general a nivel del propietario del producto. Aquí vienen tareas previamente coordinadas entre direcciones. Además, necesitamos coordinación técnica, que se lleva a cabo de varias maneras.

Si un empleado necesita coordinación con otro equipo, entonces él se pone de pie y dice que tienen tal o cual problema, pide ayuda. Llamamos a estos empleados "exploradores".

Además, tenemos una reunión técnica general Master Sync, que reúne a desarrolladores y representantes de todos los equipos, sin propietarios de productos. En él, resolvemos solo problemas técnicos, discutimos cómo resolverlos correctamente, cómo sincronizar la tecnología común. tareas entre equipos. A veces, en Master Sync, se formulan tareas que son realizadas por empleados de dos o más equipos o se colocan en una cartera de pedidos común para una solución conjunta adicional.

Para elaborar un plan, se lleva a cabo un PBR (refinamiento de la cartera de productos. - Aprox. Ed.). Los desarrolladores evalúan las tareas y ayudan a los propietarios de productos a hacer planes y priorizarlos. PBR puede tener lugar tanto en un equipo como entre varios equipos. A veces, la planificación se lleva a cabo con un equipo externo, si el producto implica integración.

Termina con una demostración semanal del producto. Cualquiera que quiera puede venir. Estamos transmitiendo en línea. Los propietarios de productos miran, miran CPO, a veces marketing, personal de ventas, soporte. Los equipos hablan sobre características implementadas, API, documentación, pruebas y todo lo que se ha hecho. Aquellos involucrados en arquitectura o administración pueden hablar sobre sus decisiones y planes. Es decir, la demostración es una especie de hito común que muestra los resultados del trabajo de todo el equipo en una semana o dos, dependiendo de la duración del ciclo del equipo.

Además, cada equipo realiza su propia retrospectiva, sobre la cual se discuten los problemas de la organización. Si el equipo no puede decidir algo dentro de sí mismo, las preguntas se envían al retro entre equipos. Lo realizamos una vez cada dos semanas y decidimos qué se aplica a todos los equipos, a toda la oficina y a todo el producto. Según los resultados de retro, a cada tarea se le asigna una persona responsable que puede resolverla o seguir su decisión, si depende de servicios externos. En la próxima sincronización retro o Master Sync, los responsables cuentan lo que hicieron o no, por qué razones, qué ventajas y desventajas se revelaron.

Cuéntame sobre alguna situación inesperada y anormal.
Suceden situaciones anormales, pero cada vez menos. Por ejemplo, una vez en nuestro sitio, todos los JS en el escritorio dejaron de funcionar. Lo más importante era encontrar la causa del problema y resolverlo. Hablando en términos científicos, recurrimos a la metodología Andon: detuvimos todos los procesos, todo el equipo fue en busca de una razón. Encontrado lo suficientemente rápido. Se requirió más tiempo para resolver el problema.

¿Cuál fue el motivo?
Agregue un poco más de aceite al fuego. En el front end, no actualizamos nada. Y por qué todo se descompuso, nadie lo entendió. Pero se rompió en todas partes de inmediato. Resultó que habíamos lanzado una pequeña herramienta de utilidad, que arrancó una biblioteca JS de terceros, que tenía un error. Esta biblioteca fue reemplazada inmediatamente en todo el código. Como resultado, JS llovió. Nadie esperaba que una herramienta completamente extraña en el panel de administración del sistema de control pudiera romper todo.

Mencionaste la metodología Andon. Que es esto
Todos tienen algún tipo de especialización. Soy el director técnico, hay desarrolladores front-end, desarrolladores móviles, administradores de sistemas, DevOps, etc. Parecería que si soy un programador de C ++, escribiré en C ++. Pero si la interfaz rompió JS? " ¿Qué es JS? Algo incomprensible de las humanidades, no lo haré. - Pero generalmente soy administrador del sistema o DevOps. No tengo nada que ver con eso, saca tu propio JS .

Andon fue diseñado para prevenir tales situaciones. Nuestro proyecto se rompió, es nuestro común. Todos estamos empezando a buscar dónde se rompió. En el caso descrito por mí, el desarrollador de backend habitual encontró la razón, que simplemente se sentó y comenzó a buscar, sin decir que no escribió en JS, que no sabía algo. Es decir, Andon reside en el hecho de que todos se rinden y comienzan a resolver el problema tanto como pueden.

Usted dijo que el problema surgió debido a algún tipo de utilidad interna del sistema. ¿No usaste la contenedorización, que es muy popular ahora?
No

¿Ahora tienes un docker en producción?
Si

Es decir, ¿cambiaste activamente a Docker y lo usaste?
Esta es una de las principales direcciones de nuestro trabajo.

¿Cuáles son tus impresiones?
Bueno Ni siquiera sé cómo viviríamos sin él. Anteriormente, teníamos PHP: eliminemos los scripts y comenzó. Y ahora no puedes vivir sin contenedores de ninguna manera.

Usted, como director técnico, está involucrado en la "salud" del equipo. Cuéntanos un poco al respecto.
Una de mis principales cualidades: me gusta escuchar a la gente. Estoy tratando de ponerme en su lugar, esto hace posible comprender su estado de ánimo, sus problemas, por qué toman ciertas decisiones, por qué se sienten así. Y esto me ayuda a encontrar la manera correcta de salir de la situación, tomar la decisión correcta. Para mí, la "salud" del equipo, el "bienestar" de cada persona es extremadamente importante: es bueno para él, se siente cómodo en el equipo, hacia qué objetivos se dirige, qué quiere lograr.

Una vez, un desarrollador dijo en una conversación personal: “ Solía ​​soñar con convertirme en director técnico o director técnico para obtener más dinero, tener poder, etc. Ahora trabajo en una estructura plana, no tenemos techlide. Pero hay un director técnico que realiza tareas de gestión y los desarrolladores toman decisiones técnicas. ¿A dónde debo apuntar? Como vivo Los principios de la vida están rotos. No está claro a dónde ir más lejos ".

Poco a poco, me di cuenta de que ese no era el punto. Un hombre debe ser feliz. Las tareas que realiza, le gustaría. Y puede elegirlos por sí mismo. La escala profesional brinda crecimiento financiero, pero se puede lograr de otra manera: resuelve problemas más complejos, ayuda a otros, su equipo trabaja más rápido, entrega características complejas más rápido. Tanto para el crecimiento profesional, el salario, la tasa está creciendo. Los cambios en el libro de trabajo son secundarios. Trabaja bien, te da placer. Y si esto afectará positivamente el producto, entonces el salario aumentará y la posición en el libro de trabajo cambiará.

¿Cómo convertirse en un líder de equipo?
Simplemente no puedes ser. El significado del trabajo en equipo es hacer lo que te gusta. En mi práctica, ha habido casos en que una persona fue recetada tímidamente a petición suya. Bueno, escribimos un memo, cambiamos la entrada en la mano de obra, aumentamos el salario. Además, la persona dice que es un líder de equipo, pero el equipo no lo reconoce.

Ocurre al revés: una persona explica al equipo cómo hacer algo, y el equipo lo reconoce. Estos son los mejores líderes de equipo. Si quieres convertirte en un líder de equipo, lo serás. Y si no quieres, no lo harás.

Dices que te gusta escuchar a los desarrolladores, das muchos ejemplos cuando te dicen algo. Pero los desarrolladores suelen ser introvertidos; sacar una palabra de ellos a veces es difícil. ¿Cómo lidias con esto? ¿Cómo hablar con el desarrollador?
Todos los introvertidos. Todos odian a las personas. Ese no es el punto. Trabajamos juntos Trato de hablar con la gente uno a uno de vez en cuando. Es extremadamente útil obtener comentarios. Una vez no pude entender lo que le estaba pasando a una persona. Luego acordamos que nos reuniríamos una vez cada dos semanas y hablaríamos. Y después de eso, todo salió a la perfección. Le digo que no me gusta, él me dice que no le gusta. Encontramos puntos comunes, tomamos decisiones, discutimos lo que haremos a continuación de esta manera. Y seguir adelante. Funciona muy bien Necesitamos comunicarnos más.

Nuestra pequeña encuesta sobre bombardeos. ¿Qué sistema operativo elegirás?
Mac OS

¿Cuál es el mejor IDE?
JetBrains

¿La última aplicación, sitio web o startup que te impresionó?
Banca móvil de Tinkoff Bank.

¿Qué es mejor: una startup o una gran empresa?
Si solo quieres vivir cómodamente y cobrar, entonces ve a una gran empresa. Si constantemente te enfureces, quieres movimiento, adrenalina, aventuras, entonces una startup es tu todo. No es necesario ir a una startup si solo quieres mucho dinero. Esto no es así.

Ayer, la tendencia fue móvil primero. Hoy es el aprendizaje automático primero. ¿Qué pasará mañana?
En un entrenamiento dijeron que hay personas especiales que determinan lo que sucederá mañana, incluso roban cartas sobre este tema y las venden por dinero. El aprendizaje automático es una especie de exageración. También hay big data, realidad virtual, nano y biotecnología. Vi un mapa similar: una especie de maraña de lazos enredados que se mueven en diferentes direcciones. Predicciones a nivel de astrología. Diría que mañana no habrá aprendizaje automático, sino grandes datos. Ya se sabe mucho sobre cualquier persona que se conecta. Solo necesita aprender a usarlo correctamente. Este conocimiento se recopila, procesa, es una fuente de ingresos.

¿Cuándo te reemplazarán los robots?
Podemos decir que ya han sido reemplazados. Compré una aspiradora robot.

¿Cómo valoras las tareas: en horas o en Story Points?
Tanto en Story Points como en horas. Quien lo quiere

¿Qué última cosa no podrías permitirte?
Subaru Ascent.

¿Cuántos bitcoins tienes?
Cero

¿No te interesa este tema?
Esto es bombo.

¿Qué preguntan más a menudo tus amigos sobre am.ru?
Cuando nos hacemos cargo del mundo.

Y cuando
Próximamente