martes, 23 de febrero de 2010

Motivación intrínseca / extrínseca

Tras la entrada que escribí con Lucía he visto en el blog una nueva posibilidad: las colaboraciones. Me encantó la experiencia, y me mostró que así podría ofrecer contenido de más calidad al contar con la experiencia de otra persona y también podría ofrecer la perspectiva de profesionales que no estén directamente relacionados con el desarrollo del software. Por otro lado, realmente más importante para mí, es una forma de poder realizar algo junto a personas a las que aprecio, pero que por su profesión o circunstancias no tenemos la oportunidad de trabajar juntos.

No es nada sencillo, pues muchos de los colaboradores en los que he pensado no se dedican a la programación en ninguno de sus aspectos, pero lo que escribo hoy es una clara muestra de que todo es posible si realmente crees en ello, pues hoy la colaboradora es Nala, un bulldog francés que se ha ganado un importante puesto en mi vida y que me ayudará a explicar de forma gráfica la diferencia entre motivación intrínseca y extrínseca.

Motivación intrínseca. Nace de nosotros mismo, y es la motivación que sentimos al hacer aquellas cosas que nos gustan, que el simple hecho de hacerlas ya es una recompensa en sí misma. Al realizar determinadas tareas en determinados entornos que generan este tipo de motivación veremos que no nos cuesta concentrarnos, que ponemos empeño no sólo en acabar la tarea, sino en hacerlo bien y sin buscar una compensación extra. Para mí, aunque igual no podamos relacionarlo directamente con nuestro trabajo, el siguiente vídeo muestra de forma clara lo que una persona puede conseguir cuando hace algo con pasión, cuando sus acciones son movidas por el amor y no necesita más recompensa.



Motivación extrínseca. Por muy ideal que sea el entorno en el que trabajemos, pueden haber tareas que no sean del todo de nuestro agrado. Y aquí puede entrar en juego la motivación extrínseca, que nos anima a realizar una tarea pensando que al finalizar obtendremos una recompensa. Lo cierto es que con este tipo de motivación será más difícil mantener la concentración, nos bastará con realizar la tarea lo suficientemente bien para recibir el premio y evidentemente, si desaparece la recompensa desaparecerá las ganas de realizar la tarea. Quizás no veamos valor en este tipo de motivación, pero lo cierto es que puede llegar a ser muy útil y lograr hacer más llevaderas ciertas tareas que no son del agrado del equipo. Por ejemplo, cuando estuvimos adiestrando a Nala, el etólogo nos recomendó que cuando fuera a pasar mucho tiempo sola, la metiéramos en un transportin para hacer que su carácter fuera más equilibrado. Lo cierto es que ella prefiere salir con nosotros, y cuando le decimos que entre al transportin suele intentar persuadirnos. Para ello, primero se sienta, mostrando que se portará bien… si le seguimos insistiendo se echaría y luego se haría la muerta, todo con el objetivo de hacernos reír y aguantar un poco más fuera. Pero si ponemos en juego un motivador extrínseco (un trocito del bizcocho que le encanta) su actitud es totalmente diferente:



Prometo que las siguientes colaboraciones serán más serias, pero hay que reconocer que Nala lo ha hecho genial y yo me he divertido mucho. En términos de motivación, divertirte con tu trabajo es todo un éxito, así que creo que esta entrada no ha estado mal, por lo menos para Nala y para mí :-)

jueves, 18 de febrero de 2010

Falacia del costo irrecuperable

Hace unas semanas, intentando aprender de los que más saben, leí este artículo de Kent Beck. No es cuestión de traducirlo, porque ya lo ha hecho la gente de DosIdeas, pero sí que me gustaría comentarlo.

Kent Beck pone el ejemplo de una partida de poker en la que pierde mucho, y sólo piensa en seguir apostando para poder recuperar su dinero. Pero se da cuenta de que ya no era su dinero, había dejado de serlo desde que lo apostó. Tras esta reflexión, vuelve a jugar como si fuera la primera partida.

Luego explica que esta situación pasa también cuando programamos. Cito la traducción hecha por Leonardo De Seta para esta parte, porque este punto es realmente interesante:

Mi experiencia es que lo correcto en esta situación en donde no sabemos lo que hicimos para romper las pruebas es volver inmediatamente a un estado verde conocido, y volver a ejecutar las pruebas. Luego comenzar el refactor otra vez y correr las pruebas a cada paso. Pero, y aquí está la parte irracional, mientras más tiempo llevamos haciendo el refactor, más tentados estamos en seguir. Esta es la Falacia del Costo Irrecuperable en acción.

Mientras más llevo haciendo un refactor, menos recuerdo todos los pasos, más difícil será encontrar el error, mayor el valor de empezar otra vez. Mientras más difícil es comenzar otra vez (emocionalmente), más valioso es comenzar otra vez.

Ya no es mi tiempo. ¿Estuve haciendo un refactor por un minuto? ¿Una hora? ¿Un día? No importa. Ya no es mi tiempo. Se lo di al programa. Se fue. Lo que haga ahora no debería estar influenciado por la magnitud del tiempo que ya invertí. Ya no es mi tiempo.

Esto que explica Kent Beck se basa en la falacia del costo irrecuperable o falacia de la concordia. Esta falacia se produce cuando alguien realiza una inversión que parece ser no rentable y razona de la siguiente manera: «No puedo parar ahora, de otra manera lo que he invertido hasta el momento se perderá». Esto es verdad, por supuesto, pero irrelevante para la decisión de si uno debe continuar invirtiendo en el proyecto. Es decir, los argumentos para seguir invirtiendo en el proyecto no se deben basar en el miedo a la pérdida de lo invertido sino en las expectativas de funcionamiento del proyecto ambas cosas totalmente independientes.

Desde luego, ahora intento tener muy en cuenta esta historia al tomar decisiones, no sólo cuando programo.

martes, 9 de febrero de 2010

Estimación de poker

Desde la primera vez que leí acerca de la estimación de poker, tuve claro que era una técnica que podía aportar mucho al equipo. Desde mi punto de vista, sus principales ventajas (teniendo en cuenta mis circunstancias) son:

  • Visión general del proyecto. Estimar el tiempo que se debe invertir en realizar una tarea, requiere hacer un esfuerzo e imaginar cómo la haríamos y qué hace falta para realizarla. Esto hace que todos los miembros del equipo tengan una idea más precisa de lo que se hará en la siguiente iteración y no sólo de su parte.

  • Flujo de conocimiento. Cuando algún miembro hace una estimación que se sale de la media, tanto por encima como por abajo, lo normal es que explique en qué se basa. Esto puede hacer, por ejemplo, que este miembro o miembros muestren una situación que el resto del equipo no han tenido en cuenta y que hubiera hecho que se incumplieran las estimaciones; o que informe de alguna librería, utilidad, etc., que facilitaría en gran medida la implementación de la tarea y por eso requiere mucho menos tiempo.

  • Distribución de la responsabilidad en la estimación. La estimación ya no depende de una o algunas personas. Todo el equipo se implica en este proceso, aportando mucho más valor.
Afortunadamente, en mi empresa trabajamos en un ambiente distendido en el que las ideas no tienen las puertas cerradas. Siempre que se hagan responsablemente, toda propuesta es bienvenida, por lo que he aprovechado que estábamos a punto de iniciar una nueva iteración en un proyecto importante para proponer el uso de esta técnica.

Como me costaría ser objetivo, en las siguientes líneas Lucía explicará su experiencia con la estimación de poker. Ella ha sido la encargada de dirigir el proceso, así que nadie mejor para ofrecer una impresión parcial:

Bueno, antes de empezar a expresar mi opinión, quiero darte las gracias Gregorio por ofrecerme la oportunidad de aportar mi granito de arena a este blog, por el cual te felicito.

Empezando con la experiencia en sí, aunque sólo ha sido un primer pequeño pasito, creo que ha sido muy enriquecedora. En primer lugar, este tipo de estimación exige que haya una descripción clara de la tarea a realizar, pero que no sea excesivamente extensa. En nuestro caso, escogimos realizar la estimación vía web, usando la herramienta google wave con la extensión 'ScrumPoker'. El hecho de tener que explicar la tarea de forma escrita, no hablada, da menos interacción entre los participantes, pues no permite tan claramente un turno de dudas y preguntas tras la explicación de la tarea, lo que podría haber sido una desventaja, pero creo que en nuestro caso ha servido para definir con más rigor las tareas, lo cual en sí ya es una ventaja. Además, también nos evitamos que el turno de dudas se extienda demasiado, ya que, en todo caso, las dudas se responden directamente a la persona.

También el ser vía web creo que ha podido dar un poco más de tranquilidad a los participantes en las primeras estimaciones, pues para quien estima por primera vez puede ser un poco violento el dar una estimación muy desviada con respecto al resto dentro de una reunión 'cara a cara'. Además se evita el peligro de no tomar del todo en serio la estimación al ser una forma tan distendida de estimar, hablando claramente, no se corre el riesgo de demasiados comentarios jocosos durante la reunión que, antes de que todos los componentes hayan visto la utilidad de este tipo de estimación, es fácil que se dé.

En cuanto al momento de la estimación, la acogida por el grupo de trabajo fue muy buena, ya que todos los componentes se han implicado y han respondido muy bien. Al estudiar los resultados he visto que, salvo alguna excepción, las estimaciones eran muy similares, lo que facilita enormemente la estimación final de la tarea. En este sentido, he visto realmente útil los siguientes aspectos:
  • Facilidad a la hora de especificar la estimación final: el tener una visión de todo el equipo acerca de la duración de cada tarea hace más fácil especificar la estimación definitiva, así como da más seguridad sobre estar acercándonos más a una duración real.

  • Mayor conocimiento de los componentes del equipo: al ver la estimación realizada por cada componente del equipo, se conoce algo más de la forma de trabajo de cada persona, y las diferencias existentes en el equipo según tareas. Esto ayuda mucho para saber también quién sería el mejor candidato para cada tarea, lo cual es una ventaja extra que, hasta realizar la estimación, admito que no había previsto.
Creo que otro punto importante es el que señala Gregorio acerca del flujo de conocimiento, aunque si quiero ser sincera, creo que aún es pronto para saber el impacto que ha tenido en el grupo el conocer previamente la descripción de cada tarea (en este aspecto, espero que dentro de un tiempo Gregorio me deje otro “cachito” de blog para describir como ha influido :-)).

Esta primera prueba que hemos hecho creo que ha sido solo una pequeña aproximación a la estimación de poker, pues hubo algunos aspectos que creo que hicieron que no se pudiera sacar todo lo positivo posible, como la falta de tiempo para poder comentar mejor las desviaciones de las estimaciones o el desconocimiento de la herramienta utilizada. Aún así, Roma no se construyó en un día, y creo sinceramente que si la primera vez que se realiza ha dado tan buenos resultados, seguramente en la siguiente iteración, con más tiempo, con el equipo conociendo ya de qué se trata exactamente, las ventajas que nos dé este tipo de estimación pueden aumentar.

Para terminar, querría sólo comentar brevemente la experiencia del uso de la extensión 'ScrumPoker' de google wave. Creo que es una gran herramienta, muy sencilla de usar, y que hace muy cómoda este tipo de estimación, aunque aún está en fase de pruebas y, como es normal, tiene algunos errores que debe arreglar para ser realmente útil. Creo que cuando haya terminado la fase de pruebas, puede ser una herramienta que facilite mucho las estimaciones en los proyectos.

Lucía Manescau García

sábado, 6 de febrero de 2010

Metodologías ágiles: ¿Somos capaces?

Cuando empecé a leer sobre las metodologías ágiles, dos de los conceptos que más se repetían eran “equipos auto-organizados” y “profesionales competentes”. Estos días he estado pensando en estos conceptos, tras leer dos artículos:

Uno de ellos fue “Adiós al trabajo fijo, bienvenida la empleabilidad” de Pilar Jericó. Mientras lo leía, me quedé reflexionando en el siguiente fragmento:

Y por último y puede que más complicado, el profesional ha de velar por su propia carrera. Ya no vale quedarse de brazos cruzados para que la empresa decida qué es lo mejor para uno mismo. La persona se ha de preocupar de su formación y ser exigente con su propia empleabilidad. Si se está en una vía muerta, ha de poner los medios para salir de ahí estudiando, buscando alternativas o lo que sea… El objetivo personal no debería perderse nunca de vista: En el hipotético caso de que a uno lo echen (o amorticen su puesto, como se dice más elegantemente), tiene que ser empleable en otra organización. Desgraciadamente, esta crisis ha encontrado desprevenidas a muchas personas, que siguen culpando el sistema, cuando han estado durante años haciendo y repitiendo lo mismo. Ojala esta situación nos ayude a darnos cuenta de que de nosotros sólo depende nuestro futuro y que nuestro compromiso sólo tenemos que desarrollarlo si también nos aporta valor a nosotros.

¿Necesitamos una razón exterior, como es la crisis, para intentar ser competentes, formarnos, etc? Los estudios indican que para que un profesional sea realmente efectivo se debe trabajar la motivación intrínseca… pero si nos hace falta un toque de atención, como ha sido en este caso la situación del mercado laboral, para intentar estar a la altura, ¿podemos tener un problema? ¿Con esta radiografía de nuestro panorama, es factible hablar de equipos auto-organizados?

En este otro artículo, se habla de la intención de una multinacional norteamericana de cerrar su cede en España. Entre los motivos, yo me quedé pensando en estos:

… la falta de compromiso …

se quejan de lo poco operativos que son los españoles con los que comparten proyectos. Al parecer, y me lo creo, los españoles siempre se están quejando de esto o lo otro, no buscan de manera intuitiva soluciones a los problemas que surgen sino que intentan encontrar culpables para justificarse ellos mismos … (Con respecto a esto, sería interesante leer el siguiente artículo de Ángel Medinilla)

Reflexionando sobre estos dos artículos, lo primero que me planteo es si esto es un reflejo fiel de nuestra situación… ¿qué opinas? Luego, ¿puede ser esta una de las razones por la que otros países nos lleven ventaja en cuanto a la aplicación de las metodologías que están demostrando ser la solución a los problemas frecuentes en nuestra industria?