Cambiando a modo Autoritario – Una historia real

La Misión

La misión era formar un equipo para un proyecto de esos grandes, realmente muy grandes, así que la empresa se puso a la búsqueda de desarrolladores para que eligiera de entre ellos a los que considerase más apropiados. La búsqueda se comenzó tanto de manera interna como externa en un esfuerzo contra reloj por conseguir profesionales que cumpliesen con los requisitos que yo había solicitado; nada del otro mundo a mi entender.

Buscando profesionales

Está claro que uno debe privilegiar la incorporación de aquellos profesionales que ya forman parte de la empresa por sobre aquellos es necesario reclutar puesto que el recruiting es un proceso largo, así que comencé por donde debía aunque paralelamente evaluaba los perfiles de las candidatos que el equipo de recruiting me enviaba (haciendo una tarea excepcional) y los entrevistaba en horas extra laborales ya que la gente que trabaja difícilmente puede “escaparse” de sus lugares de trabajo para ser entrevistados.

Como en las empresas los desarrolladores no vagan por los pasillos a la espera de una asignación sino que en su inmensa mayoría están asignado a proyectos, luego de evaluar a un par (los disponibles), y a falta de opciones (quería evitar a toda costa formar un equipo distribuido) me focalicé en entrevistar candidatos externos. Candidato tras candidato fallaban miserablemente en temas técnicos los cuales yo consideraba sumamente esenciales y me hacían replantearme mis niveles de exigencia, los cuales me vi forzado a relajar hasta niveles mínimos; y luego los debí relajar un tanto más. La verdad es que encontrar verdaderos profesionales es una tarea titánica que puede asombrar a muchos pero el punto es que luego de 2 semanas no había podido encontrar ni a uno solo. Los candidatos, en un gran número, provenían de entidades bancarias, empresas constructoras u otras no dedicadas directamente a la industria del desarrollo de software (nota: no había límite alguno en la propuesta salarial ni en los beneficios ofrecidos por lo que si se hubiese presentado un arquitecto seguramente se lo hubiese tentado, doy fe. En realidad, para ser honesto, se presentó un arquitecto pero este era un título que se había autoasignado de manera descarada, pero ese es otro tema)

Sin demasiadas opciones y repleto de presiones desde varios frentes, porque básicamente tenía que formar un equipo y el tiempo se agotaba, me decidí por aquellos que tenía más experiencia y respondían con mayor coherencia en las sucesivas entrevistas. Y no solo eso sino aquellos con mayor predisposición y que pensaba que trabajarían mejor como equipo, nada fácil. Luego, cuando el tiempo se agotó definitivamente, el management más alto se encargó de sugerirme los restantes, tres juniors.

Características del equipo

Ninguno de los miembros del recientemente formado equipo había escrito nunca una prueba unitaria y tampoco sabían nada al respecto, tampoco habían trabajado con integración continua a excepción de uno de ellos, y muchos no habían usado nunca una herramienta de gestión de versiones. Aunque no es necesario continuar con esta lista, quien lee puede inferir el resto de los tópicos faltantes.

No obstante a esto que menciono, es de tener en cuenta que de entre los descartados había quienes conocían estos temas aunque fallaban en tareas como ordenar un vector de 10 números enteros, algo que quedará para otra entrada porque me ha llamado poderosamente la atención.

Comienza el proyecto

Comienza el proyecto y caigo en el primer error. Yo creía que luego de explicar las prácticas básicas (UT, CI, PR y SCA), estas iban a ser reconocidas como beneficiosas a la primera; error! La resistencia fue grande, recuerdo solo algunas pocas opiniones por su repetición:

  • ¿Para qué UT? Yo nunca los necesité!
  • ¡Qué importa si el build está roto! No entiendo por qué no puedo subir mis cambios
  • ¿¡Como %#&!* querés que suba código si todavía no lo he terminado!?, mañana lo termino y lo subo
  • En eso de revisar el código se pierde mucho tiempo
  • No pongo los comentarios en los checkins porque me olvido, además nunca los va a leer nadie

Lo peor es que obtener estos y otros conocimientos (o hábitos) es algo que lleva mucho tiempo. No solo eso sino que además estos fueron problemas a nivel técnico pero también los hubo a nivel organización: el equipo no era capaz de auto organizarse, requerían dirección, requerían asignaciones, requerían control y seguimiento y requerían…. órdenes.

Cambiando a modo autoritario

Antes de continuar debo decir que cambiar a modo autoritario es en extremo sencillo, casi que me animo a decir que es natural, y es quizás por eso que es tan común en el mundo. Pero aunque va en contra de todo lo que crees, de lo que sabes, de lo que has aprendido, de lo que has estudiado, de lo que has pensado y reflexionado, la autoridad es una facultad (y una responsabilidad) con la que, en parte,  te enviste embiste la compañía y, que en parte, tenés por tus conocimientos. Y en ese momento entendí que debía utilizarse por el bien de todos.

Comencé por imponer la prácticas de manera muy rigurosa, a controlar su cumplimiento y a alertar a los infractores. Solo como ejemplo las siguientes fueron las primeras reglas inquebrantables y me aseguraba que se cumplieran:

  • Nadie sube nada con el build roto
  • Todo el mundo sube código al menos una vez al día
  • Nadie deja el build roto por ninguna causa
  • Si el build se rompe, a arreglarlo inmediatamente (es prioridad número uno)
  • Antes de subir, se pide a un compañero que revise el código y se incluye el nombre del revisor como parte del commit
  • Todo método tiene que tener al menos un UT
  • Los comentarios en los commits deben explicar el motivo y contenido de los cambios

También hacer el seguimiento del avance de manera estricta para forzar a las personas a que siguiesen no solo las prácticas sino que también las tareas de soporte como reportar avance, tiempo consumido en la tarea, etc. Recuero que día tras día siempre debía recitarle a alguien: “si no subiste código ni ayer ni antes de ayer y no reportaste las horas consumidas ¿cómo puedo saber que estás trabajando?”. Obviamente detrás es esta excusa lo único que pretendía era que subieran código periódicamente y que reportasen las horas en una herramienta en la que queríamos tener esas horas, nada más. También sacaba reportes diariamente de las distintas “infracciones” y se las comunicaba.

Todo esto, como habrán de imaginarse no me hizo merecedor del premio al mejor amigo, sobre todo después que la experiencia me diera la razón en repetidas oportunidades. Solo dos ejemplo:

  • Caso 1: Un día uno de los integrantes me dice que se le había roto la PC a lo que yo le pregunto: ¿perdiste algo de trabajo? Sí, lo de hoy y lo que de ayer –me responde. ¡Pero acaso no quedó claro que se hace commit todos los días?!
  • Caso 2: Otro miembro reportaba que había solucionado un conjunto de bugs un día y al siguiente reportó que había solucionado otros tanto pero a todo esto yo veía que no subía código. Subí el código le decía una y otra vez pero luego QC reabrió todos sus bugs porque nunca hizo commit.

Primera buena noticia

Pasado casi tres meses todo el mundo subía código al menos una vez al día, es más, casi todo el equipo subía código varias veces al día. Todo el equipo comentaba sus commits y luego fueron mejorando sus comentarios a medida que necesitaban buscar cosas en SVN, nunca nadie dejó el build roto jamás, ni lo rompían con la frecuencia inicial, incluso hubo semanas en las que con más de 200 commits nunca se rompió el build (mucho código nuevo, pocas pruebas unitarias y mucho cuidado por parte de todos – no usábamos análisis estático de código). Las pruebas unitarias mejoraron algo (no mucho). La calidad del código se incrementó notablemente aun cuando distaba de ser lo esperado.

Luego el equipo siguió creciendo y los nuevos integrantes se adaptaban a las reglas de manera natural ya que el resto se las comunicaba como algo positivo “che, rompiste el build, es un UT ¿querés que te de una mano con eso?”, “fulano, hay que poner comentarios en los commits. Fijate como lo hacemos nosotros!”.

La buena noticia

Por último, con la mejora de la comunicación, la confianza adquirida y la experiencia en el proyecto el equipo fue capaz al fin de auto organizarse, de elegir las tareas, de coordinarse, de reportar proactivamente sin esperar a ser consultados, de evaluar alternativas y sugerir cambios, de trabajar como un verdadero equipo, unido. Recién luego de estos cambios “forzados” el equipo comenzó a dar verdaderos resultados y de disfrutar de la autonomía y la confianza que se habían ganado. Luego de esto abandoné el proyecto con una gran satisfacción y un orgullo inmenso.

Conclusión

Cuando estamos en un equipo bien aceitado, un nuevo miembro experimentado (y técnicamente fuerte) que pertenezca a la industria se adaptará a la manera de trabajo y en poco tiempo habrá asimilado todas la prácticas que ejecuta el equipo sin problemas. Pero, un equipo grande y completamente nuevo formado en parte por profesionales que no pertenecen al la industria, y otros tantos juniors, y no fuertes técnicamente, no será capaz de auto organizarse.

Llegar al nivel de madurez necesario para que sea posible todo esto no ocurrirá mágicamente nunca, antes de esto tendremos lo que al principio: un equipo completamente inmaduro e incapaz de lograr los resultados que se necesita que alcance. Estos equipos requieren que se los dirija, y para ello contamos con la autoridad (no solo la del conocimiento sino también, y en este contexto quizás más importante, aquella que te otorga tu posición en el grupo)

Entonces, el ejercicio firme de la autoridad (o el autoritarismo) es un vehículo que, a falta de mejores opciones, debe en estos casos utilizarse para generar las condiciones necesarias para su total desaparición (El autoritarismo anti-autoritario).

Sin categoría

Deja un comentario

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *