Resultado de etiquetas “cliente”

Hace algún tiempo salió el tema sobre lo políticamente incorrecto que era aprender a costa del cliente para el que se trabaja. Es decir, que mientras te pagan por hacer una aplicación web, uno aprenda a usar struts.

Solía estar de acuerdo con esto...

Pero ya no. O no sin matices, al menos...

Cuando alguien nos contrata (y, por si alguien llega despistado, hablamos de informáticos, mejor si tienen formación específica) no lo hace porque seamos robots intercambiables, capaces de trabajar sin pensar.

Nosotros aprendemos cada día. Si tras un mes trabajando no has aprendido nada, intenta aprender a automatizar tu trabajo... si es así de simple, no es necesario un humano para hacerlo. Y quizá hasta puedas vender el resultado.

¿Suena a utopía? Bueno, hay muchas cosa a nuestro alrededor creadas para eliminar la repetición de tareas tediosas... maven, hudson, capistrano, filtros antispam, 1password, los pagos por domiciliación bancaria, Ctrl-C / Ctrl-V, la imprenta... seguro que puedes ver alguno más.

Los trabajos que realmente importan, los trabajos por los que debemos ser contratados son aquellos que nos permiten aprender durante el trabajo. No tiene porque ser algo revolucionario...

El matiz (que habelos, hailos) es que el aprendizaje revolucionario no podemos conseguirlo sólo durante el trabajo con el cliente. Si no sabes django, primero juega un poco con él en casa y luego lánzate a algún proyecto. Una cosa es aprender y otra sacrificar un proyecto (y puede que tu futuro profesional).

Otro matiz importante... es que hablo desde la perspectiva de un autónomo y trato directamente con mi cliente... Si estás dentro de una empresa puede que tengas oportunidad de elegir o, más probablemente, que sea otro el que decide en qué empleas tu tiempo.

Finalmente... ¿porqué no aprender solo en casa? ¿o en coding dojos y code retreats como los que organiza agilismo.es? Así no pondremos en riesgo el proyecto...

Pues, en mi opinión, por múltiples motivos. Además de que podríamos ser reemplazados por autómatas, se me ocurren estos dos:

1. Seguro que dedicas más tiempo a trabajar (y aprender) durante la jornada laboral. No mucha gente se pasará otras 8 horas aprendiendo sin cobrar.

2. Los problemas de juguete no sirven para aprender de verdad. Son una buena iniciación y quizá una buena forma de pulir detalles. Pero sólo se aprende de verdad cuando estás bajo presión, cuando hay que reducir el alcance para llegar a la fecha, cuando unos cientos de usuarios hunden tu servidor... ahí es dónde un puede lucirse... y dónde demuestra si lo que cobra lo vale o no.

P.D: a mis clientes... espero que yo sí valga lo que cobro :-)

Tras leer a JMBeas en agile-spain insistir en la necesidad de un cambio cultural entre los técnicos y enumerar cosas como TDD , Pair Programming y otras sutilezas técnicas me ha venido un pensamiento a la cabeza...

Si volviese a nacer... pediría tener las orejas más grandes, para saber escuchar a los clientes. Y un sacacorchos, para sacarles lo que realmente quieren (y tenerlos enganchados para que dediquen el tiempo que ello requiere).

Sé que no tiene mucho que ver con el comentario de Beas, pero es curioso como funciona el cerebro... cualquier cosa puede disparar una chispa. En este caso, es que me cansa que echemos las culpas de todos los males del mundo a la (falta de) habilidades técnicas.

¡Ah! Y que sí, que tenemos que mejorar técnicamente y no asumir que con un curso de 40 horas de Cobol uno es programador senior...

Hace algún tiempo que tengo esa idea en la cabeza... la primera vez que la comenté con alguien fue tomando un café con Leo Antoli y poco después, en una conversación en la lista de Agile Spain.

La mayor parte del material sobre agilismo hace referencia a mejorar el equipo de desarrollo. Mejorar sus skills técnicos. Mejorar su comunicación con el cliente. Mejorar la calidad del producto. Mejorar la calidad del proceso.

Aunque todo eso está muy bien, hay algo que chirria... ¿cómo podemos mejorar los procesos y la comunicación con el cliente sin el cliente?

Todo para el pueblo pero sin el pueblo

Hay una cierta prepotencia subyacente en que el Agilismo se esté vendiendo a los roles técnicos. Nosotros sabemos mejor que nadie como funciona esto.

El agilismo de guerrilla, el volar bajo el radar son cool. Hace que los técnicos puedan reconfortar sus egos al sentirse mejores que esos estúpidos jefes de proyecto que ponen fechas imposibles.

Pero, en realidad... ¿quien tiene la sartén por el mango?

Si no han cambiado mucho las cosas: el que paga... es decir, el cliente.

Los técnicos pueden ser super cool, adoptar todas las buzzwords e implantar las tecnologías y herramientas más cutting edge del sector. Pueden esforzarse mucho. Pueden hacer demos y montar un entorno de CI (¡y yo les animo a todo ello!).

Pero si el cliente no juega a lo mismo, si no está realmente implicado en el porqué de esas demos (detectar defectos e introducir los cambios cuanto antes)... entonces un día, poco antes de la fecha de entrega, llegará la orden de "hay que cambiarlo todo".

Y el equipo técnico perderá la sonrisa.

¿Y si fuese al revés? ¿Y si el cliente fuese el que exigiese una forma de trabajo ágil?

Pasarían dos cosas beneficiosas:

• Los parásitos del sector desaparecerían. Los malos profesionales no podrían sostener el ritmo. Es mucho más difícil entregar un producto funcionando cada 1 o 2 semanas que entregar papelotes para que parezca que sabemos lo que hacemos.

• El cliente se convertiría, automáticamente, en un aliado. No habría que buscar un Product Owner (lo que parece ser la mayor queja en la comunidad ágil española).

Entonces... ¿porqué seguimos vendiendo agilismo a los chicos de la cueva?