Técnicos demasiado exquisitos

3

Entre los blogs que suelo frecuentar como lector, está el de Javier Garzas. Y uno de los motivos por lo que le sigo, entre otros, es porque sobre muchos puntos tenemos una visión diferente, o al menos eso me parece. Esa visión diferente me hace pensar, y muchas veces tras leer algo suyo se me ocurre algo que creo que merece la pena comentar. Y esto es lo que me ha pasado en este artículo.

Estaba leyendo su serie de dos posts sobre tareas no-técnicas y si deben ir al product backlog o no. Y en su segunda parte me encuentro con el punto 4, que es realmente el meollo central de los dos artículos. Aparte de si se deben poner esas tareas o no en el product backlog, me pongo a pensar en la reacción del equipo técnico cuando les llegan tareas así. Y de eso voy a hablar hoy.

Unos ejemplos

Como siempre, todo queda más claro si usamos un ejemplo. Así que pongo el siguiente caso:

Un equipo de desarrollo tiene un site e-commerce de venta de seguros como producto principal asociado. Cada vez que alguien compra, una compleja lógica se ejecuta calculando ratios, comisiones y múltiples aspectos para poder dar un precio. La gente de negocio que lleva tiempo en la empresa tiene claras todas esas normas para calcular precios, pero les cuesta mucho explicárselo a las nuevas incorporaciones. Y como están en plena expansión de negocio, la gente nueva entra casi a diario. Así que se ponen a hacer un manual de como funciona esa parte. De repente llegan al punto en el que empiezan las dudas y terminan acudiendo al equipo de desarrollo para que les explique como funciona. Por supuesto, nadie en el equipo tiene claro 100% todo el proceso por el que se determina el precio, por lo que alguno tendrá que “patearse” el código y revisar, exactamente, lo que sucede. Y allí llega la petición de negocio: ¿Podríais hacer un informe que explique como se calcula el precio a partir del código que tenemos ahora?

A este equipo le piden documentación sobre el proceso. Negocio la necesita y aportará mucho valor. Y los desarrolladores son los únicos que pueden realmente hacerlo.

Otro ejemplo:

Hubo una gran caída en la empresa debido a un fallo de software, esto ha provocado quejas de los clientes que podrían estar en posición de demandar a la empresa. Algunos clientes piden visibilidad sobre lo ocurrido y garantías para que no pase otra vez. Por lo que dirección pide al equipo encargado un informe post-mortem y un plan de acción.

O un último ejemplo:

La empresa se acaba de fusionar. Hay que introducir miles de configuraciones de golpe en una herramienta cuyo back-office está diseñado para meterlas una a una. Así que piden al equipo que incorpore los datos que tienen en un excel. Hay que revisar el excel, ver que los datos son correctos, escribir scripts para traducirlo a SQL e insertarlo de forma masiva.

La reacción

En muchos casos la reacción del equipo, o de algunos integrantes puede ser: “Soy un programador, esto que pides no es programar, no es mi trabajo”. O “la documentación no sirve para nada. Somos ágiles y el manifiesto ágil habla de no escribir documentación”. O “esto es trabajo de operaciones, no de desarrollo, que lo hagan ellos”.

Resumiendo, puede aparecer resistencia en el equipo por tener que hacer un trabajo que consideran de poca categoría o que implique escribir un extenso word. He visto hacer algo parecido al primer ejemplo, y llevó una semana de varias personas. Así que no es una “simple tareíta”.

¿Es sano este comportamiento? ¿Deberían hacer los programadores tareas que no son exclusivamente programar?

Mi opinión

Si un equipo está entregado al negocio, si está alineado con el negocio como debería estarlo, esto no debería suceder. Que sucedan  este tipo de cosas no es más que el resultado de una falta de implicación con negocio. “Yo programo y ese es mi trabajo”. Creo que esa forma de pensar es dañina y solo demuestra que lo que les pase o necesiten en negocio no te importa demasiado.

Si lo piden es porque aporta valor. Si crees que no aporta valor, habla con ellos porque, o ellos están equivocados o tú no lo entiendes. Acláralo, y si tiene valor, haz lo que esté en tu mano para maximizar ese valor.

Me acuerdo de casos en el modelo antiguo de “jefe de proyecto” más un grupo de programadores en el que estas tareas se las comía el jefe de proyecto. Ya los conté en el artículo sobre que el jefe de proyecto es un chico para todo, lo que es sinónimo de que se come toda la “mierda” que nadie quiere hacer en el equipo. Y creo que es porque en ese escenario es el único con sentimiento de responsabilidad sobre lo que se hace en el proyecto. Y no es raro que eso pase, porque en esos casos hablábamos de un jefe de proyecto, sobre el que la organización descansaba la responsabilidad. Si se llega tarde la colleja se la lleva el jefe de proyecto, no el equipo.

En el mundo en el que estamos ahora, en el que son los equipos los que cogen la responsabilidad, tendrían que aplicarse ese cuento. Tendrían que hacer lo que creen que es mejor para su organización. Esa actitud es la que, en mi opinión, diferencia a alguien comprometido con la organización, o alguien que sólo está comprometido con su puesto de trabajo.

Como final, os cuento un caso de hace más de 10 años que viví en primera persona. A la empresa le habían otorgado un premio importante y el jefe nos pidió acudir a la entrega. El motivo es que vendría prensa y vea una buena oportunidad de publicidad y quería dar imagen de que era una empresa con tamaño y no un chiringuito. Algunos fuimos, otros no. Todavía recuerdo, estando en esa entrega, de un comentario de un compañero:

En momentos como este puedes ver quién viene a trabajar para ganarse el sueldo y quien viene porque está comprometido con la empresa.

Sobre el autor

Jose M. Huerta

Jose es Gestor de Proyectos y Gestor de Servicios en Mallorca. Es Ingeniero de Telecomunicaciones y obtuvo el Master of Advanced Studies durante su etapa como investigador. Pero no tardó en abandonar ese mundo y meterse de cabeza en el mundo de las Tecnologías de la Información. Está certificado como ITIL Expert. Tiene amplia experiencia en gestión de servicios, clásica e integrada con desarrollo, gestión de proyectos, usando metodologías clásicas y ágiles, gestión de programas y portfolios, gestión de grandes grupos de personas, localizadas y off-shore, sin dejar de perder de vista el lado técnico y freak del sector. Ha trabajado en varias empresas del sector con distintos roles en áreas tanto de gestión de servicios de soporte como de equipos de desarrollo. Actualmente trabaja en WebBeds, como responsable del equipo de operaciones TI.

3 comments

  1. Pere 3 septiembre, 2018 at 15:53 Responder

    Me imagino que el problema principal es ¿Cómo hemos llegado a esto?
    “A este equipo le piden documentación sobre el proceso. Negocio la necesita y aportará mucho valor. Y los desarrolladores son los únicos que pueden realmente hacerlo.”

    • Jose M. Huerta 5 septiembre, 2018 at 09:58 Responder

      ¿Cómo hemos llegado a tantas cosas? Tenemos monolitos gigantescos campando a sus anchas por montones de empresas y en las que nadie conoce el monolito al completo. Incluso si hubiesemos montado todo con microservicios y lo tuviésemos más controlados, hay algunos sistemas tan complejos que a veces la única documentación que te queda es el propio código.
      Sé que no es lo deseable, y que todos tendríamos que poner de nuestra parte desde el principio para evitarlo. Pero hoy en día tener sistemas complejos que nadie sabe al 100% qué están haciendo, es habitual. Y la única fuente de verdad en estos casos es el código. Y los únicos que pueden leerlo, los programadores.

  2. Julio 13 septiembre, 2018 at 13:00 Responder

    No creo que sea un problema técnico (monolitos o microservicios), sino de cultura y comunicación.
    Cómo se ha llegado a esa cultura con esa falta de compromiso es lo que habría que investigar e intentar revertir la situación para que no vaya a peor.

    Por lo general, la gente empieza motivada y comprometida pero si no sabes cuidar a la gente, tienden a desmotivarse. Es normal.
    La mejor forma de desmotivar a alguien es marearle, no ser transparente, no comunicar bien, pej. no diciendo por qué necesitas que deje lo que está haciendo por una nueva tarea “mega urgente”. Si encima esta nueva tarea luego resulta que no valía para nada, pues más desmotivación. Otro ejemplo es cuando en una empresa todo es urgente.

    Pero vamos, si tuviera un equipo con ese problema de cultura que comentas, empezaría a pensar en si es necesario meter la pala.

Post a new comment