Objetivos.

Un equipo tiene, por definición, objetivos. Pueden ser más o menos explícitos, y su cumplimiento en tiempo y forma más o menos vital para su existencia, pero los tiene.

Las personas también tienen sus objetivos, que no son los mismos. Si bien a veces (raramente, según mi percepción) coinciden, pensar que los objetivos de los integrantes del equipo son los objetivos del equipo mismo es, por lo menos, un poco naïf.

Para entender (o predecir) las posiciones y reacciones de una persona en un equipo chico o mediano (digamos, menos de 10 integrantes) podríamos pensar en cómo esa persona compatibiliza sus propios objetivos con los del equipo, ya sea modificando, posponiendo, priorizando o descartando unos u otros, en tanto le sea posible.

Las variables crecen. Deberíamos tener en cuenta la información de la que dispone esa persona y, por supuesto, el error. Es claro que a todos, en algún momento, nos sale el tiro por la culata.

Todo esto fue disparado por una frase sacada del contexto de una conversación ajena que me quedó dando vueltas. Iba más o menos así: "Si uno tiene un producto [de software] más o menos decente y un flujo de bugs más o menos constante, vendiendo barato y cobrando un abono por el mantenimiento, puede mantener una cartera de clientes y un rédito razonable por...".

Lo que me quedó (vaya uno a saber si el emisor de la frase -que no recuerdo quién era- estaba pensando en esto) fue "un flujo de bugs más o menos constante". Claro, en este esquema los errores son funcionales al proveedor del software, ya que con un producto estable el cliente puede verse tentado a abandonar el abono de mantenimiento y estancarse en determinada versión. Pero los errores no pueden ser terribles (el producto debe ser "decente") ya que más allá de cierto límite el cliente podría pensar que existen opciones mejores.

No sé qué tan común pueda ser la situación. El negocio del cliente debería ser muy estable, de modo que no requiera nuevas funcionalidades cíclicamente.

¿Cómo afectaría esto al equipo del proveedor del software?

A la empresa proveedora tal vez le interesaría tener un producto cerrado. Al fin y al cabo, tener un equipo de desarrollo para hacer mantenimiento es costoso, y es posible generar ingresos mensuales de otras maneras. O, mejor aún, concentrarse en expandir su base de clientes.

Pero a los integrantes del equipo tal vez no les interese tanto (y es por esto que comencé mencionando el tema de los objetivos). Al fin y al cabo si no se vislumbran ánimos de lanzar nuevos proyectos, su trabajo desaparece.

¿Estoy diciendo que los integrantes del equipo introducen bugs a propósito? No, esto sería un extremo realmente inusual. Nunca escuché nada parecido.

Pero sí he visto una tendencia a mantener el "status quo". Es decir, una tendencia a no trabajar en esas cuestiones de fondo que realmente solucionarían los problemas y dedicarse simplemente a introducir parches para cada situación puntual reportada.

Pongamos de ejemplo una situación de la que se habla mucho, y que tal vez cuadre: la claridad del código, la reutilización, la legibilidad, la simpleza... "esas cuestiones" que todo el mundo dice que son importantes pero...

Si mi objetivo individual es permanecer ("permancer y tanscurrir", diría) no tengo demasiado interés en hacer el código claro y sencillo para otras personas... No es que lo esté complicando a propósito, sino que producir código de calidad creciente no es un resultado inevitable de programar sino que implica un esfuerzo consciente y adicional para el cual no tengo incentivos.

Ahora, si mis objetivos individuales son otros: aprender, innovar, progresar en lo profesional, crear un producto de calidad superlativa o simplemente que sea mejor cada día, etc... La cosa cambia.

Releyendo, es notoria mi simpatía por los "innovadores" frente a los "permanecientes" (estas frases sólo pueden surgir en época de fiestas). Cierto. Pero que no se interprete que desmerezco a los segundos frente a los primeros.

¿Por qué una persona no querría innovar, aprender, progresar? No es necesariamente que no quiera, sino que dentro del equipo prioriza otros factores. O peor, que no encuentra la forma de hacerlo, o que el ambiente no es propicio, por lo que prefiere hacerlo en otro lado. Conozco excelentes profesionales que exprimen su creatividad en su actividad privada y en el trabajo simplemente "cumplen" para obtener un suplemento extra, del que esperan poder deshacerse en el futuro... ¿qué puede haber de reprochable en eso?

Nada, en mi opinión. Pero es común que "cumplir", "dedicarse a corregir lo reportado" esté mal visto. Vemos que en los anuncios de recursos humanos se requieren siempre personas "innovadoras, proactivas y... (un montón de palabras bonitas)" cuando no es lo que realmente se necesita... o lo que se quiere.

Así, tenemos situaciones conflictivas entre organizaciones o jefes y profesionales frustrados al ver que se descartan todas sus iniciativas o renuentes al cambio y la innovación, para el que no encuentran incentivos.