archivo

Archivos Mensuales: diciembre 2010

Una cita de Peter Drucker sobre el liderazgo que me parece muy interesante es la siguiente: “El liderazgo efectivo no se basa en hacer discursos o ser querido; el liderazgo se define por los resultados.”.

Es otra vertiente del liderazgo que resulta conveniente tener en cuenta y que es compatible con las otras dimensiones que hemos visto en artículos anteriores, que se pueden resumir en:

– Un líder es aquel al que los demás le siguen, más allá de la naturaleza de las tareas que tengan que realizar.
– Un líder es aquel al que los demás respetan independientemente de que no estén siempre de acuerdo con sus decisiones.
– Un líder es aquel que consigue hacer mejores a los que dependen de él.
– Un líder es aquel que crea nuevos líderes.

En este caso Peter Drucker enfoca el liderazgo a lo tangible, a los resultados. Indica que un líder no se construye con adornos o con palabrería (propia o ajena), sino que los resultados, en definitiva, los hechos, deben ser la base sobre la que se sustentan. Todo lo demás es tener como suelo una nube que cuando se evapore te dejará en caída libre.

Como curiosidad, os indico los términos de búsqueda que más visitas han traído a mi blog:

1.- orientacion al producto
2.- certificaciones personales
3.- mantenimiento adaptativo
4.- crisis del software
5.- cual es el objetivo de una empresa
6.- mantenimiento evolutivo
7.- redmine alfresco
8.- orientacion del producto
9.- manual redmine
10.- jummp
11.- analisis funcional software
12.- complejidad ciclomatica
13.- plan de sistemas de informacion
14.- orientación al producto
15.- redmine
16.- lcom4
17.- orientacion de producto
18.- plan de sistemas
19.- la crisis del software
20.- paso a produccion
21.- redmine manual
22.- alfresco redmine
23.- modelo de certificaciones personales
24.- entorno de preproducción
25.- manual de redmine

Sobre este asunto generalmente me he encontrado con opiniones que son totalmente distintas a las mías, por tanto comienzo este artículo comentando esto, para que el lector tenga en cuenta que al menos, en mi entorno, la mayoría piensa otra cosa.

Desde mi punto de vista, el equipo encargado del desarrollo de software en una organización debe trabajar con un mismo entorno: misma versión del sistema operativo, mismas versiones de navegadores, mismas versiones de máquinas virtuales Java (como es lógico cada tecnología tendrá sus propias características), mismas versiones de contenedores de servlets y/o servidores de aplicaciones, etc…, de esta forma reducimos considerablemente las incidencias en el desarrollo que sean dependientes de la plataformas o lo que es lo mismo, que una aplicación tenga comportamientos diferentes en función del entorno en el que se ejecuta.

Contra esto están los que piensan que cada desarrollador debe trabajar en el entorno en que se sienta más cómodo y que esas diferencias entre entornos se pueden corregir utilizando los entornos de preentrega de la organización en los que ya se unifican los desarrollos procedentes de diferentes entornos clientes.

Yo soy partidario de que los problemas cuanto antes se corrijan mejor y que cuanto más se espere, más esfuerzo requerirá arreglar posibles defectos.

La unificación de entornos de trabajo tampoco supone la solución definitiva ya que la prueba de fuego se encuentra en la implantación del producto en el cliente, que generalmente es muy dura (sobre todo en las primeras versiones), es decir, en muchos casos hay que hacer adaptaciones para que todo vaya bien en el cliente (también se puede minimizar los riesgos si es posible simular el entorno del cliente en los entornos preentrega de la organización).

La implantación de procedimientos dentro de un departamento de desarrollo de software produce beneficios y por tanto un retorno de la inversión.

El principal inconveniente que encuentra es la reticencia del personal a cumplirlos ya que en su mayoría piensan que toda esa burocracia es una pérdida de tiempo.

El primer error es pensar que se trata de burocracia o por lo menos en el sentido negativo en el que se suele entender ese término, obligarte a seguir una serie de pasos para realizar determinadas acciones no es burocracia, son procedimientos. Esto no quita que el diseño de los procedimientos deba ir acorde con las posibilidades que tiene el departamento, si se va más allá de lo que se puede abarcar, estamos ante una situación contraproducente (no se terminarán por seguir los procedimientos y además se producirá una reducción de la eficiencia).

No es necesario empezar a procedimentarlo todo de la noche a la mañana. Lo mejor es ir poco a poco, que el personal se vaya acostumbrando a esta otra forma de trabajar, más ordenada, que permite, por todos, una mayor control de las acciones que se realizan.

Los procedimientos irán acompañados de herramientas (o por lo menos es aconsejable). En mi organización los procedimientos internos del departamento de desarrollo y nuestra interacción con el resto de departamentos del área TIC se realizan básicamente con 5 herramientas:

– Un Service Desk como componente que integra todo el conjunto de incidencias y peticiones en producción.
– Redmine como sistema de gestión de proyectos: planificación de tareas e interfaz con el repositorio documental (en nuestro caso Alfresco, aunque perfectamente se podría haber utilizado la propia herramienta como gestor documental).
– Alfresco, como repositorio documental.
– Mantis para el reporte de incidencias en la fase de pruebas de la aplicación.
– Una software de agenda compartida, para la gestión de nuestras citas y reuniones.

Como comenté antes, no se trató de implantar un conjunto de procedimientos de la noche a la mañana, sino que se hizo paulatinamente, asimismo no todas las herramientas se implantaron a la vez, ni el grado de uso de las mismas fue intenso desde el primer momento. Ha sido el tiempo y también determinadas decisiones de los responsables de informática los que han consolidado los procedimientos y las herramientas.

No son las únicas herramientas que utilizamos en el departamento de desarrollo ya que la realización de determinados procesos, requieren de otras herramientas complementarias que nos aportan, además una serie de ventajas:

– Subversion: Como sistema de gestión de fuentes y sus versiones.
– Artifactory: Como repositorio de librerías dependientes.
– Hudson: Para la automatización del proceso de compilación, generación del desplegable e interacción con Sonar (tenemos previsto próximamente el uso de Hudson para realizar el despliegue completo de una aplicación).
Sonar: Para el análisis estático de código.
– Enterprise Architect: Diseño de modelos (requisitos, casos de uso, etc…) y de documentación a partir de los mismos.

Como he comentado antes, los procedimientos requieren herramientas y las herramientas procedimientos, los unos sin los otros no terminan por producir buenos resultados.

Los procedimientos deben estar por escrito y ser dados a conocer por quienes los tienen que cumplir y se debe hacer un seguimiento de su implantación, por lo menos hasta que se consiga que la organización asimile la nueva dinámica de funcionamiento.

¿Por dónde se empieza? Supongamos que ya tenemos definida una dinámica de trabajo en cuanto al propio proceso de codificación de software, si no es así, ese debe ser el inicio (es decir, habría que establecer un framework de desarrollo, la selección de un IDE, de un sistema de gestión de versiones, una herramienta de integración continua, etc…, unos entornos de preentrega, un sistema de atención interna de dudas, sugerencias, etc… en el proceso de desarrollo (así como la persistencia de aquellas que sean más interesantes, para permitir la consulta futura), etc…

A partir de ahí, el siguiente paso debe ser controlar hacia dónde se enfoca la dedicación de los empleados, lo que hace necesario la existencia de una herramienta de imputación horaria. Esta gestión de incurridos es fundamental si la función principal de tu organización es la prestación de servicios a terceros. En el caso de mi organización no tenemos ninguna herramienta de esas características porque somos principalmente clientes de los trabajos (lo que ha hecho que no sea algo prioritario).

A continuación se debe trabajar en la gestión de las entradas de incidencias y peticiones por parte de terceros, así como su planificación. De esta forma se consigue dar un orden al trabajo, saber qué esta haciendo cada cual en cada momento y poder planificar los recursos humanos en el tiempo, de manera que se reduzca el número de tiempos muertos y cada persona se utilice, en la medida que sea posible, en aquellos proyectos y actividades donde se pueda aprovechar de mejor manera su potencial.

Lo comentado en el párrafo anterior se puede hacer en paralelo, con la obligación de que cada reunión con un cliente tenga como resultado final un acta (siguiendo en la medida de lo posible un mismo formato y que se almacena de la misma forma para todos los proyectos), que además debe ser enviada a los mismos. Como podéis ver, estos procedimientos que no requieren gran esfuerzo implantarlos, producen beneficios innegables. Solo requiere pequeños cambios en algunas de las rutinas de los empleados (el desarrollo de software es mucho más que tener abierto Eclipse toda la jornada laboral).

Una vez llegado a este punto resulta recomendable integrar el sistema de imputación horaria con el sistema de planificación de proyectos para tener el tiempo real que se ha invertido en cada tarea.

Sabemos cuánto se ha presupuestado cada proyecto, cuánto se lleva invertido en cada uno y aproximadamente el grado de avance en los mismos. Con esas variables es posible conocer el estado de los costes de cada proyecto, algo fundamental para detectar desviaciones a tiempo y tomar medidas (de nada sirve detectar que hay problemas si no se toman decisiones al respecto).

¿Por dónde se sigue? A partir de aquí, entrarán en juego, las preferencias personales. En mi caso, yo potenciaría el establecimiento de una normativa documental en los desarrollos apoyada en una herramienta CASE. Los desarrolladores odian documentar, principalmente porque no se sabe documentar (duele, pero es la verdad) y porque no se tiene un procedimiento, técnica y mecánica para hacer que ese proceso “insufrible” sea menos doloroso, es decir, que haga que el proceso de documentación sea más eficiente y productivo. Si con documentación vas a tener problemas con el cliente de todas maneras, ya sabemos todos los problemas que se tiene cuando se carece de ella, donde al final el cliente meterá casi tantos goles por la escuadra como quiera, ya que él dispone de todas las cartas y tú de ninguna. Además, la documentación puede guiar el proceso de desarrollo, cuestión de acostumbrarse a trabajar con ella y además permite dar un acabado a los proyectos que puede dar lugar, en muchos casos, a marcar la diferencia entre un proveedor y otro.

¿No crees en los procedimientos? Prueba a implantar alguno, hazle un seguimiento y mide los resultados, lo mismo cambias de opinión.

¿De qué sirve tener en tu organización n personas que piensan igual? Esto la condena siempre a tener un solo punto de vista, lo cual ofrece poca capacidad de adaptación y esto en un mercado tan competitivo como el que existe es muy peligroso, sobre todo si recordamos la máxima de Einstein que dice que: “ningún problema puede ser resuelto desde el mismo nivel de conciencia que lo provocó”.

Pensar diferente es molesto ya que muestra a la dirección otro punto de vista, otra realidad, que aunque puedan ser conocidas, a veces no gusta que salgan a la luz. Pero también es necesario, en la diversidad está el crecimiento, si no se confronta una idea, una política, una agenda, una estrategia, ésta nace plana y el mundo real no es así.

Para que una organización funcione debe haber un orden, que exista diferentes formas de pensar no tiene por qué romperlo, es más, no debe, porque de ser así, nos encontramos con un barco en el cual cada uno rema en una dirección diferente y eso no lleva a ningún lado. Las ideas diferentes deben ser expuestas en cada contexto y a quien corresponda y éstos que tienen la responsabilidad de tomar decisiones, tomarlas, teniendo en cuenta todas las opiniones posibles y no descartando ninguna sin haberla analizado previamente.

Los éxitos del pasado nos generan una sonrisa hoy pero no llenan nuestros bolsillos, tal vez en su momento sí, pero ahora no. La vida profesional es una reválida continua, el futuro se construye desde lo que hacemos en el presente y el pasado solo habrá servido para construir unos cimientos que serán más o menos duraderos en función de lo que se haya invertido en los mismos.

El crédito no puede ser infinito y si realmente se quiere ser competitivo hay que ponerle un límite.

La competencia muerde, intenta ir más deprisa, intenta quitarte mercado, si ayer te sacaba diez pasos mañana intentará sacarte cien y si tu le sacabas veinte intentará que ahora solo sean dos, igualarte o superarte. La realidad es esta y cualquier otra cosa son dibujitos de Disney.

Uno de los grandes problemas de las organizaciones y que merma significativamente su productividad y en consecuencia los resultados es que predomina la gestión basada en cajas negras.

Como el mismo nombre indica, el gestor solo se preocupa de lo que solicita y de lo que recibe, sin preocuparle cómo se ha gestado y quién ha participado en ello, es decir, se tiene una serie de personas cuya función es realizar un determinado tipo de tareas (así, en genérico) y sin embargo no se conoce qué es lo que realmente hacen y cuál es su implicación, importándole al gestor solamente el resultado (y a veces ni siquiera eso).

En cierto modo puede ser lógica una gestión basada en cajas negras para cargos muy altos de una organización, sin embargo el problema aparece cuando este tipo de gestión se propaga hacia abajo llegando a los mandos intermedios o a mandos de menor nivel.

¿Por qué atenta esta gestión a la productividad? porque es una gestión de espaldas a los recursos humanos, una gestión de punto gordo, es decir, miro el resultado desde las alturas, pero no sé como se ha producido y si las cosas van bien es gracias a todos y si van mal es culpa de todos. Esto crea situaciones de gran injusticia, que provocan por un lado la fuga de talentos, ya que no se les terminará de valorar como se merecen y una pérdida de productividad de los mismos, mientras terminan por decidirse si se van o no o si finalmente por el motivo que sea terminan quedándose.