Si hay una cosa que fideliza, que agrada al consumidor es la buena atención al cliente. Aunque tu producto no sea el mejor, si tienes una buena atención terminas enamorando. He escuchado mil veces lo típico de "fui a XXXXXX, no era de lo mejor, pero me han tratado estupendamente" o "he comprado XXXXX se me estropeó, pero en 1 día me lo han enviado reparado".

Y si es tan fácil tener al una persona contenta, por qué las operadoras, por poner un ejemplo, son el claro ejemplo de la mala atención al cliente?. Que tire la primera piedra el que nunca se haya quejado de su ADSL, su factura de móvil que han tardado lustros en solucionar. La respuesta es que NO es tan fácil.

Para tener una buena atención al cliente hay que tener gente que sepa darla, así de claro, así de fácil y así de difícil a su vez. Por un lado el cliente debe tener claro donde acudir, debe haber alguien que le atienda (y NO acepto una máquina como alguien), que sepa escucharle y que además sepa que hacer. Esto es, alguien que:

- sepa de lo que está hablando, no una persona que sigue un guión de preguntas,
- que sepa a quien acudir en caso de tal o cual problema
- que sepa resolver los principales problemas él solito,
- que se encargue de ese problema, tanto de estar pendiente del cliente como de que ese problema llegue a quien tiene que llegar para que se resuelva para que en la medida de lo posible no vuelva a pasar. A veces aunque no te resuelvan el problema, si ves que están pendientes de él el cabreo ese que te envenena se va. Un simple SMS con "Hola Javi, estamos trabajando en tu problema con la conexión ADSL. Te llamamos cuando sepamos algo. Fdo: Perico".

Pero no, tener a gente formada y preparada exige tiempo y dinero, y es mucho más fácil ir al país más desfavorecido que hable tu idioma y poner a los que menos cobren a trabajar sin ningún tipo de formación, sin saber de lo que hablan.

La próxima vez que vayas a comprar algo, no solo pienses en lo que compres, piensa en qué hay detrás de ese coste.

Y por último, hay una cosa en lo que creo que muchas empresas deberían espabilar y es en ser transparentes, no solo con qué hacen y cómo (hasta cierto punto) si no como tratan al cliente con sus problemas.

La pasada semana hicimos una ronda de lightning talks con el objectivo de introducir a los compañeros de la empresa en tecnologías que no habían usado hasta ahora. Además sirvieron para hacer un poco de team building y romper un poco el hielo, cosa importante en un equipo _muy_ distribuído. Lo empecé a ver a la gente de aspgems y me pareció interesante.

Por mi parte hice un par de charlas que puede que resulten interesantes:

- Introducción al testing con python y django (pdf). Repasa conceptos muy básicos del testing y trata de explicar como testear una aplicación en django. Es muy muy básico, pero puede servir de ayuda si no estás familiarizado.

- Introducción a fabric (pdf). Fabric es una herramienta para facilitar la automatización de los "deploys". Es similar a capistrano en ruby o ant (salvando las distancias) en java.

Como curiosidad las transparencias están creadas con una aplicación llamada landslide, que transforma sintáxis markdown a una presentación HTML5 o PDF. Muy simple de usar y fácilmente "maqueable".

Me gusta mucho dar charlas de este tipo -a pesar de mi nula capcidad comunicativa- y creo que dice mucho el que un equipo de desarrollo monte charlas de este tipo para estar al día. A ver si mis compañeros se animan a subir las suyas.

Primero de todo decir que no soy ni jefe de proyecto ni nada que se le acerque. La palabra jefe, gestor, responsable se usa con demasiada soltura, ser un gestor competente es muy difícil y requiere mucho tiempo, exactamente igual que ser bueno en otros ámbitos más un toque de sensibilidad con el prójimo.

En España los títulos de gestión (jefe de proyecto, jefe de sección, gestor de blabla) se usan como complemento a los absurdos salarios, "fulanito, vas a ser responsable jefe del proyecto amoeba-ultra-2.0, vas a llevar toda la gestión, sabemos que podemos confiar en ti, blablabla...", pero realmente no responden a una experiencia por parte de la persona que está en ese puesto, en la mayoría de los casos (*).

Nuestro scrum manager de cabecera en la empresa estaba de vacaciones, así que decidí tratar de hacer un sprint como mandan los canones de scrum, bueno, realmente como yo lo aprendí de @jmnavarro en mi estancia en unkasoft, con su reunión con cliente, elección de tareas del backlog, estimación, su avance, su burndown chart y finalmente la retrospectiva.

Decir que el desarrollo fue bien, se terminó en plazo, con calidad más que suficiente, pero eso no le interesa a nadie, aquí lo interesante es ver en donde metí la pata hasta el fondo, ¿no?:

- Puñetazos encima de la mesa: He tomado elecciones en base a mi experiencia por encima de las decisiones de mis compañeros, lo cual puede estar bien, pero no deja de ser un error. No dejar elegir su camino a tus compañeros es un grave error, aunque sepas sí o sí que hay formas mejores de hacer las cosas. Si la idea es formar un equipo de desarrollo a un buen nivel todo el mundo debe aprender y la mejor forma de aprender es afrontando problemas tú solito.

- Meterme en las tareas de mis compañeros: En un momento puntual decidí terminar a machete una tarea de un compañero (además de gestor, programo, ¿te suena?) ya que estaba bloqueando el desarrollo. Desde el punto de vista del proyecto es lógico hacerlo, pero no me paré a pensar que mi compañero se podría sentir ofendido, dolido por haber terminado algo en lo que estaba trabajando. Mil veces prefiero llegar tarde un sprint a tener un roce absurdo.

- Notificar los errores: no hay cosa más difícil que decir a alguien que la ha mangado. Y no quiero decir hacerlo sin que se sienta ofendido.

En resumen, si no tienes un poco de tacto, mano izquieda, inteligencia emocional, como lo quieras llamar, es mejor que te quedes como un buen técnico.

No hay nada mejor que las curas de humildad que la vida te da de gratis y que la memoria te recuerde los malos ratos que hiciste pasar a algún que otro gestor de forma innecesaria, mis disculpas atradas.





(*) En mi corta-pero-intensa vida laboral solo recuerdo a un par de personas haber estado a la altura de un puesto así, y cada día que pasa me acuerdo más de alguno de ellos :)

Para empezar, una frase:

Más hacer y menos hablar

es un ejemplo que define muy bien lo que está pasando ahora mismo. Nos hemos hartado de montar castillos sobre las nubes y cuando ya no podíamos llegar más algo nos la hemos pegado.

Estamos en un punto en el que una persona hace 1 año sin apenas saber sumar podía comprar una vivienda y sacarla un 30% sin despeinarse o que nos vendan la leche por que tiene calcio "de leche" -esta misma noche he visto un anuncio de pascual en TV, se habrán parado a verlo, alejandose unos metros de la pantalla, los creadores?-

Estoy hasta las narices de humo, quiero que cuando vaya al taller con mi coche venga un técnico y que sin pensar sepa lo que es ese ruido que apenas se escucha, y me da igual que el taller cumpla la norma de turno, quiero que cuando vaya al médico éste tenga los huevos pelados de tratar con pacientes, que sepa que me pasa o como mínimo que tenga recursos para saber qué hacer, quiero que cuando llame al banco a preguntar no me insten a hablar con "fulanito de tal" que es el que "lleva estas cosas".

Quiero que haya gente que sepa, gente preparada, que sepa hacer, que me solucione, que me aporte.

Pero claro, para hacer todo eso necesitamos muchos años de preparación -sí, de esas cosas que nunca valen para nada en la universidad-, mucha experiencia, dedicación, gusto por hacer las cosas bien... y una recompensa (social, económica, del tipo que sea), pero para que me voy yo a esforzar si puedo pasar de #ponga aquí su puesto vendehumista de moda# una temporada y eso de escornarse no está bien visto -menudo pringao que diría aquel-

Cada vez que veo a alguien haciendo bien su trabajo me resulta imposible no soltarle un "da gusto pagar cuando la gente hace las cosas bien"

Un IDE, con permiso de la definición en la wikipedia, no deja de ser un editor de texto y una serie de utilidades que facilitan el trabajo de desarrollo, tales como configuración de los parámetros del compilador, debugger, ayuda en la sintáxis, documentación del lenguaje, etc.

Hace ya cosa de un par de años que no uso un IDE, bueno, uso vim como "IDE" y las razones son las siguientes:

- Me obliga normalmente a usar el editor que el IDE quiere. Con vim uso siempre, para editar lo que edite, las mismas combinaciones de teclas, misma configuración y en todas las máquinas en las que trabajo solo con llevarme el .vimrc

- Tiende a añadir complejidad. Los makefiles que se generan, los wizards de código, etc tienden a añadir mucho código que realmente no sabes como funciona y que es difícil de modificar.

- La ayuda con la sintáxis o el autocomplete. Aunque pueda parecer una maravilla me parece uno de los inventos más perversos. Usé eclipse durante más de un año y medio con java y un día intenté hacer un pequeño programa en el editor de texto y compilarlo con javac... fue imposible, no recordaba nada, cual eran los imports que debía hacer (eclipse lo hace como mágia), nombres de clases, excepciones que debía capturar...

- Trabajo en máquinas remotas. Muchas veces tienes que editar ficheros o incluso programar en una máquina que solo tienes acceso ssh. Usando vim es transparente el estar en tu máquina o en otra por ssh.

- Si no lo usas aprendes a manejar las cosas que pasan por debajo. Cuántos habrá que no sepan crear un .jar sin eclipse, como se especifica a gcc una librería o el path donde encontrar las cabeceras... sin contar aquellos que se sorprenden cuando puedes hacer todas esas cosas que hace el IDE pero sin el IDE. Si sabes como crear un .jar puedes estar tranquilo que con el IDE sabrás hacerlo igual de bien.


Sé que todo esto que digo suena a programador masoca, pero si de verdad quieres conocer lo que estás haciendo con detalle debes conocer lo que hay por debajo.

Bien es cierto que hay cosas muy útiles, por ejemplo la documentación siempre a mano, pero qué tiene eso que no tenga un man o un pydoc en la consola, una búsqueda en todo el proyecto, aunque no la cambio un ack-grep... lo único para lo que no he encontrado algo tan potente como eclipse es para las refactorizaciones... pero los buenos programadores nunca nos confundimos :P

Este es un pequeño "truco" para testear métodos o funciones que usen datetime.now. Se podrían usar trucos aprovechando que python es un lenguaje muy dinámico, pero siempre que se pueda hacer explícito y simple, para qué complicarnos?

def method(param1, param2, now=None): 
    now = now or datetime.now()
    # do something with now
    pass

En el uso normal la llamaremos normalmente, pero en el test podremos pasarle un datetime concreto para testear.

Si has dado click en este enlace es que sabes que svn ya no mola, ahora lo que "lo peta" es git (o si eres un poco alternativo mercurial). Dejando a un lado lo de seguir las modas, seguramente conozcas más de un proyecto que trabaja con subversion y es difícil cambiar la tendencia, sobretodo por la barrera que supone pasar del modelo de funcionamiento de subversion a git.

Este post no pretende ser una guía de comandos a ejecutar para usar acceder a un repositorio subversion, para eso ya hay tropecientos manuales, voy tratar de explicar qué ventajas y problemas (alguna solución también) que he encontrado trabajando de esta forma y sobretodo pretende ser una pequeña guía para aquellos que están pensando usar git.

Ventajas:

- Puedes hacer los commits intermedios que quieras. Para los somos "amigos del commit" es muy útil, porque puedes hacer commit aunque el código no esté funcionando. En subversion para evitar esto tenías que hacer una rama y trabajar en ella hasta que terminases. En este caso tienes todo el repositorio en local y símplemente esos commits se acumulan a tu repositorio local hasta que tú decidas enviarlos al servidor.

- Trabajo en ramas: en Git trabajar con ramas es mucho más ágil que en subversion, de modo que puedes trabjar en ramas locales de trabajo para ciertas tareas, pruebas.

- Rapidez: creas ramas, cambias de rama, haces commit, compruebas el log o diff de un fichero. Aún recuerdo cuando tortoise se me quedaba pillado esperando el log de un fichero... aunque las dos anteriores son interesantes, en subversion tenían solución, esta no la tiene por el modelo cliente servidor.

- Puedes usar otras utilidades de git: stash, cherry-pick, rebases, etc.

Desventajas:

- No hay tortoise, particularmente uso gitx y/o gitg que permiten sobretodo visualizar cómodamente diffs y la historia del repo.

- Los rebases del demonio. Cuando quieres actualizarte (lo que sería un svn update) debes hacer un git svn rebase. Esto, en pocas palabras, coge los commits que has hecho en local, los deshace, se baja las nuevas actualizaciones que haya en el servidor y aplica esos commits de nuevo. Personalmente odio el rebase (me recuerda a los peores momentos de regreso al futuro), así que una forma de trabajar sería crear una rama, actualizar la rama que apunte al servidor subversion (a trunk posiblemente) y después mezclar (en git, claro) la rama de trabajo.

- No puedes actualizar si tienes algo modificado en local. Con el subversion tradicional te hacía merge de lo que venía del repo con los cambios en local. Tienes dos opciones, o hacer commit o usar stash (almacena de forma temporal esos cambios, una especie de rama rápida)

- Tienes que aprender git además de subversion. A git cuesta acostumbrarse, pero luego es más versatil y rápido, es una cuestión de inversión.

Siempre puedes empezar a probar, como siempre digo a mis pobres pupilos: "con un repositorio puedes cagarla todo lo que quieras, siempre puedes volver para atrás"

Sí, otra historia, y esta es de las que no tiene final feliz.

Las ventanas rotas en programación se pueden explicar con una variación del sabio refrán español:

No dejes para mañana lo que puedes hacer pasado mañana

Estás tirando unas líneas de código, ves que hay un problema, lo das unas vueltas, te pones a otra cosa y cuando te das cuenta el problema no está. Lo siguiente es un:

De puta madre -piensas- marrón que me quito de encima, soy un hacha, resuelvo sin querer

Total, que sabes que has dejado un error y además estás programado por coincidencia.

Pero los programadores somos muy orgullosos, así que buscamos una solución rápida:

- seguro que era una gilipollez
- la informática es así, a veces a los ordenadores les da por hacer "cosas raras"
- habrá sido "el driver"
- seguro que ha sido un pete de la base de datos
- le ha pasado a Jose el comercial, no tiene ni puta idea y lo habrá jodido
- eso ha sido porque estoy en debug
- eso ha sido porque estoy en release

Total, pasa el tiempo y un día estás programando algo que nada tiene que ver y el pete vuelve. Tú sabes que aquello volvería y en el peor momento aparece para joderte.

Bien, como los accidentes de tráfico nunca piensas que algo así te va a pasar a ti, pero siempre llega el día. Hace dos días encontré una ventana rota en agroguía (nuestro sistema de guiado GPS para la agricultura) de hace 4 años y medio.

Un error al teclear ha generado cáncer que se ha expandido por toda la aplicación. En el momento de convertir las coordenadas del GPS a cartesianas cometí el error de poner la coordenada Y donde debería estar la X y viceversa. Seguramente fue de lo primero que programé y está al principio de toda la cadena de la aplicación, ya que las posiciones del GPS son la fuente de datos.

En principio es un flip de los ejes, no debería causar problema pero eso ha causado que, sin saber porque, cambié el render del eje X (por tanto todo el render está "flipeado" en el eje X), toda la exportación está cambiada de lado, tuve que hacer ñapas para que el render cuadrase con la realidad... etc.

Ahora he estado integrando un formato de fichero GIS para darle una vuelta más de tuerca al guiado GPS de bajo coste y he tenido que arrastrar todo el fallo para que la cosa funcionase.

Casos como este y otros puedes encontrar en el libro The Pragmatic Programmer, indispensable para cualquier programador.

Hoy toca hablar de subvenciones y voy a hablar muy muy mal de ellas a pesar de que mi salario de estos últimos años atrás a dependido casi en exclusiva de subvenciones.

Pongamos una empresa española, gente trabajadora, alto nivel técnico, buen planteamiento... y ahora pongamos que existen una cosa que se llama subvenciones que hace que a los que comandan esa empresa vean un buen punto de ayuda:

"Es una de esas ayudas de i-mas-de, nos puede ayudar en el proyecto tal y contratar a cual".

A priori está muy bien, se pone a trabajar una persona en presentar la documentación, trabajar en ella, etc (lógicamente esa persona también cobra por su trabajo, faltaría más). Se consigue a subvención y se contratra a 3 personas más y, dado que se tiene mas gente, el proyecto se hace más ambicioso. El director comercial se coge de renting un Audi TT ya que es necesario ir bien representado:

"somos una empresa seria", afirma el director tajantemente a uno de sus empleados, esos que están todo el día en el ordenador.

Se va acercando el final del dinero, y como siempre pasa, al proyecto está casi listo (el 80%, por poner una cifra).

"No pasa nada, se puede buscar otro proyecto de i+d"

Y vuelta a empezar, pero aún peor, porque ahora tenemos que pagar 3 sueldos más, los coches de los comerciales y alguna que otra cosa más que se contrató en la bonanza. Por no hablar de lo minada que está la moral por no ver que el trabajo fructifica y que todo lo que haces es trabajo tirado a la basura.

Y este es el pan de cada día de muchas PYMES tecnológicas en España.

Cada vez que hablo con alguien que ha montado o está montando su empresa, que es productivo, no pasa sin que comente el daño que hacen, y no solo del lado que yo he comentado.

No estoy a favor de que desaparezcan, pero sí de que se apliquen razonablemente y siempre tratando de apoyar una mejora, no como una vía de mantener una empresa.

En voota hay una propuesta muy interesante sobre este tema.

Sí, participé junto a Félix López, Edu Lanchares y Antonio Garrote tratando de hacer una aplicación para mostrar el pueblo castellano leonés de que se habla en esas flamantes cortes.

Lo que pudimos hacer en 48h para el concurso abredatos: http://cortesabiertas.org/

y la explicación técnica detallada en en blog del sr garrote.