Lo más curioso de estos chistes es que, en realidad se están riendo de nuestras propias desgracias, ya que las situaciones que representan son reales como la vida misma.

Sin embargo, ¿es posible que algún día cambien?

Yo creo que sí, pero el cambio vendrá producido por dos hechos principales:

1. Cada vez más habrá gente con conocimientos técnicos en el lado del cliente, lo que provocará que los requisitos sean dados con un poco más exactitud.

2. Progresivamente nuestra profesión será más valorada, por lo que podremos exigir lo que otros ingenieros ya tienen: reconocimiento y sueldos acorde de nuestra importancia.

Sin embargo, por otro lado, los sistemas que desarrollamos son muy abstractos en la mayor parte de los casos, incluso para nosotros mismos, por lo que es muy complicado lograr que el cliente sepa exactamente lo que quiere. Para acotar este punto existen técnicas, como la de prototipado que comenté en un artículo anterior, pero todas exigen un sobrecoste.

En cualquier caso, a los ingenieros de caminos, o a los agrícolas, o a los aeronáuticos, dudo que los clientes les digan exactamente lo que quieren. Seguro que les sueltan frases como: “Hay que hacer una autovía Madrid-Zaragoza”, “Toda esta comunidad de regantes tiene que modernizarse” o bien “Hay que construir el mayor avión comercial de la historia… ¡y que vuele!”

Voy a desvelar un secreto: en general, el trabajo de los ingenieros consiste en ¡pensar!

Sí, sé que muchos creerán que para eso no han estudiado una carrera, que tiene que haber maneras más fáciles de ganarse el sueldo, que para eso mejor poner ladrillos, etc. Sin embargo, me temo que es una verdad que en raras ocasiones se quiebra, puesto que nosotros tenemos que dar soluciones a los problemas de todo tipo de usuarios.

¿Dónde falla pues la ecuación en el caso de los informáticos?

Creo que en muchas de las variables: desconocimiento por parte de los clientes; falta de rigor por nuestra parte; mucha abstracción… excesivos factores. Sin embargo, hay dos que pueden ser la clave: pocos ven justificado pagar a un informático por pensar; pocos son conscientes de la importancia que tiene disponer del tiempo y los recursos suficientes para realizar un proyecto adecuadamente.

Nadie ve mal que un ingeniero de caminos cobre un buen sueldo, o uno aeronáutico, o un agrónomo, pero comparados con ellos, los sueldos de los informáticos son irrisorios.

Además, como el sobrino de fulanito hace bases de datos en access, o con dos excel y una piedra es capaz de gestionar la Charcutería Casamayor, todos los sistemas son iguales.

Por eso, es necesario instaurar un nuevo credo en la profesión, que nos ayude a superar los malos tragos y evangelizar allá donde vayamos:

- Creo en el trabajo bien hecho, bien analizado y origen de todo proyecto exitoso.

- Creo en el arquitecto y en el diseñador, que son bien dirigidos por nuestro jefe de proyecto, competente y son sentido común.

- Creo en un proyecto bien estimado, planificado y ejecutado.

- Creo en los cambios de alcance y en la aplicación de los ajustes necesarios, ya sean en coste o en tiempo.

- Creo en el plan de pruebas y en la honradez de los clientes y los programadores.

- Creo en el Espíritu Santo, que da imaginación en el desarrollo para crear esa funcionalidad imposible.

- Creo en un presupuesto justo y necesario.

- Creo en un trabajo bien remunerado.

Amén.

Hay otro tipo de proyectos, también nocivos para una organización, y son los Proyectos Cucaracha.

¿Cómo reconocerlos? No son tan evidentes como los del otro tipo, pero algunas señas de identidad son características.

1. El cliente lo pide pero no está muy convencido de su necesidad ni de su utilidad. Sólo sabe que tiene un problema y espera que se construya algo que se lo solucione.

2. No están claras las funcionalidades ni la evolución que tendrá en el futuro. Los plazos son cortos y el presupuesto mínimo.

3. De repente, pasan a ser críticos para el cliente, y mágicamente se reduce todavía más el plazo.

4. La primera vez que el cliente lo ve, se da cuenta de que no es lo que necesitaba, pero evita reconocerlo y se pone en producción, generalmente con todos los problemas imaginables.

5. Al mes de haberlo puesto en marcha, y tras haber trabajado más tiempo en resolver incidencias y realizar cambios que en el propio desarrollo, se comprueba que prácticamente nadie usa el proyecto.

¿Por qué se llaman Proyectos Cucaracha?

Siguiendo el símil con el anuncio de televisión:

A. Nacen: de repente, alguien los idea, se les ocurre como respuesta a un agujero negro que saben que existe en la organización.

B. Crecen: los problemas, las funcionalidades, todo menos los plazos.

C. Se reproducen: a partir del primer planteamiento se ramifican más ideas, más proyectos cucaracha, más, más, más.

D. Mueren: es lo que más frustración produce. Una vez se ha hecho el esfuerzo para poder cumplir con el proyecto, se han invertido horas extras y se han superado todas las dificultades posibles, suele quedarse en un rincón esperando a que alguien lo use, cosa que apenas sucede.

Generalmente este tipo de proyectos terminan acumulándose en un servidor de la empresa cliente, de modo que, meses o años más tarde, cuando puede que ni el promotor ni el autor estén ya en la empresa, alguien se pregunte para qué sirven, quién los usa y si son necesarios.

Lo peor es que las respuestas más habituales suelen ser: ni idea, no sé, a mí que me preguntas.

A pesar de que son fáciles de identificar ya en la primera reunión, muchas veces son inevitables (se combinan con los Proyectos Bomba).

No hay recetas mágicas, más allá de aplicar el sentido común y, ocasionalmente, poner un par de velas en el Pilar: documentar todo de manera correcta y actualizada para poder responder el día de mañana; involucrar a los interesados para que sientan como suyo el proyecto; promocionar el proyecto en el cliente con el fin de que exista una masa de usuarios suficiente, etc.

¿Tenéis experiencia con proyectos de este tipo? ¿Qué se puede hacer para reducir los riesgos que producen?

- Sí, ¿de parte de quién?

- De Carlos, de Plásticos Fiables.

- Voy a ver si está disponible.

(Unos segundos de espera)

- ¿Sí? ¿Carlos?

- Sí. ¿Qué tal te va todo?

- Bien, liados, como siempre, pero qué le vamos a hacer. Cuéntame.

- Nada, te llamaba para saber cómo va lo mío. Hace ya varias semanas que no sé nada de vosotros y la fecha de entrega que acordamos se va acercando.

- Sí, iba a llamarte esta semana. Ha habido algún problema en el proyecto y creo que tendremos que retrasarla unos días.

En estos momentos es cuando el cliente se queda perplejo, sin saber qué decir, y se empieza a temer lo peor. Se afloja el nudo de la corbata, unos segundos de silencio y la comunicación se reanuda.

- ¿De cuánto tiempo estamos hablando? – Los nervios se notan en el tono de voz del cliente.

- Bueno, es difícil de cuantificar ya que unas librerías que habíamos comprado para tu proyecto, y que nos iban a permitir acelerar el desarrollo, finalmente no han resultado adecuadas. Además, he tenido a uno de los programadores de baja, y el gerente de organización no me ha puesto un sustituto.

La lista de excusas sigue, y la conversación empieza a tomar un carácter agrio, con acusaciones mutuas, amenazas de demanda, etc.

Seguro que más de uno ha vivido esta situación.

¿Cuál es el problema?

Muchos dirán que la falta de capacidad para afrontar los riesgos, o no haber realizado un estudio adecuado de herramientas, o una mala planificación.

Sin embargo, considero que la principal causa del cabreo del cliente está en la falta absoluta de información. No sabía en qué estado se encontraba su proyecto, ni todos los problemas surgidos, ni que no se había dado solución.

Para un cliente, su proyecto es el más importante del mundo, y quiere/necesita estar tranquilo.

Está claro que los inconvenientes se producen, y que pueden aparecer problemas que impacten de manera directa en la planificación de un proyecto. La mayor parte de los que trabajamos en este ámbito, tanto clientes como proveedores, somos conscientes de ello. Sin embargo, todos precisamos tener la información lo antes posible, para poder actuar de manera eficaz y oportuna.

Es un grave error callar y ocultar los problemas puesto que se terminan notando, bien en la fecha de entrega, o en el alcance de las funcionalidades, o en la calidad de los resultados, o en todos a la vez.

Si ocurre una situación que prevemos que va a tener impacto en cualquiera de las tres variables fundamentales de un proyecto (coste, plazos, alcance) entonces lo mejor es comunicarlo, pero siempre teniendo en cuenta que hay que plantear una solución creíble y que pueda satisfacer a nuestro cliente. En caso contrario, no estamos sino aplazando el problema y jugando, en el peor de los casos, con la cuenta de resultados final y una posible demanda por incompetencia.

¿Qué opináis? ¿Conviene advertir de que no seremos capaces de cumplir los compromisos adquiridos? ¿O es mejor esperar a que el cliente se dé cuenta y actuar entonces?

En el ataque se han descubierto unos datos realmente comprometedores para los investigadores, datos que luego se han hecho públicos y que se están investigando.

La noticia apenas ha tenido repercusión, no sé si por interés o por desinterés, y en aquellos medios en los que se ha hecho referencia, lo más curioso es que se han centrado más en el ataque que en la importancia de los datos revelados. Ignoro si a nadie le interesa poner en tela de juicio el cambio climático o en realidad venden muchos más periódicos si el titular hace referencia a un ataque informático.

Esta noticia no es muy diferente de otras similares, en las cuales se descubre información muy relevante, y que son tratadas desde un punto de vista sensacionalista. No importa qué se encuentra, sino cómo se ha accedido de manera intrusiva.

Lo peor es la sensación negativa que están generando hacia el mundo informático. Para el que no tenga conocimiento de las posibilidades que ofrecen los ordenadores, seguro que piensa “estos informáticos, siempre tocando las narices y haciendo el mal”. Somos el demonio.

Sin embargo, ésta no es la única consecuencia de tratar de manera sesgada a todo un colectivo, sino que mucha gente se está acostumbrando a culpar a la informática de su ineficiencia o su ineptitud. ¡Cuántas veces hemos oído “ha habido un fallo en el sistema informático y no he podido tramitarlo”!

Nos hemos convertido en los culpables de los males de la humanidad, y seguro que nos acusarán tarte o temprano de que a Manolete lo mató un informático ahogándolo con el cable del ratón.

Lo más graves es que nosotros mismos hemos creado parte de las causas ya que la calidad del software es, en muchas ocasiones, realmente deficiente. Entregamos productos mal probados, inacabados, tratamos al cliente como un ignorante que no conoce ni su propio negocio, cobramos barbaridades por servicios inútiles, regalamos proyectos increíbles a precios ridículos, etc. Seguro que todos somos capaces de listar una buena cantidad de proyectos en los que hemos participado y que estaban condenados a causar problemas en el cliente, casi antes de empezar.

Es muy complicado ofrecer un proyecto de software que no tenga fallos y que se ajuste a lo que el cliente desea, por múltiples razones. Sin embargo, si nosotros mismos no nos imponemos unos mínimos de calidad, y unas condiciones básicas de trabajo que nos permitan ser considerados como profesionales, seguiremos sufriendo el menosprecio de gran parte de la sociedad, ya que continuarán viéndonos como gente extraña a la que no comprenden pero que les causan problemas.

Mientras conseguimos cambiar esta tendencia y hacernos valer, tendremos que seguir siendo los malos de la película, viendo cómo cualquier presupuesto o solución resultan excesivamente caras, y cómo todo es culpa del sistema informático, incluso aunque éste no exista realmente.

En esa combinación de fuerzas es necesario, además, que los diferentes egos, miedos, esperanzas, aspiraciones, y cualquier otro componente emocional, se adapten a la organización. Esta es la parte más difícil de coordinar y gestionar, puesto que no pertenecen al mundo de lo tangible, sino que es necesario dar respuesta a todos ellos de manera que en ocasiones hay actuar más de padre que de jefe.

Sin embargo, hay ocasiones en las que el equilibrio se rompe, y una de las causas más habituales es la rumorología que aparece por los motivos más insospechados.

Hay múltiples razones que pueden ocasionar que un rumor se extienda, pero todas tienen, en mi opinión, un denominador común: el miedo al cambio.

¿Qué hacer cuando un rumor se extiende por la empresa y afecta al normal rendimiento del equipo? Hay dos posibles soluciones: dejarlo estar y esperar a que se diluya; o bien cortarlo de raíz.

Personalmente creo que lo mejor en estos casos es acabar con él cuanto antes ya que, con el tiempo, suele ser como una bola de nieve que engorda conforme más vueltas da. Me recuerda a la higuera estranguladora, que crece en las selvas tropicales a la sombra de otro árbol y termina por matar al huésped conforme más crece la higuera.

Lo malo de los rumores no es que existan, ya que es inevitable, sino que se desvirtúa conforme pasa cada minuto ya que cada uno de los afectados aporta su granito de arena, ajustándolo a sus propios miedos. Así, al cabo de un par de días, y tras varios cafés en común, todos los integrantes del equipo son conocedores de una mentira a la que han dotado de una veracidad mayor que cualquier otra afirmación que se pueda hacer.

¿El resultado? Que se pierden demasiado tiempo en darle vueltas al rumor, baja la productividad y el miedo puede hacer que algunos de los integrantes del equipo decidan que esa situación no es la que quieren y pueden decidir tomar un nuevo rumbo profesional.

Los mejores proyectos son aquellos en los que no hay sobresaltos desde que se comienzan hasta que se son entregados. Sin embargo, esta visión es utópica por lo que, ya que los riesgos y los imprevistos son inevitables, tratemos de minimizarlos todo lo que podamos.

Al final, da a entender que son los jefes los que, generalmente, pasan los días sin dar un palo al agua, esperando a que los demás resuelvan los problemas que en realidad ellos deben solucionar.

Aunque debo confesar que me ha hecho gracia, creo que el enfoque es erróneo. Solemos pensar que los jefes no hacen nada, que están todo el día en su despacho pasando las horas y pensando en nuevas formas de tortura laboral, con las cuales hacernos la vida imposible. Sin embargo, la mayor parte debemos presentar unos resultados satisfactorios, elaborar informes de múltiples tipos, solucionar conflictos, hacer las veces de sicoanalista, consejero, señor del látigo, etc, etc

En ocasiones debo reconocer que puede llegar la situación a asemejarse a la descrita, ya que el poder nos cambia a todos, lo queramos o no. Sin embargo, me resisto a pensar que esto ocurre de manera generalizada, ya que, por experiencia propia, he visto que la mayor parte de los casos la evolución hacia puestos de responsabilidad se hacía de manera natural y sin consecuencias despóticas.

A pesar de ello, en las grandes organizaciones sí suele existir un escalafón que se puede ajustar a la fábula presentada en el blog antes mencionado. Suelen ser determinados mandos intermedios, de los que nunca se sabe qué hacen exactamente, ni a quién rinden cuentas, ni a qué departamento pertenecen,  ni otros datos habituales en cualquier empresa normal. Sin embargo, son capaces de dar órdenes a otros empleados, de hacer ver que están extremadamente ocupados, de tomar varios cafés a lo largo del día sin que nadie se extrañe por ello, y desarrollan una habilidad extraordinaria para el escaqueo y el buen vivir dentro de la oficina.

Este tipo de personas son extremadamente peligrosas, puesto que no sólo estamos gastando una parte de los recursos de la empresa en mantener su salario (no suele ser pequeño) sino que el riesgo de “contagio” a otros empleados es grande. Cuando ves que tu vecino vive bien, hace poco o nada, y nadie le llama la atención, sueles terminar imitando las mismas costumbres, a pesar de que inicialmente puedas resistirte. Ello empieza a contaminar la estructura y la productividad de la empresa y termina convirtiéndose en un problema crítico de manera más o menos rápida.

Para los gestores, sean de proyectos, departamentos o de empresa, es fundamental detectar a esta clase de empleados, vividores del cuento, y tratar de apartarlos cuanto antes porque si no, en el futuro, el número de personas productivas será mucho menor que aquellos que vivan en la máquina del café.

¿Conoces algún caso como el descrito? ¿Te has sentido tentado a seguir su ejemplo? ¿Cómo se podría solucionar este problema?

En el mundo de la tecnología hay clientes buenos, regulares, malos, y terribles. No se diferencia mucho de otros negocios. Sin embargo, en nuestro ámbito se unen dos agravantes: la ignorancia que existe acerca de la informática y, por otro, lo intangible del resultado de un proyecto.

El primero de los factores, el de la ignorancia, creo que está cambiando paulatinamente, ya que en los puestos directivos de los departamentos de informática se están situando técnicos con cierta experiencia que entienden la problemática de las empresas de servicios de tecnología. Sin embargo, estas personas se encuentran, por lo general, bajo la presión de otros directivos que ni entienden ni quieren comprender la complejidad que supone realizar un cambio de requisitos, o acortar plazos, o cualquier otra circunstancia que afecte a la planificación inicial de un proyecto.

En estos casos, la presión y las exigencias se trasladan de manera directa al proveedor. Hay un interesante artículo al respecto que he leido en el blog de PresiónBlogosférica

Por otra parte, el hecho de que, salvo la parte de hardware, los proyectos informáticos sean algo intangibles, es un handicap para nuestra profesión. Hasta hace unos meses participé en un proyecto de más de siete millones de euros de presupuesto, el cual, una vez realizado, podría presentarse en un lápiz de memoria convencional. Casi cien personas involucradas, cuatro localizaciones de los equipos de desarrollo, años de trabajo, para verlos resumido en una simple memoria usb.

El hecho de que los clientes no puedan tocar el software, ni ver grandes máquinas de construcción, ni decenas de operarios, le crea la impresión de que no cuesta nada hacer las cosas. Si se trata de hacer una carretera, la gente entiende que el asfalto, las excavadoras, los operarios, las señales, cuestan dinero y que el proceso de construcción es complejo.

Estos condicionantes debemos asumirlos como propios de nuestra actividad, y es necesario que los aceptemos como inevitables. Sin embargo, es preciso que nosotros mismos seamos capaces de “educar” al cliente, haciéndole ver que el desarrollo de software es una actividad compleja que requiere las mismas consideraciones que cualquier otra rama de la ingeniería. No es un trabajo sencillo, y hay que tener en cuenta que nuestra profesión es relativamente joven, por lo que todavía nos queda tiempo para lograrlo.

Sin embargo, durante el ciclo de vida de un proyecto ocurren numerosos imprevistos. En el mundo del software éstos pueden ir desde la marcha de un técnico del equipo, a problemas de hardware con un servidor o un ordenador de trabajo, periodos de baja, reasignación de recursos, o aspectos tan simples como problemas de software (liberías de terceros que no hacen lo esperado, se corrompe la IDE, fallos de configuración inexplicables, etc).

burbuja

Todos estos son elementos que tienen un impacto claro en la planificación prevista, de modo que implican una modificación del plan general. Es en este momento cuando la burbuja que rodeaba al proyecto empieza a temblar, o incluso se rompe, y es necesario admitir que alguna o todas las variables inicialmente previstas, van a sufrir desviaciones.

En el caso de que los problemas surgidos sean responsabilidad del proveedor, lo más conveniente suele ser asumirlos y tratar de negociar unas nuevas condiciones para el proyecto. En caso contrario, los problemas se irán convirtiendo en bolas de nieve, cada vez más difíciles de parar. No es posible mantener un engaño durante mucho tiempo, y tarde o temprano el cliente pedirá realizar una revisión y se verá que el grado de avance declarado no es el adecuado, o la estabilidad del proyecto no es la esperada.

A menos que estemos totalmente seguros de que somos capaces de reconducir la situación que ha ocasionado el problema sin poner en riesgo ninguno de los tres pilares fundamentales del proyecto,  debe seguirse una política de sinceridad como norma habitual, la cual afiance la confianza mutua que debemos ser capaces de crear con nuestro cliente.

Si los problemas están ocasionados por el cliente, la situación es más complicada de gestionar, puesto que hace falta ser habilidoso para hacerle entender que no ha cumplido su parte del trato, y que resulta imprescindible la implicación de todos para poder llevar el proyecto a buen término.

De nuevo la mejor política es la sinceridad, sentarse juntos a revisar el avance del proyecto y ser claros a la hora de establecer responsabilidades y fijar soluciones. El cliente deberá comprender que no podemos ayudarle a llevar a cabo sus planes si no se deja ayudar. Los proyectos que para él vamos a desarrollar tendrán un impacto en sus procesos, en su personal, en su relación con sus clientes o proveedores, etc y por eso requiere de su esfuerzo y su colaboración, no debe desentenderse del mismo esperando que el proveedor adivine sus necesidades o deseos.

Los engaños siempre terminan siendo descubiertos, y existe un punto de no-retorno a partir del cual el desastre está asegurado, siendo la situación ya muy difícil de reconducir. Todas las partes suelen resultar perjudicadas, ya sea por el esfuerzo y la ilusión invertidas, o bien por el gasto material realizado. Hay que evitar llegar a este punto siempre que sea posible.