archivo

Archivos diarios: julio 15, 2010

Tener a clientes y usuarios contentos y satisfechos es un activo muy importante, ya que futuros clientes por regla general se van a fiar más de lo que le cuente alguien que ya ha trabajado contigo que todo el arsenal de habilidades del comercial de turno.

Tampoco se puede explotar y estar dando la lata a esos clientes o usuarios satisfechos cada vez que vayas a intentar vender un producto o un servicio a un tercero, pero sí de saber en qué situaciones es conveniente utilizar el recursos (a veces la propia habilidad comercial o necesidad del cliente hará que no sea necesario, en otros casos el poco convencimiento del posible cliente unido a un posible contrato no muy interesante, también podría hacer que no fuera recomendable).

También está ese siempre interesante boca a boca, ya que clientes distintos suelen coincidir en diferentes actos y suelen preguntarse entre sí por los productos que están desarrollando y por la opinión que tienen de tal o cual proveedor.

Una recomendación que hago es que las organizaciones revisen sus procesos y procedimientos cada cierto tiempo. No digo que se haga todos los años, pero sí cada cierto tiempo y que se haga el análisis desde una visión crítica, buscando siempre simplificar los mismos, porque tras su simplificación vendrá un incremento de su eficiencia.

Se debe buscar siempre mejorar, porque siempre se puede mejorar. En un mercado tan competitivo, la diferencia puede estar en ser más ágil y eficiente que los adversarios.

Agilidad y eficiencia se entiende como algo externo a la existencia de procesos y procedimientos y eso desde mi punto de vista es un error, ya que el fallo precisamente está en que no existan ya que se perdería el control, las referencias en la calidad de los servicios y los productos y la capacidad de medir y comparar, perdiendo objetividad y ganando en subjetividad.

Aunque es recomendable que un jefe valore con un algún detalle, aunque sea con un gracias, un trabajo bien hecho, no debe ser ese el eje en el que centrar nuestro bienestar en el trabajo.

Si nuestro bienestar se centra en el reconocimiento nos pone en una situación de debilidad, ya que dependemos de que alguien nos acaricie el lomo. Nuestro bienestar debe basarse en estar contentos con el trabajo que hacemos y en como contribuimos con ello a la entidad en la que trabajamos y a nuestro crecimiento como personas.

Palmaditas por el trabajo bien hecho, sí, pero no trabajar con el objetivo de recibir palmaditas.

En demasiadas ocasiones intentamos buscar soluciones sin analizar antes cuál es el problema, de esta forma encontrar la posible solución se convierte en casualidad.

Esto es aplicable también al desarrollo de software.

Como ya he tratado en artículos anteriores, hemos implantado Sonar en nuestra organización y aunque todavía tenemos que avanzar mucho (sobre todo en definir un conjunto de reglas a analizar que se adapte más a nuestra organización que las que te vienen por defecto, las cuales por otra parte tampoco están nada mal) las métricas que estamos obteniendo son muy interesantes, ya que además de poder analizar la evolución de la calidad del software conforme va evolucionando una aplicación, permite como es lógico estudiar cómo está la misma en un momento dado del tiempo.

Eso precisamente hemos hecho con una aplicación que estaba presentando problemas en su mantenimiento debido a síntomas evidentes de alto acoplamiento. Una revisión rápida de las métricas de Sonar nos mostraba clases con RFC mayor que 200 (incluso alguna con un valor mayor que 300), lo que quiere decir que la suma de los métodos de la clase más la invocación de métodos de clases distintas lleva a esos valores, lo que da una idea del acoplamiento existente y de las repercusiones que puede tener hacia fiera modificaciones en dichas clases y dependencias cíclicas entre paquetes. De esta forma podemos determinar de forma sencilla dónde puede encontrarse el centro del problema (existe un alto acoplamiento, con métricas que hacen evidente este problema), después tocará ver cuál es la solución más adecuada que puede pasar desde el rediseño de las clases problemáticas hasta la posibilidad de rehacer gran parte de la aplicación (dependerá también de estudiar cómo está construida y cuál es la solución más rentable de cara a reducir la deuda técnica y a facilitar la mantenibilidad de las aplicaciones).