La reunión se llevó a cabo como parte de la serie “El ingeniero entra en un bar”, donde ingenieros de diferentes empresas de TI hablan sobre temas profesionales no relacionados con la ingeniería. Los ingenieros de la empresa Miro organizaron una serie de eventos , con el apoyo de la oficina de DevRel de Dolgushev y Storozhilov .
La segunda reunión de la serie tendrá lugar el 20 de agosto. El tema es la toxicidad en equipos, empresas e industria. Ponentes: ingenieros y líderes técnicos de Miro, SEMrush, Parma TG, Xsolla. La inscripción ya está abierta .
Tabla de contenido:
- Las particularidades de la empresa y el sistema actual de desarrollo profesional de ingenieros.
- Desafíos en los sistemas de desarrollo actuales
- Cómo implementar una cultura de desarrollo al comienzo de un nuevo equipo
- Pregunta candente sobre el dinero
- ¿Cómo defiende una empresa en la que los empleados necesitan un porcentaje de su tiempo para la educación y el desarrollo?
- Encuesta de herramientas de desarrollo profesional
Las particularidades de la empresa y el sistema actual de desarrollo profesional de ingenieros.
Artyom Susekov, Jefe de Ingeniería de Software de Producto, Miro. Creamos un producto para la colaboración online de equipos, una plataforma de pizarra colaborativa online. La empresa emplea a 400 personas, algo menos de la mitad son ingenieros. Oficinas de desarrollo de productos en Perm y Amsterdam. Los equipos son multifuncionales: ingenieros, gerentes de producto, diseñadores y, si es necesario, especialistas en marketing. Usan scrum, algunos usan kanban. Para la planificación: OKR a nivel de campaña y a nivel de equipo individual.
Tenemos calificaciones y las expectativas para cada una se formulan como patrones de comportamiento específicos. Esto se hace para no detenerse solo en expectativas formales ("para hacer tantas tareas, obtener tal o cual certificado"). Es más importante que los conocimientos adquiridos se apliquen en el trabajo diario, esto es precisamente lo que se muestra en los ejemplos específicos que se describen para cada uno de los grados.
Grados estándar: Junior, Middle, Senior, hay varios pasos dentro de cada grado. Hay oportunidades después de Senior para convertirse en un especialista técnico o convertirse en líder de equipo y luego en gerente de dirección.
Existe una Revisión de desempeño, que realizamos dos veces al año. Durante el mismo, recibe comentarios de sus compañeros de equipo, los líderes del equipo reciben comentarios de aquellos que son sus subordinados directos. Además, el empleado escribe una autoevaluación, es decir, evalúa de forma independiente su trabajo.
Se resumen los resultados, después de lo cual se lleva a cabo la Conversación de Carrera: qué salió bien, qué salió bien, qué se debe enfatizar en el futuro, qué se debe trabajar. Luego, el gerente ayuda a formular un plan de desarrollo para los próximos seis meses o un trimestre.
Career onversation ( , , ), : , , .Alexander Borisov, director del Centro de competencia tecnológica de Innopolis, X5 Retail Group. Probablemente, la mayoría de la gente está familiarizada con X5. Somos propietarios de las cadenas Perekrestok, Pyaterochka y Karusel. Si hace tres años éramos una empresa que vende tomates, y ahora nos esforzamos por convertirnos en una empresa de TI que vende tomates.
La mayor parte de las ganancias proviene de nuestros servicios de TI. Cómo funciona Pyaterochka y qué precios ofrece, quizás debido a una logística bien construida y un sistema de gestión para este gran proceso. Tenemos más de dos mil especialistas en TI en la empresa, hay casi 150 personas solo en Innopolis.
Durante el año pasado, todo esto ha comenzado a transformarse de un formato de departamento a un formato de equipo de producto. Hemos dividido los servicios y productos en microservicios y subproductos, de los que un equipo puede ser responsable. Ahora tenemos Product Owners para cada producto, equipos multifuncionales, cada uno de los cuales tiene desarrolladores, probadores, analistas y parte de las funciones en las que las personas pueden superponerse entre sí.
Naturalmente, tenemos reuniones individuales, OKR, retroalimentación de 360. Interesante es la función del propietario del grupo de recursos. Estas son las personas responsables del grupo de Java, JS, Python, pruebas, análisis, etc. Cada ingeniero de la empresa tiene un líder empresarial (Product Owner) que comprende cuánto invierte una persona en un producto y cuánto beneficio genera su trabajo, y hay una persona que es responsable del desarrollo técnico en su competencia específica.
Nos negamos a formalizar la transición entre grados, como "para pasar de Junior plus a Middle menos, necesitas hacer esto y aquello". Tememos que si damos criterios claros para la transición, la gente comenzará a abordar esto de manera demasiado formal. Pero la formalidad aquí es perjudicial, porque en cada equipo todo puede ser muy individual: una y la misma persona puede asumir más responsabilidades y por ello desarrollar, o bombear en un estrecho segmento de tecnologías que nos son propias, y por ello convertirse más valioso para el negocio.
Para los puestos senior, la difusión del conocimiento es un requisito previo importante para el crecimiento. No eres un Senior en el vacío, compartes tu experiencia con el equipo y llevas el resto contigo.
Sergey Averyanov, director de tecnología de Funbox. Llevamos más de 10 años desarrollando software para los tres grandes operadores. Actualmente, contamos con unos doscientos desarrolladores de varios perfiles y un número bastante grande de técnicos especialistas en soporte técnico.
Por un lado, no tenemos un solo producto en el que esté involucrado todo el equipo, y por otro lado, no hay un gran flujo de proyectos y tareas como en el outsourcing. Aquí es donde crece nuestro desarrollo profesional específico de ingenieros. Abandonamos deliberadamente los sistemas de calificación formales: quizás esto sea lo que le gustaría a la gerencia y a los propios empleados, pero este es un sistema extremadamente inflexible que intenta estilizar a todos con el mismo pincel, lo que no siempre es posible en la práctica. En cambio, utilizamos cosas bastante estándar: evaluación periódica del progreso del empleado y conversaciones personales. Tenemos la oportunidad de evaluar objetivamente la contribución de cada uno por Task Tracker. Todo esto en conjunto nos da una comprensión del nivel de cada uno de los ingenieros.
Por otro lado, uno de nuestros principales objetivos es hacer que cada persona entienda cómo y dónde puede desarrollarse. Tratamos de tener en cuenta el hecho de que todas las personas son diferentes: alguien está interesado en trabajar como expertos técnicos, comunicarse mínimamente con la gente y no sumergirse en cosas administrativas; alguien quiere comunicarse, trabajar con personas, participar en el desarrollo de los compañeros. Todo esto es normal, todas las opciones de desarrollo son posibles.
Estamos tratando de construir un sistema que nos permita elevar el nivel de los ingenieros y brindarles una guía clara sobre lo que la empresa quiere de ellos y hacia dónde pueden ir a continuación. También prestamos mucha atención al crecimiento interno. Yo y todo el equipo creemos que el mejor especialista es el especialista que criamos dentro del equipo. Por eso, estamos invirtiendo activamente en desarrollo interno, en meetups, conferencias internas y externas. Este es también uno de los principales objetivos: el desarrollo completo y de alta calidad de todos nuestros ingenieros.
Un departamento de desarrollo abstracto no debería estar involucrado en el desarrollo de los empleados. Ésta es una de las responsabilidades del gerente de línea.
Este enfoque nos da una ventaja a nosotros y a los propios empleados. Por un lado, tenemos un crecimiento orgánico constante entre la plantilla. Por otro lado, podemos hacer de los ex juniors senior juniors y líderes de equipo, y el empleado mismo ve que su supervisor inmediato es el que era junior en este proyecto hace cuatro años, lo que significa que antes de la cooperación ahora las mismas oportunidades y pasos comprensibles para crecimiento.
Mikhail Mazein, jefe de ingeniería, ManyChat.Estamos desarrollando una plataforma de marketing SaaS que le permite organizar las comunicaciones entre las empresas y sus clientes. La empresa está creciendo activamente: hace tres años éramos 15 personas en el equipo, ahora somos más de 120. En las primeras etapas, trabajamos con equipos funcionales clásicos: backend, frontend, testing, equipos de diseño. Cada equipo tenía un líder de equipo que era responsable de la planificación del sprint y la descomposición de tareas.
En el proceso de crecimiento, nos dimos cuenta de que esto nos impedía movernos a la velocidad deseada y reformateamos el trabajo en equipos multifuncionales. Ahora tenemos nueve de estos equipos multifuncionales, no hay líderes de equipo, ya que los equipos resultaron ser autoorganizados y pueden ser responsables de la forma en que trabajan.
Para sincronizar cosas funcionales, desarrollamos enfoques comunes para que el desarrollo no se convierta en anarquía. Esto es necesario, por ejemplo, cuando los desarrolladores de backend están distribuidos en diferentes equipos, pero trabajan con un proyecto, con una base de código y envían código allí. Organizamos comunidades funcionales para abordar estos problemas. Con el tiempo, aparecen líderes informales en las comunidades que impulsan los procesos y las comunicaciones. El resultado es una estructura plana que no limita el rol del desarrollador al rol de un ingeniero que solo escribe código, sino que le permite hacer varias cosas que son útiles para la empresa y al mismo tiempo interesantes para la persona misma.
Dado que abandonamos el rol de líder de equipo, necesitábamos un proceso que nos permitiera construir de manera clara y transparente vías de crecimiento para los ingenieros. Para ello, utilizamos un sistema de mentoring: cada colaborador tiene un mentor que es responsable de su crecimiento y desarrollo dentro de la empresa.
No puedes simplemente acercarte a una persona al azar y decirle: "Déjate ser un mentor". Primero, se deben reunir varios factores: el deseo de la persona misma; alto nivel de confianza en el equipo hacia la persona; confianza de la propia empresa y de la dirección. Una de las tareas de un mentor es formar nuevos mentores. Resulta tan incipiente, de mentor a mentor.
Distinguimos tres vectores principales de desarrollo:
- La primera gran pista es un trabajo más profundo en el equipo de productos para el desarrollo de productos, con una comprensión más profunda de los valores y métricas comerciales.
- – , , .
- – , .
También intentamos crear un sistema de calificación: todavía no podemos describir formalmente todas las calificaciones, por lo que el sistema se construye al nivel de la contribución de una persona, el nivel del equipo, el nivel de toda la empresa. Describimos expectativas en cada nivel, qué área de responsabilidad o área de influencia esperamos de una persona, con ejemplos claros. El mentor, por otro lado, puede decirle a una persona qué habilidades deben bombearse para llegar al punto deseado.
Anton Grishin, director de desarrollo de MadRobots. A primera vista, nuestra empresa es un comercio electrónico que se ocupa de dispositivos, pero en general nos dedicamos a la distribución en Rusia y al desarrollo de marcas de cosas interesantes.
Nuestro equipo se ha reunido hace relativamente poco, por lo que todavía no tenemos el dolor de cabeza asociado con el desarrollo de ingenieros dentro de la empresa. Antes de Madrobots, trabajé en outsourcing durante 6 años, tres de los cuales estuvieron directamente a cargo de la producción en la agencia, y me gustaría contarles más sobre esta experiencia.
En la subcontratación, nuestro dolor fue un gran flujo de proyectos y rotación de personal, en la subcontratación este es siempre el caso. Decidimos que necesitábamos superar esto de alguna manera y comenzamos a invertir en el desarrollo de los empleados.
Sí, teníamos un sistema de calificación, una vez cada seis meses una persona recibía retroalimentación de un gerente técnico, construyendo su propio camino con él durante los próximos seis meses.
, . , . , , , .
Posteriormente, tuvimos otro dolor. En la corriente de proyectos, de los que a menudo había bastantes, la gente perdió el enfoque en el desarrollo personal. Esto no se debió a que no tuvieran tiempo suficiente, sino a que estaban cansados de la cantidad de tareas que tenían que realizar. Introdujimos la práctica de las reuniones uno a uno, una vez al mes, que tenían como objetivo hablar con una persona y recordarle que tienes un plan de desarrollo y que realmente debes cumplirlo. Si necesita algo de tiempo para esto y debe liberarse de la rutina o constante fuera del sitio, hablemos de ello, porque su punto de control se acerca y necesita hacer algo al respecto. Eso ayudó. Por regla general, esto lo hacían los PM de los equipos, porque quienes, si no ellos, sabían mejor en la planificación de recursos para el futuro.
Desafíos en los sistemas de desarrollo actuales
Artem Susekov, Miro. Es difícil equilibrar el sistema de calificación de inmediato, por lo que avanzamos en iteraciones. Por ejemplo, la primera versión de la pista del líder del equipo resultó estar sobrecargada: expectativas demasiado altas, un súper soldado universal, lo que difícilmente es posible en la vida.
Actualmente estamos tratando de simplificar el umbral para ingresar al rol de líder del equipo para facilitar que las personas cambien de una rama puramente de ingeniería a una rama de gerente. No quiero sobrestimar el listón, necesitamos una oportunidad para avanzar sin problemas hacia este nuevo campo de actividad.
Otra dificultad es el enfoque demasiado formal del proceso. Por ejemplo, "Hice 8 de 10 puntos en el plan, lo que significa que cumplo con las expectativas y puedo pasar al siguiente nivel". No queremos convertir todo esto en una lista de verificación que solo necesita cerrar para pasar al siguiente nivel, como en un juego.
Me gustaría que la gente pudiera pensar en los prospectos sobre la base del plan, pensar por su cuenta en áreas de interés para ellos, es decir, para que trabajen con esto como una estrategia y no como una lista de tareas formales.
Alexander Borisov, Grupo minorista X5. Las personas a menudo no comprenden exactamente cómo pueden crecer en una empresa, porque no existen algoritmos claros. Al mismo tiempo, las personas que realmente ya pueden ser promovidas encuentran cosas en las que pueden y deben crecer, aquellas cosas que se pueden asumir y mejorar. Pero sucede que es necesario "simplemente crecer". Pero probablemente sea imposible crecer en la empresa así, porque quieres crecer.
Solo creces cuando asumes más responsabilidades, asumes nuevos proyectos.
Sergey Averyanov, Funbox . Como llevamos muchos años trabajando, hemos tenido muchos problemas y desafíos. Uno de los primeros es entender con quién queremos trabajar, con quién queremos desarrollarnos. Como resultado, llegamos a la conclusión de que queremos trabajar con personas que sepan cómo hacer algo bien, y realmente no importa en qué. De buena gana tomamos especialistas de cualquier pila que estén listos para usar lo que usamos. Esta resultó ser una práctica bastante exitosa: siempre es agradable y conveniente desarrollar personas que ya tienen competencia en un área temática relacionada. La brecha de conocimiento que tienen no es un defecto fatal, sino una nueva motivación para una persona, el estudio de un nuevo campo de actividad.
El segundo desafío es comprender cómo pueden crecer los ingenieros de la empresa. Para el desarrollo, es necesario crear condiciones de trabajo cómodas: una oficina normal, procedimientos y normas laborales claros, simples pero estrictos, cumplimiento del Código de Trabajo, disgusto por el exceso de trabajo. Todo esto le da a una persona la confianza de que puede aumentar su nivel sin problemas, sin prisas. Le mostrarán, le dirán, le ayudarán.
Puedes gritarle a las papas tanto como quieras: “¡Papas, crezcan! ¡Tomates, vamos! ”, Pero no crecerán con esto. Necesitan buena tierra y riego.
El desafío final es que no todas las personas quieren crecer donde queremos que crezcan. Sucede que un especialista fuerte bajo ninguna circunstancia quiere lidiar con la carga administrativa y trabajar con colegas más jóvenes. Aquí la cuestión no está en las cosas formales, ni en el salario, sino simplemente en lo que una persona tiene interés e inclinación. Es por eso que en todos los ingenieros valoramos la pasión, la capacidad de tomar una tarea compleja y llevarla a cabo a través de un proceso de varios pasos de principio a fin. Como regla general, cualquier ingeniero que sea capaz de esto es interesante y agradable para nosotros. Pero, como dije, al mismo tiempo siempre dejamos la oportunidad para que una persona se convierta en un experto técnico sin sumergirse en funciones administrativas y de gestión.
Mikhail Mazein, ManyChat... Ya es bastante difícil formalizar los requisitos para las calificaciones, y tampoco intentamos formalizarlos estrictamente, centrándonos en ejemplos de expectativas de lo que nos gustaría ver de un ingeniero en diferentes etapas de desarrollo. Todo esto se envolvió en un impacto específico que las personas aportan a los procesos a nivel de equipo o empresa.
Esto crea dificultades. Por un lado, no limitamos a las personas en crecimiento, aparece un lienzo en blanco frente a ellos, en el que pueden dibujar su pista de desarrollo. Pero dibujar una nueva imagen en una hoja de papel en blanco es mucho más difícil que moverse por el camino trillado. Resolvemos este problema mediante la tutoría. Los mentores ayudan a construir pistas basadas en los deseos de las personas y sincronizándolas con las necesidades de la empresa. También tratamos de desarrollar la mentalidad de búsqueda de problemas para que los ingenieros detecten los problemas en los procesos e intenten iniciar su solución ellos mismos. En esto, nuevamente, los mentores ayudan.
Anton Grishin, MadRobots.Hay personas para quienes el crecimiento es su propia necesidad, y hay personas que crecen porque así está establecido alrededor y para eso se han creado las condiciones. Pero todos ellos periódicamente tienen una pregunta: ¿para qué? Se pierde la motivación personal para aprender cosas nuevas, para el desarrollo, porque esto puede no ser aplicable en las realidades actuales o con los compañeros actuales.
Como una de las soluciones, realizamos encuentros internos, pero no como un grupo de hobby, sino como una conferencia interna, con una preparación real de un nuevo tema. De esto surgió una historia positiva, los chicos comenzaron a entender entre ellos que si, por ejemplo, los frontends pueden hacer algo nuevo, entonces nosotros, diseñadores y diseñadores, podemos repensar nuestros enfoques y probar nuevas herramientas. Resulta que la motivación natural de cada uno para intentar hacer algo nuevo juntos.
El dolor siempre provoca el acercamiento personal de cada individuo a su propio desarrollo.
Cómo implementar una cultura de desarrollo al comienzo de un nuevo equipo
Sergey Averyanov, FunBox: El hecho mismo del crecimiento de la empresa nos ayudó. Cuando no hay muchos ingenieros, todos cocinan juntos, todos se conocen y hacen el mismo tipo de tarea. Y tan pronto como los diferentes tipos de proyectos y roles en ellos comienzan a alinearse, entonces todas las personas se vuelven dotadas de diferentes poderes. Alguien hace tareas, alguien está involucrado en implementaciones, clústeres, alguien está involucrado en el diseño de productos.
Es importante para nosotros que cada miembro del equipo comprenda lo que necesita actualizar para pasar de desarrollador a desarrollador de nivel superior o líder de equipo.
, 125 , , , , .
Las reuniones internas son muy útiles. Cuando una empresa tiene muchos equipos y varios productos, cada persona cocina en su propia salsa y en las reuniones hablan, cuentan qué cosas interesantes hacen, intercambian conocimientos. Esto no genera competencia entre equipos, sino la búsqueda de la excelencia.
Artem Susekov, Miro: En una etapa del crecimiento del equipo, varios gremios que se forman alrededor de tecnologías ayudan bien: backend, frontend, QA. En los gremios, el conocimiento se intercambia entre diferentes equipos.
Los eventos internos también ayudan: reuniones, revisiones públicas de Sprint, donde los equipos comparten un contexto común, hablan sobre los resultados. Aquí es importante ayudar a los ingenieros a prepararse para tales actuaciones.
Alexander Borisov, Grupo minorista X5:No puedes esperar que digas que se necesitan reuniones y que la gente comience a organizarse. También necesitan ser tratados. En el caso de nuestra escala, tiene sentido destacar a las personas responsables que la organizan. Los equipos suelen tener cosas interesantes dentro, pero cocinan dentro de sí mismos, simplemente no tienen tiempo suficiente para organizar una reunión y compartir sus mejores prácticas. Parece que nos hubiéramos tomado media hora, nos hubiéramos reunido en una sala de reuniones y gastado, pero no. Hay algunos matices.
Mikhail Mazein, ManyChat: Un proceso de incorporación bien estructurado para nuevas personas le permite transmitirles los principios y enfoques generales, para formar correctamente una imagen del equipo y el proyecto. Entonces la cultura con la llegada de nuevas personas se acumulará y se transmitirá.
Pregunta candente sobre el dinero
Una pregunta de un espectador: “No está tocando la solidez financiera de la organización. ¿Cómo se determina la parte de los gastos de la empresa para que el empleado lea libros durante el horario laboral? El segundo es un ejemplo, deje que la solución de un problema tome 80 horas para un desarrollador que ya ha resuelto tal problema, y 150 horas tomará la solución del mismo problema para un desarrollador que no está familiarizado con el contexto, pero al mismo tiempo crecerá y bombeará. La pregunta es quién pagará la diferencia de 70 horas dedicadas al desarrollo ".
Alexander Borisov, Grupo minorista X5:En nuestro caso, no hay cliente. Comenzamos a construir activamente un equipo interno en lugar de continuar subcontratando algunas cosas, porque entendemos que la competencia es muy costosa para nosotros y resulta en costos finales, al aumentar la marginalidad del negocio, de un Pyaterochka en particular cerca de su hogar. Es una inversión de futuro.
Pero si una persona, en lugar de hacer una tarea durante tres horas durante 150 horas, se dedica a leer un libro, la pregunta surgirá solo del propietario del producto o del propietario del grupo de recursos. Si se trata de una inversión comprensible en el hecho de que una persona ha crecido, entonces, nuevamente, al nivel de estas dos personas, esto se resuelve fácilmente. Por ejemplo, un plan para un sprint, respectivamente, dentro de él colocamos algo que será necesario leer, y encajamos en él, esta es una historia normal.
Artem Susekov, Miro:Existe un convenio a nivel de empresa que ayudamos a los ingenieros a desarrollarse a través de cursos y talleres, que se realizan dentro del horario laboral. Es decir, la empresa lo paga, es una inversión en cada miembro del equipo, porque creemos que este tipo de inversión ayudará a que todo el equipo se mueva más rápido en el futuro.
El tiempo específico reservado para el ingeniero para la educación dentro del sprint se discute a nivel de equipo específico. Es importante aquí que no haya distorsiones en la otra dirección, que todo el tiempo durante el sprint solo estudiemos y no hagamos nada más.
Sergey Averyanov, FunBox:Creo que la pregunta sobre 80 y 150 horas es más aguda para la subcontratación, cuando se puede preguntar: ¿por qué un desarrollador sin experiencia debería hacer 150 horas por mí, como cliente, si un desarrollador experimentado hizo lo mismo por mí después de 80? Cómo la subcontratación resuelve esto, no puedo decirlo, porque no estamos subcontratando. En el marco de una empresa de productos, esto se resuelve por el hecho de que el presupuesto se consolida, y los costos laborales para el desarrollo se expresan en utilidad debido a que un miembro del equipo sube de nivel, comienza a trabajar mejor, más rápido.
Sobre la lectura de libros en horario laboral. Tenemos la práctica de que la necesidad de aprender algo es un paso completamente natural para trabajar en un problema. No arrojamos al desarrollador a una vorágine, estableciendo tareas como: "Leer un libro" o "estudiar una tecnología que no tiene un objetivo final". No debe ser tal que una persona se siente y piense: ¿ya he estudiado la tecnología o necesito estudiar más? Una tarea fuera del contexto, fuera del objetivo conduce a la dilación, al hecho de que una persona pierde la confianza en sí misma y no sabe cuándo hacer algo.
Investigar y leer literatura, estudiar cualquier cosa, debería ser parte de la tarea, pero debería haber un objetivo tangible final al cual este estudio pueda aplicarse.
Anton Grishin, MadRobots: Soy de un mundo donde cada hora alguien gana y alguien pierde dinero. Como regla general, al cliente se le dice honestamente: "No tomaremos más dinero de usted, pero haremos la tarea por más tiempo". La empresa, su empleador, paga de todos modos el desarrollo de un ingeniero. El cliente simplemente espera un poco más, pero en el futuro se da cuenta de que ahora no uno, sino dos desarrolladores están comprometidos en el desarrollo de su producto, todo se resuelve más rápido, la escala de implementación está aumentando.
En los estudios y agencias, donde los procesos normalmente se construyen, nunca se pondrá al desarrollador en un proyecto que objetivamente no lo atraiga, porque traerá más pérdidas a la empresa de las que ganará en desarrollo.
Alexander Borisov, Grupo minorista X5:Además de mi trabajo en X5, tengo mi propio pequeño estudio de subcontratación. Entiendo muy bien su economía. Establecimos 80 horas pagadas, pero entendimos que eran 150, y la cantidad de horas pagadas y el tiempo de desarrollo, muy a menudo diferían. Siempre tomamos algún tipo de acciones y simplemente las pagamos con nuestro propio dinero. Si en algún lugar existe algún tipo de fuerza mayor, significa que se paga con su propio dinero.
Mikhail Mazein, ManyChat: El desarrollo de productos, donde no tenemos un cliente externo, nos desata mucho en este sentido. En general, no hacemos un seguimiento del desempeño de cada individuo, medimos el desempeño del equipo.
Cada equipo tiene su propia capacidad y velocidad, pueden variar mucho, pero en general, nos enfocamos en el desempeño de todo el equipo en su conjunto. El tiempo libre que tiene un ingeniero en particular en el sprint actual no es muy importante para nosotros, como empresa, este tiempo siempre queda para entrenar, y de sprint a sprint, en principio, es diferente para cada ingeniero. En algún lugar del sprint, habrá más carga en la interfaz, en el próximo sprint habrá más carga en el backend, y toda esta historia se nivelará a largo plazo.
Si hablamos de evaluar el desempeño de cada persona individual, el propio equipo es el responsable de ello, es como una estructura autorreguladora. Hay situaciones en las que la retroalimentación proviene, por ejemplo, del mentor de esta persona, de que algo anda mal con el desempeño, o de sus compañeros de la comunidad funcional.
, ?
, Miro: , , . , , … , .
Sergey Averyanov, FunBox: Creo que puede haber empresas que se centren en especialistas de nivel fijo, siempre tienen el mismo trabajo con las mismas calificaciones, no quieren criar a nadie. Esto se resuelve por el hecho de que hay una gran rotación y los empleados que podrían crecer encuentran nuevos trabajos. O invertimos en el desarrollo de los empleados y la expansión de la empresa, o tenemos una facturación.
Artem Susekov, Miro: Esto ya se puede calcular, si hablamos de facturación, nos ceñiremos a esta métrica, si se trata de dinero, ¿verdad? El costo de atraer a cada nueva persona, cuánto tiempo se dedica a los reclutadores, cuánto gastamos en onboarding y cuánto luego, cuando la persona se va, cerramos la vacante nuevamente. Todo esto se puede contar en dinero.
Sergey Averyanov, FunBox:Por cierto, un indicador interesante que incluso es útil para uno mismo es el período medio de trabajo en la empresa. Nos permite estimar la rotación, es decir, cuántas personas trabajan en nuestra mediana. Cuando ves que la mediana es grande y en los bordes de esta distribución hay personas que han trabajado de ocho a diez años, no se han agotado, les va bien y todos están contentos entre sí, me hace feliz.
Anton Grishin, MadRobots: Me parece que ahora el negocio no necesita explicar todo esto, es obvio que la necesidad de autodesarrollo es inherente a las personas que crean productos intelectuales. Por tanto, ni siquiera puedo pensar en ejemplos en los que se necesiten especialistas del mismo nivel, porque las mismas tecnologías que utilizamos nos dictan lo que necesitamos desarrollar.
Mishanya Storozhilov, Oficina de DevRel:Me parece que no se trata solo de personas con rendimiento fijo y tecnologías fijas. Creo que esta historia también trata de una gran refactorización, una gran deuda técnica. Trabajamos con empresas que comprenden la necesidad de desarrollar ingenieros, pero siempre surge la cuestión de justificar el costo de la educación y el desarrollo.
Sergey Averyanov, FunBox:Aquí sonó la palabra "refactorización" y la actitud al respecto puede ser interesante. Mucha gente piensa erróneamente, especialmente los especialistas no técnicos, que estos son algunos gestos extraños de tipos en suéteres que no hacen nada y gastan dinero. El problema aquí está precisamente en la comunicación, es decir, el gerente debe entender que la refactorización que no sucedió hoy es el aumento del tiempo de desarrollo mañana. Hoy ahorraremos algunas horas hombre y mañana las gastaremos.
Internamente hemos acordado que el líder del equipo tiene derecho a decir que una condición necesaria para completar la tarea es llevar a cabo una refactorización, sin él nos da tanta tontería que es imposible trabajar con él.
Naturalmente, esto es en última instancia una cuestión de acuerdo, pero no vemos la refactorización como una actividad secundaria y un desperdicio de recursos, sino como parte del flujo de trabajo.
Artem Susekov, Miro: Si hablamos de desarrollo de productos, los acuerdos son importantes. Por ejemplo, el gerente de producto determina las prioridades en función de la puntuación, y el equipo o la voz del equipo, el líder tecnológico o el líder del equipo, determina exactamente cómo hacerlo. El producto dice lo que es más importante ahora, el ingeniero dice cómo lo vamos a hacer.
La refactorización es un proceso natural. Refactorizar hoy nos costará mucho más barato que refactorizar en un trimestre. Es como con un préstamo: si no paga, la próxima vez tendrá que pagar más.
Alexander Borisov, X5 Retail Group: Existe un término "deuda técnica", y justo en la etapa de comunicación entre el equipo y el producto, entendemos que si no lo hacemos ahora, se trata de una deuda técnica. En consecuencia, la deuda técnica a través del sprint será mayor, en seis meses será aún mayor y tendrás que pagar con este porcentaje. De hecho, al igual que con un préstamo regular, exactamente de la misma manera el equipo negocia con el producto, si lo desea, más rápido o más humanamente. Si es más rápido, algún día tendrás que pagar mucho más. Como con un préstamo.
Mishanya Storozhilov, DevRel-bureau: O esta deuda simplemente se convierte en una “hipoteca técnica”.
Reunimos a cinco ingenieros, hablaron solo una hora y media y ya empezaron a hablar de refactorización.
* * * El
segundo encuentro de la serie tendrá lugar el 20 de agosto . El tema es la toxicidad en equipos, empresas e industria. Los ponentes son ingenieros y líderes técnicos de Miro, SEMrush, Parma TG, Xsolla.
Las inscripciones están abiertas .