Continuamos compartiendo extractos de
la guía de supervivencia para principiantes tecnológicos de J.H. Rainwater. En la primera serie, hablamos sobre las razas de desarrolladores con las que el gerente generalmente tiene que trabajar; Ahora tratemos de entender qué hacer con todo este zoológico. Las actividades organizativas en un equipo técnico se pueden dividir en dos partes: cosas más o menos nativas (como revisiones de código y gestión de arquitectura) y todo para lo que la vida de un programador no se preparó, es decir, administrar personas y procesos. Tratemos primero con un extraño.
Priorización
Lo primero que generalmente derriba a un líder recién horneado es una avalancha de la información más diversa. Este estado de cosas es bastante lógico: el que está al frente del equipo está menos cerrado en su marco y está involucrado en más procesos, pero no se hace más fácil. Como resultado, el líder técnico a menudo comienza a dispersarse: teniendo en cuenta su deber de responder a cada señal, se agarra de todo de una vez, salta de una tarea a otra y se pierde lo que más necesita atención.
Solo hay una salida: filtrar este flujo de información, separando lo que está directamente relacionado con la tarea principal (liberar un código que cumpla con los requisitos comerciales, con una fecha límite acordada) y enviar el principal a la cartera de pedidos. Pero al principio, los criterios para tal clasificación pueden no ser obvios. Para los principiantes, absolutamente todo parece importante.
Lo complicado es el hecho de que muchos estímulos excitan emociones que interfieren con la evaluación sensata de la importancia y la urgencia de un problema. Las señales entrantes pueden causar interés (se encontró una anomalía curiosa en el código), culpa (el diseñador recuerda que ya ha solicitado muchas veces implementar la función que quiere implementar), aprensión (el usuario expresa insatisfacción con la actualización).
Para sistematizar con mayor éxito todas las solicitudes e información, el autor sugiere utilizar la siguiente matriz para procesarlas:
- ¿Cómo afectan los nuevos datos al alcance del proyecto, la decisión de diseño y la fecha límite del proyecto?
- ¿Es confiable la fuente de información? Si no, ¿se puede ignorar?
- ¿Debo reaccionar a la recepción de información de inmediato o puedo esperar un poco?
- ¿Dónde y cómo guardar la información para que, de ser necesario, se pueda abordar rápidamente?
- ¿Cuál es el período de validez de la información? ¿Cuándo se vuelve irrelevante?
- ¿Cómo se compara esta información con lo que ya se sabe sobre el proyecto?
Como puede ver, esta matriz ayuda a separar los granos de la paja en varios aspectos: deshacerse de la información francamente inútil o poco confiable, rechazar qué más se puede mover y evaluar la importancia de la información estrictamente para el proyecto actual. Sin embargo, las preguntas sobre el tiempo y los métodos de almacenamiento insinúan que la información que no es relevante en este momento no debe descartarse como irrelevante en principio; este es otro extremo que llevará al equipo al estancamiento a largo plazo. Hablaremos más sobre esto más adelante, cuando discutamos los conceptos de "liderazgo" y "liderazgo".
Proyectos en expansión
El siguiente punto doloroso es la evaluación de volúmenes y términos de trabajo. Nuevamente, durante algún tiempo, "nadar" en esta área es casi inevitable para un principiante de tecnología: se necesita experiencia para poder revisar todos los componentes del proyecto a la vez, sin perder nada, y desde el primer intento de establecer para cada tipo de trabajo, incluidos términos desconocidos y adecuados. Pero incluso la experiencia adquirida no salva de un cierto error, y no es posible reducirlo a cero. La precisión extrema en la planificación del trabajo se ve obstaculizada por dos leyes que Humphrey formuló acertadamente:
Cualquier proceso durará más de lo que espera. Siempre aparece algo en lo que no has pensado.
En base a todo esto, el autor llama a tratar el problema filosóficamente. Lo más probable es que, como primera aproximación, no pueda tener en cuenta funciones menos obvias o complicaciones impredecibles, y requerirán un recurso adicional que no hipotecó. Para tales sorpresas, debe estar preparado y preparar un equipo, para enseñar a las personas a reconstruir rápidamente con el fin de "reparar agujeros", para dejarles un poco de tiempo en reserva para circunstancias imprevistas. Lo que no se puede hacer en ningún caso es considerar el crecimiento natural como una emergencia y buscar al culpable, especialmente en otros departamentos (y esto siempre parece especialmente tentador). Entonces solo siembras enemistad entre los equipos y no haces nada para resolver el problema.
Sin embargo, uno no debe caer en un fatalismo completo: el crecimiento del proyecto es, sin embargo, el resultado de fallas en la planificación. No podrá deshacerse de ellos por completo, pero puede y debe reducir la concentración.
Si transferimos las leyes de Humphrey a realidades programáticas, queda claro que la planificación se hunde por dos razones: análisis insuficiente de detalles y estimaciones demasiado optimistas de la duración del diseño del producto de software. El optimismo entre los gerentes generalmente se desvía de una manera natural: varias veces rompiendo los plazos, seguramente comenzarás a jugar a lo seguro. En cuanto a los detalles, esta habilidad también viene con experiencia, pero desde el principio vale la pena tener una idea general de cómo debería ser la hoja de ruta.
Por ejemplo, si se embarca en un proyecto armado con dicho documento, habrá muchos desastres naturales y problemas por delante:
Si la hoja de ruta es más similar a la muestra a continuación, las posibilidades de un resultado feliz aumentan significativamente:
Además de estas dos razones, Rainwater enumera algunos factores de riesgo adicionales que Robert Glass, autor de un triste libro sobre proyectos de desastres en el campo de TI, destacó:
- Especificación inadecuada de los objetivos del proyecto.
- Aplicación de tecnología nueva para esta empresa.
- Metodología de gestión de proyectos anuales / faltantes
- Falta de expertos líderes en el grupo.
- Interrupción de acuerdos por fabricantes de hardware / software
Búsqueda de lenguaje común
Puede pensar que estamos hablando de habilidades de comunicación de talentos comunicativos, pero no, el significado del título es mucho más literal. En diferentes compañías, se forman equipos de programadores en diferentes terrenos. Si tiene suerte, podría estar a cargo de las personas que trabajan con su pila de tecnología nativa. Pero muy a menudo se encuentran equipos mixtos, donde diferentes empleados hablan diferentes idiomas. Tal confusión a veces dificulta la vida del líder.
Una de las tareas del líder es supervisar todas las actividades del equipo, para garantizar que todo el código que entra al mundo funcione, sea de alta calidad y sin excesiva complejidad. Si no está familiarizado con las herramientas que usan sus subordinados cuando desarrollan, entonces sus manos están atadas. No puede realizar revisiones de código de forma independiente, aprenderá sobre los errores graves solo en la etapa de prueba, lo que derriba todo el ritmo del trabajo y, hablando en términos generales, es mucho más fácil conducir por la nariz.
¿Qué hacer en esta situación? En general, hay dos formas. Si el conjunto de idiomas y tecnologías no es demasiado grande y cambiante, no puede perder tiempo e intentar dominarlos al menos a un nivel básico. Esta es quizás la mejor salida, por lo que no tiene que depender de nadie, recibirá información directamente, lo que significa que puede evitar el "teléfono muerto" cuando discuta la funcionalidad, los requisitos y los plazos.
Si no es posible aprender los idiomas necesarios usted mismo, deberá buscar formas de delegar esta responsabilidad. Forme el núcleo de asistentes que pueden brindarle una retroalimentación objetiva y honesta sobre cada tecnología desconocida (si solo un empleado la posee, este método, naturalmente, no funcionará).
Profundizar su conocimiento en temas relacionados con tecnologías y herramientas también es útil por otra razón: esta es la única forma de convertirse en un líder técnico en el sentido completo de la palabra. En su sistema terminológico, el autor divide los conceptos de "gerente" y "líder". Un gerente es aquel que organiza el trabajo, resuelve los problemas cotidianos y se asegura de que las tareas actuales se completen a tiempo y de manera adecuada. Un líder es un estratega que piensa fuera de los plazos de control, establece la dirección general de movimiento para su equipo, eleva el listón, reconsidera y optimiza los procesos. Por supuesto, en el equipo de desarrollo, este trabajo visionario requiere un buen conocimiento del mercado de la tecnología. En el fondo, el líder técnico estima constantemente que el juego de herramientas actual está desactualizado y necesita ser reemplazado, monitorea nuevos productos y al mismo tiempo tiene una perspectiva lo suficientemente amplia como para evaluar sus méritos reales (y no caer en el síndrome de Stunt).
En la primera parte del artículo, hablamos sobre el hecho de que el líder no necesita preocuparse de que dejará de trabajar con la tecnología, y para aquellos que marcan líderes, esto es realmente así. Pero aquí tiene sentido repetir la advertencia desde el mismo lugar: no espere al mismo tiempo evadir las responsabilidades del gerente. La gestión implica un equilibrio entre los dos roles, que a veces entran en conflicto, pero siguen siendo casi iguales (la gestión es algo inferior) necesaria para la supervivencia del equipo. Perfeccione las habilidades de organización para su ventaja: cuanto menos tiempo coma una rutina, más rápido crecerá como experto técnico. Si las tareas cotidianas se dejan al azar, reinará el caos en el que ya no habrá ninguna estrategia.
Recogida de rebaño
Ahora pasamos al segundo bloque de problemas: el notorio trabajo con las personas. Comencemos desde el principio: antes de hablar sobre cómo administrar un recurso humano, debe averiguar dónde obtenerlo. Incluso si tiene el equipo establecido, tarde o temprano surgirá la pregunta sobre la contratación de empleados. Anteriormente, analizamos los tipos de programadores y señalamos a aquellos que deberían ser perseguidos en primer lugar. Ahora debe comprender cómo actuar para identificar las cualidades necesarias en los candidatos y no sentirse decepcionado por su elección.
El autor ofrece las siguientes recomendaciones para entrevistas:
- Dele al candidato una tarea de prueba. Asigne a un empleado potencial una tarea que tendrá que resolver de inmediato o llévela a su casa y resuélvala para la fecha de vencimiento.
- Asegúrese de realizar una prueba oral de las habilidades del candidato, para que pueda evaluar tanto su conocimiento como la capacidad de pensar con claridad en una situación estresante.
- En la medida de lo posible, escriba los deberes del empleado deseado, todas las tareas que tiene que llevar a cabo, y entregue esta lista al candidato para su revisión. Entonces, la conversación se volverá más objetiva y, por regla general, más franca.
- No te limites a una reunión. Será muy bueno si el candidato se comunica no solo con usted, sino también con el "núcleo" antes mencionado: sus asistentes, diputados, desarrolladores líderes en el equipo. Pero organizar un espectáculo con todo el equipo no vale la pena, esto ya es demasiado.
- La verificación de las cualidades personales, las pruebas tipológicas y similares son un paso posible, pero opcional. Solo recurra a él si el candidato no se opone y tiene herramientas de evaluación confiables.
Hablando de contratación, uno no puede dejar de mencionar el otro lado: el despido de los trabajadores que derriban al equipo. Aquí Rainwater toma una posición bastante dura y aconseja sin vacilar deshacerse de aquellos que se han mostrado incompetentes o problemáticos. La mejor posición es la política de una advertencia: le da a una persona la oportunidad de mejorar, pero no permite el abuso de este derecho. Si un empleado está en la "lista negra" y usted tuvo una conversación con él, debe supervisar su éxito posterior con gran cuidado. Esto requiere un esfuerzo adicional, por lo que dar una tercera oportunidad ya es un derroche injustificado.
Además, la negligencia de un miembro del equipo generalmente afecta no solo a la "causa común" abstracta, sino también a personas muy específicas que tienen que corregir sus errores o tolerar el hecho de que estropea los resultados de su trabajo. La indulgencia excesiva, por lo tanto, se paga a su costa y es poco probable que fortalezca su posición de liderazgo.
Organización del trabajo de los empleados.
Ambiente de vida confortableEl libro presta mucha atención a este aspecto. Lograr la máxima productividad de sus empleados es una responsabilidad directa del líder, pero una alta productividad requiere una alta concentración, y la concentración es imposible si el programador está rodeado de irritantes de todos lados. Por lo tanto, el líder debe hacer todo lo que esté a su alcance para proporcionar al equipo buenas condiciones de trabajo.
Las recomendaciones específicas para diseñar una oficina que Rainwater ofrece en lugares parecen algo idílicas (por ejemplo, en una oficina separada para un hermano), y en lugares que suenan como ecos de un pasado lejano y difícil (cada desarrollador debe tener su propia computadora). Pero el principio general sigue siendo razonable y aplicable: para que los programadores tengan éxito en sus actividades, deben tener la oportunidad, por un lado, de trabajar en un equipo durante algún tiempo y, por otro, lavarse el cerebro solo. Para lo primero, necesita lugares de entrenamiento que estén equipados adecuadamente: salas de reuniones con proyectores, equipos de ocio (idealmente) con las famosas mesas de tenis o consolas de juegos. Para el segundo, es necesario organizar el espacio disponible para que las personas tengan que distraerse lo menos posible por el ruido, el parpadeo, los olores y otros factores de distracción. Si las condiciones son malas, deje que los empleados, especialmente aquellos que son valiosos y confiables, trabajen desde casa.
Un mínimo obligatorio de servicios también incluye equipos modernos y de alta calidad, que el desarrollador puede, dentro de lo razonable, configurar a su propia discreción. Si los autos son débiles y anticuados, no hay necesidad de hablar sobre avances tecnológicos, y no solo tiene una operación silenciosa y sin problemas. Para los programas de prueba, se deben asignar dispositivos especiales que reproduzcan las características estándar del usuario.
Horas de trabajoEl montón de deberes del asesor técnico, que describimos, sugiere que la duración de su jornada laboral casi debería duplicarse. Pero aquí debes tener cuidado. El problema es que, con su régimen de trabajo, el gerente mismo, de mala gana, establece el tono para todo el departamento. Si se sienta tarde, los trabajadores supondrán que también se espera algo similar de ellos. Como resultado, el procesamiento puede entrar en la carne y la sangre de su cultura local, y esto está lleno de problemas.
En primer lugar, no todos estarán contentos con este estado de cosas. En primer lugar, el procesamiento afectará a aquellos que están agobiados por obligaciones adicionales, por ejemplo, obligaciones familiares. Si hay muchas de esas personas, la situación en el equipo será tensa. Bueno, y en segundo lugar, el autor, como muchos después de él, señala que las horas de trabajo adicionales tienen más probabilidades de dañar la productividad, tanto por la fatiga como por la disminución de la motivación. Es más sabio exigir un trabajo efectivo de la escuela en la lección que inculcar hábitos que conduzcan al agotamiento.
Distribución de tareas y supervisiónSeamos honestos: incluso las condiciones ideales y un horario suave en sí mismos no alentarán a las personas a organizarse y trabajar diligentemente. Entre otras cosas, se necesita un jefe para distribuir el trabajo y garantizar que se lleve a cabo. Una parte de su tiempo debe estar ocupada por el control; por cierto, esto también contribuye a la concentración.
El autor aconseja no dividir demasiado los "períodos de informe" para los subordinados, no sofocarlos con una observación constante con una solicitud diaria de resultados. Es más inteligente determinar una lista de tareas para cada semana y evaluar la cantidad de trabajo realizado para el mismo período. En períodos particularmente calurosos, las listas tendrán que ajustarse incluso en este pequeño intervalo debido a cuestiones urgentes que surjan y cambios en las prioridades. El líder debe tener en cuenta todos estos cambios (y en las realidades modernas, y realizarlos en los sistemas contables apropiados).
Si un líder llega a un equipo "extranjero" con un ritmo de trabajo ya establecido, vale la pena pedirle a cada empleado que dibuje sus tareas habituales de la misma manera. Dicha documentación puede revelar muchas cosas interesantes, no solo quién y qué está involucrado y cómo se llevó a cabo la gestión antes, sino también lo que la gente generalmente piensa acerca de sus responsabilidades.
En cuanto al contenido de estas listas, por supuesto, en muchos aspectos estará determinado por las habilidades de los empleados y los requisitos de la empresa. Pero con todo esto, el libro avanza la idea de que es necesario rotar las tareas lo más posible: el desarrollador no debe hacer lo mismo de una semana a otra. Hay varias razones para esto. En primer lugar, ayuda a mantener un clima saludable en el equipo: sin ofender debido al hecho de que alguien constantemente recibe las cosas más desagradables o, por el contrario, las más interesantes, menos sensación de rutina y monotonía en el trabajo. En segundo lugar, los programadores deben mantenerse en buena forma intelectual: una variedad de tareas contribuirán a esto. Finalmente, con tal alternancia, se requerirá un mínimo de esfuerzo para formar un banco.
El Reinwater concede gran importancia al banco. La idea principal aquí es que en caso de enfermedad, vacaciones, despido, muerte prematura de cualquiera de los desarrolladores, el equipo debe incluir personas que puedan cumplir sus funciones, al menos durante ese período, hasta que contraten un reemplazo. Esto no solo garantiza el buen funcionamiento del departamento, sino que también evita algunos otros problemas (por ejemplo, la aguda dependencia de la empresa de Wizards). En consecuencia, es necesario mantener el interés de los empleados en las tecnologías relevantes, de todas las formas posibles para fomentar la cooperación y la participación en proyectos "extranjeros".
Por cierto, el propio jefe no está protegido del factor de caída de ladrillos. Por lo tanto, tan pronto como se acostumbre un poco, comience a pensar en quién sería su sucesor. Esto no es solo un reaseguro, sino también un buen ejercicio para delegar tareas: al preparar un sucesor, sin darse cuenta, debe pensar qué trabajo es el más fácil y seguro para confiar a otros. Durante hurgar este conocimiento será muy útil.
Y lo último: hasta ahora, se trataba principalmente de los intereses del equipo y de los superiores, pero no pierda de vista el hecho de que todavía trabajamos con personas. Las preferencias y características personales de los empleados deben tenerse en cuenta siempre que sea posible. No debe esperar una movilidad especial de alguien que es difícil cambiar de uno a otro, no debe, por razones de justicia, enviar los frenos a una tarea que teme no hacer frente, etc. Aquí nuevamente descansamos en contra de la tesis de que necesitamos monitorear cuidadosamente a nuestros empleados y conocerlos bien.
Motivación y ánimo.
Pero lo suficiente sobre los látigos, hablemos de los más agradables: esas galletas de jengibre que los programadores deberían obtener del trabajo. Rainwater nombra los siguientes tipos de pan de jengibre (en orden de prioridad): salario, avance profesional, palabras amables y, finalmente, regalía corporativa abstracta.
En términos de remuneración, los gerentes que han abandonado el desarrollo no son demasiado propensos a ser exigentes, pero a menudo caen en el extremo opuesto y sobreestiman las expectativas de los empleados. Al decidir las tarifas, tenga en cuenta los siguientes factores: productividad, experiencia, efectividad, puntualidad de las tareas, tarifa promedio actual, condiciones del mercado y estándares corporativos. Un error común es aumentar los salarios por adelantado, con la esperanza de que esto aliente a los trabajadores a dar todo. , – , .
, , , . , , .
– . , , , (, , «»). . – , . , , , .
, . – , -, , , , . : , . « » , . ( – ) – .