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.

Lo cierto es que me gusta, ya que da una idea exacta de lo que pasaría si un simio tuviera un arma cargada, especialmente si decidiera usarla. Nadie sabe a qué dispararía, ni cuántas balas, ni habría posibilidad de predecir sus consecuncias.

Estas navidades le regalaron a mi hijo un juguete compuesto por dos piezas: una especie de cubo en el que cada cara tenía un juego, con música, con piezas, unos muñecos para darles vueltas…; por otra parte, sobre el cubo se pone un juego de alambres de colores, con piezas de plástico que hay que mover de un extremo a otro.

Está claro que nosotros, como adultos, tenemos una idea exacta de cómo hay que jugar, y que las piececitas hay que desplazarlas a lo largo del alambre, y que la estrellita entra en el hueco de la estrellita, y que dándole al botón naranja sonará música.

Sin embargo, mi hijo aporrea el cubo, le da vueltas a una bola que hace ruido, castiga a los muñequitos, y se pone como sombrero los alambres cuando le apetece, o lo castiga sin misericordia.

¿Por qué? Porque no sigue el razonamiento lógico de quien inventó el juguete, ni las normas que todos hemos aprendido a la hora de jugar. A él le gusta golpear el juguete, aunque ignoro la razón, y le gusta volcarlo, y no mete las piezas en su hueco, sino que las agita y luego las aparta.

Si nos paramos a pensar, seguro que encontraremos un paralelismo con los usuarios de las aplicaciones informáticas

Lo que pasa es que son muy parecidos monos con pistolas y a los bebés: impredecibles.

La gente que diseñamos e implementamos sistemas informáticos tenemos en la mente una manera de utilizar los componentes, y un método muy estructurado de navegación a través de las pantallas: primero A, luego B y como resultado C.

Sin embargo, lo primero que aprendí yo cuando trabajé en mi primer proyecto fue que esto no se acerca a la realidad. Los usuarios para los que tenía que diseñar el sistema apenas tenían formación en informática, por lo que todo debía ser fácil, intuitivo y sin margen de error, puesto que se jugaban el tener o no agua para regar los campos.

Hay varias leyes que se cumplen y que es necesario tener en cuenta, tanto a la hora de plantear la solución como en el momento de implementarla y probarla:

- Si algo se puede pulsar, aunque no sea conveniente, el usuario lo pulsará. La funcionalidad más utilizada puede llegar a ser un botón que ponga “No pulsar”.

- Aunque creas que el usuario lee los mensajes de advertencia, tranquilo, nunca lo hará, a no ser que lo destaques en rojo y le provoques un ataque de pánico. Aún en ese caso, no hay nada seguro.

-El botón Aceptar y Siguiente provocan una misteriosa atracción que el usuario no puede rechazar.

- Si quieres que haga A-B-C entonces no le dejes hacer nada más. No son buenos chicos. Tampoco malos, sólo curiosos.

- Una vez le has enseñado a hacer algo, no lo toques. Aunque la pantalla que cambies funcione bien, cualquier error que ocurra será culpa “del nuevo sistema”.

- Puedes hacer la mejor aplicación, pero si no tiene colores e iconos, seguramente no servirá.

- Innovar está muy bien, pero no esperes que los usuarios compartan tu punto de vista. Está muy acostumbrados al güindous, la excel y el güord, así que procura darles cosas parecidas o que no les suponga tener que buscar por toda la pantalla cómo se hace algo.

Seguro que hay más normas generales (podéis aportar las que consideréis oportuno) pero creo que éstas son importantes y bastante generales.

Recordar la metáfora de los monos y la pistola suele ser my útil si queremos evitarnos digustos, problemas e incidencias fantasma.

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.

Más allá de que me guste el personaje y me resultara entrañable verlo de nuevo en la televisión, me llamó la atención la frase e inmediatamente me vino a la cabeza la actividad de ingeniería, informática en mi caso.

¿Qué tiene que ver un tío que hacía artes marciales con los informáticos? Mucho y nada.

Obviamente, nada en cuanto a tipo de actividad, si dejamos a un lado el hecho de que algunos clientes nos pidan cabriolas, patadas voladoras e incluso la llave del dragón en algunos de los proyectos.

Sin embargo, creo que nos identificamos claramente en cuanto a que, con esa frase, Bruce Lee se refería a que hay que adaptarse a las circunstancias de cada combate, y de la vida en general, igual que lo hace el agua, que se amolda al recipiente que la contiene.

Cuando trabajas en una empresa informática, muy a menudo es necesario aplicar dicha adaptación lo mejor posible.

¿Por qué?

Es habitual que un jefe de proyecto o un analista funcional estén involucrados en diversos proyectos, ya sea al mismo tiempo o de manera sucesiva.

El tipo de clientes varía sustancialmente, y podemos encontrarnos desde una empresa dedicada a la venta de juguetes, o bien un grupo cuya principal actividad es la minería, o sistemas de gestión tributaria, o procesos documentales, etc. Esto implica que, aunque realmente no conozcamos el negocio del cliente, debemos adaptarnos a sus circunstancias, entenderlo de la manera más rápida posible, y darle soluciones a los problemas que tienen detectados.

Sin embargo, generalmente se espera de nosotros un paso más, y es que les ayudemos a mejorar los procesos que tienen implantados, ya sea proporcionando las herramientas necesarias, ya sea realizando incluso una reingeniería de los mismos.

Es decir, que en cada nuevo proyecto y ámbito de actividad nos adaptamos al recipiente que conforma la empresa de nuestro cliente.

Esta adaptación tiene, no obstante, dos consecuencias:

1. Realmente no somos especialistas en nada en particular, pero sí conocemos diversos negocios, pudiendo incluso importar procesos o buenas prácticas de unos a otros. Sin embargo, generalmente lo que está mejor remunerado es la especialización, por lo que el hecho de ser tan transversales en ocasiones tiene un efecto directo en la cuantía de la nómina.

2. Genera un tipo de estrés, funcional en este caso. El hecho de tener que estar aprendiendo continuamente nuevas formas de negocio, nuevas problemáticas, y nuevos métodos supone un desgaste importante, por lo que debe regularse la dosis, como en los medicamentos.

Sin embargo, a pesar de todo ello, considero que esta capacidad de adaptación debe ser una de nuestras grandes señas de identidad como ingenieros, puesto que será una de las maneras en las que podamos obtener el reconocimiento profesional que todos buscamos. Tenemos que pasar de ser “los informáticos que me arreglan el ratón” a “los informáticos que me ayudarán a encontrar una solución”.

¿Qué pensáis? ¿Es mejor especializarse en un ámbito concreto de actividad o es mejor conocer un poco de cada negocio y así ganar en capacidad general? ¿Realmente tenemos los informáticos una oportunidad de mejorar nuestra imagen siendo una fuente de soluciones a la que todos acudan?

- 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?

Cuando hablamos de proyectos informáticos, son varias las propiedades que esperamos de ellos, como son: ausencia de incidencias, código fuente con comentarios, eficiencia en los procesos, velocidad de respuesta adecuada, usabilidad, estilos gráficos trabajados, etc. Cada uno damos más importancia a una u otra característica, pero buscamos todas ellas puesto que somos conscientes de que, si existen, las probabilidades de lograr un proyecto con éxito son mayores.

Sin embargo, son muchos los obstáculos a los que tenemos que enfrentarnos en el día a día del proyecto, y que provocan retrasos, errores, etc: falta de experiencia, plazos demasiado ajustados, baja productividad, requisitos imposibles… y un sinfín de problemas que todos conocemos.

¿Qué hacer entonces? ¿Nos rendimos y asumimos que es imposible obtener productos con la calidad suficiente? ¿Cambiamos de actividad? ¿Quemamos los ordenadores y volvemos a hacer muchas cosas manualmente?

Está claro que la respuesta a todas esas cuestiones debe ser negativa.

En mi opinión, hay dos factores que influyen notablemente en todos los problemas de calidad de los proyectos:

1. El factor humano: en el sector tecnológico, especialmente en la parte de desarrollo, es un factor fundamental puesto que muchas de las tareas dependen del conocimiento, de la motivación e incluso de la inspiración de quien las realiza.

Existe una radical diferencia entre poner un tornillo de un coche o desarrollar una pantalla para realizar una integración con algún sistema de producción. En la primera de las tareas apenas tiene influencia la motivación o la inspiración o la formación, pero en la segunda pueden marcar una clara diferencia entre el éxito y el fracaso.

2. El factor cultural: el ámbito tecnológico que nos rodea es relativamente joven, y más si tenemos en cuenta que fue realmente a finales de los 90 cuando hubo un verdadero boom con la expansión de internet, la compra masiva de ordenadores, y un auténtico desarrollo de tecnologías móviles.

Esta juventud implica, necesariamente, que ni nuestros clientes tienen asumido qué significa realizar un proyecto informático, ni nosotros tenemos unos procesos lo suficientemente alejados del trabajo artesanal.

Si comparamos nuestro sector con uno ya asentado y maduro (algunos dirán que demasiado maduro) como es el del automóvil, las diferencias son claras:

- cuando uno compra un coche, asume ciertas limitaciones, y que los añadidos son los que aparecen en el catálogo. Si deseas cosas extraordinarias, tendrás que “tunearlo” y pagar un alto precio por ello. Sin embargo, en un proyecto informático el cliente tiende a pensar que hay barra libre para hacer cambios y que apenas tienen coste.

- en la industria del automóvil existen robots que hacen multitud de trabajos de manera exacta y programada. Lo más parecido que tenemos en el mundo tecnológico son herramientas automáticas que nos permiten simplificar parte de las tareas: generación de código, pruebas, test de cargas… pero tienen muy poca implantación y son reinventadas una y otra vez.

- las pruebas de calidad que se realizan sobre los automóviles son intensivas y se invierte mucho dinero en seguridad y en confort. En cambio, en muchos de los proyectos informáticos, las pruebas se realizan si se puede, la palabra seguridad apenas se oye, y temas como usabilidad o accesibilidad pertenecen a esa extraña lista de deseos que se suelen pedir por Navidad.

Obviamente, hay muchas más diferencias, pero creo que éstas son las más significativas.

Necesitamos ganarnos la confianza de nuestros clientes/usuarios, y tenemos que lograr procesos cada vez más industriales. No debe ser admisible que construir un sistema informático sea más parecido a elaborar una cuchara de madera por el artesano del pueblo que un automóvil en una fábrica.

Para lograr este objetivo se pueden tomar varias medidas, la mayor parte de ellas muy sencillas, que comentaré en un próximo artículo. Sin embargo, cualquier sugerencia, anécdota y aportación será bien recibida.

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.

Tenemos muchos datos a nuestro alcance pero, ¿realmente estamos informados?

A mí personalmente me parece que no. El hecho de que continuamente nos bombardeen con noticias, novedades, promociones, anuncios, estadísticas, y otro tipo de valoraciones, me causa estrés, y en general nos está obligando a desarrollar una capacidad, cada vez más perfecta, de saber qué información es útil y cuál es muy probable que nunca nos vuelva a hacer falta.

Yo soy un lector compulsivo de todo lo que cae en mis manos, desde los típicos periódicos, libros, revistas… a folletos de información, anuncios en marquesinas, panfletos de publicidad, e incluso los papelitos del doctor Mubutu que con magia negra te arreglarán la vida.

Leo todo tipo de temáticas, desde temas tecnológicos a revistas de historia o negocios, suplementos de economía, blogs de actualidad y cotilleos, veo programas de televisión culturales y estrafalarios, chistes, etc. No soy escrupuloso en cuanto a cultura se refiere, creo que casi todo merece la oportunidad de emplear treinta segundos de mi tiempo para comprobar si realmente merece la pena.

Emplear más tiempo en un tema considero que tiene que estar realmente justificado ya que, en la vida que todos tenemos hoy en día, lo que menos nos sobra (después de los euros) es el tiempo. 

Creo que hago lo adecuado, devorando toda la información que puedo, pero la mayor parte de ella apenas deja poso en mi memoria puesto que realmente es absurda o innecesaria. No merece la pena preocuparse por cosas cuya probabilidad de ocurrencia o repetición es ínfima.

Sin embargo, sí considero que es una buena política a seguir de cara a incrementar la cultura personal. Restringirse a un tema es restringir la capacidad para mejorar.

Y esto, ¿cómo se puede aplicar a la gestión? Su relación es obvia. Cuando nos dedicamos a gestionar proyectos, vivimos situaciones de todo tipo, imprevistos a los que debemos dar respuesta, y es importante demostrar nuestra capacidad continuamente. Además, la temática de los proyectos puede ser muy variada. En los años que tengo de experiencia he tenido que gestionar proyectos de logística, de administración pública, de turismo, de tributos, etc.

Una buena cultura general es crucial para desarrollar nuestra labor de manera adecuada y saber afrontar los retos que, diariamente, se nos presentan.

- ¡Ah! Estupendo. Vamos a ver pues.

http://dominiodelaempresa.com/aplicacion/login

El cliente empieza a abrir un poco los ojos.

- ¿Esto qué es?

- Es la pantalla de entrada. Sólo los usuarios con permisos podrán acceder.

- ¡Ah, vale! Es cierto. Sigamos

Usuario. Clave. Enter y aparece el menú inicial, en unos colores modernos y discretos, iconos sencillos, elegidos con esmero.

- Pero esos iconos, son demasiado raros. No se parecen a los del Güindows.

- Ya, pero es que esos son bastante anticuados, y además, están protegidos por derechos de propiedad.

- ¡Ah, claro!

La primera piedra en el camino. Sigue la demo y el cliente, tras ver un par de listados y dos ventanas de detalle de entidades, suelta la famosa frase

- ¡Pero esto no es lo que queríamos!

También están las variantes: ¿qué nos estáis enseñando? / esto no nos sirve / creo que os habéis equivocado.

Este es un problema muy habitual, demasiado frecuente, en el desarrollo del software, y uno de los quebraderos de cabeza más grandes para los gestores, puesto que la aplicación suele estar acabada o muy avanzada, se ha gastado muchas veces más presupuesto del que sería deseable, y se esperaba una aceptación rápida del cliente para poder continuar o terminar con el desarrollo a una velocidad mayor que la llevada hasta ese momento.

¿Cómo podemos solucionarlo?

Hay varias técnicas, pero una de las que más me convencen personalmente es la elaboración de prototipos.

Puedo sentarme con el cliente durante horas para comentar cómo será la aplicación, qué hará, lo bonita que quedará, lo moderna que tendrá la apariencia, y lo rápido que se comportará. Sin embargo, habrá numerosos aspectos que no se habrán comentado, como los colores de la aplicación, las columnas de los listados, logotipos y posición, distribución de los menús, iconos a utilizar, tipos de letra, navegación entre ventanas, operativas especiales, etc

También podría hacer el esfuerzo de escribirlo en un documento y luego pasárselo al cliente, pero a todos nos ha ocurrido que después de hacer esto, y haber invertido numerosas horas, descubrimos que apenas le ha prestado atención a la espera de ver funcionar la aplicación real.

Creo que un prototipo resuelve la mayor parte de estas cuestiones, puesto que permite una revisión visual, se pueden discutir todos los aspectos importantes de la aplicación de manera práctica y el cliente tiene la sensación de estar tocando ya algo real (lo cual supone, por otra parte, un posible riesgo si piensa que ya está hecho). Además, algunas aplicaciones específicas permiten establecer anotaciones funcionales o técnicas, valores de especificación, navegación entre pantallas, reutilización de plantillas y componentes, y exportación a Word para poder realizar el documento que se entregue al cliente y éste firme.

Obviamente, no es la panacea, y siempre habrá aspectos que puedan ser dudosos o que ninguna de las partes ha terminado de aclarar. Sin embargo, el objetivo es, como siempre, reducir los riesgos todo lo posible. Con un prototipo se logra aclarar qué hay que hacer exactamente, fundamental para que un proyecto pueda llegar a buen puerto. En caso contrario, existen muchas probabilidades de ir dando bandazos, gastar el presupuesto y quemar al equipo.

¿Usáis el prototipado como herramienta de definición funcional? ¿Qué aplicaciones usáis para elaborar las maquetas?