El otro día hablaba con otro profesional del sector (informática) que estaba jodidamente molesto con la forma de actuar de uno de sus compañeros de equipo.
Básicamente, el chico se quejaba de que el otro “no tenía vida social” y por tanto se llevaba trabajo a casa. Que llegaba el fin de semana, y como se aburría, se ponía a programar como un loco, adelantando mucho más que él. Y que para colmo no le enseñaba lo que había hecho, teniendo él luego que buscar en el código los cambios para entenderlos.
Por lo cual, tenía que dedicar parte de su jornada laboral a comprender qué trabajo había ya hecho y qué parte quedaba. Descontando, además, la presión por la supuesta “productividad” de su compañero.
Bajo este escenario hay, a mi modo de ver, varios puntos que delatan que en esta compañía (unos 700 empleados y varias oficinas, no hablo de una PYME familiar precisamente) no se están haciendo las cosas correctamente.
Vayamos por partes.
Crunch vs trabajo en horas libres
Sobre este punto he dedicado ya un artículo en profundidad, así que no me voy a repetir mucho.
Simplemente diré que:
- El crunch, se mire por donde se mire, es nocivo de cara al trabajador (y a la industria): Entiendo por crunch la obligatoriedad por parte de la empresa, sea o no remunerada, de dedicar más horas de las estrictamente acordadas en el trabajo. ¿A qué se debe? Pues a que la ingeniería informática de ingeniería tiene más bien poco. Haciendo el símil, a un arquitecto que diseña un puente se le exige que ese puente funcione sí o sí. En cambio a un ingeniero informático pues oye, si no funciona ya se irá solucionando con el tiempo. Lo que transforma la gestión de proyectos informáticos en un cachondeo de timing en el que si llegamos pues genial, y si no pues o bien se alargan los plazos, o bien se hace crunch.
- El trabajo que se hace porque a uno le da la gana no es crunch: Dicho esto, el que alguien quiera dedicar porque sí más tiempo a trabajar del que debería no debería molestarle, ni mucho menos afectar, al resto de trabajadores del equipo. Cada uno es libre de hacer lo que quiera en su tiempo libre: trabajar incluido. Y si no, que nos lo digan a los autónomos…
Por tanto, por aquí doy toda la razón al compañero de mi conocido. Si quiere llevarse trabajo para casa, adelante. Más feliz será el empresario y la empresa. Pero, y ojo al dato, esto no debería representar ningún problema al resto del equipo si las cosas se hicieran correctamente.
¿Y a qué me refiero con esto?
La gestión de proyectos está para algo
Porque sí. Igual que hace un momento echaba pestes de esta disciplina, sigue teniendo todo el sentido del mundo en una industria como la informática.
Que un trabajador sea más productivo, o como en este caso dedique más horas (ya expliqué que una cosa no tiene por qué venir de la mano de la otra) no afectaría al resto del equipo si éste tuviera un buen sistema de gestión de equipos y proyectos.
Un servidor, tanto cuando trabajaba por cuenta ajena para Telefonica I+D o para el BBVA, como desde que trabajo como externo para otras grandes compañías, SIEMPRE SIEMPRE una de las primeras labores que realizamos es la creación de un sistema de gestión de tareas.
Y me da igual el servicio que quieras usar:
- Que si Trello.
- Que si Asana.
- Que si GIT.
- Que si reuniones diarias a lo SCRUM.
- Que si nubes de humo.
La cuestión es que por experiencia para que un proyecto que se realiza entre más de una persona acabe en buen término, se necesita saber, como mínimo:
- Qué han hecho el resto.
- Qué labores tienes que hacer tú.
Descontando que además nos permite establecer un timing más real, al vernos obligados a subdividir en tareas las funcionalidades que tenemos que desarrollar.
¿A que cuando vas a comprar al supermercado en vez de llevar una lista que diga “comprar”, haces un listado con las cosas que quieres comprar?
Pues lo mismo para gestionar proyectos profesionales.
Llega hasta el punto que un servidor tiene varios tableros de Trello para proyectos profesionales y personales en los que, ojocuidao, el equipo soy solo yo. El blog, por ejemplo, es uno de ellos, que tiene una estructura como la que puedes ver en la foto que acompaña este artículo.
Imagínate recibir en tu correo semanalmente historias como esta
Suscríbete ahora a “Las 7 de la Semana”, la newsletter sobre Nuevas Tecnologías y Seguridad de la Información. Cada lunes a las 7AM horario español un resumen con todo lo importante de estos últimos días.
Documentar debería ser O-BLI-GA-TO-RIO
No opcional. Obligatorio.
Que lo repito por si no se ha entendido.
Y entiendo que a un programador lo que le mole es escribir código. Pero ese código tiene que:
- Ser entendible por el resto del equipo.
- Ser auditable por futuros equipos.
Y estas dos cosas únicamente se consiguen documentando. Punto.
En el caso que os ponía, de nuevo, el problema no lo tiene mi amigo, sino el empresario que les paga la nómina. Cuando su compañero deje el trabajo a ver quién es el guapo que hereda ese código sin documentar.
Es más, ya expliqué por aquí el caso de otro conocido cuya empresa se fue a la mierda precisamente porque el programador jefe se fue de la empresa, y como aquella compañía era un mero bastión del código creado por ese programador, en cuanto se fue el resto no pudieron seguir implementando.
Aguantaron 3 meses. Lo que aguantó la maquinaria funcionando sin engrasar (y la paciencia de los clientes). Y luego a la quiebra.
Caso aparte es el hecho de que mi amigo esperaba que el otro le explicase qué había hecho.
Pues no, hijo, el trabajo de tu compañero es sacar adelante las tareas pendientes, no explicarte a ti o a alguien cómo ha hecho su trabajo. Pero, eso sí, deberíais tener un sistema centralizado de versiones documentadas, y un gestor de tareas para saber qué parte te toca a ti y qué parte le toca al otro.
Que sirva de aviso a navegantes, tanto para trabajadores como para empresarios.
Sin estas dos patas cubiertas, es pan para hoy hambre para mañana.
________
¿Quieres conocer cuáles son mis dispositivos de trabajo y juego preferidos?
Revisa mi setup de trabajo, viaje y juego (ES).
Y si te gustaría ver más de estos análisis por aquí. Si el contenido que realizo te sirve en tu día a día, piénsate si merece la pena invitarme a lo que vale un café, aunque sea digitalmente.
