Our values - cuánto vale y cuánto cuesta el bienestar de los developers

Hace poco me tocó ponerme a pensar en formas de hacer nuestro trabajo de forma más profesional, más ágil y cómoda, pero también formas para sentirnos mejor haciéndolo.

No es algo que hice muy concientemente tampoco: desde que empecé a trabajar mi mente barrunta buscando mejoras que sean convenientes para todos, y es algo que creo que me sale bastante bien.

Me puse a hacer un compilado de las cosas que, me parece, se necesitan en particular con la gente que estoy trabajando ahora, pero quise también escribir algo más general: creo que muchas veces el aspecto de cómo se siente el developer no es tenido en cuenta como se debe. Hay mil factores a tener en cuenta para que alguien se sienta cómodo en el laburo, con responsabilidades a distintas alturas de la cadena de management.

En principio, está en la responsabilidad del developer aprovechar las herramientas (técnicas, hardware, de apoyo moral) que se le brinden, y también estar constantemente evaluando cómo se siente y tratando de ver si las cosas que no están bien se pueden solucionar. Y, por supuesto, si tiene ideas de cómo hacer las cosas mejor, ¡comunicarlas! Es un paso importantísimo en el que hay que vender timideces si las hay, porque difícilmente el otro pueda adivinar cómo nos sentimos nosotros (y juro que aprender esto me costó sangre, sudor y lágrimas, más lágrimas de las que hubiera querido).

Respecto a las cosas a las que hay que prestar atención, enumero una lista acá seguramente no exhaustiva, pero que he visto (y sufrido) en mis años laburando en esto. Creo que los items de la lista se pueden clasificar en 3 categorías principales: información, herramientas y medio ambiente. Aquí el top ten:

1. Información sobre la tecnología usada: es importante que el developer cuente con lugares y personas a los que acudir con preguntas específicas sobre las tecnologías que usa. Esto es crucial sobre todo cuando la persona en cuestión recién está empezando: es esencial saber que tenemos una fuente última a la cual recurrir después de haber agotado nuestros otros recursos (libros, material online, canales de irc de ayuda, foros, etc). Este material/persona de consulta debe ser, en mi opinión, provisto/pagado por la empresa que nos emplea.
   
2. Información sobre la estructura en la que se está inserto: es *sumamente* importante saber con quiénes estamos tratando (es decir, qué papel cumple una persona dentro de una organización). Esto influye tanto para buscar la mejor forma de relacionarnos, como también para acudir a la persona correcta ante cualquier necesidad. Así, nos vamos a evitar hablar con la persona equivocada, ahorrándonos (y ahorrándole) tiempo, y obteniendo respuestas más diligentes.
   
3. Información sobre lo que se espera de uno: Tener claro lo que se espera de nosotros es indispensable para poder enfocar nuestro trabajo a cumplir esos objetivos. Además, se tiene así una escala conocida por ambos (empleador y empleado) para poder evaluar el desempeño de este último, y establecer, por ejemplo, si se merece un aumento de sueldo, o una compensación de otro tipo. El feedback regular (por supuesto, de manera respetuosa) puede ayudar mucho: a corregir errores y a estimular al programador y sentirse justamente tratado.
   
4. Información sobre el trabajo que se está haciendo: Requerimientos y plazos deben ser dejados en claro desde el comienzo, y si hay cambios en uno u otro, éstos deben ser comunicados en tiempo y forma al desarrollador. En un caso ideal, los cambios deberían ser hechos después de una charla sobre la viabilidad de los cambios con el equipo de desarrollo, o su líder. Hay varias herramientas que ayudan a plasmar y llevar registro de los requisitos (tanto de funcionalidad como de usabilidad y apariencia). El project manager y el contacto con el cliente tienen un rol protagónico acá.
   
5. Herramientas tecnológicas adecuadas (infraestructura de SF): Es difícil hacer una tarea si no se tienen las herramientas adecuadas. Y, siendo que muchos ya han pasado por nuestros mismos problemas, y que existen muchas soluciones libres a esos problemas, es una picardía no utilizarlas. Además, hay que conocer las fortalezas, debilidades y especialidad de cada software, y usarlo acordemente: Un editor es buenísimo para escribir, pero para llevar issues, mejor que un .txt es un issue tracker :). Hay quienes piensan que algunos reemplazos son tan útiles como el original, y esto no siempre es cierto: es necesario un diálogo sincero y abierto con los que utilizan las herramientas diariamente para saber si realmente cumplen su función, y son las adecuadas para el problema que buscan solucionar. Por ejemplo, para desarrollar skins que anden en (fucking) IE, *hay* que tener un IE para probar. Desarrollar para IE es un sufrimiento, pero si además no tenemos un IE para probar a mano, el sufrimiento es aún mayor. Os juro.
   
6. Herramientas físicas adecuadas (HW): Lo mismo pasa con las máquinas. Como desarrolladora de skins de plone, sé que necesito RAM. And I mean it. Aunque el hardware no es tan barato como uno quisiera, es notable cómo una mejora en la performance de una máquina (no siempre tan caro) mejora el humor, predisposición y productividad de un desarrollador. Y tiene sentido: uno se preocupa sólo por su trabajo, en vez de quedarse esperando y perdiendo el tiempo.
   
7. Herramientas gerenciales (personas): Cuando trabajamos en grupo, es necesaria una buena coordinación y adminsitración de los recursos. Creo que este punto debería ser obvio, pero tener gente capacitada y capaz en los puestos de decisión es fundamental. Tanto por cuestiones administrativas, contables o del proyecto en sí: Que los sueldos sean pagados en término (y que alguien se ocupe de que eso se haga), que la cuenta de la luz esté al día, que las cosas que desarolla alguien más y que yo necesito estén listas para cuando yo necesite trabajar en eso son todas tareas que necesitan a alguien *muy* atento a cómo se mueve, articula e interrelacionan las distintas partes de una organización.
   
8. Puesto de trabajo cómodo: El trabajo en la compu es, casi por definición, antiergonómico. Sumado a esto, pasamos muchas horas frente a la compu: las de trabajo propiamente dichas más siempre algunas de recreación (revisar mail personal, leer feeds, bloggear, chatear, desarrollos propios). Las consecuencias son por todos conocidas: muñecas agonizantes, dolores de cabeza, ojos irritados, piernas dormidas, dolores de cuello a montones. Además del ejercicio físico que todos deberíamos hacer aunque sea un poquito, descansos periódicos para estirar músculos y descansar la vista, y mesura en la cantidad de horas ivnertidas frente a la compu, hay muebles que pueden ayudar a disminuir las malas posiciones y hábitos. Se pueden buscar consejos en internet, un arboco o fisioterapeuta amigo.
   
9. Condiciones ambientales: Tener internet sin cortes y con bandwidth decente; un ambiente bien iluminado, sin reflejos molestos y que no nos haga forzar la vista; una temperatura que nos permita trabajar sin derretirnos ni que se nos escarchen los dedos y un nivel de ruido bajo ayudan a concentrarnos en el problema en que estamos trabajando.
   
10. Condiciones ambientales interpersonales: La relación con el resto del equipo (a pequeña y gran escala -esto es, el equipo de un proyecto en particular, pero en general con todos con quien tenemos trato dentro de la organización) debe ser idealmente cordial (con un mínimo de buena onda y respeto). Este aspecto debería ser tenido en cuenta por todos: sin llegar al chusmerío ni a ventilar cosas privadas, creo que es bueno que quienes toman personal u organizan los equipos de trabajo sepan las opiniones de sus empleados que sean relevantes a la organización. Cuando se puede armar un equipo sólido, donde todos quieran ayudarse entre sí y donde haya espíritu de cooperación, el resultado es obviamente mejor que cuando el equipo queda fragmentado, aún sin cosas explícitas, pero que se sienten en el trabajo diario. La comunicación (en tiempo y forma adecuados) es un skill que acá toma relevancia extraordinaria.
    

Concluyendo, y después de releer lo que escribí, creo que al final este top ten es "Cómo mantener a su programador concentrado en el problema que ud. le paga por resolver". Tener condiciones adversas en uno o más de los puntos que mencioné es, sencillamente, ponerle palos en la rueda al programador e impedirle que haga bien su trabajo. Now, it's up to our employers si quieren aprovechar bien su inversión en la mano de obra que están pagando.

Pero no quiero cerrar este texto sin mencionar el punto que me parece que engloba a todos los otros, y que va incluso un poquito más allá: La valoración del programador como persona y como profesional. Si el empleador realmente valora al empleado, estas cosas deberían estar funcionando - o en camino a funcionar. Y con valoración quiero decir dos cosas: decirle que se lo valora, con palabras. Pero, tanto o más importante, decírselo con las condiciones que se le ofrecen para trabajar.

Creo que, lamentablemente, muchas empresas de IT no se han dado cuenta todavía de que la materia prima escasa en estos días de reviente de la informática son sus empleados. Y que hay que cuidar el bienestar de esos cerebros y su cubierta corpórea :)

PD: Las condiciones que se le ofrecen para trabajar incluyen el sueldo, pero sobre eso voy a escribir alguna otra vez.
Pd2: Dice David Fetter que para él el número 10 debería ir primero: "it's all about humans", asegura.
PD3: El Dani acota que muchas de estas cosas no son aplicables sólo a developers. Yo digo que es cierto, pero digo esto porque es lo que conozco.