👩🏽‍🤝‍👨🏾 ☄️ 🔤 De desarrollador a gerentes y viceversa ↖️ 👨🏻‍⚕️ 👺

En el invierno de 2012, un colega sugirió que yo, un programador de C ++ con cinco años de experiencia, escribiera la primera aplicación para Android. Un año después, comencé a dirigir un pequeño equipo de desarrolladores móviles, y desde entonces el tamaño de mis equipos ha crecido constantemente. Pero el año pasado, después de 2 años de administrar el departamento de desarrollo móvil, volví a echar polvo con mi IDE favorito.

Digamos cómo fue en el otro lado, por qué volví a los desarrolladores a la edad de 30 años (spoiler) y no me arrepiento.

Camino a los desarrolladores de Android

Android, que en ese momento era un truco en mi ciudad de provincias, me pareció otro "juguete" divertido, al jugarlo, se podía soltar con seguridad y volver al Qt habitual. Y así comenzó todo: un amigo lanzó la idea de una aplicación simple para contabilizar ingresos y gastos, comenzamos a verla en nuestro tiempo libre, y seis meses después, MVP estaba listo para su publicación.

Nuestro Money Keeper tenía un diseño bastante primitivo, pero una experiencia de usuario bien pensada: los ingresos o gastos se registraron con un solo clic: al tocar el ícono de categoría, se abrió inmediatamente una ventana para ingresar la cantidad.

Recuerdo muy bien cómo vi las estadísticas de descarga: la primera persona en descargar mi aplicación fue alguien de Egipto. ¡Y esta no eliminó la aplicación esa misma semana, sino que continuó usándola!

Poco a poco, varias docenas de descargas por día, la audiencia creció, la calificación creció, aparecieron las primeras críticas positivas. Decir que inspiró fue minimizarlo. Respondí a las revisiones en el mercado, planifiqué un mayor desarrollo basado en los deseos de los usuarios, simplemente porque los usuarios necesitan mi aplicación, agradecen y ponen cinco. Y toda nuestra publicidad estaba en una sola publicación en w3bsit3-dns.com.

También fue sorprendente cuánto difiere el desarrollo móvil del desarrollo de sistemas embebidos y aplicaciones de escritorio en las que trabajé antes. La ruta de la aplicación para el usuario y sus comentarios son muy cortos. La audiencia es enorme, y todo lo que haces, debes hacerlo al menos bien, de lo contrario, nadie necesitará la aplicación, y todo el trabajo se puede tirar.

Cómo me convertí en líder de equipo, "porque_to_to_alguien_algo_se debe_"

La aplicación creció y se volvió más complicada, apareció una versión paga con funcionalidad adicional. Mi par de manos para el desarrollo de dos aplicaciones ha dejado de ser suficiente, especialmente teniendo en cuenta el hecho de que las escribí en mi tiempo libre desde el trabajo principal. No había un presupuesto especial para contratar empleados, porque la monetización no generaba tantos ingresos.

Rechazamos la idea de "congelar" una aplicación gratuita por una paga, porque no queríamos decepcionar a la comunidad de usuarios agradecidos, de la que habíamos estado obteniendo energía e ideas para el desarrollo todo este tiempo. Por lo tanto, decidimos ganar un pequeño salario a dos muchachos que estaban lejos del desarrollo y quemaron para entrar. Se decidió llevarlos por mi camino, pero con una diferencia significativa: tuve que enseñarles cómo moverse y navegar por el mundo del robot verde y mostrarles todos los baches y agujeros que conocía en este camino.

imagen

No tenía miedo de asumir tareas difíciles)

queríaotras personas compartieron mi entusiasmo por el desarrollo, e incluso dos pares de manos claramente no fueron superfluas para nosotros. Fui a su casa, les expliqué, enseñé, aconsejé, ayudé. Configuré tareas y verifiqué su implementación. Así que silenciosamente me convertí en un pequeño pero gerente.

Sin embargo, la aplicación tuvo que cerrarse ... Fui a una startup, luego a otra, luego llegué al desarrollo de productos en una gran empresa. En todas partes donde no había suficientes personas para el papel principal, había un escenario aproximadamente similar: "Descubriste el área temática, hiciste amigos con el equipo, no estás en contra del trabajo de liderazgo, y ¿tienes incluso esa experiencia? Intentemos establecer tareas para otras personas. Al menos en este sprint ... ”

Pero había otro aspecto importante: estaba pensando en el futuro, y parecía brumoso.Hace mucho tiempo me encontré con un artículo sobre la edad promedio de los desarrolladores. Dijo que la "carrera máxima" del desarrollador cae en 27 años. Comencé a notar artículos similares, y me pregunté involuntariamente: ¿qué haré como desarrollador, por ejemplo, a los 32 años, cuando "viene una mierda joven que nos borrará de la faz de la Tierra"? ¿No es mejor recorrer lentamente el camino hacia los gerentes y resolver el "problema de los 30 años" por usted mismo?

Mis principios como timlida

Cuando abandoné C ++ y me fui a Android, ya había trabajado con varios líderes y sabía exactamente qué tipo de líder quería ser. Y más tarde, en equipos completamente diferentes: producto (compuesto por analistas, diseñadores, desarrolladores, evaluadores) y equipos de desarrollo, intenté no apartarme de mis principios.

Necesito trabajar con aquellos que están

Un estudiante con ojos ardientes, que está siendo enviado por el camino correcto, después de un tiempo puede comenzar a aportar más beneficios al proyecto que una "estrella de rock".

En uno de los proyectos, decidí que era hora de alejarnos del paquete familiar MVP + Dagger + RxJava, y probar en la producción esas herramientas que Google recomienda usar para crear aplicaciones móviles modernas. Planeamos implementar la arquitectura recomendada usando solo Jetpack y Kotlin con Coroutines.

Todos los desarrolladores y jefes experimentados torcieron sus dedos en el templo y dijeron que con un equipo de dos jones que nunca habían usado nada de la pila que seleccioné, llenaríamos el proyecto y la responsabilidad recaería en mí personalmente. Pero esos dos joons estaban encantados de que trabajarían con lo que los desarrolladores de Android escribieron en el blog ayer.

imagen

Sí, por supuesto, al principio descubrimos un montón de enfermedades infantiles de versiones alfa de bibliotecas ...

Pero los muchachos trabajaron duro, subieron a la fuente y estudiaron temas sobre Github, perfilados por la noche, y al final obtuvimos:

código limpio, estable y fácil de mantener,
producto exitoso en producción,
y un montón de experiencia invaluable.

En otro proyecto, un desarrollador muy bueno llegó al equipo, que no se hizo amigo de inmediato de todo el equipo, sino que eliminó las tareas perfectamente. Los chicos lo contactaron a través del dolor, las lágrimas y los jefes, y alguien incluso dijo que sería mejor tomar cualquier junio en lugar de él, pero al final reduje la comunicación en vivo entre ellos al mínimo necesario, y todo se calmó.

También debe trabajar con "estrellas de rock", no importa lo difícil que sea a veces.

Naturalmente, hay personas que no hacen su trabajo a sabiendas: alguien piensa que ha llegado al "jefe que hará todo por mí", alguien simplemente no puede o no quiere trabajar. Si las conversaciones y el tiempo no ayudan, no debe temer separarse de ellos.

No trabajo con subordinados, sino con personas.

Cada uno tiene sus propias circunstancias, necesidades, temperamento y estado de ánimo. Una vez, antes de pasar un sprint difícil, una chica de prueba, de quien todos esperaban el resultado de la prueba final del producto, llegó a trabajar enojada debido a un escándalo con su esposo que no pudo encontrar calcetines limpios. Fecha límite, este no es el primer día de pruebas intensas, pero aquí está. No tenía ganas de trabajar en absoluto. En esta situación, fue posible aplastar, exigir y amenazar. Pero traté de entenderlo y redistribuir el recurso de otros probadores de tal manera que cubriera la brecha. Después de medio día, se enfrió y con éxito invertimos en tiempo.

imagen

Quien antes de las vacaciones no se sentaba en otros sitios durante las horas de trabajo, deja que el primero me arroje un monitor)

O otra historia: un colega dejó de hacer algo un par de días antes de las vacaciones, simplemente porque estaba ocupado con las últimas reuniones para un viaje en bicicleta a Europa, que había estado preparando durante casi un año. Todo este año realizó meticulosamente tareas de trabajo, y aquí, como sustituto. Y le di estos dos días. Después de unas vacaciones de dos semanas, regresó descansado y se puso a trabajar al mismo ritmo, pero me las arreglé para no estropear la relación en el equipo.

En una situación difícil, nadie avanzará a menos que yo lidere

En un equipo de DevOps que era nuevo para mí, durante un par de meses me "dinamice" con el despliegue de CI, y los desarrolladores sabotearon abiertamente su implementación, sin estar de acuerdo con los argumentos sobre su utilidad. No es que fueran perezosos retrógrados, simplemente me pareció que no trabajaban en el entorno donde CI estaba preparado correctamente.

Abrazando a Google, me sentaba por las tardes y escogía la configuración. Poco a poco, DevOps y los desarrolladores se involucraron en el proceso. Como resultado, pudimos configurar CI y los enlaces necesarios para crear y distribuir aplicaciones, que de forma rápida y silenciosa se convirtió en el estándar para los diferentes equipos de la empresa.

¿Cierro los agujeros en la organización de procesos con intervención personal y microgestión? Tal vez. Pero, me parece, en una situación de estancamiento, hay dos extremos: "apretar los tornillos", alejarse cada vez más del equipo y convertirse en el "jefe", o tratar de ayudar a una persona cuando es difícil para él, incluso haber completado su trabajo, convertirse en "su". Pero no dejan "lo suyo" en problemas.

Necesitas desarrollarte y desarrollar a todos en el equipo

Lugar de trabajo típico de un líder

: cuanto más tiempo me sentaba en un proyecto, más sentía que el desarrollo moderno pasaba por mi lado. Se seleccionó una pila de tecnologías, lenguajes y marcos hace varios años, y no ha cambiado significativamente desde entonces. Esto se debió a las eternas fechas de combustión, el débil interés comercial, pero sobre todo: el miedo de los desarrolladores a algo nuevo, cuando hay un viejo tan familiar.

Llegó al punto de que los desarrolladores recién aceptados tenían prohibido escribir en Kotlin, porque los principales programadores no lo conocían y no encontraban el tiempo (¿no querían encontrarlo?) Para enseñarle. Estos problemas se resolvieron de manera bastante simple: mantuve charlas tecnológicas, reuniones y cursos sobre temas que fueron interesantes para todo el equipo. Es más fácil y más interesante para los desarrolladores clasificar una tecnología en un proyecto de mascotas durante una semana y contarles al resto que arrastrarla ciegamente a la producción.

Y es más fácil para una empresa justificar un aumento salarial para una persona que está estudiando e introduciendo algo nuevo y útil para toda la empresa.

No se puede ir lejos de los problemas de desarrollo.

Tan pronto como ya no comprenda los problemas de los desarrolladores con deudas técnicas, características de la plataforma y la interacción entre diferentes partes del sistema, el porcentaje de sprints está disminuyendo.

Hubo casos en que los gerentes se sorprendieron genuinamente de que era imposible publicar una aplicación de iOS en la víspera de Año Nuevo porque los revisores de Apple se habían ido de vacaciones. Los diseñadores a veces no entienden los problemas de los desarrolladores de Android con la composición tipográfica en diferentes pantallas. Los backenders que no hayan trabajado con clientes móviles antes deben explicar que no necesitan dar un error de página HTML en lugar de JSON.

Y si "mira" esos momentos cuando desarrolla el sistema o su parte, las consecuencias para los plazos pueden ser muy deplorables.

imagen

Oh, cuánto bien se puede lograr simplemente tomando soluciones técnicas. E incluso si dan las tareas para distribuir, ¡puedes rodar montañas!

¿Logré liderar?

No pretendo decir que estos son los principios correctos. Ni siquiera sé si corresponden a lo que escriben en los libros sobre gestión de personal, porque no he leído ninguno de ellos. Juzgo por varios hechos:

Las relaciones en el equipo mejoraron. Si antes de mí hubo escándalos con la aclaración de las relaciones con las autoridades, entonces conmigo: un máximo de pequeñas escaramuzas.
En general, encajamos en sprints. Incluso lo imposible. Y si no encajaban, no tanto que el cliente estaba enojado. Naturalmente, este es el mérito del equipo. Pero probablemente un poco mío. Siempre intenté tener en cuenta todos los riesgos y llevar a cabo la planificación de tareas teniendo en cuenta estos.
Reestructuramos y mejoramos constantemente los procesos de desarrollo y producto, disminuyó la deuda técnica.
Los desarrolladores crecieron en rango y salario.
Mi orientación directa también fue bonita.

Bien, ¿qué pasa con las desventajas del liderazgo?

Para mi son:

Cuanto más administrador eres, menos desarrollador. No importa cómo intentes hacer un seguimiento de las complejidades de la parte técnica del proyecto, te eluden cada día más y más. Y cuanto más grande es el equipo y más activo es el desarrollo, más rápido. Poco a poco, el volumen de nueva información recibida sobre Android e iOS se redujo a la lectura de notas de lanzamiento de nuevas versiones de sistemas operativos y un par de artículos sobre Habré por mes.
. — , . , “” . .
. . , . - - , .
. , . , 2-3 . - — 70-80% !

!

No importa cómo te guste en algún lugar, tendrás que irte alguna vez. Y en algún momento comencé a buscar un nuevo trabajo. Como era de esperar, quería entrar en un negocio aún más grande para continuar el desarrollo.

La siguiente entrevista de Skype estaba en curso: 10 entrevistadores, 2 horas , requisitos: conocimiento de la parte técnica del nivel de Desarrollador Senior y la capacidad de gestionar personas. Y después de 2 horas, me di cuenta de que al administrar personas no sé casi nada. Al menos no conozco la teoría, y me baso solo en mis principios y experiencia.

Se parecía a esto:

— ?

— .

— ?

— , . , .

— ?

— …

— , scrum kanban?

— .

— ?

— …

Bueno y así sucesivamente. Fallé la teoría. De alguna manera logré implementarlo, pero para explicar los principios básicos de por qué una forma u otra tenían que hacerse, no. Después de la entrevista, me di cuenta de que había llegado a mi límite en la liga de gestión amateur y que seguir sentado en dos sillas no funcionaría. Para desarrollarme, era necesario decidir a dónde quiero ir.

imagen

Este es mi equipo visitante actual para trabajadores remotos. Al menos una persona más participó de la misma manera: fue a los líderes de equipo y regresó conscientemente a los desarrolladores.

La primera forma es a los gerentes. Aún así, lee los libros correctos. Comience a mirar videos y asista a conferencias de gestión, planificación y motivación. La liga gerencial profesional tiene sus propias reglas y sus propios detalles.

Segunda forma- Sumérjase en el desarrollo, si es posible ponerse al día con los años de gestión.

Bueno, la tercera opción de compromiso es "levantar" la teoría y tratar de continuar "en el medio", colgando "en aficionados" por unos años más.

Y luego recordé cómo comenzó todo. Con la sensación de que estás cambiando el mundo, haciendo algo útil para los demás. Incluso si pintó el botón de verde, y se volvió un poco más agradable para miles de usuarios. Incluso si corregí un error tipográfico. Y si ya eliminó una característica que los usuarios esperaban desde hace mucho tiempo, y se lo agradecen en los comentarios, ¡esto es solo una explosión de emociones y un buen estado de ánimo durante un par de días!

¿He experimentado un sentimiento tan fuerte al trabajar como gerente? Creo que no. Incluso cuando los clientes, el equipo y los líderes lo elogian. Y cuando los usuarios elogian la característica esperada, esto, por supuesto, se debe principalmente a quien la preparó, aserró, probó y mostró. Y bastante, el mío como gerente.

Por lo tanto, encontré un lugar agradable para trabajar, escribo código y hasta ahora no me arrepiento.
¿Hay vida en los desarrolladores a los 32? ¡Ahi esta!

PD:

¿Qué me ha dado como desarrollador la experiencia de liderazgo?

Ahora entiendo mejor los negocios y el PMA, incluso sin palabras. A menudo sé qué pregunta me quieren hacer.
Planifico el tiempo y las tareas de manera más competente teniendo en cuenta los riesgos.
Contraste. Después de ver cómo estaba en el otro lado, me di cuenta de lo que me gusta de este.

De desarrollador a gerentes y viceversa