Ya se ha dicho mucho sobre la gestión de las personas en su conjunto (según muchos, más que suficiente). Acerca de la gestión de programadores, teniendo en cuenta las características específicas de sus tareas, la organización del trabajo y las relaciones internas en un equipo, es mucho menor. Cualquier intento de resumir y analizar su experiencia de una persona que ha cocinado en el entorno de TI y como desarrollador y como gerente es de particular valor para aquellos que se preparan para seguir el mismo camino y descifrar cómo aplicar las teorías de gestión general a las realidades del programador.
J. Hank Rainwater, un programador de la vieja escuela, es una de las personas que conoce todas las zanahorias en el papel de líder técnico al final, porque ellos mismos flotaron en ellas. Su libro "
Cómo pastar gatos " cautiva con su objetividad: describe situaciones específicas que son bien conocidas por todos, los diferentes componentes y las condiciones de trabajo del equipo, entienden incluso las soluciones tecnológicas del autor (desafortunadamente, ya están desactualizadas). En una breve serie de artículos, planeamos cubrir todo lo que nos pareció más útil y relevante en el libro, desde la tipología de los empleados hasta las recomendaciones para comunicarse con otros equipos.
Comience con una pregunta razonable: ¿por qué, de hecho, los gatos? El autor mismo, como explicación, se refiere a una cita de Helen Alman, quien dibuja esta analogía en su libro Close to the Machine:
“Uno de mis conocidos con los gerentes de proyecto alguna vez comparó el proceso de administrar programadores con el pastoreo de gatos. Quería decir que los perros, mirando fielmente a los ojos, absolutamente no necesitamos. Un buen programador debe ser apreciado junto con todas sus rarezas. Por otro lado, todos estos buenos programadores deben hacerse de alguna manera para moverse en una dirección ".
En primer lugar, los programadores están relacionados con los gatos por el hecho de que ninguno de los dos tiene una tendencia innata a extraviarse. Prefieren caminar por su cuenta, y la cultura que se ha desarrollado en la esfera de TI ha alentado durante mucho tiempo este tipo de comportamiento (o, al menos, no lo impidió). En consecuencia, el gerente técnico se enfrenta a una tarea doblemente difícil: organizar a las personas solteras en un grupo más o menos cohesionado, sin violar su individualidad, lo más probable es que tenga que perfeccionar sus propias habilidades para trabajar con personas.
Rainwater define su público objetivo de la siguiente manera: recién llegados a la gerencia (desarrolladores de ayer que recibieron una posición de liderazgo), líderes de equipos pequeños (hasta diez personas) que trabajan en varios proyectos, desde pequeñas y medianas empresas. Para una escala mayor, algunas técnicas ya no funcionarán, y los líderes técnicos más experimentados probablemente ya hayan aprendido mucho por sí mismos. El libro está diseñado para ayudar al líder en el período de transición más agudo y prepararse para futuros cambios.
Si se mira en términos generales, un gerente novato se enfrenta a dos problemas principales: una nueva posición transforma fundamentalmente los mecanismos de su interacción, en primer lugar, con las personas y, en segundo lugar, con los procesos. Hablaremos del segundo en detalle más adelante, pero un error común debe mencionarse de inmediato.
Muchos no pueden aceptar que tendrán que renunciar a parte de sus tareas relacionadas con la escritura del código, y cuanto más fuerte sea el programador, más fuerte será este sentimiento de protesta. La situación se ve agravada por un nuevo sentido de responsabilidad por todo el código que produce el equipo. Como resultado, en lugar de redistribuir el tiempo y dedicar horas al trabajo administrativo, el jefe se preocupa de lleno por el lado técnico de los proyectos: él mismo hace todas las revisiones, verifica meticulosamente el diseño o incluso reescribe los fragmentos que no tuvieron éxito. El descuido más persistente de todas las demás responsabilidades no directamente relacionadas con el código, y esto termina en un desastre. Los más sobrios se convierten en hombres lobo: durante el día, el líder, por la noche, el programador, y esto termina en agotamiento.
Por esta razón, lo primero que debe hacer un líder técnico es reconocer y aceptar la inevitabilidad de los cambios en la estructura del trabajo y sintonizar durante un período bastante largo de "ruptura". El autor estima que el período de adaptación es de aproximadamente seis meses; solo en este momento, la mayoría se acostumbra al nuevo rol y comienza a sentirse cómodo en él. Uno puede sentirse reconfortado por el hecho de que la definición de "técnico" no es una frase vacía: el que dirige a los desarrolladores simplemente no puede darse el lujo de dejar de trabajar por completo con las tecnologías, por lo que no hay necesidad de temer que la actividad gerencial lo suplante.
Ahora pasemos a la segunda fuente de cambio: trabajar con personas. En una posición de liderazgo, un programador no solo tiene que llevarse bien con los miembros del equipo, sino que, hablando en términos generales, usarlos como un recurso: identificar quién es capaz de qué y dirigir estas habilidades a donde más se necesitan. Por lo tanto, la tarea se divide en dos partes: debe ser capaz de comprender a las personas y poder comunicarse con ellas.
Para ayudar al lector con el primer párrafo, Rainwater ofrece una clasificación de las "razas" de gatos informáticos, que construyó sobre la base de su propia experiencia y observaciones. Su lista de razas resume los tipos de desarrolladores que ocurren regularmente con características distintivas vívidas, fortalezas y debilidades. Como cualquier otra, esta clasificación no debe tomarse como un estándar absoluto: en la naturaleza, los tipos a menudo se mezclan y se cruzan, son más y menos pronunciados. Sin embargo, este es un punto de partida útil para analizar las características intelectuales y personales de sus programadores.
El autor divide las razas en tres grupos: comunes (capturadas con mayor frecuencia), raras (capturadas ocasionalmente) y mestizos (en su forma original tienen menos valor que la masa total).
Razas comunes
ArquitectoFavorito de la mayoría de los gerentes. Se enfoca en la estructura general del código, va desde análisis y construcciones abstractas hasta la implementación de soluciones específicas para ellos en el código. Fuerza: genera buenas ideas, a veces puede dirigir un proyecto solo, desde el concepto hasta la forma final (aunque algunas personas pierden interés después de que se describe la estructura general y dan el trabajo "artesanal" a los desarrolladores de nivel inferior). Debilidad: a menudo produce un código confuso y oscuro con diseños extraños que solo obedece al propietario y es muy difícil proporcionar soporte externo.
ConstructivistaDisfruta sinceramente del proceso de programación en sí, se esfuerza por obtener un buen resultado. La planificación estratégica suele ser indiferente, el código está escrito en una corazonada, sin pensar demasiado en la lógica general. A distancias cortas, esto no hace mucho daño, y puede confiar en la calidad del trabajo del constructivista. Cuando el proyecto crece, la falta de lógica interna generalmente comienza a afectar y se utilizan decisiones "parcheadas"; recordamos que el constructivista está muy centrado en el resultado. Funciona muy bien en conjunto con un arquitecto. Documentos a regañadientes ("todo está claro"), pero con la debida persistencia de la cabeza, bastante bien.
El artistaTambién conocía la alegría de escribir código, pero su elemento es la búsqueda de soluciones inesperadas y elegantes para implementar los requisitos dados. Con la lógica y la organización, como regla, no hay problemas. La principal desventaja es un amor excesivo por el arte y la experimentación, que alienta a estirar tareas simples y romper los plazos. Tiene algunas similitudes tanto con el arquitecto como con el constructivista, pero generalmente se destaca con su brillante estilo de programación individual.
IngenieroConsidera el desarrollo de software como un análogo virtual del ensamblaje de hardware con todas las consecuencias resultantes. Le gusta encajar uno con el otro, ensamblar módulos dispares en una estructura compleja para que todo funcione, para encontrar un lugar para las soluciones de terceros en el sistema construido. Las habilidades son ciertamente útiles, pero hay una manera de dejar que el ingeniero se deje llevar, la complejidad puede convertirse en un fin en sí mismo para él. La complejidad excesiva y la falta de flexibilidad del producto son dos vulnerabilidades de esta raza.
CientíficoA diferencia de los artistas, considera que la programación es una ciencia exacta: trata de seguir los principios fundamentales en todo y evitar la "mordaza". Muy pedante, se esfuerza por llevar el código a la perfección y lograr un funcionamiento correcto en cualquier condición, a menudo en detrimento de consideraciones prácticas. Como un ingeniero, tiende a complicar todo innecesariamente. Pero cuando se trata de tareas verdaderamente complejas que requieren escrupulosidad y conocimiento, no tiene precio.
LihachPone la velocidad por encima de todo, incluida la calidad del código. Descuida las pequeñeces como comentar, diseño correcto, siguiendo las regulaciones aceptadas. A primera vista, da un buen resultado, bastante funcional, pero las pruebas en profundidad revelan muchos problemas. Lamentablemente, esta raza es cultivada por los propios líderes: los scorchers se obtienen con mayor frecuencia de programadores jóvenes a quienes se les inculca prioridades falsas y que temen no cumplir con las expectativas.
Razas raras
El magoEn la terminología moderna, un mago generalmente se llama estrella de rock. Asume las tareas y gestiones más difíciles, encuentra formas revolucionarias de resolver problemas, hace todo a tiempo y de manera eficiente. Incluso con el mantenimiento de su código, generalmente no surgen dificultades especiales. En general, todo parece ser maravilloso, pero el líder técnico debe mantener los ojos abiertos en dos aspectos. En primer lugar, no se debe permitir una dependencia excesiva del asistente: todo el equipo, incluido el líder, corre el riesgo de convertirse en un baile para un empleado. En segundo lugar, debe estar preparado para el hecho de que un día el asistente lo decepcionará de todos modos: nadie puede hacer milagros de manera constante. Tal oportunidad debe tomarse con calma y tener un plan de respaldo.
MinimalistaEscribe código sorprendentemente funcional de cantidades muy modestas. Todo se ve armoniosamente, claramente construido y anuncia inequívocamente su nombramiento. Esta raza es muy malhumorada en la elección de tareas y proyectos; minimalista luchará más que otros por el derecho a establecer el área de aplicación de sus habilidades. Punto débil - escolta. Lucha con todas sus fuerzas para hacer cambios en su código (sin mencionar el de otra persona); simplemente no está interesado en meterse con los detalles cuando se hace lo principal.
AnálogoDifiere en el pensamiento específico, compensa sus dificultades con las abstracciones con un amor por las analogías. En las reuniones, es difícil captar su línea de pensamiento, pero rápidamente comprende el punto. Como regla general, escriben un código bueno y fácil de admitir, pero en algunos casos un malentendido de una abstracción puede ralentizarlo. También sucede que las analogías fallan, especialmente si la analogista destaca a uno de sus seres queridos de todo lo que está tratando de sacar de todo. Puedes equilibrar los defectos del analogista poniéndolo en conjunto con el arquitecto: se matan entre ellos o crean algo sobresaliente.
EspecialistaLe encantan los trucos espectaculares y busca constantemente las innovaciones tecnológicas que los ofrecen. De hecho, no hay un retorno real de este pasatiempo: el especialista no puede pensar pragmáticamente, el valor real de esta o aquella tecnología para el producto final y el usuario permanece oculto para él. Este empleado deberá monitorear constantemente y redirigir su entusiasmo a las tareas prioritarias.
Mutts
El agua de lluvia destaca a los mestizos en una categoría separada como gatos con algunos defectos obvios, una ventaja sobre las debilidades en relación con las fortalezas. Pero él no llama para deshacerse de ellos sin mirar. Muchos de los mestizos son bastante susceptibles de entrenamiento y pueden ser gradualmente entrenados en otras razas. A continuación ofrecemos pronósticos y recomendaciones para diferentes tipos.
BabaEl principal proveedor de código descuidado, descuidado. A menudo salta de un estilo a otro. Como un scorcher, sacrifica el diseño y la adhesión a los acuerdos adoptados por el equipo, pero, a diferencia del scorcher, no puede justificarse ni siquiera por la alta velocidad del trabajo. Es su código el que a veces tiene que reescribirse desde cero, por lo que es agotador y requiere muchos recursos para comprenderlo.
El descuido es agudo y crónico. Si atacó a un empleado repentinamente, esto puede deberse a problemas personales. Si esta es una condición habitual para él, vale la pena considerar si tiene sentido dedicar tiempo al reciclaje. El criterio principal aquí es el deseo y la disposición de los sloven para hacer esfuerzos. El desaliñado, que generalmente disfruta de su trabajo, con la debida atención del director o mentor, bien puede ser rehabilitado y aprender métodos de trabajo más efectivos.
FrenoDurante mucho tiempo no puede asumir la tarea, no sabe por dónde empezar, persigue las especificaciones con la desesperada esperanza de que aporten algún tipo de claridad. Como no es difícil de adivinar, la indecisión del freno proviene de la duda. Es necesario actuar aquí según el origen de esta incertidumbre. Si un desarrollador ha fallado miserablemente en el pasado y ahora tiene pánico por los fracasos, permítale tener la oportunidad de demostrar su valía incluso en tareas pequeñas y sin complicaciones para que este miedo desaparezca gradualmente. Si el asunto es inexperiencia, entonces con el tiempo y el conocido apoyo del equipo, todo se normalizará por sí solo. Si tal indecisión es simplemente un rasgo de carácter, es más fácil darle al pobre tipo un modelo que lo ayudará a elegir un estilo y ponerse a trabajar.
AmanteEl amante carece de conocimiento, pero generalmente hay motivación más que suficiente. Es más probable que esta especie de mestizos se convierta en buenos desarrolladores. Sin embargo, su progreso debe ser monitoreado de cerca: para evaluar las habilidades, registrar los logros que dan razones para enviarlos a tareas más responsables. No se deben exagerar demasiado las expectativas: muchos se agotan cuando se enfrentan a dificultades o una rutina inevitable en el trabajo de un programador. En términos generales, los aficionados tienen sus ventajas: en primer lugar, la notoria apariencia fresca y despejada, aunque puede ser agotador esperar hasta que pisen todos los rastrillos y comprendan verdades comunes.
ProfanParece simplemente aburrido. Por lo general, el nuevo líder hereda esto del anterior; la historia de su ubicación en el equipo sigue siendo un misterio. Hacer algo por esas personas es difícil: el desarrollo requiere una mejora personal constante, que simplemente no lograrán. Si un lego mismo es consciente de su nivel y no se distingue por sus ambiciones inadecuadas, puede intentar vincularlo al departamento de pruebas; a veces, las habilidades bajas no impiden que las personas encuentren errores correctamente. Aquellos que ni siquiera son conscientes de su cercanía están mejor sin tener que lidiar.
EclécticoUna mezcla nuclear de ingeniero, artista descuidado y poco talentoso. El código que escribe es una vinagreta indigesta de diferentes estilos y módulos. A diferencia de los productos de descuido, este es un código con un reclamo de talento: en apariencia puede parecer que incluso tiene algo hasta que intentas ejecutarlo. La pregunta principal de la persona que lee el código ecléctico: "¿Qué quiso decir?" Para rectificar la situación, primero debe comprender si esta confusión es realmente el resultado de algún tipo de búsqueda, o si hay un intento antes de que se bañe las pistas. El eclecticismo benigno se beneficia enormemente con revisiones sistemáticas de códigos.
Finalmente, hay otra raza que se distingue del resto en todos los sentidos: este es un
vaquero o un lobo solitario. Los hábitos felinos lo alcanzan al más alto grado. En su oficio, un vaquero, como regla, es muy bueno (de lo contrario, simplemente no puede permanecer en su lugar), en el trabajo en equipo, es absolutamente inútil. Se distingue por su determinación de jugar solo de acuerdo con sus propias reglas: asumir proyectos que le interesan, y no otro, usar los medios que desea, contar exclusivamente con sus planes, y así sucesivamente. Los vaqueros solo tienen una forma: comprender de una vez por todas que no formarán parte del equipo y decidir si los valora lo suficiente como para soportar sus hábitos peculiares. En general, los vaqueros son indispensables en dos casos: situaciones críticas, aparentemente sin esperanza y proyectos aislados que serán acompañados por expertos externos.
Entonces, hemos enumerado esas razas que el autor ha encontrado con mayor frecuencia. Sin embargo, se deben hacer algunas notas a esta clasificación:
- El líder no debe considerarse una excepción a la regla: tiene experiencia en programación, lo que significa que él mismo pertenece a una de las razas. Esta es una circunstancia importante: su enfoque individual para escribir código afectará la cultura del equipo en su conjunto. Por ejemplo, en un grupo de líderes minimalistas, la documentación puede deslizarse, porque nunca le prestó la atención adecuada, incluso en su propio trabajo.
- Repetimos una vez más: los tipos no siempre son puros e inmutables; las personas a menudo resultan ser más multifacéticas que las construcciones teóricas. Es más fácil juzgar quién pertenece a qué raza en esos momentos cuando las características individuales se muestran de manera más prominente, con nuevos comienzos y cuando se acerca la fecha límite.
- Si tiene que formar un equipo desde cero, tenga en cuenta que el conjunto más ganador es el de arquitectos (pensamiento estratégico), constructivistas (elaboración de detalles) y artistas (racha creativa). Pero lo más probable es que ya tenga un equipo con personal, y esto es completamente normal: pueden trabajar juntos en cualquier equipo.
- Las tres cualidades principales que se necesitan para trabajar con la mayoría de las razas son el discernimiento, la paciencia y la capacidad de convertirse en un mentor.
Con toda la diversión de esta lista, puede no ser inmediatamente obvio cómo beneficiarse de ella en el trabajo diario. El autor ofrece un par de ejemplos con análisis de situaciones específicas que a menudo surgen con ciertas razas.
Ejemplo no 1
Situación: tiene un código voluminoso que debe actualizarse a las necesidades actuales de la empresa, y un desarrollador minimalista que lo ve por primera vez en su vida. El desarrollador afirma que el código debe reescribirse desde cero: todo es demasiado complicado, pero no puede hacerlo: ya se han gastado muchos recursos en el producto. Que hacer
Solución: cambie ligeramente la tarea. Al minimalista le encanta la claridad, tiene una debilidad por trabajar con la arquitectura: sobornarlo con varios objetos o funciones no demasiado caros y obviamente defectuosos, darle libertad para reconstruirlos a su discreción en el futuro. Solicite estudiar y documentar el código, incluso para este propósito. Como resultado, el minimalista se verá obligado a hacer lo que negó: descifrar el código milagroso para pasar a una lección más interesante.
Ejemplo no 2
Situación: no está de acuerdo con el arquitecto sobre la solución que implementó. Te parece que algunas cosas no se hacen de la manera óptima, él no ve ningún problema.
Solución: los arquitectos suelen tener una visión propia de la estructura: holística y coherente, pero no obvia para el observador externo. Si no puede mirar el asunto a través de sus ojos, no lidere disputas especulativas, sino que organice una discusión más sustantiva. Supongamos que le pide al arquitecto que describa en detalle el mecanismo de acción, idealmente un prototipo funcional o una versión de demostración simple. Esto revelará rápidamente todos los defectos de implementación, si los hay, o mostrará su error. Del mismo modo, si el código le parece demasiado engorroso y monolítico, sugiera dividirlo en componentes; si esto no afecta el sistema, está bien.Esto concluye la primera parte del ciclo. Más adelante, discutiremos temas como el mal inevitable de las reuniones técnicas, según los escenarios en los que los líderes suelen ir al fracaso o al éxito, problemas que recaerán en el nuevo líder de inmediato y mucho más.