A raíz del mismo, mantuve una interesante conversación con un compañero de trabajo en la cual estuvimos hablando de la importancia de la pruebas y del poco rigor que en ellas se aplicaba, con la consecuente falta de calidad.

Él sostenía que, en general, era problema de dejadez de los integrantes del equipo, especialmente los programadores, y de la falta de tiempo.

Sin embargo, aunque para mí son factores que sí son importantes, no creo que sean los fundamentales.

A menudo, en un proyecto y de manera repetitiva se oye la frase “tenéis que probar”. Pero, realmente, ¿el equipo sabe qué significa?

La respuesta habitual, cuando le preguntas a un programador, es “claro que he probado”. ¿Y qué ha probado? Pues el camino de baldosas amarillas. Es decir, el camino ideal 1-2-3 pero no ha considerado otras opciones alternativas y más rebuscadas.

Esto se produce, en mi opinión, por tres razones principalmente: por falta de tiempo, por dejadez, y, sobre todo, por ignorancia.

Como véis, coincido en las dos primeras con los argumentos que mi compañero esgrimía, pero pueden llegar a ser secundarios al lado del tercero.

La falta de tiempo suele ser inherente a un proyecto. Debemos asumirlo y cubrir ese riesgo de la mejor manera posible. La manera de hacerlo dependerá de las características particulares del propio proyecto y servirá como argumento para otro artículo futuro.

Que un integrante del equipo no asuma la responsabilidad de las pruebas suele advertirse pronto, ya que con la primera acción (pulsar el botón Aceptar, rellenar un campo obvio, etc) saltan errores. Tiene sólo dos soluciones: se reconduce o se aparta. En cualquier caso, debe ser un riesgo a eliminar.

Sin embargo, la tercera razón, la ignorancia, requiere un esfuerzo adicional para corregirla aunque si se logra, los resultados son excelentes. Resulta la mejor inversión de cara al futuro.

En nuestra formación técnica nos enseñan a crear procedimientos, a comentar el código, a utilizar correctamente la sintaxis del lenguaje de programación, a realizar diagramas de gantt, etc pero ¿nos enseñan a probar? Yo creo que no. Es más, se repite una y otra vez la frase de “hay que probar más”. Bien, pero ¿cómo? Un programador prueba, claro que prueba, pero ¿lo hace correctamente? ¿Sabe él que lo está haciendo mal? ¿Conoce la manera de hacerlo?

La respuesta es, en general, única: NO.

Nadie nos enseña a probar. Aquellos que lo hacen bien es porque han seguido un proceso de autoaprendizaje, basado en un espíritu crítico y en la creencia de que una hora invertida en solucionar problemas en desarrollo son muchas más que nos ahorramos una vez puesto en producción.

Personalmente, cuando programaba, me ponía muy nervioso tener incidencias, ya que, por un lado, cuando llegaban solían interrumpir el proyecto que estuviera haciendo en ese momento, y eso solía causar, o bien retrasos, o un esfuerzo extra por mi parte. Por otro lado, tener una incidencia es como una marca señalando que has hecho algo mal y que te has equivocado. Detesto equivocarme.

Sin embargo, no se puede esperar esta reacción de todo el mundo. A veces hay que provocar la chispa.

¿Cómo hacerlo?

Hay muchas maneras, pero las meras palabras no son suficientes. Hay que recurrir a los hechos.

Personalmente, una práctica que creo que resulta extremadamente útil es reunirme a revisar con el programador lo que ha implementado y probarlo juntos. Prefiero que sea él quien maneje el ratón y el teclado, de manera que, cuando le pido hacer algo que no ha probado o que ni siquiera ha contemplado, se nota vacilación y cara de “uy, espero que no falle…”. Además, cuando la ventana o el proceso fallan, son conscientes de que por mucho que crean que han probado, se han dejado cosas por el camino.

De esta manera, creo que ambas partes ganamos:

- yo reviso las funcionalidades de los módulos y puedo conocer detalles incluso de implementación que, en ocasiones, sólo el programador tiene frescos.

- el programador aprende a probar. Ve que hay muchas alternativas aparte de las que él había considerado y, seguramente, en la próxima revisión, los trucos que ahora ha visto que uso para probar, los casos raros, etc los tendrá en cuenta, aunque sólo sea para no quedar en evidencia. Poco a poco la frase “sí, he probado” tendrá más veracidad e incluso él se fiará más de su propio trabajo.

Probar una aplicación es complejo, y de hecho hay toda una rama de la informática dedicada al estudio de métodos y herramientas de test. El objetivo de este artículo no es entrar a profundizar en estos aspectos, sino sólo concienciar a todos los que participamos en proyectos que, si nadie nos dice lo contrario, lo normal es que seamos como Dorothy y vayamos por el camino de baldosas amarillas, todo ideal y maravilloso.

Desgraciadamente, los usuarios son más como el conejo blanco, que va saltando de un lado para otro, sin ningún sentido. Por lo tanto, hay que pensar como ellos y estar preparados para el caos.

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?

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?

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.