El desarrollador principal no es en vano el "líder". Esta frase se escuchó en una conferencia sobre gestión de TI y planteó una pregunta, ¿por qué, de hecho, "no en vano"? Fue esta pregunta la que me impulsó a escribir este artículo.

Al evaluar mi experiencia, puedo decir que las características principales de un desarrollador líder se pueden reducir a 3 puntos:
- Él piensa no solo en su jardín, sino también en todo el jardín (esta es una cualidad clave). Listo para construir estándares y monitorear su implementación.
- Conoce perfectamente su propio lenguaje y marco, está bien versado en arquitectura, tiene una sólida base de trabajo detrás de él. "Solidez" no significa necesariamente el tiempo que se pasa en el teclado; la cantidad y calidad de los proyectos escritos es importante.
- Quiere y puede transmitir razonablemente su opinión, defenderla y buscar un compromiso si es necesario.
Además de escribir el código (sigue siendo la responsabilidad principal), el facilitador participa en la selección del equipo y su desarrollo en la dirección correcta, la búsqueda de soluciones técnicas a problemas dolorosos o inminentes, monitorea la seguridad e integridad del sistema y regularmente elimina ideas locas de los gerentes u otros desarrolladores.
Una de sus fortalezas es una imagen holística del mundo, en la que se determina con precisión qué es bueno y qué es malo. Esto le permite tomar decisiones rápidamente y, sin dudarlo, darles vida. Esta confianza es contagiosa y le permite ganar credibilidad a los ojos de los gerentes que ya no son tan simples y claros. De hecho, además de los técnicos, "mejor", "más confiable" y "más rápido", a nivel de gestión hay todo tipo de "el cliente no querrá", "el inversor no apreciará" y todo tipo de "Vasya se ofende". Cuando el gerente escucha "no, aquí solo es necesario hacer esto, porque 1, 2 y 3" - suspira con alivio. La elección se vuelve obvia y la responsabilidad cae de sus hombros.
Hace poco más de un año, finalmente abandoné el puesto de desarrollador principal y decidí hacer una pequeña retrospectiva de mis errores más molestos. Entonces
Error número 1. Sobregestión
Tuve un caso hace unos tres años. Además de mis colegas que recibieron tareas directamente del gerente, el desarrollador acudió a nosotros en uno de mis proyectos, y yo ya le asigné las tareas. Para sumergirlo en el trabajo, pasé 3 días con él durante 14 horas seguidas, contándole y mostrándolo todo, asegurándome de que entendía todo correctamente. Esto arrojó resultados, y luego todas las tareas se establecieron inmediatamente con la solución: abra un módulo de este tipo, agregue esta y esa función allí, conecte esta biblioteca, etc. En general, funciona e inmediatamente da frutos, pero :
- Consume mucho tiempo en detrimento de sus propias tareas.
- Alivia la responsabilidad del resultado del empleado. Usted dijo qué hacer exactamente, lo que significa que si no funcionaba, él felizmente le informará al respecto, diciendo que está buscando otra solución.
- Destetar a un empleado de pensar y evitar que se desarrolle
Después de 9 meses, me quedé
embarazada muy cansada de este modo de trabajo, y el empleado no alcanzó el nivel requerido de calificación.
Es más correcto establecer tareas a un nivel suficientemente alto para que la persona misma busque soluciones y asuma la responsabilidad de ellas. A la pregunta "¿cómo hacer esto?" siempre necesitas responder, “¿Qué piensas? ¿Alguna idea? ”, Estimulando así el trabajo del pensamiento en la dirección correcta. La respuesta puede ser solicitada, pero solo asegurándose de que la persona misma ya haya hecho esta pregunta y haya realizado un análisis.
Error número 2. Concesiones a la cabeza en la solución técnica
En algún momento, a mi gerente le gustó una de las nuevas tecnologías sensacionales (no, no la tecnología sensacional en la que pensabas). Su implementación minó la integridad del sistema, creó una división innecesaria de los frentes de trabajo y, en general, ralentizó la velocidad de desarrollo para siempre. Para mí, esto era obvio incluso entonces, pero la hermosa apariencia de la demostración y el deseo de experimentar tomaron la delantera sobre el liderazgo, me convencieron por las buenas o por las malas, y lo implementamos. La comprensión de que esto fue un error llegó al liderazgo en algún lugar después de un año y medio.
Llegué a la conclusión de que debe respetar su instinto con respeto, confiar en él y protegerlo.
En el fondo, entiendes por qué te sientes así. Uno debe ser capaz de extraer esta comprensión de uno mismo y luego formular argumentos a partir de ella.
Error número 3. Falta de empatía y toxicidad.
Cuando pasas una gran cantidad de tiempo con la computadora y te apasiona lo que estás haciendo, generalmente puedes olvidar que las personas también están cerca. No son perfectos, pero todos tienen su intención positiva con respecto a lo que están haciendo. Es importante ver esta intención positiva siempre y en todo. Esto ayuda a mantener una actitud benevolente en situaciones en las que una persona comete un error. Se escuchan constantemente historias sobre cómo las personas mayores, sin una gota de compasión, destruyen los resultados de los esfuerzos de sus colegas menos experimentados, que los sumergen en la oscuridad y los privan de la motivación para trabajar. Después de analizar mi experiencia, me di cuenta de que a veces yo mismo me permitía esto, aunque sin algunas formas extremas.
Hablando de toxicidad, me gustaría señalar por separado que, además de las críticas demasiado duras, existen otras formas que, en un grado u otro, pueden afectar negativamente el deseo de trabajar con usted. La toxicidad en sí misma es muy contagiosa y puedes recogerla fácilmente de mis colegas, por lo que en algún momento decidí profesar el principio "no dejes que el mal vaya más allá de ti mismo" (identifícalo y suprímelo en primer lugar en ti mismo) y compilé una lista de manifestaciones que puedes considere la toxicidad (según el informe de
TED "7 pecados capitales de comunicación" ):
- Chismes Todos quieren chismear un poco a veces, pero a gran escala, los chismes son asquerosos
- Convicción Es difícil comunicarse con alguien que te culpa. Especialmente si se sabe que condenará cualquier acción por adelantado.
- Negatividad Hay personas que no están contentas con nada y nunca.
- Quejumbroso Las quejas sobre la vida son permisibles solo en cantidades homeopáticas.
- Excusas Transferencia de culpa, descargo de responsabilidad.
- Adorno La constante exageración a la que muchas personas son propensas cuando hablan de proyectos, su experiencia, sus conocimientos. Cualquier exageración en el tiempo tiende a fundirse en mentiras continuas.
- Dogmatismo Cuando el hablante no comparte dónde está el hecho verificado, y dónde está su opinión subjetiva, y lo riega con una corriente continua, haciéndolo pasar por completo como una verdad comprobada. Todo lo contrario de la discusión científica.
Error número 4. Ignorar a los interesados
Su líder tiene colegas al mismo nivel que él y superiores. Pueden ser amigos o enemigos. Puede que no siempre les guste su influencia legítima en las decisiones del líder, y las decisiones en sí mismas no siempre van de la mano de sus intereses. Cuando eres programador, no le prestas atención y ni siquiera piensas en ello. Por lo general, su supervisor lo encapsulará de estas cosas el mayor tiempo posible. En algún momento, es posible que sienta un hormigueo elegante con las cosas más inesperadas y obvias por parte de personas que, a primera vista, no tienen nada que ver con su trabajo. En general, puedes vivir con esto, pero si el oponente es sofisticado, es muy posible que pronto quieras mudarte a otra oficina, trabajar más desde casa o incluso cambiar de trabajo.
Puede evitar tales situaciones si tiene en cuenta de antemano quién más está interesado en el proyecto que está implementando, qué nivel de influencia en este proyecto, qué objetivos enfrenta la parte interesada, qué miedos y esperanzas pueden surgir durante el trabajo. Los miedos deben ser disipados; uno no puede dejarlos crecer. Las esperanzas deben estar justificadas. En general, una estrategia se define de la siguiente manera:
- Baja influencia y bajo interés: no puede permitirse hacer nada
- Bajo impacto y alto interés: debe estar informado sobre cambios, planes, etc.
- Alto impacto y bajo interés: similar
- Alta influencia y gran interés: debe trabajar duro, incluso si se encuentra en diferentes departamentos y / o en diferentes niveles.
Error número 5. Reevaluar sus capacidades
Esto es común a todos de una forma u otra, y es probable que su gerente lo sepa. Sin embargo, a veces también puede subestimar la cantidad de trabajo por delante y la velocidad de su implementación. Esto suena cursi, pero esta ha sido la razón por la cual mi gerente estaba decepcionado y yo junto con él. Uno puede recordar fácilmente varias situaciones en las que respondí que podemos hacer esto en medio día, y luego me senté en una tarea durante toda la semana junto con el fin de semana. Durante este tiempo, la tarea podría perder relevancia, u otras tareas más importantes podrían hacerse. El hábito de no dar una evaluación de inmediato me ayudó mucho. Si la pregunta no es hipotética, sino específica, entonces vale la pena tomarse un tiempo para elaborar la evaluación y es recomendable tener en cuenta los posibles riesgos. Después de conocer la evaluación de
tres puntos, se me hizo mucho más fácil llegar a una conclusión razonada sobre el tiempo necesario empleado y, lo más importante, la evaluación en sí misma se volvió mucho más cercana a la realidad.
Resumen
En resumen, puedo decir que el desarrollador principal se enfrenta voluntariamente al horizonte de un entorno de gestión bastante agresivo y desconocido. Es este lugar el que se está convirtiendo en un nuevo punto de crecimiento, ya que el aspecto técnico del trabajo no plantea muchas preguntas: las inversiones en infraestructura se realizan regularmente, la deuda técnica se paga de manera oportuna, la arquitectura se desarrolla de manera armoniosa y competente. Sin embargo, para llevar a cabo su trabajo de manera efectiva (y a veces solo para "sobrevivir"), debe comprender rápidamente los conceptos básicos de la gestión de proyectos y equipos, analizar los principales problemas de sus predecesores en posiciones similares e intentar evitarlos o resolverlos por adelantado.