Procesos útiles

El tema de hoy tiene que ver con procesos de desarrollo de software.
En Agile Software Development, Alistair Cockburn comenta que uno de los criterios que él utiliza para considerar exitosa la aplicación de una metodología en un proyecto es que las personas del proyecto piensen que trabajarían de la misma manera otra vez. Por otro lado, Scott Berkun en The Art of Project Management lista los atributos de buenos procesos, aquellos que benefician la ejecución de un proyecto e incluye el siguiente:

“Las personas impactadas por los procesos están a favor de ellos. A las personas les gustan los procesos útiles. Un buen proceso sera visto como algo deseable por aquellos que lo necesitan. Si se está proponiendo un nuevo proceso que impacta a testers y programadores, y el proceso es valioso para el proyecto, no debería ser muy difícil convencerlos de probarlo.”

Mi experiencia en proyectos utilizando procesos definidos no cumplen esos criterios en general.
Quiero decir que las personas no trabajarían de la misma manera si pudieran elegir y en gran parte no estaban a favor de los procesos al momento de aplicarlos. Déjenme plantearlo de manera más personal: hoy estoy trabajando de una manera que en esencia no volvería a utilizar si pudiera elegir y, en muchas ocasiones, no estoy a favor de los procesos que debo aplicar.

Detallando un poco más, me refiero a procesos que no agregan valor, a la generación de documentación que nadie lee, a la producción indiscriminada de evidencia con poco sentido practico, a los pasos que pretenden brindar seguridad sobre los resultados y mas bien obstaculizan su concreción. Mi sensación es que mi experiencia no es aislada, parece ser más la regla que la excepción. Si esto es así, ¿qué es lo que está mal entonces?

Cuando se usan procesos definidos en una empresa, existen personas que se encargan de definirlo. Calidad, Proceso, Organización y Métodos son nombres usualmente asignados a este tipo de grupos. Es raro que estas personas dediquen su tiempo a crear procesos para torturar al resto de la gente. Todos apreciamos el respeto de nuestros compañeros y poseemos un sentido de logro. Por más incómodo, incoherente o inadecuado que parezca un proceso, alguien en algún momento lo creo con objetivos valorables y con buenas intenciones.

Mi impresión es que una de las razones de estos males es que la ejecución de los proyectos de creación de procesos adolecen de muchos de los problemas de los proyectos de software mal gestionados. Se define una fecha de fin para la definición del proceso, posiblemente atada a una auditoria o assesment que permita una certificación o evaluación de una norma de calidad. A las personas encargadas de llevarlo adelante les encantaría poder charlar con las personas que ejecutan proyectos para relevar necesidades, estudiar distintas herramientas o técnicas para incluir en el proceso, investigar practicas aplicadas en otros lugares, elaborar propuestas para ver como será este nuevo proceso.

Pero sucede que las personas que debían hacer todo este trabajo tienen otras asignaciones, las personas de los proyectos no tienen tiempo para discutir sobre estos temas y la fecha de entrega se acerca. Así los planes para hacer procesos útiles, valiosos y prácticos se diluyen, y se ve reemplazados por un esfuerzo para generar documentos para tapar huecos en el proceso que puedan afectar los resultados de la auditoria o assesment.

Es como esa pequeña funcionalidad implementada contra reloj que requiere que el usuario haga 3 clics adicionales en una lugar completamente inesperado, y que internamente requirió agregar el metodo CalcularInteres en la clase ConexionBaseDatos y la declaración de tres variables globales. Uno siente que un cosquilleo recorre la espina dorsal cada vez que piensa en como soluciono el problema pero es lo que se podía hacer con el tiempo disponible.

De todas maneras siempre hay tiempo para mejorar. Mientras esas mejoras llegan, uno debe lidiar con una realidad algo frustrante, muchas veces llamada madurez.

Idea valiosa 2: cuantificación de incertidubre

La gestión de riesgos es un tema que parece simple y no muy revelador a primera vista. En lo personal, debo confesar que la presentación tradicional sobre gestión de riesgos no me resulta muy interesante. Resumiendo, existe riesgo cuando existe la posibilidad de perdida o daño. Gestionar los riesgos en un proyecto significa hacer una lista de esas posibilidades, darles un valor de ocurrencia, un valor de impacto y definir planes de acción para mitigarlos. Bueno, resumiendo bastante.

Pero existe un enfoque para analizar los riesgos que me resulta muy práctico y valioso. Muchos de los riesgos de un proyecto convergen en un hecho concreto: no se finaliza el proyecto a tiempo. Puede ser que las personas no estaban capacitadas como se esperaba, que la funcionalidad a desarrollar fue más difícil de lo esperado, que componentes externos se entregaron tarde o cosas por el estilo. Pero todo termina en que el equipo de proyecto dijo que iba a tardar 3 meses, y en la noche del último día se da cuenta que no termino. Ese es el gran resumen de los riesgos de un proyecto de software.
Este concepto está muy bien presentado en el libro Waltzing with Bears: Managing Risk on Software Projects de Tom DeMarco y Timothy Lister. Es lo que ellos llaman la cuantificación de la incertidumbre. Y ponen un ejemplo muy claro. Supongan que llamamos a un consultor para que analice nuestro proyecto y nos dice:

“Escucha, simplemente no hay chance de terminar esto antes de principio de año – cero. La fecha más probable para entregar un producto aceptable es inicio de abril próximo. Aún esta fecha no es tan segura. Probablemente no quieras comunicar ninguna fecha antes del primero de mayo. Al menos con una fecha en mayo o más tarde tienes una probabilidad de cumplir mejor que cincuenta-cincuenta. Si quieres una fecha donde no tengas posibilidad de entregar tarde, vas a tener que irte hasta fines de diciembre próximo.”

Representando la situación gráficamente, obtenemos un diagrama como este:

Este es un diagrama de riesgo donde el area bajo la curva representa la probabilidad acumulada de finalizar en una fecha dada. Si un tercio del area total se acumula a la izquierda del 1 de abril, la probabilidad de terminar antes de esa fecha es 0.33. El area total bajo la curva es 1.

Este es un gráfico revelador porque asocia el riesgo a las fechas. Uno puede observar como aumenta el riesgo a medida que las fechas son mas agresivas. Esto parece muy natural pero no lo es tan comun encontrar gente que actúe en consecuencia. Siempre vemos que la persona que pide la fecha de estimación intenta obtener la fecha más cercana posible, como si esto no incrementara el riesgo o como si las consecuencias no lo afectaran. Pero esa no es la realidad. En nuestro caso, si la persona con poder de decisión sobre el proyecto define que la fecha a comunicar será el 1 de abril, entonces debe estar preparado para entregar tarde, porque existe el 66 % de probabilidad que así suceda. ¿Está realmente dispuesto a afrontar ese riesgo?
DeMarco y Lister utilizan el gráfico para explicar un aspecto repetido hasta el cansancio en los proyectos de software:

“Una queja común que managers comparten con nosotros es que 'la fecha más temprana mencionada automaticamente se transforma en la fecha de entrega'. Publicar el hallazgo del consultor que 'no hay posibilidad de entregar antes de principio de año' puede ponerte en una posición donde el 1 de enero es entonces fijada con concreto como la fecha de entrega. Pero en el diagrama de riesgo, el area bajo la curva a la izquierda del 1 de enero es esencialmente cero. Esto dice que la posibilidad de terminar antes de la fecha de entrega es nula. La patología de definir una fecha de entrega como la fecha más temprana mencionada garantiza esencialmente que la fecha no se cumplirá.”

Idea valiosa: el cono de incertidumbre

Mucho del material que leo usualmente tiene pequeñas ideas que me hacen pensar. Tal vez es una frase, un párrafo, un concepto, algo que hace que el tiempo invertido en leer valga la pena. Hay veces que la simpleza de esas ideas me entusiasma.
Me parece que es una iniciativa útil comenzar a incluirlas en el sitio. No son genialidades necesariamente, algunas tal vez ya son tan conocidas que suenan más bien a sentido comun o conocimiento general, pero en algún momento, para alguna persona, han sido de gran valor. Y tal vez lo sigan siendo para algún lector. No esperen la fórmula de la Coca-Cola, solo pequeñas ideas.
Basta de presentaciones, comencemos a revisar estas ideas valiosas. La primera: el cono de incertidumbre:

Temprano en mi carrera profesional comencé a tener contacto con las estimaciones y con peticiones completamente inesperadas relacionadas con estas:

- ¿Cuánto llevaría hacer un sistema de contabilidad típico? - me preguntó mi jefe una vez al pasar, casi como quien habla del clima.
- Ehh...¿qué?
- Si, un sistema de contabilidad sin nada extraño, lo básico. ¿Cuanto tardaríamos en hacerlo?
- Mmm, no sé... ¿Vamos a hacer uno? Digo, ¿quien va a trabajar en eso? - preguntaba yo desorientado, sin mencionar que no tenía (ni tengo) la menor idea de qué es un sistema de contabilidad típico.
- No, eso no importa. Considera que podrías contar con los recursos que hagan falta. La pregunta es ¿cuanto tiempo nos llevaría hacerlo?
- Aja... Eh, pero... eh ¿no sé?

Si, lo admito, no fue uno de los momentos de mayor lucidez en mi carrera. Sólo faltaba que se me cayera un hilo de baba por la comisura de los labios para completar la cara del perfecto bobalicón.
Esta petición me resultaba tan inesperada y desconcertante que era imposible para mí dar respuestas medianamente lógicas. Simplemente no entendía de que me estaba hablando. ¿Qué respuesta podía dar?

Steve McConnell presenta en Rapid Development, adaptado de Boehm, el cono de incertidumbre:

"Para cualquier conjunto dado de características, la precisión en la estimación puede mejorar sólo de la misma manera que el software mismo se torna más refinado."

Este gráfico es simple. Cuando estamos definiendo el producto inicialmente las estimaciones de esfuerzo y costos pueden ser ir desde 0.25x a 4x. Estas estimaciones sólo pueden ir mejorando a medida que se conoce más sobre el producto. Así, las diferencias van disminuyendo hasta converger en un punto al final del proyecto.
La calidad de las estimaciones esta atada en gran parte a la información que se tenga sobre el producto a estimar. Con poca información, las estimaciones pueden tener grandes desviaciones.
Considerando el gráfico, para un producto que requiere 10 staff/months para desarrollar, en la etapa inicial de definición, las estimaciones optimistas pueden decir 2,5 meses y las pesimistas 40 meses.
Esa era la respuesta para mi jefe: "El sistema de contabilidad típico le puede llevar a una persona entre 2 meses y 3 años. No lo digo yo, lo dice Barry Boehm."

Mejores prácticas

Modelos de madurez de mejora continua como CMM parten de la premisa que la calidad del proceso utilizado para construir un producto define en gran parte su calidad final. Sin aceptar esta premisa, es poco útil discutir si el modelo es bueno, malo, o inocuo. Aceptando que este principio es merecedor de atención, se puede analizar algunos efectos colaterales del uso de CMM y algunas reacciones de las personas en su implementación.

Como las características del proceso son tan importantes cuando tomamos este enfoque, es lógico que una vez adoptado el mismo, miremos con una lupa los rastros del proceso, las evidencias que el uso de procedimientos y herramientas definidas dejan en su camino. Así uno captura estos rastros, los clasifica, los guarda, los cuenta, y analiza cual es el estado actual y cómo se puede mejorar. Para la persona que analiza un proyecto de desarrollo de software desde la perspectiva del proceso, las métricas, los rastros, las evidencias son la realidad. Son estos elementos los que dibujan el perfil del proyecto, a veces saludable, a veces agonizante, a veces ordenado, a veces caótico.

Las evidencias y los rastros no surgen en la ejecución de un proyecto necesariamente como las olas vienen con el mar y las golondrinas con la primavera. Muchas veces el rastro que algo sucedió en proyecto sólo queda porque es un agregado ajeno al fin específico de una tarea. Muchas veces este rastro o evidencia se debe generar como una extensión de la actividad, variando su camino natural con el fin de otorgar información relevante para otra audiencia.

Así dadas las cosas puede suceder que un proyecto ejecute un proceso efectivamente pero que no deje rastros. Tomemos un ejemplo porque la dicusión se torna muy abstracta. Supongamos que estamos utilizando Scrum como metodología. Una práctica de Scrum es la Daily Scrum meeting:

Cada equipo se junta diariamente para una reunión de estado de 15 minutos llamada Daily Scrum. Durante la reunión, el equipo explica que ha terminado desde la última reunión, que va a terminar antes de la próxima reunión, y que obstáculos tiene en su camino.

Agile Software Development with Scrum por Ken Schwaber y Mike Beedle

En este contexto, el siguiente dialogo entre una persona de Proceso y una del proyecto es posible:

- ¿Dónde están las evidencias que se están reuniendo todos los días? ¿Existe alguna minuta de estas reuniones?
- No, en realidad no tomamos minutas de estas meetings.
- Entonces, ¿cómo se yo si ustedes realmente se están reuniendo tal como dice nuestro proceso?
- Podés venir cualquier día a las 9:30 que es la hora de la meeting y vas a ver que estamos todos reunidos cumpliendo con esa práctica.
- Mmm, pero no está en un documento como evidencia.
- Si querés te saco una foto de la meeting con algún miembro del equipo sosteniendo el diario del día, como hacen los secuestradores para dar una prueba de vida.
- ¿Me estas tomando el pelo?
- Por supuesto.

El punto es que las personas que prestan atención al proceso tienen un aprecio especial por la persistencia de información que para otros ojos carece de utilidad, pero a ellos le permiten dibujar esa realidad que quieren mejorar. Ellos no pueden mejorar basándose en comentarios. Hay mucho análisis cuantitativo entre sus funciones que no funcionan bien fundamentados sólo en comentarios como “Estamos bastante bien creo yo“.

Cosiderando este tipo de casos donde se ejecuta un proceso que no deja rastros, es que se comienzan a definir los pasos adicionales ajenos a una tarea para dejar esos pistas que esta gente espera. Por ej. “Todos los días se realizarán reuniones Daily Scrum y se tomarán minutas que dejan constancia de los temas tratados y la duración de la reunión.“

Esa última frase no tiene ningún sentido práctico para la persona que ejecuta la actividad, tiene sentido para la persona que observa el proyecto desde la perspectiva de las evidencias y caracteriza así el proyecto.

Esto es entendible y tiene un fin respetable. Pero no resulta fácil destinar respeto a estas tareas cuando se llaman “mejores prácticas“ livianamente a estos pasos adicionales para generar evidencia.

En el caso de las minutas de reunión, un miembro de un departamento de Calidad podría decir que es parte de las "mejores prácticas" tomar minutas de las reuniones.

No. No lo es.

De hecho, en una situación como la planteada puede ser una mala práctica.

En general, coincido con el pensamiento de James Bach:

No hay mejores practicas. Con esto quiero decir que no hay una práctica que es mejor que todas las otras posible, sin importar el contexto..
Cuando dices que algo es una "mejor práctica, puedes impresionar al principiante, o intimidar al falto de experiencia, pero solo puedes lucir tonto para las personas que creen en la posibilidad de la excelencia.

No Best Practices, por James Bach

Esto puede derivar en nuevos pasos en cada actividad que parecen inútiles y sin sentido, que se hacen sin saber porque, que no tienen contenido porque se hacen siempre igual, un copy and paste constante de reglas que suponen que fuerzan una ejecución más efectiva y solo entorpecen el camino.

También es posible la variante donde se generan los rastros sin que se realice realmente lo que se debe hacer o que no refleje lo que se está haciendo. Por ejemplo, que no se hagan reuniones diarias pero que se generen minutas para que nadie se alarme y diga “¿Por qué no hacen reuniones?“. O que se generen minutas que nada tengan que ver con lo discutido en las reuniones. La esencia de una práctica es completamente cambiada por el uso y por el énfasis en la documentación.

Cada documento que se escribe, cada tarea que se realiza debe tener un objetivo, una audiencia definida. Muchas veces esta audiencia es un departamento de Calidad buscando elementos para mejorar los aspectos del desarrollo de la manera que juzgan adecuada. Y eso esta bien.

Es necesario comprender que muchas veces se requiere dar visibilidad en determinados aspectos a interesados en el proceso para poder mejorar. Necesitan que registre el tiempo asignado a tal o cual tarea. Esta bien, espero que noten en donde podemos mejorar y lo hagamos en el futuro.

Pero es bueno tener algunos puntos en cuenta para mantener cierto equilibrio: los pasos adicionales para generar evidencia adicional tienen un costo y un beneficio. Implementarlos requiere evaluar ambos. Considerar que un documento podría ser evidencia útil en el futuro, no transforma la actividad de completarlo en una “mejor práctica“.

People CMM

Cuando una empresa o grupo desarrolla software con mucho ímpetu y poca formación, suceden cosas interesantes. El ímpetu y la energía aseguran que se hará todo lo necesario para terminar los proyectos, por mejorar la manera de trabajar y por mejorar la calidad de los resultados. La poca formación asegura que, en general, las acciones para alcanzar lo recién mencionado sean erradas o mal direccionadas. Así, se forma un ciclo donde la energía fluye y se neutraliza así misma.

Lo que sucede es que es difícil priorizar los problemas y no malgastar esfuerzo cuando hay tantas cosas para arreglar que no se sabe por donde empezar. Cuando nadie sabe lo que debe desarrollar, nadie sabe cuanto falta para terminar, Pepe pisa los archivos de Hugo, los errores abundan como las hormigas en un día de picnic, hay tareas que nadie hace porque son tediosas, el programador estrella reescribe el código de los demás porque no usan notación húngara, el líder de proyecto juega con un Gantt en una nube mientras todos hacen horas extra, y alguien dedica meses a escribir documentos que nadie nunca mirará... ¿Qué se puede hacer? Poner un kiosco... No, mejor pensemos en respuestas que no requieran cambiar de profesión.

En estas situaciones, por lo general, no se manifiestan problemas de desinterés en la mejora. Siempre hay alguien con iniciativa que buscará alternativas como escribir requerimientos, hacer revisiones por pares, aplicar UML o usar Microsoft Project. Pero este torbellino caótico aspira todas estas iniciativas y les quita sentido. Una acción bastante común, por ejemplo, cuando el software que un grupo escribe se desmorona en producción por enésima vez es agregar alguien que haga "testing”. "Nos está faltando testing, eso es lo que nos pasa” piensan mentes bienintencionadas, aunque no del todo acertadas. Así se agrega a alguien al equipo que tomará el software dos minutos después que el grupo de desarrollo dijo que termino (que es un minuto antes que la fecha comprometida de entrega al cliente) y lo testea. Por supuesto, sin capacitación, sin requerimientos, sin tiempos, esta persona es tan útil para mejorar la calidad como el chico que fue a la esquina a ver si llueve (sólo que en este caso, el tester puede tener la culpa de la lluvia).

Estas situaciones no son agradables y son conocidas por la mayoría de las personas que desarrollan software; pero no son exclusivas de esta actividad, aunque este hecho no representa ningún alivio para el que les toca vivirlas día a día. Hay otras personas que enfrentan situaciones similares donde hay muchas cosas para mejorar y las opciones para empezar parecen muchas.

Las empresas de software, mas allá que a muchos le cueste entenderlo, dependen del conocimiento y de las personas que lo poseen para poder evolucionar. Hasta el gerente más ingenuo, llega a un punto donde nota la necesidad de invertir algo para que la gente esté mejor, o para que esté (es decir, que no se vaya). Y aquí sucede algo similar que en el caso anterior, el objetivo parece claro: se desea mantener las personas en la empresa y además que mejoren sus capacidades para que impulse el desarrollo de la empresa. La pregunta es que hacer: eventos motivacionales, regalos de cumpleaños, bonos, premios por productividad, newsletters con información de la empresa, capacitación, definición de plan de carreras, entradas al cine o cenas.

Así como el ingeniero entusiasta tira manotazos al aire intentando mejor su caótica situación con iniciativas de todo tipo, de esa manera está el encargado de RRHH, con sus buenas intenciones, intentando mejorar la situación sin saber muy bien por donde empezar. Pero debe lidiar con particularidades más desafiantes en ciertos aspectos.

Por ejemplo, cuando intenta premiar el buen desempeño como muestra de reconocimiento, con un par de entradas al cine, están aquellos que se sienten manipulados, otros se sienten subestimados, otros piensan que el premio es poco, otros esperan dinero, otros gustan del teatro, y a otros les da lo mismo. Con cada intento de mejorar las condiciones de trabajo y la moral puede suceder lo mismo. Siempre existen escépticos crónicos que encuentran falencias en todo y es desmotivante ver caer una a una las más variadas iniciativas.

En el caso del desarrollo de software existen recursos que ayudan a salir de este estado. Aquí es donde aparece CMM con su rol más valioso a mi entender. Tan valioso que casi se equipara con lo perjudicial que resulta cuando es fuente de inspiración de obsesivos del proceso, almas en búsqueda de evidencia infinita, que combaten su inseguridad con planes kilométricos y cuyo interés por el software parece estar más ausente que gestos de cariño en una película de Steven Seagal. Pero, bueno, ese es otro temaVolvamos a lo valioso... Decía entonces que un gran aporte de CMM es darle prioridad a los problemas, proponiendo objetivos y actividades para resolverlos. Así, cuando el caos es completo nos sugiere:

- Definir que es lo que hay que hacer.
- Planificar como se va a hacer.
- Verificar el avance.
- No perder las cosas realizadas.

Esta es una gran ayuda y no es ninguna novedad para mucha gente. La novedad para mí, y en definitiva la motivación de estas líneas es mi reciente descubrimiento que para el segundo caso también existe CMM: People CMM.

People CMM es una herramienta que ayuda mejorar aspectos críticos relacionados a las personas en las organizaciones. Emplea el mismo framework de mejora de procesos que el SW-CMM como base para un modelo de mejores prácticas para administrar y desarrollar las personas de una organización. Es decir, cuenta con niveles de madurez del 1 al 5, con áreas de procesos en cada nivel con objetivos, donde el nivel 1 representa la falta de consistencia de la organización en la manera de desarrollar el trabajo.
Según sus autores úcada nivel progresivo de People CMM produce una transformación única en la cultura de la organización equipándola con prácticas más poderosas para atraer, desarrollar, organizar, motivar, y retener a sus empleados.”

Es útil iniciar observando el nivel 2 para ver, según este modelo, donde conviene apuntar las acciones iniciales de mejora, cuales son las bases sobre las cuales las iniciativas de mejora a largo plazo se deben sustentar. Las areas del nivel 2 son cinco: Staffing, Comunicación y Coordinación, Entorno de Trabajo, Administración de Desempeño, Entrenamiento y Desarrollo, y Compensaciones.
Veamos brevemente a qué apunta cada una:

Staffing
El propósito de Staffing es establecer un proceso formal por el cual el trabajo comprometido es equiparado a las personas de una unidad e individuos calificados son reclutados, seleccionados y llevados en transición a asignaciones.
Esta área involucra los procesos relacionados con balancear la carga de trabajo con las personas disponibles, reclutar, seleccionar entre los candidatos para las posiciones abiertas, ingresar y dejar la organización, y traslado a nuevas posiciones.

Comunicación y Coordinación
El propósito de Comunicación y Coordinación es establecer comunicaciones oportunas a través de la organización y asegurar que la fuerza de trabajo tiene las habilidades para compartir la información y coordinar las actividades eficientemente.
El establecimiento de una comunicación efectiva comienza comunicando los valores, políticas, prácticas y otra información importante de la organización a la fuerza de trabajo. Además de esta comunicación top-down, la comunicación bottom-up es estimulada buscando la opinión de individuos sobre sus condiciones de trabajo.

Entorno de Trabajo
El propósito de Entorno de Trabajo es establecer y mantener las condiciones de trabajo físicas y proveer los recursos que permitan a los individuos y grupos de trabajo realizar sus tareas eficientemente sin distracciones innecesarias.
Esta área de proceso refuerza la responsabilidad del management de monitorear las necesidades de entorno y de recursos que afectan la habilidad de la fuerza de trabajo de hacer su trabajo eficientemente.
El management debe tener planes para mitigar los problemas que presenten riesgos serios para la salud, seguridad, o eficiencia.

Administración de Desempeño
El propósito de Administración de Desempeño es establecer objetivos relacionados con el trabajo comprometido contra los cuales el desempeño individual y de una unidad pueda ser medido, para discutirlo contra estos objetivos, y mejorarlo continuamente.

Entrenamiento y Desarrollo
El propósito de Entrenamiento y Desarrollo es asegurar que los individuos tienen las habilidades requeridas para realizar su trabajo y que son proveídos de oportunidades de desarrollo relevantes.
El foco primario de esta área de proceso está en eliminar la brecha que existe entre las habilidades actuales de cada individuo y las necesarias para ejecutar sus asignaciones. Una vez que los individuos tienen las habilidades necesarias para realizar sus asignaciones, ellos pueden enfocarse sus actividades de desarrollo en otros objetivos (personales).

Compensaciones
El propósito de Compensaciones es proveer a todos los individuos de remuneración y beneficios basados en su contribución y valor para la organización.
El sistema de compensaciones debe ser diseñado para motivar y premiar las habilidades y comportamientos que la organización considere vitales para su éxito.

Este es un breve pantallazo del nivel 2. Como en el caso de CMM, existen prácticas, y subpracticas con guías de implementación más concretas en el documento de People CMM.
En estas se puede encontrar sugerencias sobre que deben contemplar los procedimientos relacionados a cada área de proceso.
El documento está disponible en la web en http://www.sei.cmu.edu/cmm-p/version2/

Estilos de Aprendizaje

El desarrollo de software presenta tanta variedad y matices en la manera de hacer cada tarea, en las herramientas que se utilizan y en los principios que se priorizan, que da lugar a un sin numero de inclinaciones y preferencias personales. Esto hace que cada desarrollador tenga sus valores y maneras de evaluar cada situación y que esta evaluación sea marcadamente distinta a la de otro.

Esta realidad se plantea claramente en lo personal. Noto que existe una falta de coincidencia llamativa entre mis pensamientos y los de otras personas que respeto en gran número de asuntos. En más de un momento me he preguntado donde nacen las diferencias más fundamentales con otras personas, o si es posible rastrear un único origen para muchas de ellas. Tal vez si.

El punto de partida de mi razonamiento son las palabras de Phillip Armour en su libro “The Law of Software Process”. Armour dice que el software no es un producto, es un medio para transportar conocimiento. Y continúa:

Si el software no es un producto, entonces el desarrollo de software no es una actividad de generar productos, no puede serlo. Si el verdadero producto no es el software sino el conocimiento contenido en el software, entonces el desarrollo de software solo puede ser una actividad de adquisición de conocimiento. Es cierto, podemos considerar que algunas de las funciones de desarrollo de software son una trascripción del conocimiento a una forma ejecutable. Esto es codificar. De todas maneras, codificar es sólo una pequeña parte de la actividad de desarrollar software, y se está volviendo más pequeña. También podemos afirmar razonablemente que si ya tenemos el conocimiento, entonces transcribirlo no requiere mucho esfuerzo. El trabajo real ocurre cuando tratamos de transcribir nuestro conocimiento y nos encontramos con que es incompleto. La actividad se convierte rápidamente en buscar el conocimiento correcto.
El desafío no es crear un sistema sino crear un sistema correcto. Si nosotros sabemos exactamente que es lo que tenemos que hacer, podemos crear sistemas tan rápido como nuestros dedos pueden tipear.
El desafío real es descubrir que es lo que el sistema debe hacer, y como podemos construir un sistema que lo haga.

The Law of Software Process: A New Model for the Production and Management of Software, Phillip Armour

Es algo difícil y extraño tomar esta perspectiva del desarrollo de software porque los desarrolladores tenemos una tendencia a pensar que sabemos todo lo necesario y una seguridad bastante manifiesta en nuestro conocimiento. Esta postura surge posiblemente porque los mejores desarrolladores tienen gran facilidad para aprender y cuando adquieren un conocimiento desarrollan una seguridad (excesiva) en ese conocimiento como si hubieran nacido con él. De pronto, un desarrollador que lo más parecido a control de versiones que había hecho en su vida era llamar a un archivo:

version_final.exe
version_final_final.exe
version_final_definitiva.exe

Trabaja en un proyecto donde se aplica un proceso de desarrollo CMM y a las dos semanas comienza a disertar sobre Gestión de Configuración, líneas base y a reírse de la inmadurez de otros que no tienen trazabilidad entre los requerimientos y los test cases.

Pero retomemos la idea de Phillip Armour. Pensemos por un momento que en realidad no sabemos todo y que lo que hacemos en un proyecto es, esencialmente, aprender.

Es crucial preguntarnos entonces como aprendemos, o más específicamente, cual es la manera más eficiente de aprender.

Aquí es cuando la individualidad de las personas, como siempre, comienza a ponerse en el medio. No todas las personas aprenden de la misma manera y estas diferencias en los estilos de aprendizaje se reflejan en más situaciones que las que uno supondría.

Marcus Buckingham, consultor y orador sobre prácticas de liderazgo y management dice que una revisión minuciosa de la teoría de aprendizaje de adultos revela que existen estilos predominantes que a veces se solapan. Entre ellos, el análisis y el hacer:

Primero, está el análisis. Los analistas entienden una tarea aislándola, examinando sus elementos, y reconstruyéndola pieza por pieza. Como cada componente individual de la tarea es importante a sus ojos, ellos necesitan fervientemente información. Necesitan absorber todo lo que existe de conocimiento sobre un asunto antes de poder sentirse cómodos con eso. Si no sienten que tienen suficiente información, escarbarán y presionaran hasta obtenerla. Ellos leerán el material asignado. Asistirán a las clases requeridas. Tomarán buenas notas. Estudiarán. Y aún así querrán más.
La mejor manera de enseñarle a un analista es darle tiempo abundante en la sala de capacitación. Representar situaciones. Hacer ejercicios de postmortem. Descomponer su performance en sus partes de manera que pueda reconstruirla minuciosamente. Siempre darle tiempo para que se prepare. El analista odia los errores. Un punto de vista común es que los errores alimentan el conocimiento, pero para el analista esto simplemente no es verdad. De hecho, la razón por la cual se prepara tan diligentemente es para minimizar la posibilidad de errores. Por lo tanto, no espere enseñarle mucho lanzándolo a una situación nueva y diciéndole que la maneje.
Lo opuesto es verdad para el segundo estilo dominante de aprendizaje, el hacer. Mientras que los momentos más poderosos de aprendizaje para el analista ocurren antes de la acción, para el hacedor ocurren durante la acción. Prueba y error son parte integral de su proceso de aprendizaje. Ellos aprenden más mientras están resolviendo cosas ellos mismos. Para ellos, la preparación es una actividad árida y poco interesante. En lugar de representar una situación con ellos, tome una tarea específica dentro de su rol que sea simple pero real, déle un breve resumen de los resultados que quiere, y aléjese de su camino. Luego incremente gradualmente el grado de complejidad de cada tarea hasta que haya dominado cada aspecto de su rol. Él puede cometer algunos errores en el camino, pero para el hacedor, los errores son la fuente del aprendizaje.

What Great Managers Do, Marcus Buckingham, Harvard Business Review - Marzo 2005

El analista y el hacedor son dos criaturas con grandes diferencias. Sus estilos de aprendizaje se manifiestan a cada instante y en todos los niveles en un proyecto de desarrollo de software.

¿Cómo llevaremos adelante un proyecto?

El analista quiere definir un proceso detallado, amplio, que considere los casos normales y los excepcionales, que abarque la mayor cantidad de tareas y de la manera más profunda posible. Métricas, estándares, herramientas, toda la definición que se toma hoy es tiempo ahorrado mañana. “Hay que hacerlo bien la primera vez”, “hay que evitar el costo del retrabajo”.

El hacedor quiere definir lo menos posible. Sólo las principales tareas y con mínimo detalle. La experiencia le indicará el camino. No quiere ponerse a pensar en todas las variantes ahora. Lo que quiere hacer ahora es ponerse a trabajar, y discutir sobre proceso, a sus ojos, no ofrece grandes aportes o avances en cuanto a resultados. “Hay que definir un proceso que cubra un poco menos de lo indispensable.”

Llega el momento de planificar y el analista comienza la tarea de llenar su gantt con tareas, responsables, dependencias e hitos. Descompone las tareas en subtareas, reestima cada una de ellas. Evalúa la asignación de trabajo de cada responsable, prueba que sucede si cambia algunas asignaciones, si el recurso X trabaja durante este periodo con una carga del 70 % y luego sube a 100 %. Cambia de orden las tareas. Prueba alternativas planificando ejecuciones paralelas. Podrá pasar horas y horas armando y puliendo esta planificación.

El hacedor hace una planificación con grandes hitos y resultados esperados. Luego descompone todo el proyecto en periodos de tiempo más cortos y solo determina el detalle de los resultados esperados para lo más inmediato. Define los objetivos para cada miembro en un periodo de tiempo y confia sabran hacer lo que haga falta para cumplirlos.

Las dependencias y el detalle de las tareas necesarias para llegar a los objetivos se resolverán sobre la marcha, tal como a él le gusta. Posiblemente ni siquiera arme un Gantt (¡sacrilegio!).

El analista comienza a pensar en requerimientos. La especificación debe ser amplia, detallada, completa y dentro de lo posible, inmutable.

El hacedor detalla sólo lo que necesita y no tiene problemas de que las cosas cambien. Tampoco lo incomoda que no estén especificados todos los requerimientos, igual cambiaran en el futuro.

El analista quiere definiciones de diseño, una arquitectura pensada que anticipe las posibles variaciones que depare el futuro, no importa que hoy no debamos implementar el software en varios idiomas, o para distintas bases de datos, o con distintos navegadores, o lo que sea. Siempre generalicemos, eso evitara retrabajo.

El hacedor piensa en diseño evolutivo, YAGNI, solo implementa la funcionalidad requerida y confía que podrá implementar las extensiones y cambios que sean necesarios, pero pensar hoy en algo que hoy no se necesita es perder el tiempo.

Hay situaciones y entornos que facilitan la postura del analista o del hacedor. Hay proyectos donde el nivel de incertidumbre es muy alto e intentar planificar en gran detalle tareas lejanas en el tiempo es una pérdida de tiempo. Hay otros donde la complejidad de la comunicación entre los diferentes equipos participantes requiere una planificación detallada y una definición clara de entregables, con fechas y criterios de completitud.

Pero el problema está en que nos cuesta realizar una evaluación racional de las necesidades de una situación particular y dejar de lado nuestros gustos.

En realidad en muchos momentos no tomamos decisiones racionales, sólo intentamos darle fundamentos racionales a decisiones basadas en preferencias o gustos.

Esto es un comportamiento bastante habitual en nuestro rol de consumidores, por ejemplo. Cuando vamos a comprar ropa y vemos una campera de marca reconocida pero muy similar a una mas barata, si nos gusta lo suficiente, encontraremos las razones necesarias que enmascaren nuestra compra como una decisión racional. “Mmm, si, me conviene comprar esta campera. Porque al final si compro la más barata no la termino usando. Y, en definitiva, estoy gastando dinero en algo que no voy a usar. En cambio, con esta, que sale un poquito más cara, estoy seguro que le voy a sacar provecho. Además como es de muy buena calidad, voy a tener campera para muchos años. Si, ¡me llevo esta!”

Clink, caja. Acabas de comprar una campera que sale el doble que otra porque tiene una etiqueta roja en la manga. No parece una decisión muy racional.

Cuando un analista o un hacedor tienen que tomar una decisión en un proyecto es muy difícil que dejen sus preferencias de lado.
El analista siempre verá riesgos de retrabajo, de hacer las cosas mal.
El hacedor siempre verá como perdida de tiempo tanta preparación, simplemente hagamos lo que tenemos que hacer y si hace falta algo más nos vamos a dar cuenta.
El analista siempre verá que los problemas de hoy son producto de la falta de preparación y planificación.
El hacedor siempre piensa que los problemas de hoy son inevitables y que lo mejor que se puede hacer es afrontarlos y aprender.

Lo constructivo de todo esto es entender que cuando otra persona realiza un planteo sobre necesidades de realizar más definiciones o de realizar menos definiciones puede estar relacionado con su manera de aprender. También darse cuenta cuando uno esta defendiendo una posición simplemente por una cuestión de gustos, no por necesidades reales de un proyecto.

En resumen, conocerse mejor y conocer mejor a los demás, para facilitar las coincidencias. Esto es positivo para cualquier proyecto.

¿Es buena idea medir y premiar el desempeño individual?

Hay temas que se presentan tantas veces en mis conversaciones con personas distintas que se ganan un espacio en este sitio indefectiblemente. En este caso, tiene que ver con algo que he mencionado antes, las métricas.

Razonando sobre el motivo de la existencia de las métricas, podemos realizar un primer acercamiento estableciendo que las métricas se toman porque ofrecen visibilidad sobre algún aspecto de un objeto en estudio, y otorgan de esta manera, información adicional para tomar decisiones. Se supone que estas decisiones tenderán a mejorar la situación. Si mido cuantos defectos introduzco en cada etapa de mis proyectos, es para saber donde debo apuntar mis acciones para mejorar, y en el próximo proyecto introducir menos defectos. Este debe ser el objetivo de tomar las métricas y de tomar decisiones basadas en ellas. Mejorar. Si todo va a estar igual o peor que antes ahorremos tiempo, dinero y esfuerzo.

Teniendo en cuenta esta ambición de mejora y considerando que las personas juegan un rol fundamental en los proyectos de desarrollo de software, no es difícil ni rebuscado llegar a la conclusión que existen grandes oportunidades de mejora midiendo el desempeño de las personas y tomando decisiones para optimizarlo. El objetivo de estas líneas es analizar esta idea:

Medir el desempeño individual de las personas para poder tomar decisiones que nos permitan alcanzar una mejora.

Este es un tema interesante. Mi percepción es que la postura más aceptada es que medir la performance individual es posible y es una buena idea. De hecho, muchas empresas lo están haciendo. Aunque las decisiones nunca son buenas sólo porque son frecuentes.

Comenzando con la primera parte de esta idea, podemos preguntarnos cómo hacemos para medir la performance de las personas. Indefectiblemente hay que establecer un sistema de medidas contra el cual todos serán mensurados. Déjenme contarles una experiencia relacionada al tema para ilustrar el punto que sigue.

Como ya he mencionado en otros artículos, por las características de mi trabajo he tenido la posibilidad de conocer varias empresas, más allá de haber trabajado sólo en dos. Conocer el día a día de una empresa nueva implica tomar contacto con cuestiones culturales muy llamativas. En una empresa en la que trabaje, observé que el reconocimiento del esfuerzo que cada uno ponía en su trabajo era directamente relacionado con el horario de salida. Existía esa idea en la gerencia y en muchas personas de la organización. Irse tarde estaba bien, irse a las 6 de la tarde era casi un insulto a las personas que se quedaban. Por supuesto, nadie decía: “Todos deben irse después de las 7 de la tarde”. La presión social tomaba caminos más sutiles pero no menos efectivos. Ciertamente, la gran mayoría de los empleados se retiraban después de las 18. Pero aquí venía lo curioso de la anécdota: muchos llegaban más tarde de lo que se considera normal. 9.30, 10, 10.30. ¿Por qué no trabajar de 9 a 18 como la gran mayoría de las empresas, en lugar de 10.30 a 19.30, por ejemplo? Porque muchas personas parecían prestarle atención al horario de salida pero no tanto al horario de entrada. Entonces todos hacían lo necesario para verse bien frente a este sistema implícito y algo curioso de medir el esfuerzo y el compromiso.

Es una tendencia casi natural de las personas. Observamos como nos miden y nos enfocamos en mejorar bajo esos parámetros.

Por lo general los trabajos se estiman en horas hombre, por lo que se podría comenzar midiendo las horas de trabajo para medir la productividad. Esta puede parecer una métrica inicial aceptable. Pero el problema es que las personas son ingeniosas y trabajan para conformar al sistema. Si saben que se las está midiendo por la cantidad de horas que pasan en la oficina encontraran la manera de estar más tiempo en la oficina sin producir más (tal vez porque realmente no puedan producir más).

“Al fin y al cabo a nadie le interesa que tan buenas son mis especificaciones, que tan efectivos mis diseños, cuanto tiempo ahorramos por mis buenas decisiones, o mi gran aporte para tomar las tareas tediosas o para capacitar a los nuevos empleados. No, a la empresa le interesa cuantas horas estoy aquí, como si fuera un guardia de seguridad o un espantapájaros. Bien, puedo hacer muchas cosas para distraerme en la oficina y hacer que pase el tiempo. Puedo traer unos buenos libros que generalmente leo en casa, puedo escribir largos mails en Visual Studio para que parezca que trabajo, puedo preparar el café instantáneo batido más batido que se haya conocido dedicándole 32 minutos por día. Por supuesto, si miran la métrica verán 20 horas más que el mes pasado.”

Esto mismo puede suceder midiendo líneas de código, bugs corregidos, o lo que sea. Podríamos definir como métrica la cantidad de cumplimientos o incumplimientos de fechas de entrega, pero el software es una entidad lo suficientemente abstracta como para inutilizar esta métrica. No es extraño ver un grupo de desarrolladores “cumplir” con su fecha de entrega a testing para recibir como retorno un reporte de defectos enorme, o (seamos sinceros) no es extraño cumplir con fechas de entrega con clientes liberando versiones de un producto de dudosa calidad. Si el sistema de medidas premia el cumplimiento de fechas de entrega, estas se van a cumplir. De una manera u otra se van a cumplir.

Por el tipo de trabajo realizado en el desarrollo de software, es muy difícil, por no decir imposible, establecer un sistema de estas características que no termine corrompiendo el comportamiento de las personas y que refleje de manera fidedigna la performance.

El problema de relacionar algún tipo de premios a estas métricas es que no aporta nada al objetivo inicial planteado. Recordémoslo:

Medir la performance de las personas para poder tomar decisiones que nos permitan alcanzar una mejora.

Aquí nada mejora. Nadie produce más, nadie está más motivado. Simplemente todos hacen lo de siempre, tal vez aumentan su nivel de cinismo frente a las iniciativas de la empresa, y hacen lo necesario para verse bien frente al sistema de medidas.

Otra alternativa usada es definir un valor de productividad, objetivos cumplidos, o algo por el estilo para calificar el trabajo de una persona en un periodo de tiempo determinado. Este valor es definido por la persona en el nivel superior de la jerarquía del empleado calificado. Esto no es una métrica, es una opinión. ¿Cómo te parece que trabajo este mes Juancito? “Mmm, yo le pondría un 8” “Me parece que cumplió con los objetivos”. No estoy diciendo que esta opinión no sea válida o que no sea útil. Estoy diciendo que no es una métrica, lo que en cierta manera nos aleja de la idea inicial de medir la performance de las personas. Pero si pienso que esto nos da una pista de algo que podemos hacer para mejorar la performance, que exploraremos más adelante.

De alguna manera, la necesidad de una métrica objetiva de desempeño individual tiene relación a la búsqueda de alcanzar la equidad, la disposición del ánimo que mueve a dar a cada uno lo que merece. Si en un periodo dado el rendimiento de un empleado es bueno y el de otro es excelente, el segundo debe recibir un retribución mayor. Pero no hay que confundirse. La equidad no está alineada con la premisa definida anteriormente porque la búsqueda de equidad puede perjudicar nuestro objetivo de mejorar el desempeño. Nadie piensa que hace un mal trabajo. Nadie dice: “Sinceramente este mes he trabajado de manera irresponsable, sin compromiso, y es mi culpa completamente. No me merezco el premio por productividad” ¡No! Todos pensamos que hacemos muy bien nuestro trabajo, o a lo sumo tan bien como se puede hacer con las herramientas que la empresa nos da. “Puede que haya hecho algo mal pero la empresa no me capacito o no me dio el tiempo necesario, o…” Siempre pensamos que estamos trabajando bien. Por eso, recibir un premio por nuestro desempeño no es más que recibir lo que merecemos; y no recibirlo es darse cuenta que nadie reconoce nuestro esfuerzo y, por lo tanto, no tiene sentido. El resultado de esta búsqueda de equidad nunca termina produciendo una mejora de desempeño sino más bien lo contrario.

Es esta búsqueda de equidad, también, la que nos hace pensar en medir individualmente el desempeño de las personas para poder comparar unos con otros. No considero que esto sea buena idea. David Anderson, manager en Microsoft, cuenta porque:

Desarrollar software es un deporte de equipo; requiere interacción y soporte mutuo a través de todo el equipo. Es trabajo de conocimiento y es hecho mejor en un entorno de conocimiento compartido. Cuando uno premia a las personas por su esfuerzo individual relativo a sus pares, estas alentándolos a acaparar conocimiento, no a compartirlo. El manager debe ser medido por la productividad del equipo, no los individuos miembros del equipo por sus esfuerzos individuales. Es un sistema – optimiza para el sistema, no para sus partes.

Managing at Microsoft, Software Development Magazine, Marzo 2005

Podemos pensar, entonces, que el problema no es encontrar la métrica apropiada para medir individualmente el desempeño de una persona y poder premiarla, porque esto nunca nos llevará a una mejora de desempeño que es nuestro objetivo original. Esto parece ser lo que realmente ocurre con los programas de premios por performance.

“Cerca del 83 por ciento de empresas con algún tipo de programa de premios por performance dicen que su enfoque es poco exitoso, o que directamente no funciona,” de acuerdo a The Wall Street Journal (“Firms Report Lackluster Results from Pay-for-Performance Plans”, 15 de Junio de 2004)

No tenemos métricas pero tal vez tampoco las necesitemos. Hay cosas que se pueden conocer más allá de la falta de métricas y se puede actuar para mejorar.

¿Cómo es la relación con tu pareja?

“Mmm, el último mes tuvimos 3 discusiones leves, y una grave. Dos veces ella no quiso cocinar y 5 veces yo protesté para sacar la basura. Dos veces no coincidimos sobre el destino de nuestros ahorros. Eso significa que si multiplico la cantidad de incidentes por su nivel de gravedad y lo divido sobre la cantidad de días me da el coeficiente de relación saludable.” [1] Suena estúpido, ¿no? Uno puede decir si la relación con su pareja es buena, mala o regular sin métricas. Porque convive, comparte momentos y la suma de cada una de esas pequeñas experiencias es la que nos da la sensación del estado de la relación. Además es saludable que uno aprenda a prestar atención a los detalles que manifiestan como esta esa relación.

Siendo un manager puedo saber si es bueno el desempeño de cada uno de los miembros de mi equipo sin métricas. Como manager uno debería prestar atención a los detalles, formar esa sensación sobre el desempeño de los integrantes del equipo y escuchar y escuchar. Muchas veces los problemas se manifiestan de formas inesperadas y sutiles. Parte del trabajo de un manager es aprender a detectar estas formas.

Esto nos lleva al esquema que planteaba unos párrafos mas arriba, sobre reflejar una opinión sobre el desempeño de una persona de alguna manera.

Pensemos en la siguiente situación: Carlos, líder de un equipo de desarrollo, observa que Luis no se desempeña de la mejor manera. Él está convencido que Luis puede realizar su trabajo mejor, nota que no lo hace con todo el compromiso que él esperaría. Es una situación muy concreta y real para Carlos. Luis puede trabajar mejor y no lo hace. Por supuesto, Carlos quiere que Luis mejore su desempeño. ¿Qué es lo que puede hacer para lograr esto? Podría quitarle el premio por productividad a Luis.

¡Ouch! Esa es una forma bastante primitiva de comunicación, demasiado simplista y centrada en el dinero. El rol que está cumpliendo el premio por productividad es dar retroalimentación sobre el trabajo ejecutado a un empleado.

Esther Derby dice que la retroalimentación “es información que le damos a otra persona cuando queremos que comience, termine, continué, o cambie algún comportamiento.”

How to Talk About Work Performance: A Feedback Primer, Esther Derby

En el caso del castigo por falta de productividad simplemente es decir: “No estoy conforme con lo que hiciste este mes”. Es una manera de dar información muy pobre y tosca para lograr algún resultado.

Se puede hacer de una manera mucho más efectiva, clara y menos ofensiva conversando sobre el tema con el principal interesado. Esther Derby brinda algunas recomendaciones en su artículo sobre retroalimentación:

• Hablar del tema tan rápido como sea posible: si como manager detecto un problema la primera semana del mes, ¿por qué esperar hasta fin de mes, cuando se definen los premios, para dar retroalimentación?


• Proveer ejemplos específicos: “No trabajaste comprometido como esperamos” es algo tan ambiguo que no da pautas al empleado sobre que es lo que debe cambiar. “Note que esta semana faltaste por tercera vez a una reunión de equipo en lo que va del mes” es algo más específico. Lo mismo se aplica para retroalimentación sobre hechos positivos. “Manejaste con gran rapidez y eficiencia los requerimientos del cliente X durante las vacaciones de Hugo. Hiciste que su ausencia no nos afectara.” En este caso el premio por productividad sólo dice BIEN/MAL.


• No depender de la telepatía:
  “Pero, ¿qué hice mal?”
  “No me lo preguntes. Sabes muy bien que hiciste mal.”
  El premio por productividad por si sólo es telepatía pura. No dice nada, todo es supuesto.


• Verificar que existe acuerdo en los datos: En caso de dar ejemplos específicos, verificar que el empleado está de acuerdo con lo que se dice. “Si, realmente falté a tres reuniones este mes.”


• Solicitar un cambio: Elemental, Watson. Si uno como manager espera que un empleado cambie su comportamiento hay que decirlo. Si uno espera que deje de hacer algo hay que decirlo. “Entiendo que las reuniones muchas veces se extienden demasiado. Ya trabajaremos sobre ese tema. Pero quiero que, a partir de hoy, asistas a todas las reuniones de equipo.”
  

Este enfoque admite que el desempeño de una persona no es proporcional al dinero que se les paga. Entiende que se deben contemplar las motivaciones, los problemas, la fallas en la definición de objetivos o en la comunicación. Y apunta a resolver los problemas que pueden causar el desempeño insatisfactorio. Claro, esta tarea es más compleja que simplemente tomar decisiones binarias sobre si pago o no un premio de productividad. Pero quienes piensan seriamente en mejorar el desempeño deben estar dispuestos a tomarse el trabajo que requiere.

Muchos managers no tienen la tendencia natural de manejar los aspectos sociales de su rol. Es más fácil para ellos sentarse a llenar una planilla con números o una aplicación de RRHH, que sentarse a conversar con los miembros de su equipo para detectar las maneras de mejorar el desempeño o escuchar los problemas que tienen. Lo que plantea un aspecto interesante de todo esto. ¿Qué tan idóneos son los managers para hacer su trabajo? ¿Qué tan bien lo hacen? ¿Qué tan preparados están para hacerlo? La búsqueda constante de una forma de medir con un número el desempeño de las personas y de premiar o castigar con dinero puede ser simplemente un reflejo de la incapacidad actual de los managers para cumplir su rol.