Evaluaciones, incentivos y castigos

Continuando la discusión desde Los ingenieros de Yahoo ahora pasan su código a Producción directamente, y son responsables de su impacto vía @IEEE Spectrum:

Debido a que nos estamos desviando un poco de temas de desarrollo ágil hacia gestión ágil, quisiera continuar por acá con esta excelente discusión:

Efectivamente, los bonos, y en general , la gestión de el incentivo y castigo es tan contraproducente que hoy no debiera seguir siendo utilizada para ningún aspecto de trabajo creativo. El caso ya ha sido presentado demasiadas veces, para muestra, un botón:

Las evaluaciones sobre las que estaba hablando no necesariamente tienes que estar motivadas a proveer incentivos o castigos. Lo que tenía en mente era utilizarlas para gatillar las motivaciones intrínsecas de cada uno como profesional y ser creativo. ¿Cómo? no se, no es mi área de especialidad. ¿Alguna idea?

Sí, está bien interesante el thread…

Bueno en realidad la respuesta es trivial… y ya está embebida en la
pregunta…

La motivación intrinseca es… intrínseca… o sea o te gusta o te
gusta… o sí o sí…

Suena extraño, pero o te gusta programar y sacar el producto
adelante… o no te gusta y hay que darte premios excepcionales… lo
que implica necesariamente que a quienes les gusta se van a quedar…
el resto se va a ir…

Típicamente un tipo empieza una empresa porque quiere dinero, al menos
en Chile es así, la ambición hace al monje en este caso… y él piensa
que todo el mundo es igual… todos son naturalmente ambiciosos y lo
disimulan… o son tontos porque todavía no se dan cuenta de lo
ambiciosos que son… Quizás tienen razón, pero hay negocios que son
negocios solamente porque pagan malos sueldos… no sé si eso es
ambición o simplemente ser tacaño… en todo caso la idea viene de
Adam Smith así que se podría decir que es la base del capitalismo…

[[ Schumpeter, un economista que explica la razón del permanente
desempleo en el capitalismo, habla de la desrtrucción creativa, de que
las nuevas empresas reemplazan a las viejas porque son más
eficientes… alguien que cree en Adam Smith piensa en menores
sueldos… pero los sueldos de los fabricantes de autos no son menores
que los sueldos de los fabricantes de carretas… Algo está mal con
las ideas de Smith…]]

Ahora bien, en la práctica cómo se hace esto? Porque si les decimos a
los programadores que ahora pagamos sueldo minimo y sin horas extras
lo más probable es que podremos esperar un siglo antes de que alguien
postule… probablemente por error… y si acepta el trabajo, cuando
se dé cuenta del error, probablemente ni renuncie y simplemente no
vuelva…

En la práctica lo que dice Tom de Marco en “Slack” es que no sacamos
nada con presionar a los programadores, van a fracasar 100%, porque al
no “tener espacio de maniobra” simplemente fracasan. Aprieta los
tiempos y todo el código será basura. Si luego les reclamas te dirán
"es que estábamos apurados", “tú mismo no nos diste más tiempo”, las
respuestas típicas…

¿Qué debe hacer un jefe de proyecto (o team leader o scrum master o el
nombre que tenga ahora)? Preocuparse de la calidad del proyecto, no de
los tiempos.

Suena contraproducente, pero es lo mismo que dice Scrum y XP: Parte
lento, controlado, como si estuvieras aprendiendo, naturalmente una
vez que la gente aprenda, los tiempos se van a reducir… El tiempo no
es el priincipal problema, el verdadero problema es la calidad…

Además Tom de Marco dice que a las personas se les debe pagar de
manera que su sueldo “no sea tema”… esto obviamente puede bajar la
rentabilidad del proyecto… Pero según Tom de Marco lo importante es
deshacerse de los proyectos que si se atrasan dejan de ser rentables,
porque eso introduce una preocupación en los proyectos que los hace
fracasar. Los proyectos deben ser interesantes, en el sentido de que
si el proyecto resulta, somos todos millonarios… ahora si los
programadores se dan cuenta de tú vas a ser millonario pero ellos van
a seguir siendo pobres, lo más probable es que te abandonen de todas
maneras, por sentirse estafados…

En otras palabras todo el equipo debe empujar hacia el mismo lado
(Scrum), porque está en directo beneficio de todos y cada uno.

Tu preocupación es probablemente “qué hacemos con el tipo que no produce?”

Lo que dice XP es que si el tipo no levanta su propio peso, hay que
despedirlo… Esto obviamente parece evidente en toda organización,
pero como decides si el tipo levanta su propio peso si no lo mides?
Queda a criterio de alguien? Eso se presta para amiguismos… Y todos
sabemos que los amiguismos tienen otro nombre: corrupción, pero de
todas maneras las personas se sienten más cómodas trabajando entre
amigos de confianza… Porque en algunos casos es equivalente a
confiarte las llaves del auto, las llaves de la casa y la chequera…
Eso sobrepasa la importancia de las habilidades técnicas.

Nótese que decimos que despedimos a alguien con la justificación de
que no rinde, pero eso es sólo una excusa, porque en realidad no
confiamos en él.

De otra manera las medicones de productividad serían individuales, y
eso abriría la puerta a una buena demanda por despido injustificado.

En mi caso yo prefiero saber si la persona que voy a contratar
aprendió listas enlazadas y árboles binarios. Recursividad en ambos
casos. ¿Aprendió o fue a la universidad a pasear y copiar como malo de
la cabeza?

Si aprendió, lo más probable es que aprenda en el trabajo también,
porque es imposible preguntarlo todo. Git? Hg? Ant? Maven? Gradle?
Jenkins? JUnit? Probar interfaces? La sintaxis de Java? Herencia?
Encapsulacion? Polimorfismo? Multimethods? Mixins? Traits? Patrones
GoF? Patrones J2EE? Algoritmos? Base de datos? Hibernate? Spring?
Vert.x? Non blocking synchronization? CAS? ABA problem? Map-reduce?
Mongo? Cassandra?

Podría estar dando pruebas durante un mes, y de seguro no alcanzaría a
preguntarlo todo, especialmente cuando hay un proyecto andando y hay
tecnologías que se están desarrollando dentro del proyecto.

Lo importante es:

  1. Es inteligente?
  2. Termina lo que empieza?

La pregunta que tú estás tratando de hacer en realidad es “es
responsable?”… otra manera de preguntar lo mismo “tu mamá te
despertaba y te iba a dejar a la universidad?”… “ella estudiaba
contigo?”… Es obvio que un ingeniero titulado es responsable.
Entonces, no creo que se siente a empollar huevos. Por lo menos en mi
experiencia, no es así.

Lo que sí pasa es que un ingeniero sólo se siente agobiado por el
tamaño del proyecto, es necesario ponerle a un par al lado para que se
motive… en general los ingenieros se motivan así, cuando les llega
un mail cuando alguien termina algo… lo que implica muchos
ingenieros en el mismo proyecto… de modo que la información que leen
es relevante… y ya no es necesario el daily scrum… ven personas
haciendo cosas…

Cuando dirigí un equipo de 15 personas, no le preguntaba nada a nadie,
sólo hacía code reviews de lo que me informaban que estaba listo.
Quienes hacen más son promovidos a “team leader”, lo que significa más
responsabilidad… y más trabajo porque deben asignar tareas y hacer
code review… si algo resulta mal, ellos tienen que arreglarlo… lo
que implica que el code review se hace en serio… y si no resulta…
adivina quien hace code review?.. yo, lo que la gente trata de evitar
cuando el código no está 100% sacro santo, porque eso significa que
pido que se haga de “la manera correcta”… usualmente la idea se
forma en mi cabeza en la medida que estoy leyendo el código… este,
este y este otro patrón… a aprender los patrones se ha dicho… y si
es muy complejo… hagamos un prototipo que demuestre que la idea es
correcta… Esos son varios días de trabajo para algo que se suponía
que estaba terminado…

Y bueno, el proyecto terminó antes de tiempo a una tasa de desarrollo
de 13 casos de uso diarios… sólo porque el proyecto se acabó ya que
la tasa seguía subiendo… yo suponía que se estancaría alreadedor de
los 10 caoss de uso diarios y no fue así…

A esa velocidad, mi idea era hacer montones de proyectos rápidamente
con el mismo equipo… pero el manual de cortapalos de esta empresa
era “todos están agotados, te odian, desbanda el equipo” y empezaron a
deshacerse de la gente después de lo dificil que fue hacer andar el
equipo.

Respecto de la productividad individual, es necesario medirla, porque
si miro a un ingeniero todo el día, parece que no hace nada… eso es
cierto… el jefe de proyecto se desespera y va a interrumpirlo… y
una vez que se pierde la concentración… chao, hasta el otro día, el
cerebro se desconectó… de modo que si veo a alguien trabajando
mucho… lo más probable es que realmente no esté haciendo nada…

Cada idea en la cabeza de un ingeniero tiene que traducirse en golpes
de teclas (keystrokes)… como te puedes imaginar el tipo se ve
inmovil mientras el cerebro traduce, en varios niveles, el request
original… Si veo al tipo trabajando mucho, probablemente alguien se
equivocó en alguna de las traducciones y simplemente está
corrigiendo… o sea corrigiendo el desperdicio o dicho de otra manera
"haciendo nada"…

Y mi experiencia personal dice lo mismo… cuando estuve trabajando en
Francia me pedían completar una hoja con lo que hice en el día… y
los días que sentía que no hacía nada, la hoja estaba llena, porque
hacía cosas sin importancia, sin dificultad (low hanging fruit)… los
días que realmente trabajaba escribía una sola línea… (sigo con el
issue 736287).

Si te pasan un feature para que lo hagas sólo, obviamente estarás un
mes haciéndolo.

En resumen:

  1. La motivación intrínseca no se puede gatillar, viene con el
    individuo, sólo la puedes medir en la entrevista o en la prueba para
    lo que se refiere a su educación (que es imposible de replicar en el
    ambiente de trabajo porque no tenemos 6 años para hacerlo).

  2. No pagar sueldos “juleros” porque obviamente la gente necesita la
    mente despejada. Si no tiene el tema “resuelto”, va a estar pensando
    en otra cosa, necesariamente, independientemente de la mentira que te
    diga.

  3. El proyecto debe ser financieramente interesante, sino el gerente
    de ventas o el CEO no está haciendo bien su pega. Eso debe significar
    que la ganancia viene dada por la venta del producto y no por los
    bajos sueldos… lo que es parafrasear el punto 2.

  4. Una de las motivaciones extrínsicas que gatillan la motivación
    intrínseca, aunque suene paradódijo, es ver que el resto también hace
    algo. Eso afecta tu propia imagen, si el resto resuelve 4 bugs diarios
    y escribe features en 3 días, obviamente el ingeniero se va a
    concentrar para tratar eventualmente de hacer lo mismo… de otra
    manera va a buscar “greener pastures”.

  5. Evitar las interrupciones a toda costa.

  6. Ah bueno, y pair programming debe ser una de las técnicas que
    aseguran que las personas se concentren. Nadie se va a poner a chatear
    o a navegar la web si está pair programming. Tomar en cuenta que el
    peak de concentración es sólo de 2 o 3 horas al día y a mí por lo
    menos me pasa cuando llego a trabajar… si me ponen a hacer pair
    programming con alguien que durmió la mona… o que todavía está
    durmiendo con los ojos abiertos porque no es un “morning person”…
    puede ser que baje mi productividad… en mi opinión por eso la
    productividad se mide issue a issue (o user story a user story)…

Otra cosa que se me olvidaba: nunca he tenido que despedir a alguien
por baja productividad… simplemente no pasa, los que tienen baja
productividad son rápidamente ayudados por los que tienen alta
productividad… Creo que esto tiene que ver con el hecho de que
organizo a la gente en equipos por capa en vez de lo que hace Scrum de
poner a cada desarrollador a hacer un “user story” aparte… Esto
porque quiero que todas las pantallas se vean igual, que toda la
persistencia se haga igual, etc. Esto viene de una mentalidad
industrial en vez de una mentalidad anti-industrial como es Scrum…
Pensemos que si llego a programar a un equipo de 100 programadores,
tengo que aprender cómo se hace la presentación acá, como se hace la
persistencia, como se escriben las reglas de negocio… y si hay
tecnologías involucradas… ¿cómo se usan acá?.. O sea puedo estar
perfectamente aprendiendo 1 o 2 meses antes de escribir mi primer
"user story", lo que es un huge waste, y generalmente termina con
jefes de proyecto despidiendo personas que no saben “como se hacen las
cosas acá”…

Ah se me olvidaba, los hago hacer por lo menos 3 prototipos (spikes)
antes de pasar a escribir código de producción. He tratado de que
escriban más prototipos pero al parecer se aburren o se les acaba la
vitamina P de Prototipo… Lo bueno de los protitpos es que aprenden
la metodología de cómo usar la herramienta de control de versiones,
cómoo se hace el code review, lo que significa “clean code”, cómo se
hacen los unit tests, lo que es evolutionary prototyping, etc.

Por el lado del proyecto mismo, los prototipos ayudan a reducir el
código repetido, porque eventualmente se convierten en bibliotecas
para ser usadas por el resto del proyecto, lo que simplifica mucho el
código. Esa es la razón por la que los proyectos se vuelven más
eficientes, no es que las personas aprendan a escribir más rápido.

Si organizo a las personas por capas, entras a la capa de persistencia
y el “team leader” te muestra como se hace (él mismo resuelve un issue
contigo mirando), luego te toca a ti con él mirando (a la pair
programming), ¿hay algo que pueda salir mal? En mi experiencia, todo
el mundo se vuelve super colaborativo, ah y de vez en cuando les hago
yo mismo el code review, ya que estoy constantemente de levantar el
nivel de abstracción del código.

Lo que sí me ha pasado es que alguien no quiere seguir los
procedimientos de desarrollo (code review, unit test, prototipos,
etc.) y el gerente lo blinda (mala señal, eso significa que esta parte
va a fracasar estrepitosamente)… el resultado es que nadie quiere
trabajar con él porque hace todo muy diferente y queda completamente
aislado… lo que a nadie le gusta, menos a él… luego obviamente él
va mucho más lento, hay cambio de requerimientos constante (“es que no
entendiste”), por lo tanto se termina peleando con el gerente
también… y luego termina renunciando y hay un montón de código que
básicamente no funciona y hay que botar a la basura y hacerlo bien
todo de nuevo…

Hola, hace algún tiempo leí el libro “Motivación 360°” de David Fischman, el cual comenta sobre los incentivos y castigos utilizados para motivar a las personas, los pro y contras que tiene. Como resumen les puedo comentar que lo principal es saber que mueve a las personas, no a todos los mueve el dinero (me incluyo en esa linea), algunos nos motivamos por desafíos, por generar cambios. En base a esto hay que generar instancias para potenciar estos deseos. Los incentivos monetarios son solo calmante a corto plazo, un ejemplo, tu puedes estar muy contento con tu sueldo, pero si a tu compañero le suben el sueldo y a ti no, tu motivación ya no es la misma. En mis equipos siempre me preocupo de saber que los motiva, ejemplo,en mi equipo hay desarrolladores jr que les gusto programar y otros a los que no, a los que les gusta potencio el aprendizaje de patrones, utilización de herramientas de test automatizado, de covertura de test, siempre destaco que este proceso es para ellos ya que si el día de mañana se van de la compañía se llevan lo aprendido. A los que no le gusta programar se potencia sus intereses, ejemplo, gestión, analisis, etc.

Para terminar sugiero que nos limitemos mas en la cantidad de lineas de nuestros comentarios, ya que mucha personas no los leen por extensos de estos.

Saludos,
Roberto Mejias.

:wink: me tomó un tiempo volver a este hilo con el tiempo y disposición para leer la respuesta de @Guillermo_Schwarz, pero de eso se trata la comunicación asíncrona, creo yo :stuck_out_tongue: Además, creo que hace algunos buenos puntos.

Efectivamente, creo que tener clara la pirámide de necesidades de las personas, es una de las cosas más importantes que alguien puede hacer para mantener un equipo sano:

Esto, junto con lo que indica @rmejias sobre entender “lo que mueve a cada uno” son, a mi parecer el 90% de lo que es un buen líder de equipo. Esto significa, por ejemplo, entender que si una persona está con algún problema familiar importante, no va a estar enganchado en la creatividad ni estará en condiciones de ser un aporte al equipo. O que si alguien está haciendo algo que en el momento no le interesa (desarrollo web v/s desarrollo de librerías o frameworks) tampoco estará en su completa facultad.

Las personas somos complicadas, pero al mismo tiempo, las bases de esa complejidad son simples. El problema es que las empresas (la mayoría, al menos) no están diseñadas para considerar estas bases humanas y se enfocan en la parte económica/financiera ante todo, como comenta guillermo en este párrafo:

Afortunadamente, creo que las empresas que están surgiendo y teniendo éxito esta década, están considerando el hecho de que son fundamentalmente una comunidad mas que un ejército, y espero que esta mentalidad con el tiempo se refleje en las leyes, aunque sé que no será pronto.

Sobre los incentivos en sí y cómo gatillar la motivación intrínseca, era una pregunta algo retótica y otra parte desafiante para motivar la conversación, ya que obviamente no se puede gatillar, pero si se puede hacer lo contrario y matarla. Lo que una empresa o líder de equipo debiera hacer, es estar en constante vigilancia de que haya un ambiente adecuado que permita que esta motivación se exprese de la mejor forma posible y que aquellos que aun no la han desarrollado completamente se sientan con la total libertad de hacerlo, junto con encausar las personas según su motivación a generar valor para los clientes o para el producto.