365 días

El otro día estuve viendo un episodio de «El Ala Oeste» (The West Wing), una de mis series favoritas. En concreto, el episodio 6×12 titulado «365 days». Ojo, a partir de aquí empiezo a hablar de la serie: aunque trataré de ser lo menos explícito posible, si no la has visto y te fastidia que te den pistas sobre lo que pasa, puede que prefieras dejar de leer. Por la misma regla de tres, si has visto más que yo, ten cuidado con tus comentarios porque te puedo arrancar los ojos si me haces un spoiler 😀
El caso es que la administración del Presidente Bartlet afronta el último año de su legislatura. Mientras todos los miembros del equipo presidencial están sumidos en el día a día, respondiendo a una y mil crisis, uno de los personajes (que por motivos que no vienen al caso ha estado apartado de ese día a día durante un tiempo) se dedica a repasar obsesivamente los discursos del estado de la nación y de investidura de todos los años precedentes. Y aprecia una notable diferencia respecto al del último año: han desaparecido los grandes retos, las grandes aspiraciones. El equipo presidencial está cansado, no tiene iniciativa, se limita a actuar de forma reactiva a las crisis que van surgiendo.
Entonces, les reune a todos para comentar este hecho, limitándose a escribir en su pizarra «365 días». Es el tiempo que les queda en la Casa Blanca. «En un día aquí podemos resolver más cosas de las que podremos resolver en el resto de nuestra vida una vez salgamos; ¿qué vamos a hacer en estos 365 días?«.
Una nueva llamada hacia la reflexión acerca de lo importante frente a lo urgente, la necesidad de plantearse hacia dónde vas, y qué quieres conseguir.

Próximo paso: proyectos propios

Hace ya más de un año que puse en marcha la idea de Digitalycia, después de haber pasado 2 años (de una forma u otra) colaborando con Weblogs SL, y después de haber pasado 7 años como consultor «serio». En total, 10 años de consultor, en los que se han sucedido proyectos muy variados pero con una característica común: han sido proyectos de otros.
Ya he confesado alguna vez que hay una parte de la consultoría que me gusta mucho: la de conocer un nuevo negocio, entender sus circunstancias, profundizar en las raíces de su situación y proponerles vías para mejorarla. Lo que pasa es que, después de eso, viene la parte de «implementar» el proyecto, sea un blog corporativo, una evaluación global del desempeño, el establecimiento de un sistema retributivo o desplegar una estrategia 2.0. De hecho, los clientes por lo que pagan (ahí está el negocio de verdad de los consultores) en el fondo es por esto: lo del «análisis y diagnóstico» está muy bien, pero al final lo que quieren es «házmelo». Y ahí viene el lío.
Porque en la inmensa mayoría de los casos no puedes aplicar tus propios criterios al desarrollo de los proyectos. No tienes control sobre los plazos, sobre las prioridades, sobre la forma de resolver los imprevistos. Si tienes suerte y se genera una gran sintonía, el cliente (que es al final el que marca el paso hacia un sitio u otro, o directamente no marca nada) te consulta y luego te hace caso. Pero lo normal es que te consulte pero luego decida por su cuenta y riesgo, cuando no que directamente ni te consulte ni decida. O que haya varias «voces autorizadas» dentro del cliente, cada una dando indicaciones variadas o directamente contradictorias. Y a eso siempre podemos sumar «el fuego amigo» procedente de tu propia empresa, con los jefes y sus «ideas felices», sus compromisos «off the record», su gestión de tus recursos, su agenda oculta o sus intereses al margen del proyecto. Te conviertes entonces en el mero ejecutor del proyecto de otros, en un triste tripulante de un barco capitaneado por personas que ni siquiera están de acuerdo entre sí, que ni va exactamente a donde tú crees que debe ir (o directamente en dirección contraria), ni al ritmo que crees que debe ir, o que directamente queda a la deriva sin que tú puedas coger el timón.
Por eso, tras 10 años, ha llegado el momento de un cambio. No radical, porque voy a continuar mi actividad «consultoril» para terceros. Pero, como línea estratégica, voy a empezar a desarrollar proyectos propios. Proyectos en los que yo sea el máximo responsable de las decisiones, de establecer prioridades, de marcar plazos, de gestionar recursos, de reaccionar ante los imprevistos. Y también el que se beneficie del resultado positivo o sufra el negativo. Siguiendo con el símil náutico, quiero ser el que define el rumbo, el que iza las velas, el que maneja el timón, el que decide cómo enfrentarse a las tormentas. Quiero poder aplicar mis criterios sin que haya un cliente que me diga «vale, me gusta lo que me cuentas pero vas a hacerlo de otra forma», ni un jefe que me diga «muy bien todo, pero he hablado yo con el cliente y ahora vas a hacerlo como yo te diga».
¿Llegaré a buen puerto, o me hundiré en el intento y tendré que seguir toda la vida sirviendo en barcos ajenos? El tiempo lo dirá. Pero ahora, en este momento, ha llegado la hora de ponerme al timón. El barco está a punto de zarpar.

Cuando las fechas se imponen al producto

El otro día estaba en una reunión de planificación de un proyecto. Pensando en el calendario, alguien dijo «tenemos que lanzar antes de X». Y a mí se me hizo un plazo demasiado corto, y así lo dije. «Pero es que esa fecha es importante porque…», me respondieron. «Vale, pues la mantenemos si queréis, pero dudo que lleguemos. Y si llegamos, va a ser haciendo las cosas a medias».
No me entendáis mal. El establecimiento de fechas de entrega o deadlines es un paso clave en la planificación de cualquier proyecto. Según la conocida como ley de Parkinson, cualquier tarea se expande hasta llenar el tiempo disponible para que se termine. O sea, que si no se establecen fechas de entrega, las tareas tienden a extenderse hasta el infinito… Disponer de fechas límite es importante, por lo tanto, para focalizarse en la finalización de las tareas, y también para tener un objetivo compartido.
El problema es cuando estas fechas de entrega se mantienen aun a costa del buen término de un proyecto. Llega la fecha acordada, la tarea no se ha terminado adecuadamente (bien porque la planificación era incorrecta, bien porque se producen errores en la ejecución; da lo mismo), pero alguien insiste en que «da igual, hay que lanzar como sea en la fecha prevista».
¿Resultado? Productos a medio terminar, sin pulir, que no terminan de funcionar bien, errores, insatisfacción… eso sí, se ha «cumplido» con la fecha.
Me parece un gran error de gestión permitir que estas cosas pasen. Si se había hecho una planificación irreal, entonces habrá que asumir el error y corregir dicha planificación para fijar una fecha de entrega más realista. Las cosas tienen un proceso, y un periodo de maduración, y llega un punto más allá del cual no se puede comprimir sin que se resienta el resultado final.
Y si se producen errores en la ejecución, lo que procede es analizar las causas y resolverlas. Cualquiera de estas opciones es mejor que poner en el mercado un producto defectuoso, con todo lo que eso conlleva.
El problema es que muchas veces estas fechas son compromisos adquiridos/impuestos por otros: un jefe, un comité de dirección… gente que valora más un producto regular en fecha que un buen producto un poco más tarde. Es más fácil que caiga una bronca por un retraso que por algo mal hecho (fundamentalmente porque la mayoría de las veces no le dedican ni un minuto a usar el producto/servicio; le echan un vistazo por encima y listo). Mientras tanto los clientes/usuarios, que son quienes deberían importar (al fin y al cabo son ellos los que nos pagan) van a notar mucho más los fallos, mientras que las «fechas de entrega» que nos hayamos fijado a nivel interno les vienen a importar bastante poco…
En definitiva, ¿qué es lo importante? ¿quedar bien con «los jefes» o con los usuarios/clientes? Lamentablemente, una vez más, en el mundo corporativo la respuesta es la que no debería ser.
Foto | Joe Lanman

Los problemas de los diseñadores

Llego vía Lucas a este video que me ha resultado muy ilustrativo de las penalidades que sufre un diseñador. Yo no soy diseñador, o igual sí, un poco. En mi último proyecto he jugado a veces el papel del diseñador (teniendo que asumir los requerimientos evolutivos, crecientes y a veces contradictorios del cliente; y escuchando el célebre «está guay, pero…»), y a veces el papel del cliente tocapelotas (pidiendo cambios adicionales sobre el briefing inicial que yo mismo había hecho); y la mayor parte del tiempo, ejerciendo la labor de «correa de transmisión» y a la vez de «árbitro» entre cliente y diseñador/desarrollador.
Lo cual me permite alcanzar un cierto entendimiento de todas las partes. Entiendo al cliente al que le resulta imposible dar por cerrada la parte de especificaciones (porque siempre hay algo más de lo que te das cuenta después, cosas en las que no caes hasta que las ves negro sobre blanco, o siempre hay alguien que opina a destiempo), o que se ve sometido a presiones para contentar a mucha gente a la vez. Y también entiendo al pobre diseñador (o, haciéndolo más amplio, al equipo de desarrollo) que ve cómo las especificaciones cambian cada dos por tres (a veces de forma totalmente contradictoria) invalidando el trabajo realizado hasta el momento, obligando a replantear cosas (pero manteniendo las fechas de entrega, claro), y viendo cómo el cliente no valora el impacto de cada una de sus nuevas «ideas felices».
Pero sobre todo, sobre todo, entiendo al pobrecito que está en medio, intentando comprender a las dos partes y equilibrar los intereses de todo el mundo: por un lado haciendo que el cliente vea atendidas, dentro de lo razonable, sus expectativas; y por otro lado procurando «proteger» en la medida de lo posible al equipo de diseño y desarrollo. El problema es que eso se hace a base de «templar gaitas», de peleas y enfrentamientos (al cliente le tienes que decir, en algún momento, que entiendes sus demandas pero que no es posible; y al diseñador o desarrollador le tienes que decir, en algún momento, que entiendes que es una putada pero que hay que hacerlo y punto), de gestionar las renuncias de cada una de las partes (para dejar «moderadamente satisfecho» a todo el mundo todos tienen que ceder, lo cual implica que también estarán «moderadamente insatisfechos»).
Malabarismos que desgastan un huevo, una labor de fontanería poco agradecida con la que, si has hecho bien tu trabajo, nadie va a estar nunca 100% contento.

¿Quién debe marcar el ritmo?

Tortuga

Hace unas semanas, me interesé por un proyecto colaborativo que me apeteció. Me puse en contacto con quien lo lideraba, ofrecí mi colaboración… estupendo. Pasados unos días, hice mi primera contribución al mismo, y unos días después hice una segunda con la que completaba todo lo que podía hacer hasta el momento.
Había otras personas vinculadas al mismo proyecto. Un par de ellas habían hecho también el 100% de su contribución, otro par de ellas un 50%… y el resto un 0%. El caso es que hasta que no hubiese una masa crítica de personas contribuyendo, el proyecto no podía seguir adelante.
Había dos opciones: avanzar al ritmo marcado por quienes sí estaban contribuyendo (y dejar atrás a los que no, incluso sacándoles del proyecto), o seguir esperando y «animando» a los que no contribuían en espera de que lo hiciesen para avanzar. Hasta ahora se ha optado por la segunda, y creo que es un error.
Si una persona no ha contribuído pasado un tiempo razonable, es que no tiene ningún interés en hacerlo, y no lo va a hacer. En el mejor de los casos, después de mucho insistir, hará algo para cubrir el expediente… y así hasta la próxima vez. Pero siempre será una rémora, alguien a quien hay que insistirle para que aporte, un «peso muerto» que va a dificultar el avance del proyecto en vez de impulsarlo.
Mientras tanto, los que sí han contribuído a buen ritmo ven como, a pesar de dicha contribución, las cosas no van a ningún sitio por culpa de la tolerancia con los que se retrasan. Y llega un punto en el que se plantean qué sentido tiene dar pedales y esforzarse por impulsar un barco que en cualquier caso se va a mover al ritmo de los más lentos. Conclusión, ley del mínimo esfuerzo, «que tiren otros» y, si acaso la cosa remonta, ya veremos. Pero claro, si los que tiran dejan de tirar… pues proyecto moribundo o directamente muerto.
¿Cómo habrían sido las cosas de seguir el ritmo de los entusiastas, aun a riesgo (o a certeza) de dejar atrás a otros? Pues probablemente el proyecto tendría un nucleo menor, pero muy activo, que permitiría que fuese evolucionando poco a poco hasta acabar desarrollándose correctamente.
El café para todos, el «que nadie se quede atrás», es algo que desincentiva el esfuerzo y los avances. Porque mide a todos con el mismo rasero de la mediocridad.

Todos los proyectos son iguales

Caníbales

Impagable descripción de la merienda de negros en que se convierte un proyecto la que hace el amigo Luis:
Es que al final todos los proyectos son iguales:

  • unos que piden
  • otro que decide que hay que hacerlo y da el visto bueno
  • uno que paga (no siempre es el anterior) y para compensar otro que dice que hay que ahorrar y presiona para ello
  • por supuesto está al que le cae el marrón de que el proyecto salga (responsable de proyecto) y con él un conjunto de damnificados (también llamados Key Users) que tienen que dedicar una buena parte de su tiempo al proyecto, ademas de sacar adelante su día a día – que nadie les quita.
  • otros que, aunque ni les va ni le viene la mayor parte de las veces, siempre opinan (suelen formar parte de un ente llamado comité de dirección)
  • los que son contratados para hacerlo y que les miden por el tiempo que pasan, su tarifa horaria, si llevan corbata o no y a veces también por los resultados que obtienen. Si el proyecto va mal cargan seguro con las culpas por lo que en su precio siempre hay esa prima de riesgo
  • y a veces otros, un poco raros, que en medio de esta merienda de negros están organizando, poniendo orden y asegurando que todo tira p’alante y el proyecto salga adelante… éstos últimos son importantes y … somos nosotros.

El gestor de proyectos malabarista

Malabarista

Impulsas una bola hacia el cielo. Mientras, de reojillo, ves como otra está bajando y tienes que recogerla para volverla a lanzar, mientras otra vuelve a caer. Juegos malabares. Así es la función del gestor de proyectos.
En muchas ocasiones, las tareas del gestor de proyectos no son largas o complejas, ni siquiera abundantes. Las tareas, en gran medida, las tienen que hacer otros. La labor del gestor de proyectos es coordinar todas ellas, asegurarse que todas se cumplen en tiempo y forma, darles coherencia y conseguir que formen un todo. Al igual que el malabarista, que la mayor parte del tiempo no tiene ninguna bola en sus manos, pero es el responsable de que las bolas fluyan al ritmo adecuado.
Un gestor de proyectos vela por las tareas, y también por los intereses de todo el mundo: los intereses del cliente, los intereses económicos, los intereses del equipo técnico, los intereses del equipo de diseño, los intereses de los proveedores… intereses muchas veces contrapuestos (uno lo quiere rápido, otro lo quiere flexible, otro lo quiere ordenado, otro lo quiere barato, otro lo quiere…). El trabajo del gestor de proyecto es conocer esos intereses y buscar la intersección entre todos ellos, aquel espacio de equilibrio en el que todos vean satisfechos sus intereses en la mayor proporción posible, gestionando a su vez su descontento por la parte que no ven satisfecha.
Más malabares. Más difícil todavía. Pero el espectáculo debe continuar.
Foto | fotosdecirco

Los proyectos QCHYA

Los proyectos QCHYA (o «cuchia») son… sí, vamos, no me digáis que no habéis oido hablar de ellos. Seguro que cuando los explique os suenan mucho. Y es que QCHYA es el acrónimo de Qué Coño Hago Yo Aquí. Seguro que ahora ya los vamos encajando mejor, ¿a que sí?
Se trata de esos proyectos en los que, simplemente, no sabes qué aportas. No sabes demasiado bien qué es lo que busca el cliente (porque dice una cosa y hace otra, o porque nadie se para a contártelo) y/o desde luego no entiendes por qué han contratado contigo o te han asignado al mismo, porque no tiene demasiado que ver con lo que tú sabes hacer. Proyectos en los que no te proporcionan los recursos necesarios para desarrollarlos, ni autonomía para ir avanzando, en los que no puedes aportar criterio ni opinión ninguna.
Pero ahí estás, y hay que hacer como que sí sabes lo que estás haciendo.
Recuerdo varios de estos a lo largo de mi carrera consultoril. Son proyectos agotadores mentalmente, en los que gran parte de las horas las pasas perdiendo el tiempo, bien porque no tienes ni idea de por dónde seguir o bien porque no te proporcionan los recursos (información, acceso a las personas clave, etc.) necesarios para hacerlo. Proyectos en los que tienes que poner más veces de las recomendables «cara de haba» porque no puedes decir nada medianamente inteligente. Proyectos en los que cada nuevo entregable se transforma en una fuente de angustia, porque te das cuenta de que no estás aportando ningún valor (aunque, con el tiempo, te das cuenta de que cuando estas cosas suceden es porque tampoco nadie está esperando que aportes demasiado…).
Si me pongo a pensar, creo que en este tipo de proyectos han coincidido algunas variables comunes:

  • Eran proyectos en grandes organizaciones: estructuras gigantescas, donde hay espacio para la dilución de responsabilidades, donde tu persona de contacto probablemente no tenga mayor interés ni conocimiento del proyecto que tú (pero le ha caído el marrón de tratar contigo), donde si te descuidas pueden pasar días sin que nadie se acuerde de que están pagando un consultor (y que está en aquélla habitación del fondo donde no va nadie nunca), en los que gastar pasta en consultoría sin resultados es una posibilidad.
  • Eran proyectos «delicados», con un cierto componente político (en el que entraban en juego rivalidades entre departamentos, etc.), en los que el consultor debía ser muy discreto: no puedes moverte por tu cuenta, ni planificar reuniones por tu cuenta (probablemente requieran aprobación del supervisor de tu contacto), ni pedir información de cualquier forma (siempre a través de tu contacto, que a su vez tiene que pedirla a otro departamento probablemente opuesto al proyecto, que a su vez…)
  • Eran proyectos en los que te dejaban «de la mano de dios»: tu gerente aparecía de guindas a brevas, echaba un vistazo superficial a las cosas… y desaparecía. Poca o ninguna orientación sobre por dónde avanzar, poca o ninguna gestión, poco o ningún interés por conocer la evolución del proyecto, poca o ninguna ayuda para sacarte de los atolladeros.
  • Para ser sinceros, yo lo he pasado mal en esos proyectos. Por la sensación de perder el tiempo, de que lo que estás haciendo no vale para nada, de estar «con el culo al aire» permanentemente, de que no avanzas, de que no aportas. Sobre todo, por la sensación de estar proporcionando, con perdón, «un servicio de mierda». Son proyectos en los que lo único que he deseado era que me sacasen de allí de cualquier forma, porque no veía la manera de terminarlos con bien. Algunos terminaron abruptamente. Otros terminaron con de forma vergonzante (se da por terminado sin ningún resultado plausible, aquí paz y después gloria… y tú has perdido el tiempo miserablemente).
    Creo que en resumen se puede decir que son proyectos hechos a conciencia de que da igual cómo resulten, en los que no se espera obtener ningún resultado real (ni rentable) ni ninguna contribución apreciable por parte del consultor, y que únicamente sirven para justificar alguna necesidad (en algunos casos más oculta, en otros más explícita) de quien te contrata.
    Pero mientras tanto, ahí tienes que estar tú pasando malos ratos. Cuando no eres consciente de estas realidades, angustiado por que ves que no estás siendo capaz de aportar. Y cuando eres consciente, hasta el gorro de perder el tiempo y de hacer un trabajo que sabes que no va a valer para nada.

    Un sapo en el desayuno

    Uno de esos consejos que merecen la pena

    Todas las mañanas, desayunate un sapo. Acomete cuanto antes todo aquello que queda fuera de tu zona de confort. Cuanto antes lo ataques, antes te lo quitarás de encima, menos ciclos cerebrales tendrás que dedicarle, menos estrés generarás y antes de darás cuenta de que no era para tanto.

    Ángel Medinilla

    ¿Cuántas veces no nos habremos enfrentado a tareas «desagradables»? Y pensamos en ellas, y qué pereza, y menudo marrón, ya verás qué movida, pfff… y si la dejo para mañana… es que hoy no lo veo… Y te pasas el día dándole vueltas, porque aunque hagas lo del avestruz, la tarea sigue ahí, esperándote. Tienes la secreta esperanza de que, si no le haces caso, acabará desapareciendo. Pero lo normal no es que desaparezca, sino que siga igual o, aún peor, que por nuestra falta de decisión empeore. Y mientras tanto nosotros, que sabemos que está ahí, le seguimos dando vueltas y nos angustiamos…
    Un gran consejo éste de desayunarse un sapo. Debería aplicármelo.

    Con la lengua fuera

    Irse por ahí «de saraos» está muy bien, y es importante… pero al final es un problema operativo. Son días en los que uno apenas puede «sacar temas adelante», por lo que todos se van acumulando esperando el regreso. Y aquí estamos, intentando «desenfangar» temas pendientes después del «efecto Expomanagement» y el efecto «Networking». Y mientras, algunos temas que se me quedan en el tintero digital…