Se pueden hacer estimaciones basadas en diversos factores como la experiencia, cálculos matemáticos, el dedo al aire… que nos permiten conocer el esfuerzo necesario, las personas que deberemos involucrar, por qué fases habrá que pasar y la duración de éstas, y otros datos indirectos como costes, solicitudes de contratación para recursos humanos, que nos ayudarán a minimizar los posibles problemas.

Sin embargo, todo siempre existirá una sensación de vértigo cuando un proyecto arranca, y es normal que exista. Incluso creo que es bueno tenerlo, ya que nos hace estar atentos para lograr que el proyecto empiece con buen pie. Tengo claro que, si antes de comenzar un trabajo, creemos tener todo controlado, entonces es que hay algo de lo que no nos hemos enterado.

¿Qué debemos tener claro para que el vértigo no se convierta en un desmayo por el susto?

Los datos clave que debemos conocer son:

• Objetivos. La primera pregunta que deberíamos hacernos es “¿Qué nos han pedido hacer?¿Qué quieren?”. ¿De verdad lo tenemos siempre claro? ¿Hemos sido capaces de obtener esa información? Si no sabemos lo que se espera del proyecto no merece la pena siquiera empezar.
• Participantes e interesados. Es indispensable saber quién va a participar, qué intereses tiene cada uno, qué grado de involucración van a tener, qué esperan del proyecto, si son pro/contra, qué papel van a jugar y su grado de influencia, la manera de contactar con ellos y lo accesibles que son, quién firma los requerimientos. No saber quién influye en el proyecto es un error grave puesto que son los que darán el veredicto final, ya sea de manera directa o indirecta.
• Plazos. ¿Cuándo esperan que se ponga en marcha el proyecto? ¿Es viable? ¿De qué depende el poder cumplir los plazos?
• Tecnología. Parece increíble pero conozco algún caso en el que se ha arrancado un proyecto, se ha realizado una fase de análisis de requerimientos y, a la hora de hacer el diseño, la empresa proveedora y la contratista se han dado cuenta de que cada una pensaba en una tecnología diferente. Obviamente no es un caso habitual (afortunadamente) pero, como dicen en Alerta Maxima 2: “las suposiciones son las madres de los metepatas”. Dejemos todo claro y reduciremos los problemas.

Podrían considerarse otros factores claves a la hora de arrancar un proyecto, pero, a mi juicio, estos son los más importantes, ya que contestan a las preguntas más importantes: ¿Qué? ¿Quién? ¿Cuándo? ¿Cómo?

Además de aportar mi punto de vista, me gustaría que fuera una especie de “cápsula del tiempo” en la cual poder hacer vaticinios y apuestas de qué ocurrirá con determinados productos, lenguajes, fusiones, tecnologías, etc. Se trata de un desafío-juego en el que todos podemos participar.

1. United Airlines usará iPads en lugar de manuales en papel. Por un lado no me parece mala idea ya que se pueden actualizar todos a la vez, ahorran papel (son alucinantes los datos que ofrece la compañía) y peso. Sin embargo, ¿qué pasará si se descargan? ¿Y si no tienen cobertura de algún tipo? ¿Y si se corrompe el sistema? ¿Y si se caen al suelo? ¿Y si les echan agua por encima? Imagino que estas cuestiones y más las tendrán contempladas ya… ¿o es mucho suponer?
2. Construyen un parking sin rampa de acceso. Una chapuza más de un ayuntamiento español. Se gastan miles de euros en una obra nueva y ni los técnicos, ni los arquitectos, ni el concejal, ni el alcalde ni demás personajes involucrados son capaces de darse cuenta. ¡Meritocracia y responsabilidades ya!
3. ¿Por qué permiten patentar ideas?. Ahora Samsung se defiende contra la demanda por supuesta infracción de patentes de Apple diciendo que en la película Odisea 2001 ya aparecían unos aparatos similares a las tablets, así que no ha sido idea suya. Más allá de si puede valer o no para la justicia americana, ¿os imagináis la reunión de abogados en la que pensaron ese argumento? ¿Estuvo Pocholo?
4. Tecnología Apple Low Cost. Acabo de enterarme del rumor de que Apple planea sacar un iPhone “baratillo” (unos 250 euros) con capacidades inferiores al iPhone actual. ¿Por qué? ¿Huele que en esto de los móviles ya le han alcanzado? Sinceramente, nunca me ha gustado la posición de Apple ni el aura de misticismo que le dan sus incondicionales, pero claro, si tienes gente dispuesta a pagar por cualquier cosa que saques al mercado, es normal que se aprovechen. ¿Quién es más culpable: la folclórica que vende su historia en el Hola o quien compra la revista? Como en la tele, contraprogramación (de Samsung, claro).
5. Quien con chicos se acuesta, meado se levanta. Llevarse tu centro productivo a oriente puede hacer que te copien todo, incluso el iPhone 4, y a precios mucho más baratos.
6. Ayer probé el Motorola Xoom. Es una maravilla técnica. Éste sería el resumen más apropiado. Todo fluye con suavidad. La pantalla es una gozada, se navega perfectamente, las fotos son fantásticas, y se pueden ver archivos multimedia sin ningún problema. Sin embargo, sigo viéndole los mismos problemas que al iPad: por un lado el peso y por el otro el precio. Estuve apenas 20 minutos sosteniéndolo con las manos y las muñecas empezaron a molestarme. Al final, 850 gramos sigue siendo un peso considerable para sostener un buen rato. Por otra, no tengo claro que gastarme 600 euros en una tablet sea una buena inversión. Desde luego, hay que sopesar si es mejor opción que un portátil o un buen netbook.

Obviamente, antes de correr hay que saber andar y resulta difícil gestionar de forma correcta un proyecto si no se controlan todos los aspectos básicos.

Sin embargo, cuando ya te has enfrentado a varios proyectos, con diversos tipos de personas a tu cargo, te das cuenta de que eso que has aprendido no es suficiente, ya que se trata sólo de teoría. Es un caso similar al de obtener el carnet de conducir: te enseñan las señales de tráfico, las prioridades, las normas legales, pero, a pesar de las clases prácticas, no llegas a conocer las normas no escritas de la conducción, esas que aprenden en el día a día cuando sales a la jungla del asfalto tú solo tras el volante.

En el caso de la gestión de proyectos ocurre lo mismo.

Puedes crear un diagrama Gantt con el plan detallado de todas las actividades e hitos.

Puedes rellenar una matriz de riesgos, ponderándolos de la manera más objetiva posible.

Puedes hacer estimaciones de esfuerzos y asignación de tareas basados en cálculos complejos de puntos función.

Sin embargo, nadie te enseña cómo debes reaccionar cuando uno de los integrantes de tu equipo decide acercarse a ti y contarte un problema personal.

Tampoco nadie te enseña cómo lograr que esa persona confíe en ti, ni cómo mantener motivado al equipo, ni cómo delegar tareas, ni cómo pedir a una persona que se quede más allá de su tiempo de trabajo porque el proyecto debe terminarse en el plazo establecido y hay una desviación, ni cómo decirle a alguien que no vale y que es mejor que busque otro empleo.

Todo ello son habilidades que si bien no son objeto de examen cuando obtenemos, por ejemplo, una certificación PMP, sí forman parte del día a día como gestores y que no tenemos más remedio que aprender o los problemas nos superarán.

Entonces, ¿cómo hacerles frente? ¿Cómo resolver este tipo de problemas?

Yo creo que hay cuatro pasos fundamentales:

1. Ponerse en el lugar de la persona que los sufre: ¿qué nos gustaría escuchar si estuviéramos en su situación? No siempre funciona, ya que cada persona es diferente, pero si logramos conectar de esta manera ya tenemos el primer paso dado.

2. Determinar cómo afecta al proyecto este problema y su gravedad.

3. Plantear alternativas que sean válidas para el proyecto y para la persona que tiene el problema.

4. Ser consecuentes con la decisión tomada y ser conscientes de que será el nivel con el que nuestro equipo mida futuras situaciones (por desgracia, el nivel de similitud lo suele establecer el afectado y no nosotros).

Obviamente, cada problema deberá ser analizado individualmente ya que no es lo mismo (para algunas personas puede llegar a serlo) que nuestro perro se haya lastimado una pata que la defunción u hospitalización de un familiar.

Lo mejor es aprender de lo que ocurre a nuestro alrededor, ya sea con nuestros inmediatos superiores o a través del ejemplo ajeno de otros compañeros.

Además, como siempre, es imprescindible aplicar el sentido común y ser rigurosos con nuestras decisiones, ya que cada una de ellas será tomada como “jurisprudencia” para futuras situaciones.

Hace un tiempo me compré la serie completa de Harry (el sucio, el fuerte, la lista negra…) y, de vez en cuando, vuelvo a poner una en el dvd.

Hace poco vi de nuevo Harry el Ejecutor. Obviamente, no es una gran película en cuanto a términos de calidad artística e interpretativa se refiere, pero sirve para pasar el rato y disfrutar viendo cómo un policía aplica lo que, en general, entendemos por justicia.

Más allá de cualquier consideración cinéfila, me dio por pensar su analogía con la gestión de proyectos y las organizaciones en general, y lo curioso es que, en muchas ocasiones, vemos reflejados gran parte de los perfiles de este tipo de películas.

En mi opinión, hay cuatro tipos de empleados:

1. Los que piensan. Hacen evolucionar a la empresa, aún a riesgo de equivocarse. Son una especie rara de encontrar y difícil de contentar.
2. Los que ejecutan. Acatan las órdenes del primer grupo, bien con un toque propio para mejorar el resultado, o bien sin parar a reflexionar en nada más que las órdenes recibidas.
3. Los que se dejan llevar por la corriente. Generalmente son buenos empleados, cumplen con su cometido, pero no se le pueden pedir peras al olmo.
4. Los que hacen bulto. Son necesarios para completar la plantilla, pero sería deseable sustituirlos por los del grupo 2 o 3.

Obviamente, el protagonista de Harry el Ejecutor es del grupo 2, aunque llevado al extremos en cuanto a los métodos, el celo con el que se aplica y los toques personales con los que adereza su trabajo.

Sin embargo, creo que nunca llegaría al grupo 1, ya que es una persona de acción, que prefiere aplicar las soluciones a teorizar sobre ellas.

Conforme avanzamos en nuestra carrera profesional más vamos situándonos en el grupo de los protagonistas o de los actores secundarios. En ello influyen muchos factores externos que no somos capaces de controlar, aunque en nuestra mano queda decidir si queremos evolucionar hacia los que piensan o conformarnos con dejarnos llevar por la corriente.

¿En qué grupo crees que estás? ¿Es posible moverse de un grupo a otro?

Es la dura realidad a la que nos enfrentamos todos día a día, ya sea en nuestro ámbito personal o profesional.

Cuando trabajas en un producto, cada decisión debe ser pensada meticulosamente, mucho más que si estamos desarrollando algo a medida. Saber cómo va a afectar técnicamente ya es una tarea compleja, pero adivinar lo que van a pensar tus usuarios es un ejercicio de completa adivinación.

A menudo nos enfrentamos al diseño de una nueva funcionalidad. Bien, sabemos qué pretendemos hacer y sabemos (aunque no siempre) que es algo que nuestro producto necesita para poder competir con otros similares, o es una necesidad que los usuarios han manifestado.

Entonces, ¿dónde está el problema?

La clave está en cómo llevar a cabo esa idea. Por ejemplo: pasar del sencillo ”quiero que envíe un correo de aviso” a diseñar la solución ya final puede llegar a ser un duro camino a recorrer.  ¿Cuántos destinatarios? ¿Cómo elegirlos? ¿En qué momento? ¿En qué formato? ¿Dónde presentar la ventana de edición? Etc, etc, etc.

A menudo la tentación de implementar la solución que a nosotros nos gustaría es enorme. Yo he discutido mucho con colegas de trabajo porque no entendían la clase de usuarios que teníamos, y es que los informático tenemos tendencia a pensar que nuestros usuarios conocen tanto la técnica como nosotros, y que usarán recursos como atajos de teclado, ayudas contextuales, ctrl-c, etc. Esto casi nunca se da y terminamos construyendo la solución que nosotros querríamos en lugar de la que realmente van a usar.

Es decir, hay que pensar en lo que gustará a la mayoría.

Debemos tener claro que contentar a todos es imposible. Incluso puede que nosotros mismos no estemos satisfechos con lo que hace la funcionalidad, pero no importa. Lo que de verdad tiene relevancia es que ese desarrollo debe satisfacer las necesidades de la mayor parte de nuestros usuarios.  Habrá un gran porcentaje que añadiría o quitaría algo, un porcentaje menor que no considera útil lo que hemos hecho o cómo se ha ejecutado, y deberíamos lograr que sólo un porcentaje residual considere una estupidez el trabajo realizado.

Si logramos dar satisfacción a una gran parte del público objetivo, entonces nuestro trabajo habrá sido un éxito.

Si por el contrario implementamos una cojo-funcionalidad que luego no usa nadie por mala, inútil, complicada, fea o cualquier otro motivo que se os pueda ocurrir, entonces habremos perdido tiempo y dinero, aunque si somos listos habremos obtenido una valiosa lección.

En general, mi experiencia se reduce al ámbito profesional ya que he tenido que colaborar en la creación de productos informáticos. Sin embargo, me temo que los peligros del “esto me gusta, esto no” son generales a cualquier actividad que requiera la elaboración de artículos repetibles, ya sean coches, ropa, adornos, cosmética, etc. Todos estamos sujetos a la tiranía de la mayoría.

Que afecta, como siempre, a los que menos tienen, tampoco.

Sin embargo, es paradógico que incluso en este tipo de circunstancias haya gente que logre buenos negocios y sepa amoldarse perfectamente a los problemas.

Muchos de los que os acercáis por este blog sabéis que hace unos meses pasé de trabajar en una consultoría para formar parte del departamento de informática de una importante empresa industrial. No entraré ahora a comentar los cambios que ello ha supuesto, tanto de mentalidad como de forma de trabajo. Sin embargo, es curioso observar una tendencia que, por lo que hablo con otros compañeros de consultoras, resulta general en nuestro sector, tanto en las empresas como la que estoy como en aquellas que tienen un corte más de tipo consultoría.

Hasta hace unos años, los proyectos que se solían encargar eran desarrollos de nuevas aplicaciones, ya fueran de gestión económica, de recursos humanos, etc.

Las empresas estaban interesadas en tener información acerca de los diferentes aspectos de su negocio y se encontraban en la fase de transición desde la no-informática (o herramienta rudimentaria) a la implantación de una primera herramienta (o un ERP completo). Personalmente creo que ese es el paso más importante en una empresa, por el cambio tecnológico obvio, pero, sobre todo, por el cambio de mentalidad que debe haber en toda la estructura jeráquica.

Durante los años de bonanza, muchas empresas han comprendido que, para poder tomar decisiones y aprender de las consecuencias de éstas, era necesario disponer de información acerca de ventas, beneficios, mercados, etc. Por ello, se embarcaron, con más o menos éxito, en proyectos de implantación de herramientas y en esa tarea hemos estado trabajando la mayor parte de informáticos los últimos años.

Sin embargo, en los últimos dos o tres años la tendencia ha cambiado, sobre todo motivada por la crisis.

¿Qué ha ocurrido?

La respuesta es simple: aquellas empresas que tenían implantado un sistema de gestión informática han pasado de pedir más módulos y ampliaciones de funcionalidad a solicitar dos tipos de proyectos: minería de datos y control, e integraciones; las empresas que no se atrevieron a dar el salto simplemente se han encontrado que no había ya dinero para este tipo de inversiones (gastos según algunos), por lo que han perdido una oportunidad y la mayor parte de ellas están abocadas a pasar numerosas dificultades.

En cuanto a los proyectos que hoy en día se realizan, todos se centran en extraer la máxima cantidad de información, ya sea de los sistemas propios de la empresa, ya sea de otras con las que se relacionan.

El trabajo que desarrollamos en el departamento no se ha mantenido ajeno a esta tendencia, y actualmente la mayor parte de proyectos están relacionados con integraciones (ya sean internas o externas), realización de informes, elaboración de indicadores y cuadros de mando, y supervisión, etc.

Todo ello encaminado a tomar las decisiones de manera más exacta, ya que hoy en día es crucial no equivocarse, porque el margen es pequeño.

Aquellas empresas y aquellos departamentos que hayan sabido ver que no es tiempo para nuevas aplicaciones, sino que es el momento de ofrecer conclusiones o indicadores, creo que podrán hacer negocio a pesar de la crisis en la que estamos.

¿Notáis en vuestro trabajo esta tendencia en el tipo de proyectos que desarrolláis?

Es mucho más acusado en empresas de consultoría o servicios de informática que en departamentos internos de las empresas, puesto que en las primeras generalmente todo va contra un presupuesto y se exige, antes o después, una rentabilidad a los proyectos.

Se trata de un viaje de ida y vuelta, al que he llamado El Método Nadal.

¿Qué es exactamente El Método Nadal (EMN)?

Se trata de hacer que la pelota esté el mayor tiempo posible en el campo contrario, y que nuestro usuario-cliente deba realizar un esfuerzo en el proyecto igual o mayor que nosotros para garantizar el éxito.

¿Cómo se logra desplegar EMN?

Es sencillo. Cuando somos nosotros, ya sea en el papel de analistas, programadores, jefes de proyecto, etc los que tenemos la pelota en nuestro tejado, somos vulnerables a la presión por realizar las entregas a tiempo o por cumplir unas espectativas que no siempre están claras. Sin embargo, si un hito, una validación o concertar una reunión no dependen de nuestro trabajo, sino de que el usuario-cliente tome la iniciativa, entonces ganamos un tiempo valioso para poder tomar las acciones oportunas que beneficien tanto a la organización como al proyecto.

Si nos fijamos en la forma de jugar de Rafa Nadal, veremos que nunca da un tanto por perdido, pero la consecuencia más importante de ello es que siempre obliga a su compañero de partido a hacer un esfuerzo adicional para intentar pasar la pelota al otro lado de la red.

Aplicando esto a la gestión de proyectos, veremos que tenemos oportunidades de hacer participar e incluso responsabilizar a nuestros clientes de posibles retrasos en proyectos, indefiniciones, etc, con un doble objetivo: por un lado tratar de crearnos un marco seguro para el caso de que haya problemas y, por otro y mucho más importante, involucrar a todos los interesados con el fin de lograr el éxito de los proyectos.

Cuando un cliente solicita un proyecto y apenas recibe información del mismo, muchas veces se desentiende y eso afecta de manera directa a su percepción de calidad y a su grado de satisfacción.

Es nuestra obligación hacerle partícipe del proyecto, lanzándole tareas, hitos, etc, que deba realizar también y con los cuales sienta que es también responsable del resultado final.

creo que debo pedir disculpas a todos aquellos que, hasta hace unos meses, leíais los artículos que escribía puesto que he permanecido en silencio durante muchas semanas y no he dado una explicación.

Hace unos meses cambié de trabajo (prometo escribir un artículo al respecto) y mi paternidad ha exigido cada vez más tiempo, por lo que, unido a que entré en una fase de poca creatividad, hizo que dejara de publicar.

He vuelto a marcarme el objetivo de seguir escribiendo, al menos un par de artículos mensuales, aunque quizá la temática se vea ampliada y hable también de algo de tecnología y de eso que llaman la sociedad de la información.

Una vez más os pido disculpas y espero que poco a poco os logre enganchar nuevamente a este pequeño rincón que he creado y en el cual voy dejando trocitos de mi experiencia y mis pensamientos.

A todas ellas, yo añadiría unas más, las cuales he puesto más abajo.

1. En nuestro caso es diferente.
2. Ya lo hemos intentado antes.
3. Cuesta mucho.
4. No es mi trabajo.
5. Estamos demasiado ocupados para eso.
6. No tenemos tiempo.
7. No tenemos suficiente ayuda o gente para hacerlo.
8. Es un cambio demasiado radical.
9. A la gente no le va a gustar.
10. Va en contra de la política de la compañía. 
11. Los sindicatos van a protestar.

12. Eso aumentará la burocracia.
13. No tenemos permiso.
14. Volvamos a la realidad.
15. No es nuestro problema.
16. No me gusta la idea.
17. No digo que no sea así, pero…
18. Vas adelantado dos años a tu tiempo.
19. Ahora no es el momento.
20. No está en el presupuesto. 
21. A mi no me vas a enseñar nada nuevo.
22. Bien pensado, pero no es práctico.
23. Pensémoslo mejor.
24. Seremos el hazmerreir de la industria.
25. Otra vez eso no…
26. De dónde te has sacado eso?
27. Nos hemos arreglado perfectamente hasta ahora.
28. Nunca se ha intentado.
29. Pongamos eso como idea de baja prioridad.
30. Hagamos un comité.
31. En nuestro lugar no funcionaría.
32. El comité ejecutivo nunca lo aprobará.
33. No encuentro la relación.
34. Mejor consultarlo con la almohada.
35. No se puede hacer.
36. Es demasiado problema cambiar.
37. No da beneficios por sí solo.
38. Es imposible.
39. Conozco una persona que lo intentó y la despidieron.
40. Siempre lo hemos hecho así.
41. A la larga perderíamos dinero.
42. No tentemos a la suerte.
43. Ésto es lo que se puede esperar de un novato.
44. ¿Alguien lo ha intentado antes?.
45. Pensémoslo más detenidamente.
46. Tenemos que rendir cuentas a los accionistas.
47. No sueñes.
48. Si no está roto no es necesario arreglarlo.
49. Demasiado bonito para ser verdad.
50. Es demasiado trabajo.

51. Esto, que lo haga el nuevo.
52. Con lo que cuesta, cogemos a 3 becarios y nos ahorramos mucho.
53. ¿Quién ha osado pedir eso?
54. Hazme un informe detallado de eso que propones.
55. Mejor lo subcontratamos a la India.
56. No creo que sea para tanto.
57. Eso jamás lo comprarán.
58. Si tienes narices, díselo al jefe.
59. ¿Quieres recibir una llamada de personal?
60. Has visto demasiadas series de robots.
61. Ya, ¿y los Pokemon cuándo salen?
62. Yo no tengo una bola de cristal ¿y tú?
63. Si no funciona, ¿te despedimos?
64. ¿De verdad crees que sabes lo suficiente como para proponer eso?
65. Mira, llevo aquí más años que tú y sé que nadie lo aceptará.
66. ¿Quién te has creido?
67. ¿Has tomado algún carajillo a la hora de comer?

Seguro que a todos se os ocurren más frases. Os animos a ampliar la lista.