Las letras que figuran en la cabecera significan Last In, Marrón Get, que traducido al castellano significa “el última la pringa”.

¿Qué comportamiento se define bajo estas siglas?

Aunque hoy en día es más frecuente el proceso contrario, todavía hay empresas que incorporan a nuevos trabajadores a su plantilla, de modo que los hacen partícipes de los diferentes engranajes de la compañía, se encuentren éstos más o menos engrasados.

Cuando una empresa decide incorporar nuevas personas a su plantilla debe enfrentarse a dos problemas:

1. En primer lugar encontrar a la persona adecuada, aunque en la mayor parte de las veces no deja de ser como jugar a la lotería sabiendo sólo 1 de los 6 números.

2. Una vez ha escogido, se enfrenta al que en mi opinión es un problema todavía más importante: encajarlo en la estructura organizativa.

Generalizando, hay dos tipos de perfiles: directivos, y el resto. Sin embargo, a pesar de que la problemática de cada uno es particular a los cargos que se desempeñen, ambos comparten un riesgo en común, y es el de LIMG.

¿Por qué?

Salvo excepciones, las empresas se piensan mucho y retrasan todo lo que pueden la incorporación de una nueva persona, ya que supone un gasto extra, es un riesgo nuevo, y requiere recursos tanto para su captación como para su integración y desarrollo.

Por ello, cuando ya los empleados que hay en ese momento se encuentran desbordados de trabajo, es cuando se decide la contratación de alguien nuevo. ¿Qué ocurre entonces? Alguien se plantea las tareas, cometidos y responsabilidades que tendrá la persona que se incorpora, y por una extraña razón, aparecen temas que llevaban enquistados mucho tiempo, sin avance, que parecían olvidados en el limbo de las tareas bien porque no había tiempo, o interés o ganas de hacerlas, bien porque nadie las había reclamado.

En ese momento, si los empleados son suficientemente hábiles, se produce un traspaso de tareas (brown-giving-day) de manera que cuando llega la nueva persona, por arte de magia tiene un montón de asuntos que resolver. Es decir: Last In, Marrón Get.

Obviamente, es un error proceder así, al menos de forma tan radical.

En mi opinión, es bueno que las personas que se unen a una empresa cuenten con tareas preasignadas de antemano, ya que a todos nos gusta sentirnos útiles (sé que corro el riesgo de equivocarme al generalizar) y también ayuda a aprender tanto el funcionamiento interno de la compañía a la que se incorporan como a conocer la gente que forma parte de ella, y todos los que se relacionan de alguna manera con la empresa.

Sin embargo, para que la evolución del nuevo empleado sea la correcta es necesario elaborar un plan de “integración” que le permita incorporarse de forma paulatina en su nuevo sitio. Ese plan, entre otras cosas, deberá contener una descripción del puesto y sus responsabilidades, las personas encargadas de supervisar y evaluar su progresión, los criterios a aplicar, fases por las que va a pasar y objetivos de cada una, y, en general, toda aquella información que nos permita planificar adecuadamente la incorporación del nuevo empleado.

Sólo así, y unido a sus capacidades personales e intelectuales, se podrá lograr que en lugar de conocer uno de los números ganadores de la lotería, podamos tener en nuestro poder un boleto con premio.

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.

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?

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?

Según la Wikipedia: “Se denomina inteligencia empresarial, inteligencia de negocios o BI (del inglés business intelligence) al conjunto de estrategias y herramientas enfocadas a la administración y creación de conocimiento mediante el análisis de datos existentes en una organización o empresa .”

Está muy bien la definición y es la que habitualmente se utiliza cuando se usa ese concepto. Sin embargo, no creo que eso sea inteligencia de negocio. Cuando se habla de BI no se hace referencia a nada más que una serie de aplicaciones informáticas, reglas y resultados que terminan representados por un conjunto de informes acerca de tendencias o predicciones futuras. Se basan en datos históricos y sistemas predictivos más o menos elaborados. Lo cierto es que todavía estamos lejos de lo que yo realmente considero que es BI.

Durante mi vida profesional he conocido a gente que iba un paso por delante del mercado, siendo lo suficientemente previsor como para ocupar nichos de negocio de manera oportuna y eficaz. Generalmente se basan en dos factores: la información de la que disponen; y lo que se suele llamar “olfato”.

Se relacionan con muchas personas, escuchan gran parte del tiempo, son capaces de separar la paja del grano, y con una visión clara de lo que realmente se dice entre líneas.

Además, tienen una capacidad innata para saber qué tendencia va a seguir el mercado, antes incluso de los primeros síntomas, ya que pueden intuir los cambios y subirse a la ola en el momento justo.

A pesar de ello, muchas veces incurren en dos problemas: tienen un ego tan grande que no les permite admitir errores y, por otra parte, suelen dispersarse entre multitud de asuntos, de manera que precisan de un equipo muy bien coordinado y autosuficiente, al que poder dar indicaciones en apenas un minuto y, con ello, ser capaz de entender los objetivos y cumplirlos sin tener que hacer un seguimiento continuo.

Puede parecer que hablo de superhéroes o algo parecido, pero estoy seguro de que todos conocemos a gente parecida, puesto que en la mayor parte de las organizaciones más importantes suele haber alguna (no necesariamente en los puestos directivos más altos). Su labor es lo que yo considero verdadera Business Intelligence

¿Conocéis a alguna persona que se ajuste a esta descripción? ¿Es vuestro superior inmediato? ¿Es fácil trabajar con él/ella?

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.

Hemos acudido a varios de ellos, todos relacionados con aplicaciones o servicios informáticos, y cuya temática es realmente variada: desarrollo de plataformas de movilidad, implementación de portales institucionales, prestación de servicios de asesoría, etc.

Resulta realmente dura la elaboración de una buena oferta, ya que requiere muchísimo esfuerzo por parte de un equipo multidisciplinar, como son administrativos, comerciales y técnicos. La cantidad de horas necesarias, traducidas a dinero, es ingente puesto que no sólo hay que sumar el dedicado por todas aquellas empresas que concurrimos a cada uno de los concursos.

En algunos de los concursos hemos participado en UTE de manera que pudiéramos complementarnos para realizar una oferta más competitiva. El tiempo dirá si ha sido una buena opción o no, ya que el tema de las uniones de empresas dará para un futuro artículo, ya que personalmente las miro con mucho escepticismo. Por ahora ha sido positiva y nos ha ayudado a lograr los objetivos marcados.

El tema de los concursos públicos ha sido una novedad para mí puesto que aún no había tenido la oportunidad de participar en la elaboración de ninguna oferta.

Mi labor ha sido estrictamente técnica y de revisión. La mayor parte de mis horas de trabajo han transcurrido durante la noche, ya que no es posible ni adecuado descuidar el trabajo de proyectos actuales por la posibilidad de un contrato futuro. Otros compañeros sí han podido dedicarse a tiempo completo para realizar diversas ofertas, lo cual nos ha permitido abarcar un mayor número de ofertas.

Muchas horas empleadas, robadas a las horas de descanso, a fines de semana y a momentos de familia. Afortunadamente el resultado ha merecido, por ahora, la pena y ya hemos ganado varios de ellos.

Las conclusiones personales que he extraído de todo el esfuerzo realizado son:

1. Si no tienes posibilidades de ganar, entonces no merece la pena perder más tiempo del necesario para leer el pliego.

2. La mejor forma de ganar es presentar una oferta impecable, ajustar cada uno de los criterios solicitados en el pliego, y contar con una imagen de empresa muy positiva.

3. Deben estar implicados todos los estamentos de la empresa: la dirección para asumir el coste que va a suponer, los comerciales para aportar los efectos de imagen y de venta que los técnicos no solemos dar, los profesionales con experiencia técnica que sepan dar una respuesta eficaz a los requerimientos de la administración pública convocante, y la gente del departamento de administración para elaborar la documentación.

4. Sólo una oferta gana, por lo que el dinero perdido por todas las demás que se presentan al concurso es enorme y supone un esfuerzo no despreciable que debe ser considerado, puesto que es tiempo robado a otras labores como búsqueda de clientes, mejora de procesos, investigación, etc.

5. Por mucho tiempo que se disponga, termina siendo todo entregado a última hora, como los proyectos, puesto que siempre pueden surgir mejoras, retoques, o cambios que permitan presentar una oferta mejor.

¿Cuál es vuestra experiencia en la elaboración de ofertas para administraciones públicas?

¿Es planteable otro modelo para la adjudicación de proyectos o contratos de servicios por parte de la administración pública?

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.

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