La historia del bono anual que desapareció


(Germán G.) #1

Este relato lo cuento a pedido de @agustinvillena, de la conversación en el hilo Bonos de Performance y Trabajo Creativo: Una relación incómoda.

Escenario: año 2010++, estamos desarrollando un producto de software, que se lo vendemos a bancos. Es un producto de Banca Internet, que permite a los bancos integrar flujos preparados para realizar cosas como: transferencias, consulta de saldo, mensajería y otros módulos.

Existe un bono anual, que desde siempre ha estado definido. Es parte del contrato y está sujeto a:

  • Cumplimiento de los objetivos del equipo / área
  • Cumplimiento de objetivos personales

Nos encontramos desarrollando 2 enormes proyectos de desarrollo e integración del Producto en dos importantes clientes. Cada uno tiene su propio conjunto de customizaciones excluyentes del otro. Es decir, no comparten requerimientos y a veces son antagonistas. Tiempo asignado de desarrollo: 2 años en total.

Yendo al tema del bono, después de varios meses (quizás un par de años inclusive) he tenido varias conversaciones con mi jefe de proyecto, conversaciones en donde le comento que entregar un bono anual de performance en realidad no motiva a nadie: todos esperan el bono como algo otorgado, casi como un monto extra permanente. La gente, si recibe su bono íntegro (90% o más) se siente pagada justamente por su esfuerzo. Si reciben menos, se sientes decepcionados.

Año 2013, mi jefe decide compartir la idea de eliminar el bono con el directorio (que se encarga de asignar presupuesto para la empresa.) Sorprendentemente, el directorio acepta la idea y se implementa a las pocas semanas de acordar el asunto.

  • Todos firmamos el anexo de contrato en donde se volcaba el bono en el sueldo mensual
  • Aquellos pocos que no firmaron fueron despedidos, y efectivamente eso era lo que ellos querían

¿Qué pasó después? ¿Recuerdan esos 2 grandes proyectos de desarrollo que estábamos realizando? Estaban sobrepasados en presupuesto y tiempo. Gastando más de lo estimado y con más de un año de atraso.

Finalmente esta empresa, que tenía más de 25 años de existencia en el mercado nacional, le fue tan mal en la ejecución de estos proyectos que tuvo que reducirse a la más mínima expresión: de haber llegado a contar con 180 developers y testers (más managers) ahora se redujo a una veintena de valientes que se quedaron a dar mantenimiento del producto.

Entonces claro, el bono anual desapareció. Y hubo mucha gente que no alcanzó a disfrutar del cambio. Fuimos sometidos a una reducción de personal drástica.

Surgieron 2 bonos extras:

  • Por llegar todos juntos al final del proyecto. Es decir, entregar hasta donde llegáramos en una fecha indicada.
  • Por entregar el producto con una cierta calidad. Es decir, una cantidad definida de bugs reportados.

Algunas personas no disfrutaron de los bonos finales, ya que: o los despidieron, o decidieron renunciar y trabajar en otro lado.

Reflexiones finales:

  • Aunque en un momento del tiempo se eliminó el bono anual, después de eso surgieron un par de bonos que apuntaron a terminar los proyectos antes de prácticamente “cerrar la empresa” (reducirla a la mínima expresión)
  • Es decir, tuvimos bonos como parte del trabajo casi permanentemente
  • ¿Sirvieron los bonos para mejorar la performance? ¿Para mejorar los tiempos de desarrollo? ¿Para mejorar las entregas con calidad? Dado el resultado final, la respuesta es: no, no y no.
  • Sirvieron los bonos para algo. Claro! Para quedarse en la empresa hasta el último día, entregando el proyecto al momento de “hundirse el barco” El bono anual sirvió para… nada con respecto a mejorar el producto.

Bonos de Performance y Trabajo Creativo: Una relación incómoda
(Guillermo Schwarz) #2

Bueno, no es por nada, pero si hay o no un bono parece secundario con respecto a lo que cuentas de que la empresa casi se murió.

Sospecho que eso genera presión en la jefatura, y ellos a su vez traspasan su estress a la gente que hace que las cosas funcionen, entonces es cuando los desarrolladores reciben esas instrucciones tan ultiles como saltate las pruebas, y saltate los procedimientos y el proyecto termina siendo un caos.
Un proyecto bien llevado a cabo es más como un monasterio o una fiesta de amigos que comparten sin preocupaciones, porque no hay nada que hacer, todo esta hecho, o si aparece algo que falta se hace en 5 minutos juntando cosas que ya existen.
Se reemplaza la programación por la configuración.
Obviamente llega el gerente de finanzas, ve que nadie trabaja hasta tarde o fines de semana y reduce personal. Incluso esos gerentes te lo dicen a la cara, sin pestañear, como si fuera una idea brillante. Gente que ha trabajado en sun, que no es… Bueno, no era… Una empresa chica.
Por algo sun ya no existe… Pidieron 10 mil millones de dólares. Al año se compraron mysql en mil millones. Pocos meses más tarde oracle compró sun (incluido MySQL) en 5 mil millones.

Creo que la lección de sun es: no sea estupido, no se endeude si no tiene proyectos que generen dinero. Mira como lo hizo steve jobs con apple: creó productos completamente diferentes que la gente adoraba y estaba dispuesta a pagar muchísimo dinero por algo que antes (por ejemplo los teléfonos celulares) casi te los regalaban.

?se entiende?

Si desarrollas un producto magnífico, los clientes están dispuestos a pagar por el.

A steve jobs le preguntaron si quería hacer un estudio de mercado para saber si iban a comprar su nuevo producto. Steve jobs respondió que no porque la gente no sabe lo que quiere hasta que se los muestro. Es lo mismo que dice tom peters. Pero la idea no es tan superficial como parece. En realidad lo que ocurre es lo siguiente: para hacer un producto excepcional tienes que ser fanático de los detalles, tienes que estar absolutamente loco para gastar tanto tiempo en un simple detalle.
No se trata de gold plating. Gold plating es cuando te esmeras en algo que a nadie le importa. En este caso es lo mismo, pero te esmeras porque algo te molesta, es lo que ocurre con los expertos en UX. Tienes que ser fanático de los detalles que importan, si usualmente son 5 minutos de trabajo, pero te demoras 5 dias, no importa, con tal de que el resultado sea tan bueno que el usuario se obsesione con tu interfaz y con tu producto.


(Guillermo Schwarz) #3

Ahora bien volviendo a tu problema original, todas las empresas han pasado por el síndrome del proyecto grande que nunca termina y que termina arruinando a la empresa.

Las empresas tenían protegiéndose colgando un cuadro en el lobby que dice “acá no hacemos proyectos de más de 3 semanas”… O puede decir 3 meses, o 6, da lo mismo, ya saben que los proyectos ambiciosos fracasan.

Todas las metodologías ágiles dicen lo mismo.

Ahora bien, supongamos que tu intentas aplicar kanban en uno de esos proyectos que arruinan la compañía. El problema de kanban es que kanban asume que tu empresa produce algo y una empresa con un proyecto que nunca sale a la luz en realidad no produce nada. Tratas de arreglar algo con kanban y no sabes si lo estas haciendo mejor o peor,las discusiones serían eternas.

Congelar los requerimientos es una técnica, pero todo se mueve mas lento y hace que la empresa produzca algo que nadie quiere, para luego planificar cambiarlo, lo que significa que la empresa se desfinancia rápidamente.

?porque crees que te piden una carta gantt? Porque de esa manera la empresa calcula el costo del proyecto y parte al banco a pedir el crédito.

Imagina si el proyecto se atrasa o no se vende… No hay como pagar ese crédito. Las empresas se suicidan al hacer proyectos de software con cartas gantt, porque las cartas gantt siempre mienten, y siempre los proyectos se atrasan cuando hay una carta gantt porque una carta gantt es sólo un dibujito, no es un plan.

Un plan tiene siempre un objetivo claro, algo que queremos conseguir que es importante (cosa que la carta gantt no tiene) y un plan tiene además pasos simples, realizables, con los que todo el mundo esta de acuerdo. Esa segunda parte tampoco la tiene las cartas gantt. Para más remate la carta gantt no tiene realmente todos los pendientes, para eso hay reuniones, que son una tremenda pérdida de tiempo solo para decir que esta hecho y que no. Y la carta gantt esta siempre desacralizada. No puedo mirar la carta gantt y ver que me falta por hacer, ni donde esta lo que hice para revisarlo. La carta gantt es una tremenda pérdida de tiempo.

La solución es el agilismo, scrum y xp en particular, porque hay entregas al cliente. Tratando siempre de entregar MVP. Es decir: toma acá tienes valor. ?y ese valor como se mide? Porque aumentan tus ventas, sin mayores ventas, no hay mayor valor.
Y si no hay mayor valor, o probamos otras funcionalidades, o mejor nos dedicamos a otro proyecto que parezca más interesante.

Es decir, las empresas no deberian (mal)gastar más de 1 o 2 semanas creando productos que no generan más valor para la compañía.

Volviendo al ejemplo de la empresa donde estabas, era mejor un equipo pequeño (si la empresa casi quiebra en un año claramente esta mal administrada), y entregas cada una o dos semanas.

La verdadera protegida por Scrum y XP es la empresa. Los empleados no ven ningún beneficio real (monetario) salvo la felicidad de que están usando su producto. Y eso bordea en la autosatisfaccion.


(Guillermo Schwarz) #4

Lo que dijiste de que las personas cuentan con el bono para sus gastos es cierto, no tener el bono es casi un castigo, y las personas creativas castigadas no son creativas, se manejan más bien por la ley del mínimo esfuerzo.

Le pasa también a los jefes de proyecto: a los más motivados se les asigna más pega, porque terminan más rápido, no los vas a dejar si nada que hacer. Pero como no se desmotivan con nada, primero haz el hoyo, luego tapa el hoyo y así sólo trabajos inútiles, todos hemos pasado por eso, y ya les conte que la solución es colocar un toggle o perilla donde se cambia lo que dice el estupido sin esfuerzo y ojalá te vea cuando después de los 5 minutos de cháchara tu cambias todo en un segundo y sigues haciendo cosas importantes y no te dedidcas a sus estupideces.

Eso es agilidad.

Y obviamente el tipo tiene en ese momento un ahí en cierra parte. Costo de crear el toggle: 5 minutos. Costo operarlo: 1 segundo. La cara del tipo mientras te ve haciendo el cambio: priceless.

Para todo lo demás, existe Scrum y XP


(Guillermo Schwarz) #5

Damn autocorrect.

Bueno, no me deja guardar un texto tan chico así que debo rellenar.

Es cierto que los bonos terminan siendo un gran desmotivador. Pensar que voya trabajar más por algo que no es más de 10 lucas diarias, y de hecho muchas veces es mucho menos, es como entre un insulto a tu inteligencia y tu honorabilidad, si es que algo de honor uno puede mantener en una industria dirigida por retrasados mentales. Los tipos de XP decían que la fenrecia eran “bean counters” y “the inmates are running the asylum”. Con el tiempo me he ido dado cuenta que tienen razón, más allá de lo que me habría podido imaginar.

Una empresa que da bonos a los programadores se esta cagando su propia tumba.

Una empresa que si lo have bien microsoft. Los stocks options te hacen dueño de una parte de la compañía. Una empresa que hace software es software, si lo haces bien, las acciones se disparan y eres millonario, si lo haces mal, no pierdes nada.

?que te conviene hacer?

Nonhay que ser ingeniero para darse cuenta. Te conviene hacer cosas increíbles, toda la carne a la parrilla. Ahora imagina que filtras a la gente y tienes sólo gente muy inteligente en casa proyecto. Y más encima todos fácilmente se dan cuenta que la empresa es de ellos, si lo hacen bien, todos son millonarios. ?con que actitud llegan a trabajar?

Es difícil de explicar a alguien que toda su vida ha trabajado en chile, pero acá la gente sólo intenta trabajar poco, esconder información, y figurar mucho. De hecho falta que hagan seminarios acerca de como figurar.

Lo llaman manejo político para que suene mejor y tenga mejor sabor en el paladar, pero en el fondo es figurar. En la práctica eso puede destruir una empresa, si todos figuran y nadie trabaja, o si todos figuran y realizan sólo trabajo inutil.

El problema es que cuando todo el país lo hace, cuando su rol es estar presente y no hacer nada util, la gente se da cuenta rápidamente y empieza a imitar.

Cuando todos los políticos son ladrones, cuando la cosa casi parece chiste, pero el problema es que nadie se salva, cuando a los políticos les gustaría meterte preso si nos vas a votar por alguno de los corruptos… ?no es eso el colmo?

Decir “manejo político” debería ser un insulto.

Toda la economía al final es un problema de pq. Los ingresos de una empresa son pq. Los precios en la economía son una curva IS-LM con ejes P y Q.

Cuando la cantidad producida Q es menor que la cantidad P demandada los precios suben porque “para fulanito no alcanza”. Eso no lo puedes resolver imprimiendo más dinero o bajando la tasa de interés, necesitas que se produzca más y eso se resuelve con bandas de precios. Se hace en USA y la agricultura en ese país anda bien, porque un agricultor no puede tomar el precio de hoy para saber a que precio va a vender en 6 meses mas., las bandas de precios le ayudan a saber si debe invertir o no.

Obviamente en chile no se nos ocurre copiar un modelo que funciona. Somos copiones, pero no copiamos las cosas que funcionan. Éxito!!!/

En el caso del software el costo de producción es cero. Lo que cuesta es el diseño porque el código es diseño. La construcción es lo que se hace al momento de compilar. La cantidad de producto es infinita porque el costo marginal de producir una unidad adicional es cero. En marcados en los que el costo marginal es cero, el ganador se lo lleva todo.

Solo estoy aplicando conocimeintos de economía 1.

El único problema del software por lo tanto es que los requerimientos o los diseños son contradictorios. Si no lo son, podrían llegar a serlo.

Ok esto podría parecer una sobre-simplificacion, y en buena medida lo es.

Imagina que estas diseñando un avion, tienes un equipo de gente y todos proponem ideas: baño con jacuzzi, camas matrimoniales, pista de baile, piscina, etc. Todos van a dar ideas. Pero luego ?co hacemos que vuele?

El enfoque agilista es partir por un avioncito de papel. Inutil como transporte, pero vuela.

Esa propiedad “pero vuela” es la propiedad que hay que mantener durante todo el proyecto. Y es lo mismo que dice la teoría general de sistemas: todo sistema grande que funciona partió de un sistema chico que funciona.

Llevemoslo a la parte económica: tienes que vender tu sistema. Si logras venderlo, entonces tu sistema “vuela”. Al menos en la mente de la gente estas haciendo un sistema que les resuelve algo.

En vez de salir a romperla en el mercado, en términos técnicos, en vez de penetrar el mercado, debes descremar el mercado, es decir partes por solucionarle bien el problema a unos pocos, y de a poco vas creciendo y tomando más clientes, ellos mismos te van dixiendo que hacer, que necesitas, y como decides que hacer? La propuesta más repetida es la que más clientes necesitan, así de simple.