Get best of the week

Cómo un ingeniero se convierte en techlida

¿Quiénes son el líder del equipo, el arquitecto o el control de calidad y qué hacen, en TI, casi todo se imagina? Pero con la comprensión de quién es el experto técnico, de qué es responsable y cómo convertirse en uno, surgen dificultades. Realizamos docenas de entrevistas con especialistas de grandes empresas y descubrimos que se trata de un ingeniero que inicia procesos: conecta personas y herramientas con los objetivos de la organización. Él toma la iniciativa y la responsabilidad del desarrollo tecnológico del producto y se preocupa por la calidad de las soluciones técnicas. Además, la calidad no es solo una prueba, sino que la arquitectura, el diseño, las prácticas de ingeniería y los experimentos funcionan con la deuda técnica y la mejora técnica de la empresa en su conjunto.



También descubrimos que hay muchas conferencias para techlides. Pero casi todos se centran en herramientas, no en prácticas y procesos de ingeniería. Es por eso que lanzamos la nueva conferencia TechLead Conf 2020 en línea , para aquellos que desean convertirse en expertos técnicos y comprender qué es la calidad. 

En TechLead Conf 2020 Online, la pregunta secundaria es "¿Qué herramienta técnica se utilizó para resolver el problema?". Esta conferencia es para aquellos que se esfuerzan por la calidad de las soluciones técnicas y se responsabilizan del desarrollo tecnológico del producto. Del 8 al 10 de junio, estudiaremos la experiencia de implementar y usar prácticas, tecnología y gestión de procesos en la empresa. Le informaremos más sobre el programa y de qué hablaremos en el evento.

Programa corto


El programa en línea TechLead Conf 2020 pasa de discutir el desarrollo de techlide a poner en práctica DDD y consta de varios bloques.

  • Mapa de desarrollo técnico . Todavía hay poca comprensión de quién es y qué hace. Y las preguntas sobre cómo convertirse en techlide y qué debería poder hacer se hacen con menos frecuencia, por lo que en el primer bloque discutiremos quién es y cómo convertirse en uno. 
  • . — , -, « ». , — : , . « ». , MVP.
  • Efectos retardados de las prácticas de ingeniería . Al trabajar con código, la retroalimentación es rápida: escrita, probada, implementada, funciona. Pero en el mundo técnico, el resultado de su trabajo es notable solo después de meses. Por lo tanto, agregamos informes sobre todas las etapas del ciclo de vida de las prácticas de ingeniería: la aparición de una idea, MVP, la prevención de errores y la medición de resultados después de un lanzamiento exitoso en casos reales.

También discuta: 


Le diremos con más detalle acerca de cada bloque e informes en ellos.

Mapa de desarrollo de Techlide


Tehlid es el papel de un ingeniero que gestiona los procesos. Por lo general, estos son ingenieros al menos senior: desarrolladores, arquitectos, automatización, SRE, menos comúnmente CTO. A veces pueden ser un líder de equipo. Pero el líder del equipo construye equipos, gestiona personas y su desarrollo.
Tehlid construye procesos: toma decisiones técnicas que afectan el desarrollo de productos ante la incertidumbre.
Por lo tanto, la conferencia no tendrá informes sobre gestión y motivación de personas, sino solo temas sobre gestión de tecnología, liderazgo técnico y la construcción de procesos de ingeniería. Y lo primero que debe aprender es cómo convertirse en un buen techlide.

El éxito de la empresa depende de la disponibilidad de especialistas fuertes. Ya hemos descrito cómo el techlide difiere de otras profesiones, y Vladimir Gorovoy , Gerente de Producto de Ciencia de Datos en Yandex.Verticals , le dice a Vladimir Gorovoy sobre la diferencia entre un buen techlide de otras profesiones . Del informe " Cómo convertirse en un buen Techlide»Averigüe dónde comenzar nuestro desarrollo, qué habilidades y cualidades bombear. Vladimir compartirá su rica experiencia participando en la creación de los proyectos Yandex.Travel, Yandex.Real Estate y Yandex.Market para ilustrar la tesis.

Cuanto más fuertes sean las habilidades, más fácil será hacer frente a sus tareas. Pero el dolor no llega a ningún lado: son casi iguales para todos los deslizamientos tecnológicos.

  • ¿Escribir código o participar en una estrategia de desarrollo tecnológico para el producto y el equipo?
  • ¿Resolver problemas técnicos complejos usted mismo o delegar?
  • ¿Cómo no dividirse entre escribir código de calidad y desplegar funciones?

Estos y otros conflictos serán resueltos por Evgeny Korytov . En el informe "¿ Problemas de tecnología técnica y cómo resolverlos? "Eugene le dirá cómo hacer frente a las tareas y los problemas de los líderes, con la ayuda de un marco que" resuelve problemas ".

Combinando negocios y desarrollo


Mantener un código de alta calidad y tomar las decisiones técnicas correctas no es todo el trabajo. También debe demostrar constantemente a las empresas y los clientes la necesidad de invertir tiempo y energía en tareas arquitectónicas y técnicas. Alexey Deryushkin de Better Life Company sabe por experiencia cómo es: 15 años de liderazgo de equipo y 5 años de experiencia en consultoría. En el informe " Cómo 'Vender' las tareas técnicas a las empresas ", mostrará cómo mantener un diálogo con las empresas para crear características interesantes y no olvidar la calidad utilizando ejemplos de vida.

La lucha entre los negocios y el desarrollo es un problema estándar en los proyectos de TI. A menudo, el negocio no tiene conocimientos tradicionales, sino solo "ideas" y solicitudes. Esto lleva a decisiones incorrectas que deben corregirse durante meses o mantenerse durante años con muletas. Cómo encontrar un equilibrio entre el desarrollo y los negocios, Arthur Dementyev compartirá en el informe " Entre dos luces: desarrollo y negocios ". Arthur en TI desde 2009, en el ejemplo de historias de la práctica, ilustrará diferentes enfoques para la implementación de las funciones de MVP.

Cuando el negocio y el desarrollo hayan acordado, es hora de pasar a la siguiente etapa. Ahora techlide tiene varios meses para presentar un nuevo producto. Muy a menudo, en tales situaciones, se crea un producto de prueba de hipótesis (MVP) que funciona mínimamente. Inmediatamente después de la prueba, se desecha el código prototipo y la aplicación se escribe "como debería". ¿Pero qué hacer cuando el lanzamiento de la prueba fue exitoso y los usuarios reales ya viven en la "nave"? Aprendemos de Maxim Arshinov del informe " Cómo lanzar MVP y no convertirlo en una deuda técnica ".

Seleccionamos e implementamos prácticas de ingeniería.


Siempre es difícil implementar algo nuevo, el mismo MVP, PL o marco. La novedad puede resultar ser "cruda" y no estar a la altura de las expectativas. Cómo hacer la elección correcta y " Introducir una nueva tecnología y no desperdiciar todos los polímeros " , dice Pavel Mineev , líder del equipo de Rocketbank.

Para la introducción de nuevos productos, es óptimo utilizar la gobernanza como un enfoque de código. Con este enfoque, todas las reglas tienen su propio ciclo de vida, están sujetas a pruebas y no son diferentes de un producto de software normal. Del informe de Alexander Tokarev "La gobernanza como código: cómo cumplir con los estándares de desarrollo y no retrasar la entrega de funciones»Aprendemos cómo aplicar este enfoque: cómo y qué verificar durante el proceso de desarrollo de software, cómo el enfoque le permite desarrollar aplicaciones más seguras y de alta calidad. 

Cuando se implementan los estándares, es hora de probarlos, por ejemplo, en algo a gran escala, para crear una plataforma tecnológica. MTS es una gran empresa de TI que implementa proyectos desde telemedicina hasta IoT. Cada nuevo proyecto estimula la demanda de lo siguiente y reduce el costo de su creación. Esto solo es posible mediante la implementación de las mejores prácticas de ingeniería. Pero hay dificultades: cientos de equipos con diferentes niveles y procesos, legado, la necesidad de "vender" ideas a las empresas. ¿Cómo hacen frente las empresas a estas tareas? Aprendemos del informe " ¿Qué debemos crear una plataforma tecnológica?" Una guía paso a paso desde la idea hasta la implementación ". Cuenta secretos Philipp Bocharov- Gerente de Proyecto para Desarrollo en MTS IT.

Después de la selección e implementación de prácticas de ingeniería, el trabajo apenas comienza: debe evaluar el resultado. Esto ayudará a las métricas: es importante comprender no solo lo que está sucediendo con la infraestructura y el hardware, sino también cómo funciona cada característica, para encontrar cuellos de botella y eliminarlos a tiempo. El informe " Configurar monitoreo y ¿qué sigue?" » Mikhail Mazein compartirá métricas sobre el ejemplo de ManyChat, una plataforma donde un millón de empresas activas se comunican con 800 millones de sus clientes. Que considerar:

  • cómo trabajar con métricas bajo carga pesada y con lanzamientos regulares;
  • cuáles monitorear primero;
  • cómo construir un proceso de respuesta rápida y aprender sobre problemas en el servicio ante los usuarios.

Equipos de plataforma


De vuelta a las plataformas. Varios equipos diferentes trabajan en su desarrollo y soporte. Son responsables de sus zonas, pero no hay nadie responsable de todo: hay dolores "a través". Los equipos de la plataforma resuelven estos problemas: crean la infraestructura para desarrollar aplicaciones y su trabajo en la producción, ayudan a trabajar más rápido y mejor, son responsables de todo. Cómo crear un equipo así y aplicar el pensamiento del producto, dice Dmitry Vishin , jefe del grupo de desarrollo de la plataforma goods.ru, en su informe “ Los equipos de la plataforma son importantes. ¿Por qué? "

Crear un equipo de plataforma no es suficiente. Debe poder no desglosarlo antes de que alguien comience a usar la plataforma. De esta manera, se pueden encontrar mapaches malvados. Sí, son los mapaches. ¿De dónde vienen los mapaches y cómo se relacionan con la estabilización del equipo de plataforma ? Aprendemos del desarrollador principal de MTS, Elizabeth Golenok, del informe " Equipo de plataforma y 4 mapaches malvados ".

Los informes se complementarán con una mesa redonda de discusión " Equipos de plataforma: beneficios o daños ". Durante la mesa redonda, Philip Uvarov (Spotify) y Andrei Alexandrov (Mafin) discutirán varios temas.

  • ¿Por qué son necesarios estos comandos y son necesarios?
  • ¿Por qué se ha puesto de moda crearlos?
  • ¿Hay algún uso para ellos o es bombo?
  • « », ?


A pesar de todas las prácticas de ingeniería y la ayuda de los equipos, el techlide escribe el código. ¿Cómo escribir de tal manera que el código sea legible y compatible, y no reescribir todo en un año? Dos informes responderán a esta pregunta.

El primero es " Cómo escribir código legible " , por Grigory Petrov , Jefe de Relaciones con Desarrolladores de Evrone. Gregory organiza desarrollo, conferencias ( Moscow Python Conf ++ ), hackatones, neurofisiólogo generalista y aficionado. Como resultado, el informe tendrá mucha neurofisiología, intuición cognitiva y social. Pero lo principal es que Gregory le dirá de dónde proviene la complejidad del código, por qué no se puede eliminar y cómo vivir con él.

El segundo es el informe " Balance de contradicciones. Selección de las mejores prácticas en el código y en el equipo » Gleb Lobastov. Gleb es asesor técnico y líder del equipo de desarrollo de OneTwoTrip con 10 años de experiencia. El informe compartirá enfoques para escribir un código "bueno", comprensible y conveniente de apoyar, y responderá varias preguntas:

  • qué considerar al implementar las mejores prácticas desde el punto de vista del proyecto y del equipo;
  • el enemigo principal del buen código y cómo lidiar con él;
  • contradicciones en la práctica de escribir un buen código.

Todo esto con ejemplos, con un conjunto de principios y prácticas para escribir código de los que puede estar orgulloso.

Herencia y refactorización


El tema del código, o más bien el código anterior, continuará en el bloque de legado y refactorización. Muchos están familiarizados con el análisis estático como una herramienta conveniente. Pero a veces surgen dificultades, por ejemplo, cuando el proyecto tiene una enorme base de datos de código heredado. Cuando el análisis estadístico encuentra errores, ¿qué hacer con ellos? ¿Cómo equilibrar las correcciones de los errores antiguos y detectar los nuevos? Aprendemos del informe " Cómo corregir cientos de errores en el código heredado y no morir (por ejemplo, Unreal Engine 4) " de George Gribkov .
Puede refactorizar no solo el código, sino también la arquitectura, la infraestructura y los procesos.
Cualquier empresa de TI de larga vida se enfrenta a una desaceleración en los procesos de producción. Es provocado por muchos factores, por ejemplo, la complejidad de la tecnología y un aumento en el número de empleados. Esto lleva al hecho de que la coordinación se retrasa, nadie tiene responsabilidad y los sistemas se vuelven frágiles. Lev Goncharov (T-Systems) en su informe " Acuerdos como código: cómo refactorizar los procesos y no desglosarlos " compartirá historias de 14 años de experiencia que ayudarán a acelerar los procesos de infraestructura y hacerlos explícitos.

Después de refactorizar los procesos de infraestructura, puede proceder a estandarizarlo. Por ejemplo, deshacerse del "zoológico" de la tecnología. Cómo hacer esto en el ejemplo de la experiencia de estandarizar la infraestructura de una aplicación grande en particular, Ilya Mitrukov le dirá- Gerente de Infraestructura (Oficial de Seguridad de Información Técnica) del Centro de Tecnología de Deutsche Bank. 

El informe " No los dioses queman ollas. Estandarización de la infraestructura ”no habrá nada sobre la actualización de tecnologías, soluciones innovadoras," Cosmos "tecnológico o tuberías de CI / CD. Solo habrá una vida de infraestructura de un par de años de proyectos, minimizando los costos y apoyando el desarrollo empresarial.

Desde el código, los procesos y la infraestructura, pasemos a la refactorización tecnológica. ¿Cómo traduzco un proyecto que compromete a 70 personas al día a React y TypeScript para que nadie se dé cuenta? Le preguntaremos a Yandex, o más bien a Evgeny Dashkevich , el jefe del grupo Yandex. En el informe " Cómo pasar a una nueva tecnología para que 70 desarrolladores no noten nada"Eugene compartirá el historial de traducción y las razones para actualizar la pila técnica en el proyecto, que genera millones de combinaciones diferentes de resultados de búsqueda por día.

DDD, tormenta de eventos y gestión del conocimiento


En esta sección de la conferencia, hablaremos sobre el diseño, utilizando los enfoques y prácticas de DDD - Diseño controlado por dominio (diseño específico de dominio). A menudo se abandona debido a que esta es una metodología sin indicaciones claras de qué y cómo hacer. Pero Raiffeisenbank ha estado utilizando prácticas DDD en varios proyectos durante 5 años para descomponer el sistema en microservicios, comunicarse con los clientes y dentro de los equipos, y crear aplicaciones que no resistan los nuevos requisitos. Cómo aplicar el enfoque, qué prácticas usar y evitar errores, aprendemos del informe de Konstantin Gustov " Cómo domesticar DDD ".

Hay muchas prácticas en DDD. Uno de ellos es la tormenta de eventos. Facilita más trabajo en el campo de DDD y diseño de microservicios. Al crear un sistema en microservicios, puede crear fácilmente un monolito distribuido. La tormenta de eventos no protege contra esto en un 100%, pero puede reducir significativamente el riesgo. Acerca de cómo, con ejemplos prácticos, en el informe de Sergey Baranov (ScrumTrek) " Modelado de microservicios utilizando Event Storming ".

Cuando descubrimos qué está haciendo el techlide, cómo desarrollar e implementar prácticas de ingeniería, pasamos a almacenar, administrar, compartir conocimientos y rastrear soluciones técnicas en un equipo. Por ejemplo, la gestión del conocimiento es necesaria cuando los desarrolladores hacen una funcionalidad similar en diferentes partes de un gran proyecto. Gastan muchas veces más tiempo y recursos en esto que si combinaran sus esfuerzos.

Ilya Kashlakov dirige el departamento de desarrollo front-end de 50 personas en Yandex.Money. Con tantos desarrolladores, es vital compartir conocimientos y vigilar la arquitectura. El informe " Revisión lógica: como herramienta para tomar decisiones técnicas complejas"Ilya hablará sobre esta herramienta: cómo se les ocurrió la Revisión lógica, qué métricas recopilaron y cómo determinaron el éxito de este proceso. Todo esto con ejemplos de problemas, una descripción de los cambios que han ocurrido en el proceso desde el comienzo hasta el día de hoy.

Para la implementación de proyectos necesitamos mucha documentación. Para almacenarlo use, por ejemplo, lenguajes de marcado livianos: Markdown, reStructuredText, Asciidoc. Son fáciles de escribir y los archivos se almacenan convenientemente en el repositorio. En el taller " ¿Cómo publicar Markdown y RST? Revisión de herramientas de documentación modernas ", hablaremos sobre cómo aplicarlas a los deslizamientos tecnológicos:

  • Konstantin Valeev (Rostelecom IT) compartirá una forma de crear PDF y HTML personalizados a partir de fuentes de Markdown;
  • Semen Faktorovich (documentat.io) hablará sobre el "cuchillo suizo" de Pandoc y cómo derrotar a la generación DOCX con él;
  • Nikolai Volynkin (Plesk): cómo generar grandes portales HTML con Sphinx-doc.

Tres oradores compartirán su experiencia y todos podrán hacerles sus propias preguntas sobre el tema.

TechLead Conf 2020 en línea para aquellos que quieren convertirse en techlida


Conferencia TechLead Conf 2020 en línea para tehlidov y aquellos que quieran convertirse en ingenieros, desarrolladores, líderes de equipos, de control de calidad y gerentes de desarrollo. Incluso si aún no es un techlide, venga a la conferencia y recopile instrucciones sobre cómo convertirse en uno: un mapa de las competencias técnicas. 

Toda la conferencia se llevará a cabo en un nuevo formato: en línea. Gracias a esto, agregamos más contenido en tres días del evento que fuera de línea: más de 30 informes, charlas relámpago (informes cortos con respuestas a preguntas), OST para el intercambio de experiencias, una mesa redonda y varios formatos de red. Hemos preparado un cronograma para el programa : mira, marca tus informes favoritos o clases magistrales en el calendario para no perderte.

Un nuevo formato: nuevos precios, para que incluso en estos tiempos extraños pueda continuar desarrollando y manteniendo contactos con colegas de otras compañías. Reserve boletos : el precio de 5900 para las personas ayudará a mantenerse al tanto de los nuevos productos en la industria u obtener una nueva profesión.

Todos los participantes de la conferencia en línea en la cuenta personal pueden ofrecer su pregunta para discusión, solicitar ayuda en una tarea de trabajo o comenzar una discusión interesante y relevante. Allí puede votar de inmediato sobre temas interesantes. Los autores de las mejores ideas recibirán un boleto gratis para la conferencia seleccionada, donde se organizará la discusión propuesta.

29 18:00 -. , maturity model.

. . live-, Spring Cloud Contract Pact. , .

More articles:


All Articles