archivo

Archivos Mensuales: enero 2010

La empatía es una gran virtud para toda aquella persona que la desarrolle. Todas las personas tenemos de forma innata capacidades empáticas en distinto grado y que con la suficiente preparación y experiencia pueden utilizarlas en los distintos ámbitos de su vida.

En el ámbito laboral y si nos centramos en el negocio de las TICs, pueden existir en una organización excelentes profesionales en el ámbito técnico y un conjunto de personas tremendamente comprometidas con su trabajo, sin embargo y desde mi punto de vista, la combinación perfecta de perfiles humanos se consigue cuando se logra integrar en el grupo a personas que tienen desarrollada la capacidad de la empatía. No son condición ni suficiente ni necesaria para que una organización o un departamento funcionen bien o tengan éxito, pero integrándolas con los perfiles necesarios la maquinaria estará muchísimo mejor engrasada y, por tanto, preparada para conseguir mejores resultados.

Existe una gran cantidad de bibliografía que trata el tema de la empatía, yo os voy a dar una definición que, como es lógico, se encuentra influida por lo que he leído sobre esta temática. La empatía es, a grandes rasgos, la capacidad para poder ver y sentir las cosas desde la perspectiva de otra persona. Las personas que tienen desarrollada esta capacidad tienen la cualidad de entender mejor el entorno que les rodea, de conocer realmente cómo se sienten las personas con las que de una u otra forma colaboran contigo y de esa forma poder dar una respuesta más personalizada a sus necesidades, ya que es como si esas sensaciones las tuviera uno mismo.

La empatía no es leer los pensamientos, sino leer a las personas y no se trata de ningún tipo de magia, es una cualidad real, ¿a cuántas personas conocemos cada uno de nosotros que podemos saber cómo se encuentran sólo con mirarlas a los ojos?, pues bien, eso es empatía y como he dicho existen distintos grados que amplían su alcance tanto verticalmente, es decir, la cantidad de información que eres capaz de percibir de la otra persona a través de una mirada, de sus gestos, del tono de su voz, de sus palabras, como horizontalmente, es decir, la cantidad de personas con las que es posible obtener este tipo de información.

Insisto, la empatía es una cualidad inherente a las personas, no es cuestión ni de magos, mentalistas o gurús, es algo que tenemos todos (como he dicho antes, cualquiera puede tener este tipo de capacidad, otra cosa bien distinta es cuanta viene ya de serie con el modelo y hasta donde es posible desarrollarla) y que por tanto puede ocupar cualquier perfil dentro de tu organización. No obstante, existen algunos tipos de perfiles dentro, por ejemplo, de una empresa de desarrollo de software que sí que resulta conveniente que tengan desarrolladas las capacidades de empatía, como por ejemplo las personas que tratan con clientes (tanto técnicos como comerciales) y las personas que gestionan recursos humanos (responsables de recursos humanos, jefes de proyecto, jefes de equipo, etc…).

La empatía es algo que se puede trabajar y por tanto mejorar y ayuda mucho la experiencia personal y profesional que tenga cada uno de nosotros, porque cuanto más grande sea, más posibilidades existirán de entender, comprender y asimilar las diversas situaciones desde el punto de vista de otra persona.

Curiosamente, una de las tareas que debería ser de las más simples en el proceso de desarrollo de software se convierte en un autentico muro en muchos proyectos, tan alto que, en ocasiones, superarlo lleva muchísimo tiempo y en consecuencia esfuerzo y dinero.

¿Por qué debería ser simple? El trabajo duro de obtener los requisitos, realizar el resto del análisis, el diseño y la construcción ya está hecho, por lo que sólo quedaría el proceso final de revisión del producto y la instalación en los servidores del cliente.

Sin embargo, algo que teóricamente debería ser ejecutado de manera sencilla no lo es en la práctica por una serie de factores, algunos de los cuales paso a enumerar (en un proyecto concreto puede que no se de ninguno, uno, una combinación de ellos u otros que provoquen que el paso a producción sea una tarea compleja):

1) Miedo al cambio: Si el cliente no termina de ver clara la sustitución de la aplicación que venía utilizando por otra nueva o bien la informatización de un proceso de negocio que hasta ahora no lo estaba, pondrá muchas trabas a que el producto se ponga en producción, ya que una vez que pase dicha barrera, la posibilidad de que puedan evitar su utilización se reducirá considerablemente, ya que se ha realizado una inversión que será necesario amortizarla de alguna manera.

2) Miedo al resultado: Si el cliente tiene dudas sobre el producto (ya sea por culpa suya, del desarrollador o de ambos) y además tiene responsabilidad sobre el resultado final del mismo, tratará de retrasar el paso a producción hasta que tenga una mayor seguridad de que el producto responderá a las expectativas existentes. Como puede darse el caso de que modificar el producto, puede provocar prácticamente rehacerlo, este factor puede convertirse en una de las principales fuentes de problemas con el cliente que querrá hacer en la mayoría de los casos nuevas versiones sin rascarse el bolsillo.

3) Desinterés por el producto: Si el producto no ha sido solicitado por el usuario final que lo va a utilizar, su participación en el proyecto ha sido nula y el proceso de negocio lo tiene resuelto con las herramientas que viniera utilizando hasta ahora, puede dar lugar a circunstancias de miedo al cambio o simplemente de falta de interés en que el producto termine por implantarse, lo que dará lugar a que el producto no se revise, tarde en revisarse o se pongan impedimentos para su puesta en marcha. Otra variante del desinterés es el denominado “se me pasó el arroz”: en ocasiones, los retrasos en el proyecto son tales, que un producto que resultaba interesante, importante o fundamental en un momento dado, más tarde ya no lo es, ya sea porque las prioridades han variado, se han buscado soluciones alternativas o el equipo de personas que mostró interés en su momento o que han participado en su desarrollo ya no están.

4) Búsqueda de la perfección: Nada es perfecto y un producto software tampoco lo es y por más vueltas que se le dé nunca será perfecto, por tanto, si se trata de que el producto pase a producción con un grado de cumplimiento funcional, calidad, seguridad, etc… que se aproxime al 10, no lo conseguirá, producirá retrasos importantes que vendrán acompañados de costes (generalmente para el proveedor) y será una fuente de innumerables conflictos.

5) Mala ejecución de los trabajos: Una cosa es conseguir la perfección y otra permitir que el producto que se pase a producción sea deficiente, por tanto, si el producto no cumple unos mínimos exigibles no pasará el listón del paso a producción y deberán tomarse las medidas correspondientes para que el mismo mejore. Como es lógico, habrá que evaluar las causas que han dado lugar a que la aplicación no haya alcanzado el nivel exigible y en función de las mismas actuar en consecuencia.

6) Entornos de desarrollo distintos a los entornos de prueba y producción: La instalación se puede complicar cuanto mayor sea la divergencia entre los entornos de desarrollo utilizados y los entornos de prueba, preproducción y producción del cliente y mayor sea la complejidad tecnológica de la aplicación y mayor uso de componentes distribuidos tenga. El proceso de instalación puede ser una auténtica pesadilla y requerir un esfuerzo muy importante, con importantes retrasos en la puesta en producción. Para mejorar estos tiempos es conveniente, como es lógico adaptar lo máximo posible el entorno de desarrollo al que tenga el cliente y tener muy bien documentado las características físicas, lógicas y de arquitectura de los mismos, así como los principales problemas que han surgido en las instalaciones y cómo se han arreglado (esto que puede suponer un esfuerzo extra lo agraderán en un futuro tus compañeros y tú, por lo que te recomiendo que documentes y que pongas esa documentación accesible a tus compañeros).

Si se cae en un trabajo monótono, repetitivo o sencillo la influencia sobre la productividad es importante y el motivo principal es la pérdida de atención en las tareas al disminuir el nivel de concentración sobre el que se realizan.

Por este motivo resulta conveniente plantear retos a los empleados, cuando éstos ya hayan consolidado un determinado tipo de trabajo. Es conveniente que estos retos no se sitúen diez escalones por encima de lo que el trabajador en estos momentos es capaz de asumir, tanto en dificultad como en cantidad, ya que pueden generarle al mismo un nivel de ansiedad e incluso de frustración si no consigue llevarlo a cabo, que produzca un efecto contrario al que se persigue. Es decir, un reto que suponga una actividad diferente e incluso más complicada (adaptando esa complejidad, como he comentado a lo que el trabajador puede dar de sí en estos momentos), permitirá incrementar el nivel de satisfacción y de concentración del trabajador.

Estos retos pueden ser complementarios al trabajo que se está realizando (colaborar en otros proyectos con temática o tecnología diferente o más avanzada, ayudar en la redacción de ofertas o propuestas de colaborar, en la selección de concursos a participar, intervenir en actividades de I+D, consultarle opiniones sobre el funcionamiento de determinados proyectos, permitirle un mayor grado de decisión y flexibilidad sobre los trabajos que está realizando, etc, etc…) o bien suponer una nueva actividad para el mismo.

Es tarea de los gestores de equipos de proyecto, detectar cuando un trabajador necesita un cambio que le suponga nuevos retos y le ayude a sentirse identificado con sus tareas y debidamente motivado. La simple detección no es suficiente, ya que si el el empleado se encuentra en medio de un proyecto, no es trivial sacarlo del mismo o incluso asignarle tareas complementarias, por lo que requiere una planificación realista (que no le provoque falsas expectativas) y que sea conocida por el trabajador.

Si el empleado tiene suficiente confianza con el responsable del proyecto (para ello el responsable ha debido ganarse previamente la confianza de las personas con las que trabaja) también puede tranmitirle las sensaciones que tiene y su deseo de asumir nuevos retos. Comento esto, porque los gestores de proyecto no siempre van a detectar (queriendo o sin querer) las necesidades de su equipo y si pasado un tiempo el gestor no toma la iniciativa bien porque no se ha dado cuenta o porque le resultaba más cómodo mantener el status quo, hay que hablar e indicarle que cuando las circunstancias así lo permitan se está dispuesto a asumir nuevas o diferentes responsabilidades que permitan avanzar en su desarrollo profesional y eliminar sensaciones de estancamiento. Si el gestor valora al empleado y entiende la situación del mismo, tomará las medidas oportunar para que con la planificación necesaria (sea a corto, medio o largo plazo, en función de las posibilidades del proyecto y/o de la organización) se modifique su situación e incluso le permita adoptar alguna solución parcial.

Si se quiere implantar una política en una determinada organización se considerará que ha tenido éxito cuando se convierta su cumplimiento en un hábito por parte de los integrantes de la misma, ya que de esta forma se tiene la seguridad de que se llevará a cabo y se verá como una tarea mecánica más y no como ese incordio que ha sido impuesto, del que me tengo que acordar para hacerlo y que me supone una pérdida de tiempo.

La implantación de una política no es tarea sencilla y menos en el mundo del desarrollo de software, donde todos somos (me incluyo) un tanto anárquicos.

Para que una política termine por implantarse es necesario que cuente con el apoyo de los niveles más altos del departamento afectado o incluso de la organización si se trata de una política de carácter horizontal, ese apoyo no debe ser sólo testimonial, sino que necesariamente se tienen que involucrar (el que algo quiere, algo le cuesta), realizar un seguimiento del proceso de implantación y pedir responsabilidades en el caso de que no progrese la implantación de la politica.

Pero no es suficiente con eso (aunque sí necesario) para que la implantación de una política se lleve a cabo con éxito, también es necesario que se realice un correcto proceso de gestión del cambio en el que resulta fundamental la explicación al personal implicado de por qué se ha decidido adoptar la política y que repercusiones negativas tendría para el departamento u organización la no aplicación de la misma y que beneficios se obtiene por ello. Seguro que si el personal entiende mejor por qué se aplica una política tenderá a asumirla antes.

Y como en todos los casos, se requiere tiempo para que sea asimilada (unos la asimilan antes, otros después) y más para que se convierta en un hábito, en el momento en que se consiga esto último se podrá considerar que la implantación de la política ha sido un éxito.

Hace tiempo, leí en el blog Marketing y Innovación, un artículo buenísimo denominado “Las experiencias de cliente no deben ser buenas, también deben parecerlo”. Os recomiendo que le echéis un vistazo porque contiene una recopilación de buenas prácticas en lo que a la relación con clientes se refiere.

Si el producto final es bueno o malo, muy probablemente tendrá consecuencias en la futura relación entre el cliente y el proveedor, por lo que es fundamental que el producto final tenga la mayor calidad posible, soy muy insistente en este asunto, hay que procurar siempre, que el resultado final dentro de los medios que se han tenido en el proyecto y de las circunstancias en que haya discurrido sea el mejor que se haya podido obtener. No obstante, hay otros factores que pueden paliar la entrega de un producto no tan bueno o perjudicar la entrega de uno excelente. Algunos de esos factores están explicados en el artículo al que he hecho referencia anteriormente y se puede resumir en que en muchos casos la visión que tiene el cliente sobre el trabajo realizado es cuestión de sabores.

Si el producto resultante es satisfactorio: funcionalmente y en calidad, se tendrá, como decía, mucho ganado, pero en las relaciones con los clientes, el fin no justifica los medios y si para la obtención de ese producto resultante, han existido desviaciones presupuestarias, de tiempo, etc… que han llevado a tiras y aflojas constantes durante el desarrollo, el éxito no lo será tanto, sobre todo si éstas se concentran al final, ya que se mezclará el dulce de una buena terminación, con el amargo de todo lo que ha costado llegar a buen término.

Lo importante en estos casos para el proveedor hubiera sido gestionar adecuadamente las crisis, para que estas hubieran durado lo menos posible y se hubieran alejado lo máximo posible del final del proyecto, así como haber sabido rentabilizar y manejar los diferentes buenos momentos. Es muy difícil que un desarrollo de software vaya como la seda todo el tiempo, siempre hay factores internos y externos que afectan en su funcionamiento y que tienen consecuencias en la relación con el cliente. Gestionar adecuadamente estas contingencias, teniendo en cuenta que cada cliente es un universo distinto, permitirán que el plato resultante tenga el mejor sabor posible, no es fácil, nada fácil, pero es en este tipo de aspectos donde un gestor o jefe de proyectos puede marcar la diferencia.

Este es el tercer artículo que publico con la evolución en el uso de navegadores y sistemas operativos en dos sitios web españoles dirigidos al público general, que tienen un importante número de visitas como para que los resultados obtenidos con las métricas de Google Analytics sean lo suficientemente representativos.

El primer artículo fue publicado el 12 de enero de 2009 y contiene los datos entre el 30/06/2008 y el 31/12/2008. El segundo artículo fue publicado el 22 de julio de 2009 y contiene los datos entre el 01/01/2009 y el 30/06/2009.

En este artículo, se muestran los resultados recogidos entre el 30/06/2009 y el 31/12/2009 y se comparan con los resultados informados en los dos artículos anteriores (aparecen entre paréntesis, en orden cronológico de más reciente a menos reciente).

Como conclusiones más significativas, señalar las siguientes:

1) La trayectoria descendente en el uso de Internet Explorer es continua y se situa entre los dos y cuatro puntos al semestre. Es cierto que el dominio sigue siendo aplastante, pero también lo es que de seguir así, será cuestión de tiempo que el liderazgo no tenga la magnitud que tiene ahora.
2) La pérdida de cuota de Internet Explorer se la han repartido el resto de navegadores. A destacar el importante crecimiento de Chrome, ya que dobla prácticamente la cuota, lo cual es relavante, pese a tener todavía un porcentaje de uso testimonial. También es importante señalar el estancamiento de Opera.
3) En cuanto a los sistemas operativos, el dominio de los sistemas operativos de la familia Windows resulta abrumador. Es cierto que cada semestre pierde algo de cuota, pero es muy poco en relación a la que ya tienen. Casi todo lo que pierde Windows, se lo quedan los sistemas operativos de la familia Mac.

Sitio web 1:

Navegadores.

– Internet Explorer: 73’83% (77′27%) (81′81%)
– Firefox: 21’06% (19′40%) (16′16%)
– Chrome: 2’93% (1′50%) (0′48%)
– Safari: 1,45% (1′13%) (0′87%)
– Opera: 0’44% (0′44%) (0′41%)

Sistema Operativo.

– Windows: 96’57% (96′94%) (97′52%)
– Macintosh: 1’83% (1′65%) (1′37%)
– Linux: 1’29% (1′22%) (1′02%)

Combinación Navegador + Sistema Operativo.

– Internet Explorer + Windows: 73’83% (77′27%) (81′80%)
– Firefox + Windows: 19’19% (17′61%) (14′69%)
– Chrome + Windows: 2’91% (1′50%)
– Firefox + Linux: 1’12% (1′06%) (0′84%)
– Safari + Macintosh: 1’07% (0′92%) (0′72%)

Sitio web 2:

Navegadores.

– Internet Explorer: 69’06% (72′08%) (74′71%)
– Firefox: 24’27% (23′7%) (22′47%)
– Chrome: 3’43% (1′69%) (0′71%)
– Safari: 2’22% (1′73%) (1′45%)
– Opera: 0’67% (0′54%) (0′43%)

Sistema Operativo.

– Windows: 94’93% (95′58%) (96′3%)
– Macintosh: 2’91% (2′46%) (2′19%)
– Linux: 1’68% (1′66%) (1′34%)

Combinación Navegador + Sistema Operativo.

– Internet Explorer + Windows: 69’06% (72′07%) (74′7%)
– Firefox + Windows: 21’62% (21′12%) (20′24%)
– Chrome + Windows: 3’4% (1′69%)
– Safari + Macintosh: 1’73% (1′43%) (1′22%)
– Firefox + Linux: 1’47% (1′55%) (1′23%)

Trabajar con autonomía significa haberse ganado la suficiente confianza para que te permitan realizar determinadas tareas de esta manera. Como todos sabemos y como ya he comentado alguna vez en este blog, que la confianza es algo que tarda bastante en construirse y que puede tardar un suspiro en perderse (los seres humanos, tal vez, somos así de injustos). Por tanto, trabajar con autonomía desde mi punto de vista es algo que hay que ganárselo y que para mantener o incluso incrementar ese estatus hay que mantener un posición de responsabilidad y producir buenos resultados.

Dar autonomía a determinadas personas que tienes a tu cargo, significa dar margen para que puedan desarrollar el trabajo que tengan encomendado y para tomar decisiones dentro del dominio de tareas que tienen asignadas. Esta autonomía, permitirá que estas personas ganen en autoconfianza, motivación y en creatividad (entendiéndose creatividad en este caso como la capacidad de encontrar un mayor abanico de soluciones y alternativas antes los distintos problemas que puedan ir surgiendo) y por lo tanto produzcan mejores resultados, ya que supone un mayor reto personal y al fin y al cabo son los retos lo que nos hacen evolucionar. Dicha mejora no sólo es consecuencia de la motivación (que tiene que ver y muchísimo), sino porque probablemente estas personas son capaces de manejar mejor el día a día de sus tareas porque están más familiarizadas con ellas que otra persona que esté más alejada de ese ámbito de actuación.

Dar autonomía no significa dar carta blanca o por lo menos yo no lo veo así, ya que la responsabilidad final del resultado del trabajo, sea bueno o sea malo es de quién asigna la tarea (no hay que olvidar nunca esto) y también porque es necesario dar coherencia a lo que se hace, poniéndose en contexto con otros trabajos que se estén realizando dentro del Departamento o de la Organización. Todo esto implica que sea necesario que aunque se dote de autonomía a una persona o a un equipo, se establezcan líneas de comunicación de carácter vertical y horizontal para permitir el seguimiento de los trabajos. Sin comunicación, el riesgo de que la autonomía derive en problemas y que se convierta en un elemento aislado, aumenta considerablemente.

La autonomía es necesario modularla en función del tipo de tarea, de los conocimientos y experiencias que posea el trabajador y de la confianza que haya sabido ganarse. Un autonomía mal asignada o mal modulada puede traer consecuencias muy negativas (de la misma forma que si la asignación se realiza correctamente podrá permitir la consecución de importantes beneficios, no solo para el proyecto, sino también para el trabajador, que permitirá estar más motivado y realizado).

Soy una persona que le gusta mantener sus trabajos dentro del mayor control que me permite mi capacidad y las características de cada uno de los proyectos en los que participo y siempre me ha costado dotar de la suficiente autonomía a las personas que trabajan conmigo. Afortunadamente, me he dado cuenta de que realizar un seguimiento de los trabajos u orientar sobre cómo se deben hacer determinadas tareas o corregir situaciones cuando entiendo que se están cometiendo errores es compatible con dotar de autonomía. Para mi ha supuesto un cambio en la filosofía de trabajo y como todos los cambios, me ha costado interiorizarlo y se han producido errores (y se seguirán produciendo), pero en cualquier caso, es algo que desde mi punto de vista y desde mi experiencia personal, conviene, como mínimo, probar.