noviembre 28, 2006

La confianza y las metodologías ágiles

Llevaba varios días dándole vueltas a una idea, que acabo de plasmar en un corto comentario en este interesante post sobre los " 7 paradigmas para ser ágiles". Es algo tan sencillo como que para moverse hacia las metodologías ágiles en una empresa, la idea fundamental es la C-O-N-F-I-A-N-Z-A. Confianza .
Al abandonar paulatinamente el control basado en procesos, empiezas a confiar en que las personas desarrollarán su trabajo de la manera adecuada por que saben hacerlo y quieren hacerlo. Esto tiene numerosas implicaciones. De repente el departamento de calidad no tiene que vigilar el obligado cumplimiento de normas, procesos y burocracia. Los jefes deben confiar en sus empleados (no me gusta decir "la empresa debe...". La empresa no confía, la empresa no siente ni padece). Los empleados y jefes deben confiar en sus compañeros.Confianza en los conocimientos de los empleados, en su sabiduría y buen hacer. Confianza en la palabra de las personas. No necesitas poner exhaustivamente todo por escrito. Confías en ellos, si te dicen algo, lo harán.
Pasar a un modelo colaborativo exige confiar. Cuando en una organización se han creado los procesos para controlar el trabajo, es dificil volver atrás. Pero no debe ser imposible.
Por algo Joel Spolsky dice que hay que contratar a los mejores, únicamente en las personas en las que estés convencido.

In principle, it’s simple. You’re looking for people who are

  1. Smart, and
  2. Get things done.
That’s it. That’s all you’re looking for.

Así puedes confiar en ellos.
Sin duda no es un paso fácil en muchas empresas.
  • Existen subcontrataciones que se controlan exageradamente por que "vete tú a saber qué hacen". Pero entonces ¿por qué se les contrato? ¿se confiaba en ellas? O quizás se ha perdido la confianza a lo largo del proyecto. Entonces el problema no es controlarlas, si no volver a confiar en ellas, analizar qué se hizo mal.
  • O a veces hay jefes de equipo que controlan al milímetro lo que hacen sus subordinados, cargándose un exceso de trabajo que no les corresponde, y siendo un cuello de botella en el proyecto.
  • Incluso cuando los trabajadores no se fían del trabajo de los demás, o lo desprecian si lo han hecho en otro equipo, se ponen zancadillas al buen desarrollo de los proyectos.
¿Se puede corregir esto con normas y procesos? Pues quizás a veces sí. Pero, si queremos movernos hacia las metodologías ágiles, por que creemos que pueden ser beneficiosas en un buen número de proyectos, centrándonos más en las personas que en los procesos, el objetivo debe ser recuperar la confianza.

Actualización, para los que no soleis leer los comentarios (!¿por qué nooo?!) :)
escéptico comenta:
1.- Un Jefe de Proyecto debe ser paranoico respecto a los procesos ("Las cosas pueden fallar") pero confiado respecto a las personas ("Mi equipo saldrá adelante").
Por desgracia a veces ocurre lo contrario: se desconfía de las personas pero aun así se mantienen planificaciones irreales.
2.- Realmente los que saben realizar el trabajo son los miembros del equipo. El Jefe de Proyecto se dedica a coordinar los esfuerzos, no a repasar, revisar lo que se hace.
Por desgracia hay Jefes de Proyecto que piensan que si se pudiesen clonar ellos mismos y reemplazar a su equipo, las cosas irían mucho mejor.
3.- Un Jefe de Proyecto está solo en cuanto a sus temores pero debe escuchar y prever los de su equipo.
Por desgracia hay Jefes de Proyecto que desaniman a su equipo con su actitud.
4.- Un Jefe de Proyecto debe defender a su equipo ante su Supervisor y filtrar los aspectos negativos de éste a sus colaboradores.
Por desgracia muchos Jefes de Proyecto se quejan de los malos mimbres que les han proporcionado y hacen de mera correa de transmisión de la presión ejercida desde arriba.
2ª Actualización: Para los futboleros, Oscar me hace notar que la confianza es importante en cualquier campo (¡hasta de fútbol!): La confianza y las caderas ágiles.

noviembre 18, 2006

La publicidad de Microsoft sobre ¿software libre?

Lleva unos días saliendo este anuncio en mi bitácora, sobre Software Libre (también lo he visto creo que en Meneame alguna vez):


Y un día por curiosidad descubrí... !que se trata de un anuncio de Microsoft! Y te lleva aquí: http://www.microsoft.com/spain/hechos/default.mspx, donde te cuentan alguna historieta sobre una tal teleflora.

Ojalá estas maniobras, de "información" y competencia fuesen las únicas que utilizasen, y no la intimidación y el juego sucio del que han hecho gala hasta ahora.

Relacionado: Vivir del software libre

noviembre 16, 2006

Bruce Lee hasta en los punteros

Vía messenger, de vía email, de vía vete-tu-a-saber... Si eres programador, te toca el punterito que todos llevamos dentro.

Empty your memory,
with a free()...
like a pointer!
If you cast a pointer to a integer,
it becomes the integer,
if you cast a pointer to a struct,
it becomes the struct...

The pointer can crash...,
and can Overflow...

Be a pointer my friend...
Esta versión me ha gustado mucho... ¿cuantas más conoceis?

noviembre 15, 2006

Un añito


Y es que con esa carita no me he podido resistir a ponerle aquí.

Por qué los programadores se llevan el trozo grande del pastel (sic)

Dice Joel Spolsky que hay que saber ser flexible para cambiar de contexto cuando sea necesario. Critica que en un desarrollo de un proyecto con una metodología ágil, no se fuese capaz de cambiar al programador para algo quizás más importante por no perder un día de éste en ese proyecto. Lo que parece en realidad es falta de comunicación o conocimiento, ¿qué era más importante para la empresa en ese momento? O el desarrollo del nuevo producto, o la atención al problema que ha surgido sin planearlo. Alguien tenía que decidir. En realidad creo que la crítica a las metodologías ágiles en este caso no está bien traida, pues en realidad como afirma al final el problema es del "manager"

But every decision has pros and cons and when I hear a manager who is just talking about the cons without considering the pros, that manager is not doing their job.
Sim embargo lo que más me ha llamado la atención es esta frase:
This Is Why Programmers Get The Big Bucks. The whole reason you gave them Aeron chairs, unlimited M&Ms, free catered lunches, and the kickass computers with the 30" LCDs is so they can deal with new bugs Microsoft introduced in their code by messing up a DLL that used to work.
No cabe duda de que Joel Spolsky sabe cuidar a sus trabajadores, M&Ms ilimitados :) , comidas incluidas, los mejores ordenadores... y lo que de verdad importa, una valoración excepcional del trabajo que realizan sus programadores. Sabe que su trabajo no es fácil, y lo valora. No es el primer comentario en el que Joel da muestras de saber tratar a sus empleados.
Vamos, como aquí por España, lo mismo. ¿alguién quiere seguir siendo programador toda su vida?