¿Colaboración o control?. El software social en la empresa

Feng Office ha sido un descubrimiento interesante, una herramienta simple para gestionar la lista personal de tareas y coodinar equipos de trabajo. Una vez instalada la herramienta y después de su testeo, tocaba extender el uso de la misma en la empresa.

Cuando comenzó la búsqueda, teníamos una demanda, por parte de los responsables de áreas de la empresa, de herramientas de gestión de proyectos. Claro, cuando alguien dice herramienta para gestonar proyectos, inmediatamente se le viene a la cabeza Microsoft Project, y si encima quieren un toque colaborativo para compartir las planificaciones en línea, viene Project Server, que en términos económicos es un gasto brutal.

No es mi intención hablar mal de MS Project, creo que es una herramienta muy potente y completa, si bien es cara, además de ser software propietario. En nuestro caso, una instalación de MS Project no era matar moscas a cañonazos, más bien era matar moscas con bombas termonucleares... La gestión con MS Project es muy exhaustiva: costes, recursos humanos y dedicaciones, asignación de personas en base a un pool de recursos, replanificaciones, etc, algo que por desgracia no se hace en mi empresa, donde la gestión de proyectos está bastante simplificada. En definitiva, que para pintar un diagrama de Gantt con unas tareas vistas desde muy alto nivel (por ejemplo con tareas del tipo "hacer una web" sin bajar a más detalle), hacía que MS Project fuese algo inabordable.

Para pintar diagramas de Gantt existen herramientas, como OpenProj, que de forma gratuita permiten la realización de planificaciones y la generación de diagramas de Gantt. Ojalá llegue el día en el que la gente aplique una gestión real de los proyectos, revise el Gantt con cierta periodicidad y registre los retrasos y replanificaciones. Cuando llega el cierre de un proyecto, el calendario real y el planificado al inicio son como la noche y el día, pero no hay constancia por ningún lado de las causas que llevaron a ese cambio tan radical.

Ni mucho menos soy el responsable de calidad de la empresa, pero sí que es cierto que, en aspectos relacionados con herramientas de gestión, colaboro con él en la búsqueda y análisis de herramientas, ya que ese aspecto sí que es competencia del área de sistemas en la que yo me encuentro.

El caso es que tras un acalorado debate en los que los partidarios de MS Project intentaban justificar lo injustificable incluso amenazando con usar la versión gratuita de MS Project independientemente de la herramienta que se instaurase como oficial, logramos que nuestros mayores descartasen la idea de la solución de Microsoft y apoyasen nuestra idea de simplificar el modelo y usar una herramienta en software libre.

Tras un análisis de la actividad de la empresa y la gestión de los proyectos, logramos distinguir dos aspectos bien diferenciados dentro de la gestión: 

• Por un lado, todo proyecto necesita de una planificación y un seguimiento de ésta que normalmente se realiza a alto nivel y con unos paquetes de trabajo sin demasiado nivel de detalle. Esta planificación y su seguimiento suele usarse como reporte con el cliente y para la gestión global por parte del responsable del proyecto, pero que sin embargo apenas es usada por los miembros de un equipo de proyecto.
• Por otro lado, los jefes de proyecto asignan tareas (pequeños paquetes de trabajo) a los miembros de un equipo, tareas que se caracterizan por ser concretas y con unos plazos bien determinados. La consecución de estas tareas puede originar la compleción de un paquete de trabajo de mayor magnitud.

Es decir, que había un aspecto importante al que no se le estaba dando cobertura, a la relación entre los miembros de un equipo de trabajo, y claro, cada equipo se gestionaba las tareas como podía: con post-its, con correos, sin nada, con un cuaderno, etc. Por tanto, este aspecto era algo que consideramos importante y que debíamos cubrir, ya que para planificar con OpenProj teníamos suficiente.

Pues bien, cuando llegó la hora de presentar la solución Feng Office, aquellos que nos demandaban MS Project Server, dieron un paso atrás cuando presentamos la problemática real de la empresa en cuanto a la descoordinación de los equipos de trabajo y la mala gestión personal del tiempo y las tareas. Básicamente planeamos la necesidad que las tareas del día a día ("hacer el acta de la reunión x", "revisar el plan de pruebas", "realizar pruebas funcionales", etc) se trasladasen a los miembros de un equipo no en un mail o en una orden dada a viva voz en un pasillo o por teléfono, si no mediante una herramienta en la que quedase constancia de la asignación de la tarea, sus fechas de inicio y fin o las dependencias con otras tareas. 

¿Dependencia con otras tareas, fechas de inicio y fin, etc?, uhm, eso suena a los mismos conceptos que maneja MS Project, ¿por qué tanto rechazo?, la verdad es que me extrañó mucho ese rechazo porque estábamos cubriendo una demanda de los mismos que rechazaban la solución. Algunó sí que dió una pista, básicamente si plasmas las tareas de un proyecto en una web a la que todos los miembros tienen acceso (y los jefes también) pueden ver a qué se dedica realmente cada uno, y claro, hay gente, al menos es la sensación que me da a mi, que tiene fama de estar muy atareado y que parecen que la empresa funciona gracias a ellos, pero que sin embargo si plasmasen sus tareas en una web visible a todo el mundo, el mito se vendría al suelo.

Ha sido muy curioso el paso atrás repentino de algunas personas, de hecho, tenemos un responsable de área que se ha negado a su uso, sin embargo, la gente a su cargo sí que quieren usarla...

¿Y qué pasa cuando un equipo de trabajo tiene que interaccionar con otro?, yo vivo parapetado detrás de un helpdesk, por lo que no tengo este problema, todo el que quiera algo relativo a sistemas tendrá que venir mediante un ticket del helpdesk, sin embargo, los hay que no tienen esa suerte. En mi empresa existen áreas transversales que dan servicio a los equipos de proyecto, nosotros incluidos, por tanto, cuando existe una herramienta, todos los jefes de proyecto quieren controlar a todos sus recursos por ahí, claro que también consideran recursos a estas áreas transversales.

¿Si un proyecto tiene una demanda de un área transversal cómo realiza la petición?, pues aquí tenemos división de opiniones, los jefes de proyecto lo tienen claro: "que el responsable del área transversal me asigne un recurso y yo le asigno tareas a dicho recurso directamente", pero claro, un recurso suele ser compartido y, dado que un área transversal trabaja en múltiples proyectos y no todos son igual de prioritarios, el responsable del área transversal tiene otro punto de vista: "prefiero asignar yo las tareas en base a la prioridad global de los proyectos de la organización, la carga de trabajo del área y los recursos disponibles".

Como miembro de un área transversal, comparto esta última perspectiva, creo que un modelo de "caja negra" donde no hay recursos pre-asignados es la mejor manera de funcionar, ya que si se permite que un jefe de proyecto asigne tareas directamente a los recursos de otro área, ¿para qué sirve entonces ese área?. Soy un enemigo total del binomio proyecto-recursos propios, creo que las organizaciones deben ser flexibles y adaptarse a las prioridades del negocio.

Total, que como conclusión, creo que el software colaborativo es muy beneficioso para la empresa pero creo que aún no estamos preparados para su uso, tendemos a usar las herramientas como armas de coacción y control sobre los equipos con los que colaboramos. Aún seguimos gestionando proyectos  con estructuras piramidales, yo soy jefe de proyecto y tú siempre estarás por debajo mía, aunque seas de un área transversal y tengas mucha más experiencia y galones que yo. 

Seguimos encorsetados en estructuras jerárquicas rígidas, preferimos tropezar o estrellarnos antes de preguntarle al de al lado, porque claro, sigue estando mal visto que un jefe de proyecto no lo sepa todo. 

Preguntar, colaborar, compartir, respetar, esa es la clave para llevar un proyecto al éxito.