La Magia de las Historias de Usuario / Desarrollo Conducido por Historias de Usuario

Nivel del post: Intermedio.


Cuando uno lee sobre RUP (Rational Unified Process), en una de sus definiciones dice que es un desarrollo conducido por Casos de Uso, y hoy quiero después de convivir por más de 6 meses con las Historias de Usuario, contar cómo realmente conducen el desarrollo del software mucho mejor que los casos de uso.

Introduciéndonos: El Formato

Las HU (Historias de Usuario) de usuario tienen un formato libre, y podrían expresarse como una necesidad funcional, por ejemplo:

• consultar las películas de cine disponibles en un teatro cerca a mi casa

 O como ya es popular se pueden escribir con el siguiente formato (template):

• yo como <rol> quiero/deseo/necesito  <funcionalidad> para <beneficio de negocio>

De esta forma nuestro ejemplo quedaría:

• yo como cliente deseo saber cuales son las películas disponibles en un teatro cerca a mí casa para poder elegir que película ir a ver el día de hoy

Este formato tiene las consabidas ventajas de:

• saber quien va a usar la funcionalidad y
• comprender el beneficio del negocio de forma que el equipo pueda llegar a ese beneficio por distintos caminos

Y dónde esta la magia...

Aunque el objetivo de las historias es habilitar la comunicación entre el Cliente y Equipo (para el caso de Scrum:  Product Owner PO / Dueño del Producto y el Equipo de Desarrollo), dando cumplimiento al principios del manifiesto ágil:

• Personas e interacciones sobre procesos y herramientas (ver más sobre el manifiesto ágil)

Una definición tan simple obliga al equipo a estar en comunicación con el Product Owner (PO), de la siguiente manera:

• En el Planning (ver más sobre scrum), el equipo pregunta al PO el detalle de lo que quiere y lo que espera.
• En el Planning, el equipo con base en lo conversado estima lo que va a construir en presencia del PO.
• Durante el Sprint, el equipo clarifica con el PO detalles menores olvidados.

Pero de todo esto lo que me tiene maravillado el día radica en los criterios de aceptación.

Los criterios de aceptación nos permiten reconocer cuando la historia esta HECHA / TERMINADA / REALIZADA (o criterio de DONE de Scrum), de esta forma el equipo de desarrollo no tiene pierde, pues todo su desarrollo esta orientado al resultado esperado, o mejor, orientado a los casos de prueba que a la especificación.

Esto es una ganancia enorme!!! (para quienes hemos padecido el desarrollo en cascada o RUP basado en casos de uso) la marcha de la muerte - o Desarrollo Orientado a la Frustración DOF - es la siguiente:

• Analista: El casos de uso es especificado con sus  escenarios de uso (flujo básico, alternos y de excepción) -que a ratos solo los entiende el analista/desarrollador que los escribió -
•  Desarrollador: Para cumplir con el caso de uso el desarrollador construye lo especificado en los escenarios de uso,  y valida contra unos escenarios de prueba que "el cree" necesarios para cumplir la funcionalidad.
• Tester:  luego el tester mucho mas hábil en encontrar los errores (o enfocado en esa única tarea) construye n-mil casos de prueba a un solo escenario de uso (ejemplo flujo alterno 3 )  hasta que por fin le encontraba la caída al escenario del caso de uso y lo devolvía a desarrollo con un incidente o hallazgo (forma diplomática y "very polite" de decir bug), 
• Desarrollador:  el desarrollador dice  "#$%#"% ese escenario YO NO lo considere, no estaba escrito en ninguna parte,  me demoraré un poco más en completar este caso de uso y entregarlo para pruebas"
• Tester :  a lo que el tester responde "yo te entiendo, pero caso de prueba fallido es una forma de confirmar esa funcionalidad" 
• Desarrollador : remata contestando el desarrollador  "tienes razón, nos vemos en X días cuando termine el desarrollo y marque como cerrada tu anotación en el Bugtracker"..

 y todos seguiremos tratando de dar lo mejor en un contexto que no lo permite, y que por lo general termina en una serie de enemistades:

• Desarrolladores - Testers: - pues los desarrolladores comienzan a ver con malos ojos a los testers, por más claro que tengan el proceso de pruebas como una actividad de desarrollo.
• Gerente de proyectos - Equipo: pues piensa "como es que se continúan atrasando en el cronograma, como es que no identificaron ese escenario, pensé que tenía un equipo profesional"
• Cliente - Proveedor de desarrollo: pues el cliente piensa "como es que no son capaces de cumplir con lo especificado, casi que no completan esos casos de uso y miren todos los errores que tienen"

En cambio, en las historias de usuario ya sabemos como nos van a probar la historia y como se considerara TERMINADA.

Entonces para la historia de usuario que escribimos, los criterios de aceptación serán:

• que me liste de a 10,20, ó 50 películas con su respectiva imagen y una corta descripción
• que aparezca la calificación del público a la película
• que aparezca la crítica a la película
• que aparezca la distancia del cine a mi ubicación actual (tal vez esta pueda ser otra HU)

Aunque estos criterios de aceptación  son mejor expresados en el formato / template  BDD, de la siguiente manera:

En inglés, 

• GIVEN 
• WHEN
• THEN 

o en español

• DADO
• CUANDO
• ENTONCES

(ver más  de BDD en:

• http://adrianmoya.com/2012/08/que-hay-en-una-historia/ ( o su original en inglés http://dannorth.net/whats-in-a-story/ .
• http://dannorth.net/introducing-bdd/  )

Este template permite la automatización de pruebas funcionales y obvio la mejor escritura de criterios de aceptación, veamos:

• Escenario 1: listar de a 10 películas
• DADO que me encuentro en cualquier sección de la aplicación
• CUANDO selecciono ver listado de películas
• -- Y antes no se ha seleccionado una cantidad de lista diferente 
• ENTONCES el sistema me listará las 10 películas 
• -- Y estás aparecerán en orden de estreno con su respectiva imagen y una descripción corta 

Y de esta misma forma se seguirían escribiendo los otros criterios / escenarios de aceptación...

Aun así ustedes me dirán, pero JORGEEEEE y 

¿la interfaz gráfica y la arquitectura?

R/ Pues tanto para la interfaz como para la arquitectura se definen unos lineamientos básicos para la aplicación antes de comenzar y estos irán evolucionando conforme pasa el tiempo. Si hay que definir algo de la interfaz gráfica se hará un boceto y se validará con el Product Owner durante el Sprint.

¿ y si queda faltando algo?
R/ Fácil, estamos bajo el principio de transparencia,

•  el equipo en el Planning preguntó y
• el Product Owner contestó, y 
• con base en esto se estimaron unos PUNTOS DE HISTORIA (USER STORY POINTS ), 
• se realizó el tasking de lo que se iba a construir (identificación de las tareas para construir las historias de usuario), y
• se estableció el compromiso de las historias a construir en el Sprint.

Por lo tanto, si quedó faltando algún escenario por contemplar,  SIMPLE:

 "ENTRA COMO UNA HISTORIA DE USUARIO NUEVA PARA EL PRODUCT BACKLOG"

(no les parece esto una maravilla, a mí sí)

Esta historia debe ser priorizada, además sino se identificó y es muy importante, podemos contestar: "tranquilo Product Owner en el próximo Sprint lo incluimos que máximo lo comenzamos en 2 semanas".

Y dónde quedan los bugs / incidencias / hallazgos o como le queramos decir...

Wow, este tema con la pregunta anterior era uno de los objetivos a los que tenia con este post, la respuesta es otro abracadaba, "DESAPARECEN o TIENDEN A CERO" (nada por aquí, nada por acá como diría Harry Houdini).

La razón es muy simple, si desarrollamos orientados a casos de prueba una historia de usuario no estará finalizada hasta que cumpla todos sus escenarios y cumpla todos los criterios de DONE,estos son;

• cumplir los aspectos funcionales, 
• cumplir con los criterios de aceptación y de pruebas (ya sean estas manuales o automatizadas).
• encontrarse desplegado y funcionando en un ambiente determinado, llámese ambiente de pruebas, pre-producción, laboratorio, producción -en algunos casos , etc.

Por lo tanto, si una historia de usuario esta DONE significa que:

• fue probada y certificada por el equipo
• fue aceptada por el Producto Owner

Si llegase a existir un "BUG", con plena seguridad afirmo que fue un escenario no identificado, y por lo tanto una historia nueva debe implementarse.

De esta forma las historias de usuario REALMENTE SI CONDUCEN Y DELIMITAN EL DESARROLLO, y see convierten en un punto de encuentro y de sincronización de imagen mental (entre Product Owner y Equipo) de  lo que se desea construir (ni una linea de código adicional más - pues no es necesaria - , ni una menos - pues no cumpliríamos el criterio de DONE - )  y de lo que no se desea construir, pues respecto a esto último, no hay lío, pues nadie lo identificó, o no era necesario en el momento.

Adicionalmente, los costos por garantía  también desaparecen o tienden a cero pues no habrán sorpresas de escenarios no cubiertos en producción.

En Resumen

Las grandes ventajas que he visto son:

• Estamos orientados al resultado y no a la especificación
• No quedan escenarios sin probar, pues estos son explicitados en los criterios de aceptación, situación que si sucede con los casos de uso..
• Lo que esta por fuera de los criterios de aceptación simplemente se convierte en una nueva historia de usuario y se le asignara prioridad
• Cuando una historia de usuario esta DONE!! (CRITERIO DE HECHO, o REALIZADO) y con sus pruebas funcionales automatizadas, se puede dar por olvidada la historia de usuario, en el sentido que no nos tenemos que volver a preocupar de ella pues el desarrollo orientado a casos de prueba garantizará que no quedaron escenarios por cubrir. 

Puedo afirmar con tranquilidad

MIS DÍAS DE DEFENDER LOS CASOS DE USO HAN TERMINADO.

LARGA VIDA A LAS HISTORIAS DE USUARIO

--
Hasta acá mi reflexión,
quedo atento a sus observaciones y comentarios

JORGE HERNÁN ABAD LONDOÑO

MSc. Ingeniería Informática

ScrumAlliance Certified Scrum Master member 000260715

User Story Dojo - ( User Story Map y User Stories)

Nivel del post: Medio

Lugar: www.ceiba.co - Ceiba Softaware House. (Empresa donde trabajo y me desempeño como Scrum Master y Scrum Coach)
Ciudad: Medellín, Colombia


Temas trabajados en el dojo.

• Desarrollo Orgánico
• Cómo construir un User Story Mapping * (técnica de Jeff Patton - http://www.agileproductdesign.com/presentations/user_story_mapping/index.html o en español en  http://www.caminoagil.com/2013/02/visual-story-mapping-aplicado.html)
• Cómo elaborar Historias de Usuario - User Stories (taller. Criterio CCC e INVEST)

-
-

o acceder a directamente a  youtube

-
-

*El nombre correcto es User Story Mapping dado por Jeff Patton (en algunos medios se emplea Visual Story Mapping / Visual Story Map)

Por dónde comenzar a leer y a estudiar de Scrum

Nivel del post: Básico.



Hola a todos:

A continuación presento el listado, y en orden de lo que considero deben ser las lecturas sobre Scrum para entender más evolutivamente el framework.

1. Scrum Guide. Por Ken Schwaber y Jeff Sutherland (creadores de scrum). http://scrumguides.org/
2. El espíritu de Scrum. Por Alan Cyment -http://es.scribd.com/doc/84799747/El-espiritu-de-Scrum 
3. Un mejor Scrum. Escrito por el Coach y Entrenador Certificado de Scrum Peter Hundermark.Traducción por Alan Cyment, Entrenador Certificado de Scrum https://www.agile42.com/documents/25/Un-mejor-Scrum-2.pdf
4. Scrum y XP desde las trincheras. Por Henrik Kniberg. http://www.proyectalis.com/wp-content/uploads/2008/02/scrum-y-xp-desde-las-trincheras.pdf
5. [!Nuevo!] Kanban y Scrum – obteniendo lo mejor de ambos. Por Henrik Kniberg & Mattias Skarin. http://www.proyectalis.com/documentos/KanbanVsScrum_Castellano_FINAL-printed.pdf

En otro post http://ing-sw.blogspot.com/2013/02/por-donde-empezar-leer-de-scrum-y-de.html , comparto donde seguir trabajando y leyendo sobre agilismo.

Saludos y espero les sirva este camino de inicio en el entendimiento de SCRUM.

Jorge Abad

Nota: Si cambia algún link les pido me lo hagan saber.

---

Mi evolución sobre las retrospectivas en Scrum

Desde hace un tiempo he venido actualizándome sobre las retrospectivas en Scrum (la verdad no he leído y estudiado todo lo que he querido) pero he realizado varias con mi equipo, y he particpado en otras como coach de la organización en la que estoy.

Al inicio, comencé con el típico (propuesto en http://www.mountaingoatsoftware.com en su introducción a Scrum):

• Qué hicimos bien
• Qué hicimos mal
• Y qué debemos mejorar

Pero note que nos estábamos quedando quietos, las tres preguntas anteriores solo son un diagnóstico y te proporcionan una foto de como te fue el el Sprint que acabas de terminar pero no te lleva a la acción.

Luego entonces decidi madurarla un poco y agregar

• Qué se debe mantener
• Cómo hacerlo mejor

(esta versión es mas coherente con un ciclo de mejora PHVA de mejora continua)

Pensando en:

•  una retroalimentación al proceso 
• y una mejora del mismo, 
• manteniendo aquello que nos había generado valor.

Luego, al leer a Alan Cyment me animé a cambiar las preguntas, adicionando los aspectos de Productividad, Calidad y Felicidad, generando una matriz que involucraba los aspectos anteriores

Que como pueden deducir me llevaba de nuevo a un diagnóstico pero me permitía ver aspectos interesantes del equipo.

Luego la maduré a la versión que utilizo actualmente, que presento a continuación: 

(esta actividad toma aproximadamente 40 a 50 minuntos)

Aclaro, que sigo visionando en la parte superior los aspectos de productividad, calidad y en especial felicidad para comprender como mis equipos quieren cambiar y mejorar, y en especial ser más felices, para estar acordes con el principio del manifiesto "Los proyectos se desarrollan en torno a individuos motivados..." Y si mi equipo esta motivado y feliz pues al proyecto, y a todos nos irá mejor y será más fácil y natural la mejora.

Pronto intentaré otras técnicas:

• Dinámica de Retrospectiva: 3 caras y 4 capas (mad/glad/sad/  vs Filosofía, metodología, técnicas y ecosistema - http://thomaswallet.blogspot.com/2011/12/dinamica-de-retrospectiva-3-caras-y-4.html#.UXYWoqLEK3H
• Mad/Sad/Glad vs Keep/Fix/Try
• Estrella de mar - star fish - http://www.proyectosagiles.org/retrospectiva-estrella-mar-starfish-retrospective-scrum
• Start doing: comenzar a hacer
• More of: mas de lo anterior
• Keep doing - Seguir haciendo /mantener
• Less of: menos de
• Stop doing: dejar de hacer

Y les contaré como me fue.

Seguiremos avanzando en este aspecto de las retrospectivas, pero lo que si tengo claro es:

• De una retrospectiva se debe avanzar del diagnóstico (del qué) a la acción (al cómo vamos a mejorar).
• El equipo guiado por el Scrum Master debe mirar como avanzar y mejorar su proceso
• Las mejoras identificadas deben ser igualmente priorizadas e identificadas a realzar al corto, mediano y largo plazo. (muchas veces no podemos mejorar todo de una vez, sino orgánicamente de la misma hacemos con el producto) .

Hasta la próxima.

Quedo atento a sus comentarios, observaciones, mejoras y/o sugerencias.

Scrum: El camino del menor gasto de energía

Recuerdo como le he dicho a mis estudiantes de pregrado y posgrado mi reencarnación anterior, sí cuando fui/soy ingeniero civil, y que luego poco a poco desde los programas para cálculo estructural y matrices inversas, la realización de supermacros en visual basic para excel y la construcción de software para sistemas de información geográfica hizo que llegara al mundo que estaba destinado, el de los sistemas y más precisamente el del software.


Por mucho tiempo he estado en temas de requisitos, casos de uso, java, php, JEE, BPM, SOA, arquitectura empresarial, calidad, pruebas, CMMi, reglas de negocio, pero nunca había encontrado el dinamismo y entusiasmo que he observado con el uso de tanto framework de gestión de proyectos como Scrum, como el uso de las prácticas ágiles de ingeniería.

Son muchas las cosas que se han vuelto satisfactorias desde mis primeros dias usando scrum hace como 8 meses:

• la sonrisa del cliente
• la sonrisa de los desarrolladores
• el nivel de estrés bajo
• el de compromiso super alto
• los reconocimientos
• los bugs en producción cada vez menores
• la confianza entre el cliente y proveedor emergiendo y fortaleciéndose (por fin como aprendí en algun lugar "SIENDO SOCIOS DE NEGOCIO")

Y por fin hacer software es algo divertido, algo que anima y reta, y no algo que devoraba implacablemente el tiempo de:nuestr@s novi@, espos@, hij@s, amigos y por ende de nuestro merecido descanso (sea cual sea la forma que le queramos dar).

Y recordando mis clases de mecánica de fluidos, recuerdo que el agua siempre elegía el camino (la línea) del menor gasto de energía (no les suena similar a Lean, eliminando el desperdicio) y así se ha vuelto para mi Scrum. La forma de gastar la menor cantidad de energía para llegar al resultado esperado.

Antes nos desgastábamos en tantas cosas, wow, con solo pensar en la desconfianza típica entre cliente y proveedor, a eso súmele:

• las reuniones tediosas de levantamiento de requisitos
• el juego de las estimaciones, que nunca le acertábamos (cosa que si añoraba de mi anterior reencarnación - la ingeniería civil -  y que volví a recuperar con Scrum)
• la llenadera de actas, y documentos como evidencia de la desconfianza
• el seguimiento constante al riesgo 
• la preocupación con el alcance
• el salir perdiendo siempre como proveedor (pues como vamos a perder ese cliente tan importante, regálenle esas horas)
• las horas exhaustivas de pruebas
• el querer comprimir inútilmente el tiempo de pruebas para luego dolorosamente comprobar que ese tiempo NUNCA lo debimos haber recortado.
• el decirnos mentiras entre todos y prometer con firma de sangre fechas que no íbamos a cumplir nunca (si realmente hubiera puesto mi sangre en esos compromisos no estaría escribiendo este post)
• la amistad e idilio entre cliente y proveedor que termina siendo el peor de los odios, o un matrimonio del cual ambos quieren salir pero muchas veces no encuentran como.
• y uno como gerente de proyecto, consultor, desarrollador, comercial en la mitad viendo como pasa todo eso y día tras día, proyecto tras proyecto, el problema se repite una y otra vez..

Pero afortunadamente surgió el Manifiesto Ágil http://agilemanifesto.org/, y poco a poco los que estábamos enamorados de metodologías como RUP - iterativo, incremental y lógico -(que muy contadas veces la vi aplicar correctamente, por lo general venden RUP como un proyecto con las 4 fases - inicio, elaboración, construcción y transición-  cada una de una sola iteración y en especial la de construcción de una sola iteración convirtiéndolo el proyecto en el odiado y reconocido cascada con todas sus consecuencias funestas),vimos como fue creciendo bajo su sombra el arbolito de las metodologías ágiles y hoy más de 12 años después comienza a ser la respuesta a mi pregunta:

¿Por qué si hacer software es tan apasionante, resulta siendo tan frustrante? 

(últimamente le estaba diciendo PROGRAMACIÓN ORIENTADA A LA FRUSTRACIÓN POF o en inglés FRUSTATION-ORIENTED PROGRAMMING FOP)

o mejor

¿por qué si hacer software es tan apasionante, no es divertido?

Veía y veo iniciativas como CMMi, PSP /TSP tratando de enmarcar cosas que tienen que ver con la creatividad y la imaginación (wow casi no lo reconozco... siempre he sido fiel seguidor de los modelos de calidad, y de apoyar la escritura de código como trabajo de ingeniería, más hoy como una revelación comprendo que hay mucho de arte de libertad-controlada como diria Alan Cyment) y que en su afán de enmarcar y definir todo, terminan haciendo esto que se ve tan divertido o que uno lo imagina así al ver videojuegos en algo digno de señores de corbatas que no aman lo que hacen y que no ven la hora de ser gerentes de proyecto, o hacer un posgrado en administración, finanzas o cualquier otra cosa para cambiar de negocio.

Hoy veo a Scrum junto con las prácticas ágiles de ingeniería como el renacer de la pasión de mi equipo de trabajo, como el renacer de mi pasión por crear y proponer cosas nuevas, como el renacer de la creatividad y de la confianza entre cliente y proveedor. 

Y son pequeños hechos, pequeños caos controlados, grandes destellos de creatividad en espacios delimitados de tiempo los que están dando orden a aquello que me atrajo en un principio y que amo tanto:

• los dailys sincronizan al equipo
• los planning nos comprometen
• los review nos enorgullecen o nos hacen sonrojar cuando fallamos (retandonos a ser mejores)
• las retrospectivas nos ayudan a ser mucho mejores
• las reuniones innecesarias no existen
• las reuniones de temas que tenemos que trabajar dentro de un mes o más no existen, por lo tanto tanta complejidad se va perdiendo.
• La verbalización y activación de la comunicación agiliza el desarrollo y afianza el compromiso.
• el horizonte de estimacion es de 2 semanas haciéndonos más precisos y no tenemos sorpresas.
• ver software funcionando (como lo expresa el manifiesto ágil) es el mejor indicador de avance y de felicidad del equipo y del cliente
• el coraje del equipo esta jalando hacia la mejora continua
• si hemos de fallar, fallamos a las 2 semanas y no a los 4 meses.
• el framework de Scrum y las prácticas agiles de ingeniería estan pensados en la mitigación del riesgo.

Definitivamente ganamos todos

• software funcionando y bonito (pruebas unitarias y funcionales automatizadas)
• cliente contento
• equipo contento
• scrum master contento
• gerente del cliente y del proveedor contento.

Creo que por fin encontramos el santo grial del software, lo que nos va a sacar de pobres, la gallina de los huevitos de oro

Ahora mis grandes interrogantes son:

• ¿que huevitos quiero poner?
• ¿mi ciuidad,. mi país, y latinoamérica aprovechará esta gran oportunidad?

Saludos

Jorge Hernán Abad

Ingeniero Civil

Especialista en Desarrollo de Software

MSc. en Ingeniería Informática

Twitter | https://twitter.com/jorge_abad // sígame bajo su cuenta y riesgo

Linkedin | http://www.linkedin.com/in/jorgeabadl

Conferencia: Prácticas ágiles de ingeniería "en la práctica"

 Tertulia de Ingeniería de Software realizada en la Universidad Eafit el pasado 14 de marzo de 2013 por Jorge Valderrama https://twitter.com/jvalde @jvalde +Jorge Valderrama  (continuación de La Complejidad de lo Simple)

En esta tertulia se pone en funcionamiento (despliegue en producción) la primera historia de usuario del siguiente enunciado, utilizando prácticas de ingeniería como:

• ATDD
• BDD
• TDD
• Integración Continua (jenkins)
• Refactoring
• Repositorio de versiones (git)
• Sobre la plataforma Heroku

Enunciado

Especificación

Como usuario de recursos humanos, me gustaría ser capaz de registrar una lista de empleados, junto con la fecha de iniciode su empleo y sus días autorizados de vacaciones.

Un empleado tendrá los siguientes atributos:

·      un nombre único completo (para los fines de este ejercicio sólo hay un 'John Smith' en el mundo, y 'john smith' es igual a'John Smith')

·      una fecha de inicio que no podrá ser en el futuro

·      un número de días de vacaciones con un mínimo de 20 días y un máximo de 25 días para un empleado que la fecha de inicio es menor que hace un año, con un máximo de 30 días, de lo contrario.

Seguridad

·      Sólo los usuarios con el rol de HR podrán crear y editar los empleados.

·      Todos los tipos de usuarios podrán ver una lista de los empleados y se pueden filtrar por fecha de inicio.

·      Cualquier usuario puede ver los detalles de un empleado, pero sólo los usuarios de HR serán capaces de ver el tiempo de vacaciones disponible de los otros empleados.

El salario emocional no engorda la billetera, pero reduce el estrés y mejora la productividad

Les copio este interesante artículo sobre el salario emocional y estrategias de retención de personal;. Este tema esta muy vinculado con la Pirámide de Maslow.

Como dice uno de los doce principios ágiles


"Los proyectos se desarrollan en torno a individuos motivados. Hay que darles el entorno y el apoyo que necesitan, y confiarles la ejecución del trabajo."



___

El salario emocional no engorda la billetera, pero reduce el estrés y mejora la productividad

Fuente: http://www.portafolio.co/economia/el-salario-emocional-no-engorda-la-billetera

No llega con cada quincena, no es contante y sonante y a veces no es fácil de demostrar, pero existe. Es el salario emocional, un recurso de retención y atracción del talento humano, del que hace poco se habla en Estados Unidos y Europa y que apenas comienza a sonar en América Latina.

Este tiene que ver más con la calidad de vida y la conciliación de la vida familiar y personal con la laboral, que con el metálico y la cuenta bancaria. No se trata necesariamente de aumentar los ingresos, pero sí de que mejoren factores como más tiempo, mayor tranquilidad, menor estrés y más reconocimiento por parte de la empresa.

La introducción del salario emocional en el mundo laboral obviamente tiene que ver con esa relación que establece la compañía con el empleado: este aporta sus conocimientos, experiencia y dedicación, por lo que la empresa le paga un salario y le da unos beneficios. Es un intercambio de habilidades y capacidades. Pero el mundo de los negocios es cada vez más competitivo y retener el talento humano se ha convertido en toda una ciencia de la seducción: hay que hacer que la empresa sea atractiva para que allí lleguen los mejores, y al llegar, que se queden por largo rato para que den lo mejor de ellos.

El tema de productividad es esencial. Las empresas invierten en sus empleados para que estos rindan lo que más puedan. Pero para que ello sea así, ellos deben poderse concentrar lo más posible en su trabajo. Sin embargo, junto a la agenda de reuniones, revisión de presupuesto, desarrollo de nuevos productos, conquista de nuevos mercados, la producción del día, los trabajadores también tienen pendiente pagar los recibos, resolver el problema de los medicamentos del abuelo, solucionar las tareas de los hijos, comprar los pasajes de las próximas vacaciones…

Tener estos pendientes en la cabeza hace que posiblemente el empleado esté en la oficina, pero no necesariamente concentrado en el trabajo y quizás llegue a la casa y en vez de estar atendiendo a sus hijos esté resolviendo problemas de la oficina.

Así, hoy día las empresas son conscientes de que para tener de cuerpo y mente presente a sus colaboradores es necesario conciliar la vida personal y laboral.

Ahí es donde entra a funcionar el salario emocional.

Según Catalina Guevara, líder de segmento salud y beneficios de la consultora Mercer, el salario emocional “es un componente dentro de la compensación total, que hace que los empleados tengan sentido de pertenencia a la compañía para la cual trabajan”.

Ese componente puede ser muy diverso, pero esencialmente representa un conjunto de facilidades, comodidades o ventajas que le mejoren su calidad de vida, “en estos tiempos en los que el ritmo de vida es muy acelerado y se cuenta con tiempo reducido para la vida personal”.

CAMBIO DE VIDA

Para Alberto García-Francos, de la empresa española Albenture, especialista en el tema de conciliar la vida personal y laboral, el mundo empresarial está llegando al salario emocional por los cambios culturales que se han vivido en las últimas décadas.

“Hay factores sociales que tienen que ver con la incursión de la mujer en la vida laboral y la necesidad de reorganizar las tareas del hogar. También el cambio de la pirámide demográfica, donde cada vez hay más personas adultas al cuidado de sus familiares, y eso demanda tiempo”, comenta García-Francos.

También incide el tamaño de las ciudades, donde los desplazamientos quitan tiempo tanto por las distancias como por el tráfico.

Así mismo, el mundo empresarial se ha hecho más competitivo y exigente, tanto para los negocios como para la supervivencia laboral de los empleados.

En este escenario, es frecuente que haya mayor demanda tanto de tiempo como de volumen de trabajo para los empleados, lo que implica descuidar la vida personal y familiar.

“La tendencia es a darle un nuevo enfoque a un problema viejo. La idea es implementar políticas de servicios, donde el empleado cuente con facilidades para resolver sus problemas personales (vueltas bancarias, jurídicas, domésticas), pero no dándoles el tiempo para que las hagan sino haciéndoles el trámite”, comenta García-Francos, cuya empresa se dedica a diseñar paquetes de servicios según las necesidades de las empresas.

Catalina Guevara, de Mercer, explica que el salario emocional también puede ser ofrecer flexibilidad de tiempo para trabajadores basados en la confianza y capacidad de autogerenciamiento (jornadas flexibles de trabajo, teletrabajo, algunos días libres al año), así como comodidades en el lugar de trabajo (salas de esparcimiento, cafetería), programas de bienestar (recreación, viajes, para ellos y sus familias) y otros servicios (mensajería).

Acciones que no requieren de altas inversiones

Los componentes del salario emocional cobran caca vez más importancia por varias razones, según Catalina Guevara, de la consultora Mercer. “Cada vez es más limitada la maniobra de retención y atracción del talento humano por la vía del aumento salarial, por estar atado a la inflación. Así mismo, por los controles de costos y los presupuestos restringidos”.

En este marco, las adecuaciones que introducen los componentes de un salario emocional resultan una oportunidad sin tener que hacer grandes inversiones.

“Son acciones que, sin grandes inversiones, ayudan a consolidar una cultura organizacional que propenda por la calidad de vida y del trabajo”, dice Guevara.

Todas estas medidas que se implementen pueden medirse en cuanto a la productividad. Un persona que tenga resuelto su día a día, baja los niveles de estrés, lo que implica menos problemas de salud, menor ausentismo e incapacidades.

Además, según García Palacios, de Albenture, en el tipo de servicios que ellos ofrecen, han podido establecer que por cada peso que invierte la empresa en una política de servicios para sus empleados, el retorno es entre 3 y 5 pesos. “Los servicios familiares llegan a ser sólo un 0,1 por ciento de la masa salarial”.

El impacto: menos estrés, más compromiso y productividad

Las medidas que se implementen en términos de salario emocional redundan en una mejor calidad de vida de los empleados y un mayor sentido de pertenencia.

Al implementar medidas que representen un salario emocional el impacto suele notarse, primero que todo, en el sentido de pertenencia.

“Crece el compromiso del empleado con sus responsabilidades y con la empresa”, comenta Catalina Guevara de la consultora Mercer. Y este compromiso lleva a una mayor productividad.

También es un hecho que bajan los niveles de estrés. Según Alberto García-Francos el estrés por recarga de trabajo, que impide asumir las tareas personales, por mal ambiente laboral, mala relación con el jefe o los compañeros, se refleja en problemas de salud y éstos en ausentismo. “Estos programas de servicios para los empleados, bajan la carga de estrés y, por ende, los ausentismos y enfermedades”.

Implementar estas prácticas no es fácil, pues implican un cambio cultural dentro de las organizaciones y además deben establecerse bajo unas políticas claras.

“Estas son prácticas recientes, que implica un cambio cultural y como todo cambio se deben tener muy claros los retornos de la inversión de este tipo de iniciativas y una lógica de negocio, para que no alteren la intención del negocio”, explica Guevara.

Así mismo, no aplican a todos los cargos y niveles, o se deben diseñar paquetes y programas de acuerdo a los grupos de edad e interés de las personas que laboran en la empresa, pues las expectativas de un joven profesional no son las mimas de quién se va a pensionar (ver tabla).

Para un profesional, especialmente si es mujer, el tema del manejo de los hijos pequeños cobra especial importancia, así como el cuidado de sus padres, mientras que alguien que empieza su vida laboral prefiere tiempo para estudiar y dedicarse a actividades deportivas.

Lo cierto es que actualmente, la conciliación de vida personal y laboral es cada vez más fuerte.

Por la calidad de vida

Las posibilidades de los servicios pueden ser muchas y muy variadas. Albenture tiene experiencia en ofrecer paquetes a las empresas y estas a los empleados, quienes pueden disponer de los servicios en cualquier momento.

- Mensajería: contar con alguien que le ayude con vueltas domésticas.

- Asesoría legal, fiscal y financiera: acudir a especialistas que lo asesoren.

- ‘Coaching’: contar con un ‘coach’ en temas gerenciales.

- Servicio de consulta médica.

- Selección de personal para temas domésticos.

- Tener una oficina de banco en el lugar de trabajo.

- Negociaciones de créditos colectivos.

- Servicios de niñeras y conductores.