El vendedor de motos

El vendemotos, es otro de los integrantes de la fauna que podemos encontrar en cualquier empresa de software. El vendemotos no tiene porqué ser siempre el comercial de turno. Hay también vendemotos en otras categorías laborales, aunque suelen estar relacionados íntimamente con otro miembro de la fauna laboral: "el trepa". De éste hablaremos otro día.

El vendemotos te venderá (si es comercial) o tratará de que se use (si es técnico) la última moda tecnológica, supuestamente consiguiendo con ello la mejor eficiencia, mayor productividad, accesible desde el móvil, con soporte para la nube, etc, etc.

El comercial vende-motos

Si es un comercial, se lo ofrecerá al cliente, para mayor horror y desengaño del vilipendiado equipo de desarrollo, que se verá obligado a tratar de implantar tecnológicas poco probadas, de escaso impacto en valor real para el cliente, pero por supuesto, con un coste y un sobre-esfuerzo que pondrá al límite tanto al equipo de desarrollo como a la economía de la empresa. Claro, esto al cliente le dará igual, porque el precio cerrado conseguirá que esto no se le transmita al cliente, que sólo verá con horror como se producen retrasos en unas funcionalidades que para él eran triviales.

El técnico vende-motos.

Si el vendemotos es un técnico, se tratará de un miembro del equipo que tratará de influir en el resto, bien por categoría (analista, jefe de equipo o de proyecto), o bien por insistencia (el auténtico pesado que te está dando la paliza para que uses el nuevo hibernate-struts-mvc-loquesea). Claro, este técnico de pacotilla, auténtica piltrafa tecnócrata, trata de colocar estas novedades...¿pero por qué? Analicemos este punto:

• Habrá leído unos días antes de las bondades de la nueva tecnología
• Querrá impresionar a sus responsables o subalternos con estas novedades, atrayendo hacia sí una falsa sensación de profesionalidad.
• Quizá se aburría, y busca una forma de desarrollarse a sí mismo y a su currículum a costa de sus compañeros y empresa actuales.
• Quizá lo usó en otro proyecto, que no se parecía a este en nada, y lo que allí le salió bien (o vio a otro que le salió bien), cree que ahora puede encajar. Me encanta cómo se desprecia el valor de la experiencia y de un buen análisis que compruebe realmente lo adecuado de las cosas en relación a los objetivos buscados.  

Después de todo, para cuando se implante la tecnología, o bien le habrá dado tiempo a aprenderlo...o bien ni siquiera la termine implantando él (ya pringará otro), o bien ni siquiera estará ya él en la empresa/proyecto. Cuántos habré visto abandonar los proyectos que ellos mismos han empezado torpedeando con arquitecturas demasiado novedosas.

El mantenimiento, también se verá gravemente afectado. Las nuevas tecnologías, en cuanto maduran, empiezan a ser realmente mantenibles y productivas, pero pobres de los proyectos que las hayan implantado cuanto aún eran novedades tecnológicas: esos proyectos serán difícilmente mantenibles, porque las arquitecturas creadas alrededor de esas novedades para poderlas "sostener", serán reduntantes. Cuántas veces hemos visto implementar en los frameworks (struts, mvc, EF,...) funcionalidades que en sus primeras versiones se han tenido que implementar "a pelo" (es decir, con sufrimiento y dolor).

¿Quién pierde?

• Pierde el cliente, que ve tirado a la basura su tiempo y dinero, y que con suerte ve una solución cara e inadecuada que podría haberle salido mucho más barata (a corto plazo por el precio, y a largo plazo por el mantenimiento que va a tener).
• Pierde el equipo de desarrollo, que ve cómo sus horas se disparan al tratar de hacer funcionar cosas imposibles, complejas, bizarras. Sí, habrán aprendido mucho. Me encanta ver cómo los defensores de las novedades se escudan en el aprendizaje. Para aprender, vete a la autoescuela. Cuando sepas correr, coges el Ferrari. Los peatones te lo agradecerán.
• Pierde la empresa, que ve cómo los costes se disparan al inicio del proyecto, y se tiene que comer con patatas el precio vendido. Al final, o pone a los recursos más baratos para no arruinarse, o todo el mundo a hacer horas extras.

¿Quién gana?

• El dueño de la tecnología, que ve cómo se usa algo inmaduro y fuera de contexto, proporcionándole un beneficio a través de los vendemotos que han caído en la trampa.
• El vendemotos, suele ganar, ya que su enorme habilidad de escaquearse, hace que no le afecten los negativos resultados de sus gestiones o falta de habilidad.

¿Y tú? ¿Has visto recientemente a algún vende-motos?

Formación 2.0 en la red.

Por una vez y sin que sirva de precedente, aquí va una entrada breve y espero que fructífera: os paso un enlace de una web con abundante meterial educativo online, y en español:

http://wwwhatsnew.com/2013/03/10/buenos-lugares-para-encontrar-recursos-educativos-en-espanol/

Hala, ahora a estudiar! Saludos

Influencia de la carga de trabajo en el ángulo del monitor

Hoy os voy a relatar hechos verídicos y contrastados. Se trata de una nueva teoría científica que creo que va a revolucionar el mundo de la tecnología. Seguramente pueda vender esta teoría y jubilarme. A ver qué opináis.

Vengo observando una correlación bastante acusada entre el ángulo de los monitores de los programadores, y su carga de trabajo, que voy a ir desarrollando a continuación:

Caso 1: alta carga de trabajo.

La experiencia muestra que cuando el empleado tiene una fuerte carga de trabajo, el monitor se encuentra situado justo enfrente del mismo, de forma que éste forma una línea paralela con el eje de los hombros, y habitualmente, también con la mesa, como muestra la figura siguiente.

Además, resulta interesante destacar que esta posición es independiente de la posición en la que se encuentre sentado el responsable/supervisor del empleado.

Caso 2: baja carga de trabajo durante un corto lapso de tiempo.

La gran mayoría de casos observados permiten notar un aumento en el ángulo del monitor, que ya no se encuentra paralelo al eje de los hombros, como se muestra en la figura. Lo que resulta ya sorprendente, es que el ángulo del monitor puede ser a un lado u otro, y esta vez, sí que hay una dependencia a la posición del jefe, de forma que el jefe parece tener la manía de situarse justo donde su posición impide ver correctamente la pantalla del empleado.

Caso 3: nula carga de trabajo durante largo tiempo

De nuevo, los datos empíricos muestran que en la mayoría de casos, el monitor del empleado que lleva mucho tiempo sin recibir trabajo, acaba como muestra la figura siguiente: prácticamente perpendicular al eje de sus hombros. Para evitar el bizqueo o el colapso del empleado, éste tiende a colocarse "ladeado", corrigiendo de esta forma la postura del monitor.

Otro punto a considerar es que como ocurría con el caso 2, el jefe del proyecto tiende a situarse en el lado del empleado desde el que no se puede ver su pantalla, hecho que hemos atribuido a la mera casualidad.

Influencia de la hora.

Otro hecho sorprendente, es que especialmente en los casos 2 y 3, al principio de la jornada, y cuanto más nos acercamos a la hora de salida, el ángulo del monitor se hace todavía mayor si cabe. Sin embargo, en las horas centrales del día el monitor tiende a volver a su posición normal. De nuevo, hemos de suponer que esto es mera casualidad.

Influencia del número de monitores.

Si en lugar de un monitor, analizamos las situaciones anteriores con empleados que tengan dos monitores, ocurre algo muy curioso. El primer monitor, al que llamaremos "1", permanece siempre frente al empleado (esto es, paralelo a lo que hemos llamado su "eje de hombros"). Sin embargo, el segundo monitor, sí parece verse afectado por los casos anteriores, de forma que sufre ángulos escandalosamente extraños en función de la carga de trabajo.
De nuevo, el número de monitores y la hora del día parecen tener una correlación, de forma que el monitor "1" parece usarse en las franjas centrales del día, y es el segundo monitor (el que hemos llamado "2"), el que recibe mayor carga de trabajo en las horas tempranas, y en las horas cercanas al final de la jornada.

 

Influencia de la distancia al jefe.

Otro punto interesante digno de estudio, es que el ángulo aumenta cuanto menor sea la distancia con el jefe. Es decir, el jefe muy alejado, hace que el ángulo del monitor sea pequeño. Pero si el jefe se acerca, el ángulo se hace mayor.

¿Y tú? ¿Has observado también en tu trabajo este extraño fenómeno?

Plantillas...¿para qué sirven?

Escribo esta entrada tras observar una interesante actitud en nuestra profesión, aunque por otro lado no es nueva, sino que es tan antigua como dicha profesión. La verdad es que la tenía medio escrita hace ya días, y como llevo un buen lapso sin tener un minuto libre, creo que ya es el momento de sacar esta entrada a la luz.

Por un lado, desde el área de calidad yo preparo con cariño la metodología para cada proyecto:
- Adapto los procesos y herramientas.
- Adapto las plantillas al entorno, cliente, tecnología...
- Adapto el número de plantillas y procesos a cubrir al tamaño del proyecto y sus requerimientos de rigor, etc.
- Finalmente, intento detectar gaps que me indiquen que se trabaja más de la cuenta, y no se aporta valor al proyecto o a la empresa. El objetivo es hacer lo mínimo indispensable, y buscando siempre que nada se haga dos veces en dos sitios distintos.
- Luego con el día a día, compruebo si los proyectos necesitan algo (de más, o de menos).

Dicho esto, puedo encontrarme con la siguiente situación: para comunicar algo, alguien del proyecto manda un correo al cliente usando como adjunto un word en blanco (y unas frases escritas en él, sin ningún formato, logo ni orden prefijado).

Cuando lo reviso, realmente me pregunto porqué no se usó la plantilla que yo con tanto esfuerzo había preparado. Y no es porque me haya costado tiempo. En esta profesión, desde que se es programador, hay que aprender a que el trabajo (código o lo que sea) no es nuestro. No hay que tener el apego que se tiene a una obra de arte o a un hijo nuestro. Si hay que rehacerlo, o si hay que aplicar un cambio, se acepta. Eso no significa que lo hagamos con desgana ni sin cariño. Significa que hay que aceptar esos cambios igual que se acepta que un hijo tomará su propio rumbo lejos de nosotros algún día.

Volviendo al tema, a que si recibiéramos un documento de una empresa o del gobierno, nos gustaría que dicho documento no estuviera en blanco...sino que tuviera un formato...un logo identificando al organismo o empresa que nos lo envía...Sin embargo, cuando se trata de mandar al cliente un documento...¿porqué no usar una plantilla si ésta se encuentra ya disponible? ¿No da su uso una imagen de profesionalidad, coherencia y buen hacer?

¿No tiene el código su estilo, tabulaciones, estructura y formato? ¿Porqué no hacer lo mismo en lo único que va a ver el cliente (los documentos)? ¿No es cada día más común el usar patrones y estructuras de código estándares y que de esta forma nos aceleren el desarrollo?

Yo creo que el problema está en nuestra percepción de la diferencia entre el código y los documentos. El código lo vemos como algo que es para nosotros, y por eso le dedicamos más tiempo y atención. Sin embargo, la documentación nos es ajena: es algo para el jefe, o para el cliente.

Y aquí, en mi opinión, es cuando pecamos de no aplicarnos lo que exigimos a los demás. El código que nos pasan los compañeros nos gusta que esté estructurado y cumpla un estándar, si es posible, coherente y común en todo el proyecto. Pero no sentimos la misma obligación de seguir un estándar a la hora de por ejemplo usar un documento de cara al cliente.

Hay otro problema añadido con los documentos, y es que tienen la habilidad pasmosa de salirse de contexto. Un word adjunto a un correo, tiene sentido. Pero cuando alguien lo copia y pega en otro correo...o lo guarda en una carpeta de red...ya hemos perdido el contexto. Perdemos el autor, la fecha, la empresa...(oh, claro, tenemos las propiedades del documento, que ni son obvias ni fáciles de ver, aparte de que no demuestran un autor, sino la máquina desde la que se creó).

¿Y tú? ¿Eres de los que prefieres usar un documento en blanco aún cuando existan plantillas para algo? ¿O prefieres inventar la rueda una y otra vez excusándote en la creatividad?