archivo

Archivos Mensuales: febrero 2011

Acabo de terminar de leer “El beneficio”. Me ha parecido muy interesante las siguientes conclusiones:

– Cada persona es un mundo y que para poder obtener su mayor rendimiento hay que saber cómo conectar con cada uno de ellas.

– Una organización es una maquinaria compleja, que necesita que las diversas partes que la componen (departamentos) funcionen adecuadamente y de manera coordinada y así sucesivamente hasta que se llegue al nivel de las personas.

– Una buena o mala gestión por parte de la dirección de la organización y de los departamentos condicionan el funcionamiento general, más de lo que podamos pensar.

Libro muy interesante y que se lee muy fácil, por tanto, si tenéis la oportunidad os aconsejo su lectura.

Muchas veces, cuando las cosas van mal, cuando existen problemas, se tiende a ocultar la información hacia los superiores (o a dar información que no es cierta, que es todavía peor).

Eso es un gran error, puede que alguna vez resuelvas el marrón y nadie se entere, pero si no lo consigues (y no siempre podrás porque en muchas ocasiones no dependerá de ti) y el problema llega hacia arriba, te enfrentas a una situación mucho más difícil, ya que te reprocharán, y con razón, de por qué no has informado y además el problema probablemente haya engordado.

Dentro de tus funciones se encuentra la resolución de contingencias pero también está dentro de tus responsabilidades informar a tus superiores cuando detectes que un problema puede ir a más porque ellos no pueden ni deben encontrarse por sorpresa y sin margen de reacción con el problema sobre la mesa.

Se tiende a cargar de trabajo a las personas más productivas de una organización hasta que se supera el umbral que pueden soportar. Cuando esto se produce la única forma que tienen de sacar el trabajo adelante es invirtiendo más horas. Como también existe un límite para el sobreesfuerzo, llegará un momento donde no se pueda seguir obteniendo la misma calidad en los resultados y se incumplan los plazos.

Resultado: se tiene a personas cansadas y que empiezan a desmotivarse y que se preguntarán con cada vez más insistencia, ¿por qué me piden que esté en todos lados y no se le exige eso a otros?.

En eso caemos todos, cuando hay un problema siempre tendemos a asignárselo a quienes sabemos que lo va a sacar adelante de la mejor manera posible, pero si siempre son los mismos, tendríamos que plantearnos por qué el resto del equipo no funciona igual (o, al menos, parecido) y si es mejorable de alguna manera su contribución o hay que hacer sustituciones en el mismo.

Por otro lado, es necesario ser objetivos con aquellas personas que nos sacan las castañas del fuego una y otra vez, que se sienten parte del equipo y permitirles un desarrollo profesional acorde a todo lo que están aportando.

Critico a las organizaciones que ignoran a los empleados, que los trata como números, como meros instrumentos y todavía más a aquellas que además de lo anterior no basan el desarrollo profesional de sus empleados en sus méritos y sí en criterios subjetivos.

No sería justo que criticase esto y que no lo hiciera cuando es el empleado el que pone sus intereses individuales sobre los de su organización y en consecuencia también sobre sus compañeros. Podría haber una cierta justificación (aunque yo no la comparta) si la organización te tratase como he descrito en el primer párrafo y/o tus condiciones laborales fueran penosas.

Cuando en una organización los empleados van a su aire, no respetan a sus compañeros (respetar no consiste solo en tener un buen trato personal) es un síntoma de que las cosas van a empezar a ir mal o ya lo están. Si no se corta el problema de raíz, todo tenderá a empeorar, ya que los individualismos serán cada vez más acusados y terminarán desmotivando a cada vez un mayor número de empleados que entienden el trabajo de manera distinta, en el que efectivamente pueden ir desarrollándose y cumpliendo objetivos individuales pero entendiendo y respetando que es posible hacerlo en sintonía con los objetivos de la organización.

Si te olvidas del cliente no esperes que él se acuerde de ti. La vida suele funcionar así, tanto das, tanto recibes. Si desarrollas productos o prestas servicios de mala calidad, pensando siempre en la cuenta de resultados, tendrás pan hoy (con mucho sufrimiento, ya que el proyecto será fuente de problemas continuos con el cliente) pero lo más probable es que mañana solo te queden migajas o el recuerdo de esos días de vino y rosas.

Las empresas viven de sus clientes por lo que si no los cuidas te quedas sin combustible, sin capacidad económica para sobrevivir y los castillos vuelven a convertirse en arena. No se puede pensar en hacer rentables los proyectos a costa del cliente, si existen problemas de productividad, de metodología, de gestión o cualquiera de las decenas que puede haber en una organización y que afectan directamente al resultado de los trabajos y al esfuerzo que se emplean en ellos, no se deben repercutir sobre quien te ha contratado un producto o un servicio, sino que si la culpa es tuya, tienes que asumirla y preocuparte por mejorar o arreglar lo que no funciona.

Se dice que más vale tarde que nunca y estoy totalmente de acuerdo. Lo que pasa es que en muchas ocasiones se llega demasiado tarde y cuando esto sucede, las soluciones que se intentan aplicar, incluso siendo óptimas, lo mismo no consiguen darle la vuelta al problema que se intenta resolver.

A veces se llega tarde sin darnos cuenta, los problemas del día a día nos impiden ver que paso a paso nos vamos a una situación de difícil vuelta a atrás. El hecho de que no nos demos cuenta no nos exime de responsabilidad porque deberíamos haber dado en más de un momento un paso atrás, tomar perspectiva de cómo nos va todo, detectar los problemas e intentar ponerle soluciones.

Otras veces se llega tarde porque simplemente nos hemos dejado ir, pensando que una fuerza mágica nos va a resolver los problemas. Es curioso, pero a veces funciona, pero menos, mucho menos de lo que se piensa. Los problemas se resuelven a través del trabajo e intentando aplicar soluciones, cualquier otra cosa es casualidad y no creo que sea lo mejor dejar que aspectos importantes queden en manos del aire.

Nos esforzaremos, seremos metódicos y a veces seguiremos llegando tarde, no se trata de ser infalibles sino de ser conscientes de que podemos reducir las veces que ocurren estas contingencias, que está en nuestra mano y que si nos dejamos ir o esperamos que sean otros los que resuelvan nuestros problemas, probablemente se incrementará el número de veces que llegaremos tarde o lo que es todavía peor, que no lleguemos.

Si se actúa con previsión, si se levanta la vista del suelo, es posible que la mayor parte de posibles problemas que puedan existir en una organización, en un departamento o en un proyecto, puedan ser atajados a tiempo o como mínimo ver minimizados su impacto.

Sin embargo, el miedo a tomar decisiones, un mal análisis de la situación presente y una mala previsión de la futura, una mala elección de prioridades, el inmovilismo, el hacer oídos sordos a quien conoce de primera mano un problema, son responsables de que un problema termine por materializarse y lo que es peor, que termine por explotar y tenga un impacto importante.

Partiendo de la base de que proyectos donde el usuario pasa de ti están abocados, salvo contadas ocasiones, al fracaso y que esa es una de las peores situaciones posibles, existe otro tipo de proyectos que resultan complicados de gestionar y son aquellos donde el usuario o usuarios principales creen que saben sobre desarrollo de software.

No es un problema que el usuario sepa de desarrollo de software, antes al contrario, si sabe, probablemente entienda muchas de las contingencias que se producen en el proceso de desarrollo y será consciente de que su participación en todo el ciclo de vida del proyecto resulta esencial para intentar conseguir un producto acorde a sus necesidades. También es cierto que este tipo de usuarios será por regla general bastante exigente y tendrán base suficiente para evaluar si por tu parte como director técnico y/o por el equipo de desarrolladores se está manejando bien el proyecto y si se está dedicando la suficiente atención. Por mi parte no veo mal esa exigencia siempre y cuando se base en unos criterios objetivos y justos.

El problema está cuando el usuario cree que sabe, pero en realidad no tiene ni idea o tiene una idea demasiado superficial, cuando esto sucede te pondrán en demasiadas ocasiones en tela de juicio decisiones que hayas tomado relacionados con la gestión o del proyecto o incluso en algunos aspectos técnicos como el diseño físico de datos (de esto último he tenido experiencia directa con usuarios que han trabajado con bases de datos ofimáticas y modelos de datos desnormalizados o incluso las hayan construido y mantenido), esto en sí no sería perjudicial si realmente las opiniones del usuario estuvieran basadas en un conocimiento del proceso de desarrollo de software y sus técnicas, es más sería beneficioso porque nadie es infalible y se pueden cometer errores y cuanto antes se detecten estos mejor. Estos usuarios pensarán (es una generalización) que todo es más fácil de lo que parece, que las incidencias en el proceso de desarrollo son excusas y compararán continuamente el sistema que se desarrolla con aquel o aquellos que conoce, aunque no tengan absolutamente nada que ver.

Cuando se contrata un proyecto de desarrollo de software no sólo es suficiente con entregar un producto que funcione y en plazo, sino que la realidad es algo más complicada que eso, por ese motivo es muy importante identificar los deseos, expectativas y objetivos que tiene el cliente respecto al proceso de desarrollo del proyecto que se ha contratado, así como del resultado final que se obtenga del mismo.

Es cierto que es muy importante que funcione y que esté en plazo, pero también hay otros aspectos que son evaluables como por ejemplo la calidad del código, de la documentación, el seguimiento de estándares de desarrollo de la organización, la usabilidad, el rendimiento, cómo se han ido solucionando los diferentes problemas que se han producido durante el proceso del desarrollo, cómo ha sido el trato con el director técnico del cliente y/o con los usuarios, etc, etc…

Mantener una relación duradera con un cliente implica no sólo hacer las cosas bien, sino además llegar a conocerle. Esto no es sencillo, requiere tiempo y sobre todo tener conciencia de la importancia que tiene esto, a lo que hay que sumar que cada persona o cada cliente es un auténtico mundo y que para lo que uno es algo excepcional, para otro puede ser algo realmente pésimo.

No intentar entender lo que el cliente quiere o quedarse sólo con lo que interesa es ir a ciegas en un proyecto, ya que lo mismo se piensa que se están haciendo las cosas bien, cuando lo mismo se está yendo en la dirección opuesta a lo que se quiere.

Un cliente no es un objeto inmóvil y si algo no le gusta lo terminará diciendo, no obstante y como cada uno es diferente, lo podrá decir de diferentes formas y en diferentes fases del proyecto. Si no se detecta a tiempo que el camino no es el correcto, el proyecto correrá un riesgo importante de que fracase o se vaya en costes e incluso si el proyecto no fracasa, lo mismo sí se ha fracasado con el cliente.

Muchas veces la puesta en marcha de un nuevo sistema de información se ve afectada por la existencia de una solución previa basada en recursos ofimáticos.

El problema es que los usuarios tardan en comprender (y otros ni siquiera intentan hacer el esfuerzo) las ventajas de tener una aplicación con un modelo de datos normalizado por detrás. Generalmente se suelen decir cosas como esta: “Esto lo hacía antes en diez segundos y ahora tengo que entrar en tres pantallas…”.

Y es que competir en “velocidad de hacer las cosas” contra una base de datos ofimática que tiene todo en una tabla es imposible.

Los usuarios tendrán recelos ante el nuevo sistema y también lo tendrán aunque estén utilizando previamente otra aplicación y la hayan puesto a parir, ¿cómo convencerles? con hechos, ofreciéndoles un sistema en el que se encuentren cómodos, con alta disponibilidad y que les permita extraer la información que necesitan en el momento que precisen. Para eso se necesita tiempo, recursos y que los usuarios se sientan partícipes y ayuden a definir sus necesidades en el mantenimiento del sistema de información.