Cuando alguien se convierte en el jefe de desarrollo, una gran cantidad de tareas nuevas e inesperadas seguramente recaerán sobre él, y la adaptación ciertamente tomará tiempo. Sin embargo, el período de adaptación terminará algún día, y luego la pregunta será cómo seguir desarrollándose. No menos relevante es la cuestión de preparar a un empleado para el papel futuro de un líder. ¿Cómo trabajar con el desarrollador para que el futuro líder sea expulsado de él lo antes posible?
Elegimos el camino de desarrollo para los gerentes de desarrollo como tema para la próxima reunión de líderes de equipo , que tendrá lugar la noche del 28 de noviembre en la oficina de Yandex en Moscú. Será posible discutir este tema con expertos de grandes empresas de TI. El registro aún está abierto.
Esta vez nuestros expertos son:
- Nikolay Krapivny, jefe de desarrollo de backend, Badoo
- Roman romas1982 Ivliev, CTO, mos.ru
- Alexander Polomodov, Jefe de Investigación y Desarrollo, Tinkoff.ru
- Boris Tobotras, Director, Centro de Soluciones de Software, Jet Infosystems
- Victor Lamburt, jefe de productos recomendados, Yandex
- Igor Kuralenok, CEO, Liga de Expertos
Hoy en Habré les hacemos una serie de preguntas para establecer el tono para futuras discusiones:
1. ¿Qué consejo le darías a tu colega, un desarrollador fuerte que recientemente, ayer, se convirtió en un líder de equipo? ¿Qué acciones específicas y comprensibles debería comenzar su trabajo en una nueva posición?
2. ¿Qué libros o artículos recomendarías leer al gerente de desarrollo? ¿Y qué recursos tiene sentido estudiar regularmente?
3. ¿Cuánto tiempo cuesta trabajar en tareas técnicas y cuánto tareas relacionadas con la gestión de equipos? ¿Qué más puede o debe un tímido pasar su tiempo?
Nikolay Krapivny , jefe de desarrollo de backend, Badoo
¿Qué consejo le darías a tu colega, un desarrollador fuerte que recientemente, ayer, se convirtió en un líder de equipo? ¿Qué acciones específicas y comprensibles debería comenzar su trabajo en una nueva posición?
Yo recomendaría para empezar:
- Comprender de qué es ahora responsable y cuáles son sus principales responsabilidades como líder de equipo
- Coordinar con el gerente las principales metas y objetivos para él y su equipo.
- Hable con los miembros del equipo, descubra cómo funciona el equipo ahora
- Vea el informe de la delegación y aprenda cómo hacerlo.
- Asigne regularmente tiempo para leer artículos, libros, ver informes sobre nuevas áreas de responsabilidad para él
¿Qué libros o artículos recomendarías leer al gerente de desarrollo? ¿Y qué recursos tiene sentido estudiar regularmente?
Para el gerente de desarrollo, recomiendo leer:
- "Cómo funciona Google" por Eric Schmidt
- "Reglas de trabajo" por Laszlo Bock
- "La meta" de Eliyahu M. Goldratt
De manera regular, creo que vale la pena seguir materiales y actuaciones con Teamlead Conf y otras manifestaciones temáticas (por ejemplo, las manifestaciones de Tadoo de Badoo )
Además, se pueden encontrar muchos enlaces y debates útiles en los canales temáticos en Telegram: https://t.me/leadgr y https://t.me/TeamLeadTalks
¿Cuánto tiempo cuesta trabajar en tareas técnicas y cuánto, en tareas relacionadas con la gestión de un equipo? ¿Qué más puede o debe un tímido pasar su tiempo?
Creo que no hay una única respuesta correcta. La tarea del líder es precisamente evaluar una situación específica y decidir por sí mismo cómo distribuir su tiempo para lograr los máximos resultados.
En mi mundo ideal, cuanto menos tiempo lleve dirigir un equipo (incluyo funciones técnicas y de gestión en la gestión), mejor. Creo que la clave del éxito y un mayor crecimiento para el liderazgo es construir un equipo que trabaje eficientemente con una participación mínima. En este escenario, el líder puede y debe invertir el tiempo libre en la búsqueda de nuevas ideas y proyectos útiles fuera del área de responsabilidad actual.
¿Qué consejo le darías a tu colega, un desarrollador fuerte que recientemente, ayer, se convirtió en un líder de equipo? ¿Qué acciones específicas y comprensibles debería comenzar su trabajo en una nueva posición?
- Es hora de descargar soft-skiz. La ingeniería es buena, pero ahora hay personas con quienes trabajar de una manera completamente diferente. La ingeniería se desvanece en el fondo. Pueden leer, pueden escuchar conferencias, pueden todos juntos. No ocurre mucha información sobre este tema.
- Aprende que ya no eres desarrollador. La codificación se desvanecerá en el fondo. Se romperá, pero es inevitable. En consecuencia, debe decidir qué trabajo técnico le queda, para elegir solo lo más importante. Comience a distribuir el resto a sus colegas.
- Busque urgentemente un reemplazo en su lugar. Después de todo, desde que te convertiste en líder, en algún lugar se formó un agujero en lugar de un buen ingeniero, y se recordará a sí mismo en el primer proyecto :))
- Inmediatamente crea un modo para ti. Al principio, no hay suficiente tiempo para todo salvajemente, debe dedicar mucho más tiempo a la planificación. Y adéntrese en el hecho de que algo no está yendo según lo planeado. La toma de decisiones impulsivas perseguirá la primera vez. Bueno, el deseo de codificar todo :)
- Inmediatamente comience a construir un mapa de comunicaciones y establecer comunicaciones. En el nivel principal, la cantidad de comunicación es mucho mayor, sería mejor saber de inmediato con qué temas contactarse.
¿Qué libros o artículos recomendarías leer al gerente de desarrollo? ¿Y qué recursos tiene sentido estudiar regularmente?
Hay muchos libros buenos, me centraré en los principales, como me parece.
- Brooks "Hombre-mes mítico, o cómo se crean los sistemas de software", solo necesita leerlo, porque es un clásico.
- Tom Demarco y Timothy Lister. “El factor humano. Proyectos y equipos exitosos ”: estos chicos son generalmente geniales, se pueden leer en su totalidad, lo que resultará útil. Además de esto, también diría "aquellos que están sobrios por los patrones de adrenalina y zombis. Patrones de comportamiento del equipo del proyecto ".
- Patrick Lensioni. “Cinco vicios del equipo. Las parábolas del liderazgo ". Patrick es genial, puedes leerlo tanto como puedas.
- Agua de lluvia "Cómo pastar gatos", pero este trabajo no es para todos. Entre aquellos con quienes tuve ocasión de discutir este libro, las opiniones estaban divididas.
Se requiere algo sobre negociaciones, sobre inteligencia emocional y la capacidad de comunicarse con las personas. Puedes Gavin "Puedes estar de acuerdo en todo", Goulston "Te escucho", "No le gruñas al perro" de Karen Prior.
Recurso más difícil. Por lo general, encuentro materiales interesantes en Medium , Habré , GeekTimes , infoq.com , blogs de personas respetadas como Joel Spolsky. Me suscribí a varios canales de administración, donde los enlaces interesantes se omiten constantemente, los miro y, al mismo tiempo, estudio el recurso en el que están publicados. Por lo tanto, puede encontrar muchos sitios y blogs no muy conocidos, pero con muy buen contenido. Puede leer vc.ru , el boletín de Megaplan a veces arroja algunos buenos materiales.
¿Cuánto tiempo cuesta trabajar en tareas técnicas y cuánto, en tareas relacionadas con la gestión de un equipo? ¿Qué más puede o debe un tímido pasar su tiempo?
Todo depende de cómo sea el proyecto, equipo, empresa. Conocí proporciones completamente diferentes, pero la mayoría de las veces es algo así como el 100% del tiempo para tareas técnicas y el 46% del tiempo para la gestión :))) Siempre termina igualmente mal. En mi humilde opinión, en realidad, la proporción más correcta se parece a esto. El tiempo para tareas técnicas es 100% menos el tiempo para la gestión del equipo. 100% no son 8 horas, si eso. Cada uno tiene su propio 100%. En otras palabras, la figura está flotando.
Es necesario dedicar tiempo a la autoeducación, ampliando los horizontes de uno en áreas relacionadas (gestión de productos y proyectos; si es un backend, pegue una varita en el frente, pruebas, operación y viceversa, por supuesto), manteniendo la forma técnica: nuevos marcos, bibliotecas, idiomas, todo lo que de alguna manera se relaciona con el trabajo. De lo contrario, existe el riesgo de perder credibilidad entre los ingenieros. Debe asistir a reuniones y conferencias para ampliar sus horizontes y buscar respuestas a sus preguntas.
Alexander Polomodov , Jefe de Investigación y Desarrollo, Tinkoff.ru
¿Qué consejo le darías a tu colega, un desarrollador fuerte que recientemente, ayer, se convirtió en un líder de equipo? ¿Qué acciones específicas y comprensibles debería comenzar su trabajo en una nueva posición?
Pare y responda sus preguntas:
- Lo que se espera de mí en una nueva posición.
- Quién y qué roles juegan actualmente en el equipo:
- Quién está en la lista de clientes del equipo (es uno o varios)
- ¿Quién tendrá que informar?
- Qué empleados ya están en el equipo.
- Quién tendrá que comunicarse horizontalmente (otros leads de desarrollo, leads de infraestructura, pruebas, ...)
- Qué objetivos enfrenta el equipo y cuáles son las expectativas de los resultados de sus actividades.
Además, teniendo en cuenta los resultados de las respuestas a estas preguntas, es necesario elaborar un plan para quién entregar las viejas responsabilidades y cómo aceptar las nuevas. Debe tenerse en cuenta que después de la transición a la posición de líder del equipo, habrá más comunicación, pero menos tiempo para el desarrollo. Es muy importante tener en cuenta los criterios de éxito, de acuerdo con los cuales usted y su gerente comprenderán que está enfrentando con éxito un nuevo puesto.
Si pasamos a la segunda pregunta sobre acciones específicas y comprensibles, puedo decir que no existe una lista de acciones comprensibles que se adapte universalmente a todas las situaciones, lo que significa que debe hacer una lista de este tipo según su situación.
¿Qué libros o artículos recomendarías leer al gerente de desarrollo? ¿Y qué recursos tiene sentido estudiar regularmente?
Destacaría el libro Mythical Man-Month de Frederick Brookes. Este es un clásico sobre los problemas del equipo en grandes proyectos, en el que se discute en detalle el proyecto de IBM para desarrollar OS 360. También encuentro que los libros de Tom Demarco son muy útiles, especialmente The Human Factor y The Patterns of Behavior of Project Teams. Y para un refrigerio, recomendaría el libro de J. Hank Rainwater, "Cómo pastar gatos".
Entre los recursos en línea, leí el hilo de administración de Habré y me familiaricé con los discursos en los hilos de administración en grandes conferencias, como RIT, Highload ++, Codefest y otros.
Uno de mis pasatiempos es el desarrollo en el sentido amplio de la palabra, incluida la gestión de los equipos de desarrollo. Y publico mis pensamientos, impresiones de libros que he leído, asistí a conferencias y reuniones en mi página de Facebook . Quizás esta página te sea útil.
¿Cuánto tiempo cuesta trabajar en tareas técnicas y cuánto, en tareas relacionadas con la gestión de un equipo? ¿Qué más puede o debe un tímido pasar su tiempo?
Es imposible decir claramente en qué proporción distribuir el tiempo entre las tareas técnicas y el equipo, porque depende en gran medida del equipo específico y sus tareas. En general, podemos decir que la solución de problemas técnicos se vuelve secundaria para que el equipo trabaje eficientemente. En mi opinión, el líder del equipo debería dedicar tiempo a:
- trabajar con clientes externos y actuar como una interfaz de equipo para el mundo exterior
- Organización del proceso de desarrollo y entrega rítmica del código.
- Aumentar la efectividad de los miembros del equipo: capacitar y consultar a colegas
- entrevistar a nuevos muchachos con el crecimiento del equipo
- resolver problemas técnicos (escribir código, revisar, ...)
¿Qué consejo le darías a tu colega, un desarrollador fuerte que recientemente, ayer, se convirtió en un líder de equipo? ¿Qué acciones específicas y comprensibles debería comenzar su trabajo en una nueva posición?
Le diría: querido amigo, tienes una tarea terriblemente interesante: incluir en tu imagen del mundo no solo la tecnología, sino también las personas, los proyectos y sus complejas relaciones. Esto le permitirá resolver problemas cualitativamente más complejos que un desarrollador líder por sí solo no puede resolver. Para hacer esto, debe aprender a ver no solo lo que hacemos en el trabajo diario del proyecto, sino también para qué lo hacemos, cómo y por qué.
Supongamos que el tímido recién horneado cae en este nuevo proyecto por sí mismo. Puede comenzar obteniendo respuestas a preguntas específicas:
- ¿Cómo es el proyecto en el que trabaja el equipo? ¿Qué objetivo debería alcanzar, quién y cómo juzgará su logro?
- ¿Quién está en el equipo? ¿Qué tipo de personas son, cuál es su experiencia, especialización, características de su trabajo?
- ¿Con quién interactúa el equipo? ¿Qué espera el proyecto del desarrollo y, a su vez, qué espera de los equipos relacionados (analistas, control de calidad, arquitectos, fuerza de ventas, soporte de ingeniería)?
- ¿Con quién interactúa personalmente el líder del equipo? ¿Qué espera el gerente de proyecto de él, qué espera el equipo de él, qué esperan de él los líderes de los equipos relacionados? ¿Qué problemas ven en el desarrollo?
- ¿Cuál es el estado del proyecto? ¿Dónde estamos ahora, qué se ha hecho y qué queda? ¿Hemos terminado o no, y por qué? ¿Cuáles son los problemas conocidos en el proyecto ahora: técnicos, organizativos, humanos?
¿Qué hacer primero?
- Conozca en detalle quién hace qué y dónde.
- Analice la cartera de pedidos, lea todo el rastreador de proyectos, mire las últimas confirmaciones y revisiones.
- Comprender la metodología de gestión de proyectos (estilo de código, VCS / sucursales, ensamblajes, flujo de trabajo en el rastreador, versiones compatibles, artefactos emitidos).
- Comprenda en detalle la arquitectura del sistema que se está desarrollando con su historia (qué decisiones se tomaron y por qué).
¿Qué libros o artículos recomendarías leer al gerente de desarrollo? ¿Y qué recursos tiene sentido estudiar regularmente?
Brooks, mítico hombre-mes. Nada ha cambiado en el último medio siglo.
Alan, Colston, La piedra de los programadores.
¿Cuánto tiempo cuesta trabajar en tareas técnicas y cuánto, en tareas relacionadas con la gestión de un equipo? ¿Qué más puede o debe un tímido pasar su tiempo?
Apenas hay recetas aquí. Bueno, vamos a sacarlo de la linterna: 70% en tecnología, 30% en personas. Pero esta proporción varía con el tamaño del equipo. Si el equipo tiene 15 personas (monstruosamente una gran cantidad de IMHO por plomo), la proporción es del 5% / 95%.
Además de las tareas "internas" (equipo + personas), Timlid también resuelve las "externas": la gestión de la velocidad de desarrollo y el alcance del proyecto, junto con los planes de gestión para trabajar en el proyecto, predice el empleo de los desarrolladores
Victor Lamburt , jefe de productos recomendados, Yandex
¿Qué consejo le darías a tu colega, un desarrollador fuerte que recientemente, ayer, se convirtió en un líder de equipo? ¿Qué acciones específicas y comprensibles debería comenzar su trabajo en una nueva posición?
En primer lugar, te aconsejaría que averigües qué sucedió con el líder del equipo anterior y qué espera tu nuevo líder de ti. Después de eso, hable con cada miembro del equipo, conozca sus expectativas y problemas, y también trate de comprender sus miedos.
¿Qué libros o artículos recomendarías leer al gerente de desarrollo? ¿Y qué recursos tiene sentido estudiar regularmente?
Hay muchos de nosotros en esta entrevista y, con seguridad, mis colegas nombrarán libros importantes relacionados directamente con la gestión del desarrollo. Por lo tanto, aprovecharé el momento y mencionaré tres libros importantes de áreas completamente diferentes.
Ed Catmell. Corporación de Genios. Cómo gestionar un equipo de personas creativas.
El libro está escrito por el fundador de Pixar. Leyendo, uno se sorprende de lo sabio, discreto y al mismo tiempo que el autor fue audaz. Cómo él y un pequeño equipo de personas con ideas afines lograron reinventar el género de la animación, creando obras maestras que tocan a millones de niños y adultos en todo el mundo. Cómo Ed Ketmell estableció un diálogo con Steve Jobs, defendiendo al equipo y utilizando la experiencia de Steve en beneficio del crecimiento de Pixar.
Al contar la historia del nacimiento de obras maestras, el autor recuerda que al principio todas ellas eran extremadamente torpes, como los recién nacidos. Nada valía la pena aplastarlos justo después del nacimiento. Y solo la paciencia, el amor y una gran cantidad de iteraciones permitieron que las ideas se fortalecieran y se convirtieran en películas ganadoras de un Oscar.
Ed también habla sobre cómo crear una atmósfera en la que las personas expresen abiertamente opiniones críticas, y los críticos están felices de aprovechar esta oportunidad para mejorar sus creaciones.
Si tan solo pudiéramos hacer eso, ¿verdad?
David Keirsey. Por favor, entiéndeme II: temperamento, carácter, inteligencia
En la segunda edición, David Keirsey habla sistemática y visualmente sobre por qué las personas a menudo lo hacen completamente diferente de lo que esperas. Resulta que las personas de la misma profesión, ubicadas en el mismo contexto sociocultural, pueden tomar decisiones de maneras completamente diferentes, apreciando cosas completamente diferentes. Y esto sucede todo el tiempo, con un ser querido, con niños, con padres y, por supuesto, en equipos de desarrollo.
A pesar de algunas críticas, la tipología de MBTI ayuda a las personas a comprender mejor, racionalizar sus acciones y construir equipos más equilibrados.
Daniel Kahneman Piensa despacio ... Decide rápidamente
El fundador de la teoría económica psicológica habla fascinantemente sobre las distorsiones cognitivas con las que vivimos, sin notarlas. El libro está lleno de ejemplos que demuestran que usted y yo no somos demasiado racionales y que podemos ser manipulados fácilmente.
El libro no solo enseña a reconocer tales manipulaciones, sino que también te hace pensar seriamente si hacer esto o aquello, parece, una redistribución muy racional de responsabilidades.
¿Cuánto tiempo cuesta trabajar en tareas técnicas y cuánto, en tareas relacionadas con la gestión de un equipo? ¿Qué más puede o debe un tímido pasar su tiempo?
Debo admitir que no he trabajado en tareas verdaderamente técnicas durante mucho tiempo.
¿Qué consejo le darías a tu colega, un desarrollador fuerte que recientemente, ayer, se convirtió en un líder de equipo? ¿Qué acciones específicas y comprensibles debería comenzar su trabajo en una nueva posición?
- Comienza a mirar a tu alrededor. Observe lo que hacen las personas en el grupo, cómo lo hacen, qué los hace felices, qué los entristece. Presta atención a todos los matices que conforman el microclima del equipo del que ahora eres responsable. Su conocimiento de sus hijos y niñas le permite crear sinergia y no interferir entre sí.
- Deja de escribir código. Además de dos excepciones: cuando define un vector de desarrollo o establece una moda. El primero incluye soluciones arquitectónicas que marcan la pauta para el desarrollo y le permiten mantener su vector en la dirección correcta. El segundo: aquellas cosas que dejan de hacer todo si dejas de hacer: pruebas, ramas, buenas prácticas y otras pequeñas cosas que todos son demasiado flojos para hacer, pero sin los cuales todo se desmorona.
- No intente corregir todos los errores visibles, comenzando la vida desde cero o introduciendo un proceso de un libro. Las opiniones del desarrollador y el líder del equipo son significativamente diferentes, y lo que le parece dañino como desarrollador puede ser el clavo en el que todo colgaba. Haz cambios de forma lenta y constante. Tómate tu tiempo, tendrás tiempo.
- Dar y delegar. Su tarea no es hacer todo usted mismo, sino asegurarse de que se haga. Además, uno de los motivadores muy importantes es la responsabilidad. Poniendo su pieza en buenas manos, no solo estarás menos ocupado, sino que también motivarás a un miembro de tu equipo. Pero, si ya dio, recuerde que no solo dio responsabilidad, sino que también delegó parte de la autoridad para tomar decisiones.
¿Qué libros o artículos recomendarías leer al gerente de desarrollo? ¿Y qué recursos tiene sentido estudiar regularmente?
En un momento me gustó mucho el trabajo de Alistair Cockburn "Desarrollo de software ágil". Lo recomiendo mucho Recomiendo encarecidamente la práctica de trabajar con los estudiantes: preparas tus propios marcos + tienes que mantenerte en buena forma, ya que los estudiantes con dientes no te permiten relajarte, haciendo preguntas difíciles :)
¿Cuánto tiempo cuesta trabajar en tareas técnicas y cuánto, en tareas relacionadas con la gestión de un equipo? ¿Qué más puede o debe un tímido pasar su tiempo?
Tanto como sea necesario para que el grupo haga frente a las tareas. Si la liberación es en una semana, entonces es extraño manejarlo, y si en un mes una de las chicas se va de licencia por maternidad, es extraño hacer tareas técnicas. ¿Pasó todo al mismo tiempo? , :) , , , IMHO .
?
- . , . , , , :))
- ( , ). , , , .
- : , . « 3 » — .
- . , 1-2 , .
, , 28 2018 . .