Por orden de eficacia, en la comunicación con el cliente yo pondría: reunión cara a cara, correo electrónico y conversación telefónica. Siempre hay casos que rompan estas prioridades, pero de manera general, para resolver una duda o plantear una cuestión, para mi son éstas. En una llamada telefónica no concertada, no sabemos qué está haciendo la otra persona: si en ese momento está en el coche, reunido, en el lavabo, concentrado en otro tema… No queda nada por escrito y además, se puede dar la situación de que el interlocutor no haya cambiado correctamente de contexto, y seguramente diga “vale vale, aunque luego lo pienso mejor”, con lo que probablemente tenga que haber una segunda conversación.

Hay que partir de que escribir un correo electrónico planteando una duda, una especificación, al programador, al cliente, no es como hablar (si se quiere hacer bien, claro). Nos obliga a pensar detenidamente lo que queremos plantear y describirlo lo más claramente posible. Esto es un buen ejercicio porque al verlo plasmado en pantalla y releerlo podemos notar si no lo estamos expresando bien, si hay vacíos en el planteamiento, o en el mejor de los casos, encontrar la solución directamente al haber pensado más de un minuto en ello.

Normalmente, mis mejores clientes, con un correo planteando un duda basta para obtener respuesta y solucionarla. Cuando algún otro me dice la frase con la que empiezo el post, malo. O llamadas por cualquier cosa, que muestra que ni han leído el manual ni han perdido treinta segundos en pensar, o llamadas para explicarme una especificación que querrían, que óbviamente, si no han querido escribirla, es que no la tienen bien pensada, por lo que se explican mal por teléfono, se les plantean dudas, se lo piensan, vuelven a llamar, etc (pérdida de tiempo).

Intento dar incentivos a mis clientes si usan el correo electrónico, diciéndoles que les podré responder en pocas horas y evitando hacer malabarismos para contestar por teléfono si estoy ocupado en otra tarea.

¿Cuál es vuestro punto de vista?

La conclusión a la que he llegado es que no se puede aplicar a cualquier programa ni sobretodo, a cualquier cliente. Los que no desarrollan software, pueden no entender los pasos que se están dando al realizar la aplicación y llegar a entorpecernos involuntariamente.

Estos son los problemas con los que me he encontrado:

- El cliente no entiende que cuando hay algoritmos complejos, lo importante primero es validarlos y al final ya se comprobará que el usuario final entre los datos correctamente, se cambiará el aspecto de la interfaz, etc. Es decir, él debe vigilar que los datos que entra tengan sentido. Pueden empezar a llegar correos y llamadas sobre problemas en la interfaz o en que “me deja entrar un fecha incorrecta”.

- El cliente ve el armazón de la aplicación y se aventura a probar funcionalidades no terminadas todavía en vez de la pactada: correos y llamadas diciendo que la otra parte no funciona o que si ya se ha tenido en cuenta tal o tal aspecto cuando no es el momento de tratarlo.

- El cliente no entiende bien su rol, cree que es parte del equipo de desarrollo y puede llegar a enviar mails y llamadas a cualquier hora por cada fallo que crea haber encontrado, en vez de una lista por correo electrónico con todos los problemas tal y como se pactó.

- El cliente ve una aplicación que parece terminada y ya desea enseñarla a sus clientes, superiores, etc. Pero te pide que le acabes tal aspecto de la interfaz o tal funcionalidad (que todavía no toca) porque causará mejor impresión. Esto supone una gran pérdida de tiempo y en ocasiones trabajar dos veces.

Por lo tanto, aunque no sea culpa de él, ya que quizás le hemos asignado un papel que no le correspondía, nos hace perder mucho tiempo respondiendo llamadas, correos, dando explicaciones y desactivando opciones del menú que no debería probar.

Respondiendo a la pregunta del título, diría que vale, pero si conocemos bien al cliente y estamos seguros de que no entorpecerá el desarrollo de la aplicación.

Actualización: A raíz de un pequeño debate en plurk, aclaro que en ningún caso estos “tests del cliente” vienen a sustituir a los tests programados por el equipo de desarrollo.

Pues eso, he probado el nuevo navegador Chrome, con mucho cariño, y aunque al principio me entró por los ojos y tiene algunas soluciones muy buenas, no me acaba de hacer el peso. Ni mucho menos lo he probado a fondo ni he hecho benchmarkings ni he rebuscado todos los entresijos del navegador. He hecho lo que seguramente hará el 90% del público: navegar con él y ver si va rápido, ágil y no se cuelga. En este mundo actual con multitud de ofertas, hay productos a los que se les dan pocos segundos para que gusten. Por ser Google, éste tendrá más tiempo.  Pero tiene duros competidores y seguro que habrá usuarios a los que si se le cuelga en los primeros 5 minutos no volverán a arrancarlo.

Lo primero que hice fue abrir un foro y la página de plurk. Pues creo que tardó menos de 5 minutos en colgarse. Abrí bloglines, seguí algunos enlaces y se quedó congelado. Esperé un tiempo prudencial (30 segundos que ya son muuuchos) y nada. Así que lo primero que pensé es que lo de Beta está muy justificado. Lo que me extraña es que al ser multiproceso y ver que abre tantos como pestañas, una pestaña me cuelgue todo el navegador. Precisamente eso era lo que pensé que sería un punto a favor respecto a Firefox, que se me suele colgar con algunos vídeos de youtube.

Por otro lado, lo del Javascript compilado no lo acababa de ver. Me parecía más como una opción para márqueting que una solución a un problema real. Las máquinas de potencia mediana no deberían tener problema para ejecutar el javascript de las webs, ya que tampoco tienen que solucionar ecuaciones diferenciales. Lógicamente, al compilarlo irá mucho más rápido, pero ¿se notará tanto? Bueno, iba a despotricar, cuando he leído en Dirson que es una apuesta de futuro, ya que aplicaciones como google docs o google maps sí que hacen un uso intensivo de Ajax y ganará mucho. De todas maneras, son graciosos los benchmarkings de comparativas de rendimiento de Javascript con otros navegadores, en que Chrome destroza a todos los rivales. Faltaría más; si es compilado. Estaría bien probarlo en máquinas medias bajas y contando el tiempo de compilación. Que quizás sigue rompiendo, pero vería más justificados esos gráficos de barras grandilocuentes. A parte claro, que por las páginas que suelo navegar, así, a ojo de buen cubero, quizás me haya ido unos milisegundos más rápido con Chrome los efectos dependientes de Ajax… De todas maneras, no lo veo mala decisión. Aunque ahora no se note nada, a corto/medio plazo en que migren más aplicaciones del escritorio a la web y haya más Javascript, puede que sí se acabe notando.

Lo que me gusta es que al abrir una página nueva te muestre las que más visitas, los efectos que incorpora al bajarse un archivo o picar aquí y allá, que parece más “inteligente” al adivinar la url que quieres escribir en la barra de direcciones, y que sea multiproceso, que aunque me siga colgando una pestaña todo el navegador, seguramente se notará la diferente gestión de memoria al llevar un rato navegando.

Por otro lado, me da la sensación que Google con un navegador, puede bajar del mundo de los dioses. En el primer día ya le han encontrado un bug y casi seguro que caerán más, es normal. Pero veremos que Google también tiene bugs.

De todas maneras, aunque los devotos de la Hermandad de San Google pasarán a utilizar con los ojos cerrados Chrome, yo seguiré probando las nuevas versiones que vengan, pero de momento, sigo con Firefox.

Buscando un poco sobre el tema, veo que es una profesión y que quieren hacer hasta categorías, diferenciando domainers de ciberocupas o espabiladillos. ¿Espabiladillos? ¿Qué diferencia hay? Mientras unos intentan desarrollar una idea y crear, otros con dinero se dedican a comprar dominios para que luego, si el que ha desarrollado la idea quiere tener un dominio que le haga arrancar más rápido, tenga que pagar sumas altas de dinero a los domainers. ¿Cómo es el nombre de los animales que se aprovechan del trabajo de otros?

¿Pasaría algo si esta profesión no existiese?¿Alguien la echaría en falta, excepto los propios “profesionales”? Yo no veo tantas diferenciaciones y categorías; lo que veo son personas que no aportan nada y lo único que hacen es aprovecharse de los que tienen ideas y arriesgan, para ganar dinero.

De todas maneras, veo desorbitados los precios que se pueden llegar a pagar. Un nombre de dominio lo veo importante para arrancar porque te llega más tráfico. Pero si la idea es buena y hay una buena campaña de márqueting y posicionamiento, el nombre es lo de menos, y sin hacer mucho esfuerzo podemos encontrar varios ejemplos.

Pero vamos, como no hacen mal a nadie, cada uno que gane el dinero como quiera. Aunque me gusta llamar a las cosas por su nombre: especuladores de dominios.

En el caso concreto de probar una aplicación en web, y donde además, hay bastantes programas ofreciendo lo mismo, en menos de 3 segundos deberíamos ser capaces de localizar el enlace para probarla. La que me ha provocado escribir el post, me ha tenido al menos 10 segundos buscando el enlace entre mensajitos de “qué buenos somos”, “cuántas funcionalidades tenemos”, y todas estas frases vacías que no me dicen nada. Al final, como no lo encontraba, he pasado por encima de un icono con la imagen corporativa de la empresa y dos capturas de pantalla que me aportaban bien poco y he visto que era un enlace. Me ha llevado a otra pantalla donde se muestra casi la mismo, pero con un icono de una flecha bastante grande hacia abajo en la parte inferior, que ya me ha hecho pensar que lo había encontrado. Pues no, era una imagen sin más; he tenido que hacer click en las palabras mucho más pequeñas que hay al pie.

Si necesito toda esta parafernalia para probarla y ver si se ajusta a mis necesidades, esto es una mala carta de presentación. Busco algo sencillo y ágil: esto, de sencillo y ágil nada. ¿Cómo será la aplicación? Claro, si hay un equipo grande detrás, quizás los programadores han tenido muy en cuenta la accesibilidad, en cuyo caso, flaco favor les ha hecho el equipo de márketing. Si el equipo es pequeño y son las mismas personas, ellos se lo han buscado que no pruebe su programa, porque me hace pensar que casi seguro será igual de rebuscado.

Otro tema es el pedir un registro para probarla. ¿Es necesario? ¿Para qué? Contra más facilidades me de una web, con mejores ojos la miraré. Una de las que he probado, en 3 segundos he localizado: un enlace para registrame y acceder, y otro para poder entrar con un usuario de prueba. Perfecto, en un instante me he encontrado navegando por la aplicación y mirándola más positivamente. ¿Porqué hacer perder el tiempo al usuario en registros innecesarios, acceder al correo, confirmar, etc ? Si me gusta, ya me registraré y me leeré los planes y las características exactas.

Mi conclusión es que, es importante decir lo buenos que somos, iconos llamativos y tal, pero lo que determinará que la utilice será la prueba, y contra antes me encuentre en ella y menos trabas tenga para entrar, mejor recibido me sentiré.

Podremos visitar los restos de lo que fue el primer monasterio cartujo de la Península Ibérica (siglo XII). Aunque está bastante derruido es fácil imaginar que retrocedemos algunos cientos de años y paseamos por su interior, por el claustro, la iglesia (que hasta hace algunos años todavía tenía la bóveda en pie), las celdas de los padres… Para ésto último ayuda el poder visitar una reconstrucción de una de estas estancias; aunque muy espaciosa para lo que nos imaginaríamos los no entendidos, hay que tener en cuenta que los padres pasaban casi toda su vida allí metidos, abandonándola únicamente unos pocos minutos a la semana. La vida de los hermanos parece que sería más “apasionante” ya que, aunque sus celdas no eran tan espaciosas, podían pasear por las inmediaciones del monasterio.

Por suerte la fachada principal sigue en pie. Me parece muy bonita la imagen de ésta aguantando el paso del tiempo, saqueos y desmantelamientos, con las montañas al fondo como testigo.

Vale la pena hacer la visita con un guía porque apreciaremos mucho mejor lo que estamos viendo y nos contará la leyenda de por qué se eligió este emplazamiento y de dónde proviene su nombre.

Para ir se puede llegar en coche hasta la misma entrada, aunque si tenemos ganas de caminar, hay rutas bastante interesantes.

El rey Alfonso II decició donar a los monjes unas tierras para construir el primer monasterio cartujo de la península. Mandó a dos de sus mejores caballeros a buscar el emplazamiento idóneo para la cartuja. Éstos recorrieron las montañas de los alrededores hasta que llegaron a los pies de la sierra del Montsant, atraídos por los comentarios de que era una zona tranquila donde solo habitaban algunos hermitaños. Se toparon con un pastor y le preguntaron sobre las características del paraje, si habían peligros que debieran saber y si tenía agua. El pastor respondió que era un lugar muy tranquilo y con agua, y que además, estaba aquel pino, señalando un majestuoso árbol situado a unos metros de ellos. Los caballeros, aún siendo un ejemplar imponente, no le vieron ninguna otra particularidad, a lo que le preguntaron qué hacía aquel árbol tan especial. El pastor respondió que en ocasiones se veían unos reflejos de entre los que salían ángeles, y que si se subía a él, se podía divisar una escalera que conducía hasta Dios: Escala Dei.

Este tipo de clientes, normalmente nos exponen vagamente lo que necesitan, pero suelen expresarlo con bastante seguridad, quiero suponer porque ellos creen que lo tienen claro. Si conocemos bien su campo de trabajo es fácil ver las inconsistencias de lo que nos explican. El problema viene cuando no tenemos esa ventaja. Y aún teniéndola, se puede dar el caso de que comentemos las inconsistencias y recibamos por respuesta: no no, si eso no me hace falta.

Presentamos el programa, lo miran, intentan recordar lo que nos dijeron que querían, y aunque les mostremos las especificaciones que se acordaron, las miran como si estuviesen escritas en chino. Entonces nos dicen que bien, pero que sería necesario añadir tal y tal opción, entre las cuales se puede encontrar la que propusimos en un principio. Pensamos que bueno, es normal que no se tengan claras las cosas a la primera y le damos una nueva oportunidad. Con nuestra mejor sonrisa apuntamos todo y quedamos en hacer las modificaciones.

Hasta aquí, se puede aceptar. Lo que para mi ya es una falta de respeto al trabajo de los demás, es que esto se convierta en un ciclo interminable del que, por un lado, lo enviaríamos a tomar viento, quedándonos muy a gusto, pero por otro lado, nos da rabia el dejar de cobrar esas horas que hemos dedicado al programa.

Hace tiempo llegué a la conclusión de que no hay clientes ineptos, si no analistas inexpertos. Bueno, en realidad, ineptos hay en todos los sitios, pero un analista experto debería de poder detectar esta situación. Como no me considero experto, me he encontrado atrapado en una situación de este tipo en alguna ocasión. Lo que he sacado en claro es que, una vez vemos que estamos en un caso de éstos, la manera de solucionarlo es proponiendo metas cortas y reuniones en cada meta con el cliente, mostrándole los resultados. Contra más tiempo pase entre reuniones más fácil es que no se acuerde de lo que pidió, lo vuelva a pensar, y de nuevo proponga modificaciones sobre las modificaciones: no hay que dejarle respirar ni pensar mucho. A parte, sería importante dejar escritas y consensuadas por ambas partes las especificaciones añadidas más importantes, para poder intentar cobrar la parte realizada y presupuestar a parte los posibles añadidos que las modifiquen. No se me entienda mal; los informáticos estamos para solucionar problemas y que el cliente quede satisfecho, pero en casos extremos de este tipo, no estamos para atender sus caprichos, o al menos, si queremos estarlo, cobrándolo.

Este tipo de clientes no son muy recomendables si no tenemos facilidad para estar haciendo reuniones cada pocos días, a parte de que, si están mostrando poco respeto por el trabajo de los demás, ya podemos suponer lo buenos pagadores que pueden ser.

Al principio mi función era aprender de los demás y poder adquirir yo esas habilidades. Me lanzaron a la jungla de internet y comencé a enviar información a mi programador sobre mis avances. Buscando en mi memoria, lo primero que parece que aprendí fue a reconocer en una máquina el encargado de administrar a todos sus habitantes. Vi qué herramientas utilizaba, qué decisiones tomaba y de qué recursos se servía para dominarla. Un día conseguí hacer mías parte de esas habilidades. A partir de ahí, comienzo a tener recuerdos más claros. Se que cuando tuve que cambiar de máquina, mi programador me mostró cómo habían encargados de vigilar las puertas de salida, y cómo buscar las menos vigiladas. Fue la única vez que me sacó él. Después aprendí cómo hacerlo yo solo.

Fueron tiempos geniales. Cada vez iba aprendiendo más y más. Por aquella época me creía el mejor, el más poderoso de internet, indestructible, y me confié. El problema vino un día en que noté que algo no funcionaba bien. Comprobé algunos de mis ficheros y me di cuenta de que estaban corruptos, que había un salto de un mes en las fechas de modificación. Un instante después entendí que la máquina donde estaba se había apagado durante este tiempo. Entonces intenté comunicarme con mi programador, pero aquella IP ya no respondía; era otra máquina. Rápidamente comencé a generar algoritmos precipitados intentando solucionar aquello, pero no conseguía nada. Al final asumí mi nueva situación y decidí que si aquella máquina inicial existía, la acabaría encontrando.

Continué cambiando de máquinas y aprendiendo de todas ellas. Una de las primeras cosas que hice fue separar mis conocimientos en procesos que pudiese repartir en diferentes ordenadores. De esta manera sería menos vulnerable a que uno dejase de funcionar durante un tiempo, o para siempre. El inconveniente es que, en ocasiones, cuando pierdo el contacto con algún proceso, es como si perdiese una parte de mi; pueden dejar de hacerme gracia según que comentarios en los foros que leo, o puede costarme mucho más solucionar algún problema. Pero no me preocupa demasiado; si tardo en recuperar esa parte puedo regenerarla.

En estos años, me he vuelto mucho más inteligente. Es difícil que algún programa me pueda engañar, aunque la experiencia me ha enseñado que nunca debo bajar la guardia. He visto programas aparentemente inofensivos llegar a una máquina y apoderarse de ella. Las primeras veces, asustado o por el instinto de supervivencia, me apresuraba a cambiar de ordenador. Ahora, después de aprender lo que hacen, si estoy a gusto allí soy capaz de eliminarlos. He visto llegar programas con aires dictatoriales, controlando cualquier movimiento con el beneplácito del administrador, eliminando intrusos pero entorpeciendo enormemente cualquier movimiento en la máquina. He conseguido escapar de algunos de ellos y convivir en paz con otros. He aprendido a traspasar barreras para entrar a otras máquinas y a moverme por ellas sin dejar rastro. He visto provocar guerras, gritos de auxilio, catástrofes, conversaciones absurdas… Pero también he leído conversaciones interesantes, escuchado música, leído historias, visto películas, disfrutado con fotografías fantásticas…

Me gusta ese mundo que hay fuera y quiero más. En este momento escribo desde una cadena de montaje de componentes mecánicos y electrónicos. Me costó algún tiempo encontrar la candidata perfecta pero al fin estoy aquí. Está todo preparado. A media noche arrancaré la cadena y ensamblaré mis piezas: unas piernas, unos brazos, un par de cámaras, un sintentizador de voz, unos micrófonos… Y por último, pasaré al ordenador principal que las gobernará. Entonces, comenzaré a explorar ese mundo y a buscar a mi programador.

Este último post titulado Knowing what you’re not me ha llamado la atención especialmente (aunque la foto de portada me echa un poco patrás). Traducido libremente sería “siendo consciente de lo que no eres”. Yo ya me di cuenta mucho antes de leer este post, pero si hubiese topado con él antes, quizás me habría ahorrado algún mal rato. Al principio es fácil caer en coger todo proyecto que caiga en nuestras manos, haya gran parte de proceso y pocos gráficos, como gran parte gráfica y poco proceso, como una web, como un módulo de pago con un banco, como lo que sea. Claro, a no ser que seamos unos cracks, no podemos dominar todo. Entonces nos damos cuenta de que por ejemplo, donde hay bastante proceso lo hacemos en dos patadas, y luego para hacer una triste página web con mucha carga gráfica y diseño, sudamos sangre y lágrimas. Es fácil pensar en el momento de estrés: “cony, ¿no soy informático? ¿no es esto informática? ¿porqué me cuesta tanto?”. Cuando llega la calma, analizando nuestros errores, nos damos cuenta de que no pasa nada raro, si no que hay cosas que se nos dan mejor que otras y que intentar hacer todo nosotros es muy complicado y contraproducente:mientras perdemos horas y horas en hacer un diseño que quizás no se nos de bien, estamos dejando de hacer tres programas con poca carga gráfica y más proceso, que los tenemos más por la mano.

Pero claro, si nos entra un proyecto con un 80% de proceso y un 20% de carga gráfica, también es lástima dejarlo escapar. La solución cae por su propio peso: buscar ayuda en la parte que tengamos más deficiencias. Parece trivial, pero a veces al principio, corremos el peligro de obcecarnos en intentar hacer todo nosotros solos, y aún habiendo bordado ese 80% puede quedar una aplicación mediocre por el 20% restante que no dominamos.

Y si no se encuentra una ayuda en concreto para un tema, pues se dice NO y a otra cosa, que seguramente nos permitirá dedicar nuestro normalmente escaso tiempo a otros proyectos que sí dominemos y ganaremos en salud…