Rutina para cambiar

A veces cambiar es más difícil de lo que parece. Una y otra vez volvemos a caer en el comportamiento cotidiano.
Soy un jugador amateur de tenis y muchas veces me enfrento a rivales que tienen una técnica que considero inferior a la mía. Sin embargo, en muchos casos el resultado me es adverso.
Aprovecho los cambios de lado para mirar objetivamente qué debo cambiar. Algunas veces logro detectarlo, en otras no.
El principal ingrediente para lograr un cambio es encontrar qué es lo que se debe cambiar. Pensar solamente: "esto la estoy haciendo mal" no resuelve la situación. Es más, muchas veces pensarlo desde una óptica negativa es contraproducente (siempre es mucho más mejor enfocarse en lo que debe hacerse en lugar de lo que no).
Saber qué debemos cambiar no siempre es evidente. A veces requiere de pruebas y error para detectarlo. Otras es contraintuitivo. Sin embargo, una vez que lo sabemos gran parte del trabajo está hecho.
Empezamos a aplicar los cambios y percibimos los resultados. Acá es donde empieza la segunda parte del problema, que es en la que me quería enfocar: ¿cómo hacer para mantener el ritmo del cambio?
Vuelvo al tenis: Ya encontré lo que tengo que cambiar, lo estoy aplicando y veo los resultados, vuelvo a sentirme conforme con mi desempeño. Entonces me relajo y poco a poco dejo de prestarle atención al cambio.
Cuando me quiero dar cuenta, volví a caer en la conducta anterior, la que tengo por defecto y que quiero erradicar. Este punto a veces, especialmente en tenis, puede ser muy difícil de mantener. Es como si tuviese una superficie por donde fluyen las ideas, donde hay un surco grande y pronunciado: si no tengo cuidado, todas terminan cayendo ahí, no pudiendo escapar.
¿Cómo hago? Exagerar el cambio hasta volverlo costumbre. Repetirlo hasta en los casos en que no es necesario. Es acostumbrar a la cabeza al nuevo surco, pronunciarlo, volverlo el más relevante.

¿Para qué quiero tener razón?

¿Cuántas veces participamos en discusiones donde parece ser más importante tener razón que resolver los problemas?
Ejemplos:

• no te lo voy a repetir, ya te lo dije: ¿No sería más importante responder la pregunta y destrabar a la otra persona?
• sabía que esto iba a pasar: nada como predisponerse para el fracaso, esperarlo secretamente para tener razón…

Creo que siempre es más importante sumar, agregar valor. La razón no suma, si el producto no se entrega a tiempo, si el problema no se resuelve, tener razón es secundario, salvo para deslindar responsabilidades, que en definitiva, también es secundario. Ahora, si se llega a tiempo, si los problemas se resuelven, tener razón no tiene ninguna importancia. En cualquiera de los casos, tener razón no define el éxito de nuestros proyectos, solamente alimenta nuestro ego.

Un método básico para encontrar la razón de los problemas

Muchas veces, especialmente cuando escribo código, me encuentro con problemas que no puedo explicar, y por lo tanto, no puedo corregir.

Como todo el mundo, tengo mi propio método para abordarlos, porque muchas veces encontrar la razón puede consumir horas de frustración.

A continuación algunas de las ideas que aplico:

1. Puedo explicar por qué falla? Si la respuesta es afirmativa, ya no necesito continuar :)
2. Puedo repetir el problema u ocurre erraticamente. En el segundo caso, muy posiblemente se deba a problemas de hilos de ejecución, o datos externos, por ejemplo una base de datos que está siendo actualizada constantemente. Si es el primer caso, puedo continuar con la lista. Si es el segundo, tengo que poner logs por todos lados para capturar el problema la siguiente vez que ocurra.
3. Aislar el problema: si hay varios componente, intentar probarlos por separado para encontrar si el problema está en uno de ellos o en la interacción de dos o más (estos últimos suelen ser los más complejos de resolver)
4. Encontré el lugar donde está el problema, pero no puedo explicarlo. Es un problema que cabo de introducir ¿Funciona una versión anterior? ¿Funciona en otras circunstancias, como puede ser cambiando el navegador, versiones de componentes externos, parámetros de compilación: por ejemplo entre versiones de debugging y productivas?
5. Estoy asumiendo que algo en particular no es la causa del problema y la busco en otro lado? No hacerlo: demostrarme que no estoy equivocado probando eso que asumo que no falla pasa un test.
6. ¿Encontré la razón del problema? ¡Documentarlo! Ayudar a mi futuro yo a no tener que pasar por el mismo proceso exploratorio si me encuentro con el mismo problema dentro de un tiempo.

Oh vosotros los que entráis, abandonad toda esperanza

Esto es lo que reza la puerta del infierno en La Divina Comedia de Dante Alighieri.

Más allá de la poesía de la expresión, la frase encierra una sentencia terrible: perder toda esperanza.

¿Cuántas veces nos sentimos en una situación así, que ya nada puede hacerse, con una relación afectiva o con una profesional?

Asumir una postura así, no solamente nos predispone a sufrir, sino a que cada evento nuevo lo veamos como una oportunidad de confirmar nuestra sentencia.

Lo paradógico de todo esto, es que afirmar una cosa así, tan absoluta, nos va a "ayudar" a que se vuelva verdad. Es sabido que uno no ve a la realidad de forma objetiva, sino a través de unos ojos que están cargados de subjetividad e historia. Al margen de esto, está la tendencia del ser humano a buscar confirmar lo que pensamos. Esto es conocido como el sesgo de confirmación.

Ahora, qué pasa si lo vemos al revés: sino que en lugar de perder esperanza, no solo la tenemos, sino que la potenciamos? En este caso, nuestros ojos van a estar pendientes de que aparezcan indicios de que el cambio empieza a darse.  

Las mentiras más tontas también son peligrosas

Creo que si uno pregunta a los demás si mienten, la respuesta siempre es que no. 

Todos mentimos en algún momento, a veces por vergüenza, oteas simplemente porque es la respuesta más fácil para dar. 

El problema es cuando somos agarrados en una mentira. Hay mentiras que son importantes y otras que no, pero todas dejan una imagen nuestra cuando nos descubren. 

Me quiero enfocar en aquellas a las que no le damos importancia, que son tan tontas y parecen inocentes, pero que terminan transmitiendo un mensaje inconscientemente. 

Voy a poner un ejemplo: delante de otros colegas estoy hablando por teléfono con otra persona, donde para finalizar la conversación comento: "te dejo que tengo una reunión". Luego corto y sigo con mis cosas. La reunión nunca existió. Es una forma educada de finalizar la conversación telefónica. Pero que pueden pensar mis colegas si prestan atención: "le mintió a la otra persona solo para finalizar la llamada" y... acá viene la parte peligrosa: "¿cuantás veces me hará lo mismo a mi".

Resolver el problema a resolver

Muchas veces recibo propuestas, también órdenes de mis superiores, para solucionar algo. Suelen ser "optimizaciones" en los procesos y circuitos de una empresa. 

Ahora, lo que ocurre, muchas veces también, es que lo que queremos arreglar no está fallando. No siempre se cumplen las siguientes validaciones:

• ¿Es algo que está fallando o potencialmente puede hacerlo?
• ¿Hay algo que yo no estoy viendo?

Si no puedo encontrar una respuesta a esas preguntas, posiblemente se trate de una razón subyacente. En estos casos, el cambio puede no ser la mejor solución a este problema. Alguna vez he probado de utilizar el diagrama de Ishikawa  pero lo que me resultó más efectivo siempre es el preguntar por qué cinco veces (a cada respuesta que recibo, le repregunto por qué). 

Por último nunca está de más no perder de foco de la siguiente pregunta: ¿cuál es el problema que debería estar resolviendo ahora? Siempre que esté haciendo algo, voluntariamente o no, voy a estar decidiendo postergar otras cosas. Entonces: este nuevo problema, ¿es el problema a resolver, o debería enfocar mi atención en otra cosa. 

¿Qué hace especial a nuestros productos?

Muchas veces concebimos nuestros productos en base a una serie de características analizada, consensuada, profundamente discutida y verificada. Pensamos cuáles son las principales funcionalidades que lo van a hacer único. 

Después vienen las iteraciones donde nuestra creación va evolucionando, se va transformando... Esto ocurre porque recibimos feedback, porque vamos detectando mejoras principalmente por "vivir" ese producto. 

Y ahí aparece. De golpe, o a veces tímidamente, surge una característica nueva, que no vimos al definir nuestro producto, que de golpe pasa a ser lo que lo hace único, y hasta lo que le da sentido de ser. 

Leandro Panetta dio una charla en TEDxRiodelaPlata 2017 (aun sin publicar) donde explica el proceso creativo, donde a veces aparecen estas singularidades en las creaciones. Para él, es nuestra cabeza que aun está madurando el producto, no es algo que se inventa o descubre después, sino más bien, algo que se va gestando desde el momento cero. 

La enseñanza del "no"

Más veces de las que nos gustaría recibimos un no como respuesta a nuestras propuestas o planteos. Podemos enojarnos, pensar que la persona no entendió nuestra propuesta, que no tiene nuestra visión. En definitiva, transferirle la responsabilidad de la negativa. 

También podemos aprender y sacar algún provecho de la situación intentando indagar un poco más a fondo:

• ¿Por qué nos que no?
• ¿Explicamos bien la idea?
• ¿Hay alguna alternativa mejor?
• ¿Hay un factor que no estamos considerando?

Siempre que recibimos un no es una oportunidad para crecer, en lugar de caer en la fácil de tener pensamientos negativos sobre la persona que no aceptó la propuesta

Los mails que no hay que mandar

Hoy en día el email es una de las principales fuentes de comunicación en el trabajo, muchos inclusive lo prefieren a los llamados telefónicos para evitar la pérdida de tiempo que puede ocurrir si la conversación "se desvía"; también como evidencia de haber comunicado un tema en caso de un posterior conflicto. En mi opinión sirve para ver qué acordamos, es decir: como fuente de información para la toma de decisiones o su revisión. No hablo de los mails básicos que se usan como reemplazo de mensajes de texto o whatsapps: "almorzamos juntos?" sino de las comunicaciones que forman parte de los proyectos. Al margen de esto, creo que hay pautas básicas que pocos siguen y creo que son un error.

A continuación, resalto las más importantes:

• Nunca enviar mails enojado, el enojo pasa, pero el correo queda, y puede transmitir una sensación que ya no tenemos, y, sobre todo, puede ser usado en nuestra contra. 
• Escribir el mail con el objetivo de la comunicación completamente claro. Tenemos que poder responder la pregunta: si la otra persona tuviese que sacar una única conclusión al finalizar la lectura del correo, cuál queremos que sea?
• Revisar siempre lo que escribimos. Posee oraciones cortas? se entiende? No hay ideas contradictorias? Nada peor que un mail que no es claro o que provoca un hilo de conversación sólo para entender su significado.
• Revisar errores de tipeo o de falta de ortografía. Sino, estaremos mostrando que eso no es importante para nosotros. Si no lo es para nosotros, no podemos exigírselo a los demás. Además está la imagen negativa que estamos dando: que somos desprolijos que tenemos faltas de ortografía y no nos importa mejorar al respecto. 
• El mensaje tiene que ser autosuficiente. Si hacemos referencia a otro documento, a una página web, incluirla o poner su link. Tenemos que facilitar la comprensión a quién lee el correo. 
• Nunca poner en copia oculta a alguien. Esta es lamentablemente una práctica común, para poner en conocimiento a alguien de una comunicación sin que los demás se enteren. Más allá de que no parece una buena actitud, qué pasa si la persona en copia oculta no presta atención y responde a todos? Deja en evidencia nuestro comportamiento. En otras culturas se usa la copia oculta para avisar que alguien sale de la conversación (por ejemplo, porque ya no es necesario que siga participando) pero siempre se avisa, indicando al principio del mail lo que estamos haciendo, por ejemplo: (en copia oculta Miguel, muchas gracias por tus respuestas, nosotros continuamos hablando del tema)
• Nunca poner "Después te lo explico" o cosas similares. Hacer referencias a cosas que pueden no ocurrir en el futuro nos abre puertas a pendientes que podemos no completar.
• Si adjuntamos un documento, resumirlo en el cuerpo del mail. Muy pocos abren realmente el documento adjunto o lo pasan muy rápido. Un resumen puede ayudar a entender su contenido.
• Si necesito la respuesta u opinión de alguien, volver a mencionarla al final del mail. Los puntos de acción que necesitamos de los demás tienen que quedar perfectamente claros.
• Revisar la lista de destinatarios (así como también desde qué cuenta estamos enviando el correo, en caso de tener más de una): Los que deben actuar en "TO", los que deben estar notificados de lo que hacemos en "CC", y en "BCC" los que salen de la conversación. Leer un mail implica un compromiso, sólo enviarlo a los verdaderamente interesados. La imagen que damos en caso de estar copiando a gente externa al proyecto siempre es negativa: nos estamos dando corte o nos estamos cubriendo...
• Ya lo dije, pero creo que es muy importante: puedo resumir el mail y escribirlo más corto? Cuanto más largo sea el correo, menor la probabilidad de que sea leído en su totalidad.

La cultura de fallar

Existe una nueva tendencia, al menos en el mundo entrepeneur de celebrar los errores.

Esto apunta a lo siguiente:

• Si no se falla estrepitosamente al menos dos veces al año no se está saliendo de la zona de confort, no se está intentando empujar los límites.
• Todo error es aprendizaje. Si se despide al que comete un error, se da el mensaje que fallar es castigado. Además, el aprendizaje de haber vivido el error en primera persona, se pierde. 

Sin embargo, esto no puede llevarse a los extremos de hacer un ranking de quién fracasó más y asignar los premios en base a esa escala. Adicionalmente, se deben establecer límites para detectar tempranamente los errores, o al menos poder saber si no se alcanzarán los objetivos, para poder determinar acciones correctivas o finalizar la prueba.

Esto es una tendencia, que creo que dentro de ciertos límites, es correcta. Las empresas y las personas progresan por tomar riesgos. Pero es fundamental saber donde se están tomando esos riesgos. Estos deben ser controlados (dentro de ciertos límites) y evaluados constantemente. Distinto son los errores que ocurren donde no se los espera. Esto es simplemente no manejar una matriz de riesgos.

Lamentablemente, muchas empresas siguen todavía en un esquema mental anterior donde el error se castiga, en caso extremo con el despido.

Algunos indicios de que tu empresa castiga el error más allá de lo que diga en los cuadros motivadores que se ponen en los pasillos:

• Ante el error te preguntas: ¿esto fue mi culpa?
• En lugar de preguntar qué duda validamos o qué aprendimos, te enfocas en cuánto costó.
• Dudas en comunicar tus conclusiones preliminares si no son buenas noticias, sobre todo, esperando para ver si la situación se corrige.
• Ante un error buscas justificaciones externas a vos o a la compañía que puedan haber provocado el error.

El pasto es más verde del otro lado

Existe una frase, especialmente en inglés que hace referencia a que el pasto del vecino en general es más verde que el nuestro.

Esto hace referencia a la disconformidad con la situación actual, donde comparativamente nos vemos peor que el resto.

Hasta llegaron a analizar esto y lo mencionan como el síndrome del pasto más verde... jeje... hay gente y estudios para todo.

Sin ahondar, ni meterme en detalles, porque la psicología no es mi rama, leyendo este artículo encontré algo que me llamó la atención.
Inicialmente, menciona esto de que podemos experimentarlo en varios aspectos de nuestra vida, como trabajo, relaciones de pareja, etc. donde siempre pensamos que otros están mejor y que de alguna forma, podríamos alcanzar ese estado. El artículo no hace tanto hincapié en la envidia como sí en la disconformidad. Sea por una razón u otra, el que experimenta este síndrome está viendo la mitad vacía del vaso.

El punto que me llamó la atención es que no solo menciona el que uno tiene que aprender a ver lo que ya tiene, sino un aspecto que si bien es cierto, de alguna forma, uno no siempre le pone el foco: si quiero el jardín del vecino porque es más verde: ¿qué estoy perdiendo al abandonar mi jardín? Es decir, me enfoco en las cosas que me va a dar el cambio, pero...  ¿estoy dispuesto a perder algunas de las cosas que ya tengo para alcanzar el nuevo objetivo? Me parece un enfoque interesante. Todo cambio siempre tiene un trade off donde algo se tiene que dar para alcanzar el nuevo estado, y no siempre estamos conscientes de qué es lo que tenemos que dar, o al menos de cuán bueno representa para nosotros. Entonces, el que experimenta este síndrome, al alcanzar el nuevo jardín, empieza a buscar el siguiente...

Viví de tu pluma

Esther Feldman contó en el podcast Aprender de grandes de Gerry Garbulsky (http://aprenderdegrandes.com/esther/) que una vez tuvo que tomar una decisión importante en su vida: entre seguir en una cátedra de literatura que había conseguido una beca del Conicet (centro de investigación que financia estudios científicos) o continuar escribiendo los guiones de una telenovela de adolescentes de los 80s: Montaña Rusa.

Su profesor, le recomendó "Viví de tu pluma" y eso fue lo que la impulsó a tomar la decisión de abandonar la cátedra y seguir con la "banalidad" de la telenovela. Hoy es guionista de muchas de las producciones de la TV Argentina.

¿Cuántas veces nos encontramos en esta decisión, entre decidir lo que parece que debería ser y lo que nos gusta y nos llama? Puede inclusive ampliarse hasta puntos como la decisión entre lo altruista y lo que puede sonar como venderse por el dinero.

¿Cuántas veces se lo reclamamos a los demás, especialmente a las personalidades conocidas como deportistas, celebridades, etc? "Jugá por la camiseta... yo en tu lugar..." Primero, yo no estoy en tu lugar, así que es muy fácil hablar desde la suposición. Y yo en mi lugar juego por la camiseta o por mi propio interés? 

¿Si cada uno de nosotros buscamos siempre lo que consideramos lo mejor para nosotros, por qué no se lo aceptamos a los demás?

Pero no quiero ir por ese lado... :)

Cada vez más existe un convencimiento de que "vivir de tu pluma", hacer lo que te gusta, puede o no transformarse en volverse "exitoso", sea llenarse de plata, ser famoso, o ganar renombre en la industria en la que te moves, pero lo que lo que dicen es: disfrutá lo que hagas, eso, a la larga te va a volver exitoso... porque vas a haber disfrutado del viaje, que es muuucho más largo que la meta de llegada, que dicho sea de paso: cuando podemos decir que llegamos?

Les dejo uno de mis poemas preferidos que siento relacionado con todo esto.

Cuando emprendas tu viaje a Itaca

pide que el camino sea largo,

lleno de aventuras, lleno de experiencias.

No temas a los lestrigones ni a los cíclopes

ni al colérico Poseidón,

seres tales jamás hallarás en tu camino,

si tu pensar es elevado, si selecta

es la emoción que toca tu espíritu y tu cuerpo.

Ni a los lestrigones ni a los cíclopes

ni al salvaje Poseidón encontrarás,

si no los llevas dentro de tu alma,

si no los yergue tu alma ante ti.

Pide que el camino sea largo.

Que muchas sean las mañanas de verano

en que llegues -¡con qué placer y alegría!-

a puertos nunca vistos antes.

Detente en los emporios de Fenicia

y hazte con hermosas mercancías,

nácar y coral, ámbar y ébano

y toda suerte de perfumes sensuales,

cuantos más abundantes perfumes sensuales puedas.

Ve a muchas ciudades egipcias

a aprender, a aprender de sus sabios.

Ten siempre a Itaca en tu mente.

Llegar allí es tu destino.

Mas no apresures nunca el viaje.

Mejor que dure muchos años

y atracar, viejo ya, en la isla,

enriquecido de cuanto ganaste en el camino

sin aguantar a que Itaca te enriquezca.

Itaca te brindó tan hermoso viaje.

Sin ella no habrías emprendido el camino.

Pero no tiene ya nada que darte.

Aunque la halles pobre, Itaca no te ha engañado.

Así, sabio como te has vuelto, con tanta experiencia,

entenderás ya qué significan las Itacas.

C. P. Cavafis. Antología poética.

Alianza Editorial, Madrid 1999.

http://www.pixelteca.com/rapsodas/kavafis/itaca.html

Acerca de la autonomía

Recuerdo una vez tuve que entregar una evaluación de desempeño a una persona, y surgió la duda sobre qué significa ser autónomo. Más allá de la respuesta obvia de que pueda resolver sus responsabilidades sin necesidad de apoyo de pares o supervisores, creo que se le puede agregar algo relacionado con la visibilidad de sus tareas.

Se me ocurrió un ejemplo simple, quizás demasiado, pero que creo que puede explicar las diferentes posturas. 

Supongamos que necesito que alguien transcriba en un pizarrón una lista de tópicos a revisar en una reunión. La persona encargada toma la tarea. De golpe se encuentra con que existen tres marcadores con distintos colores, y por su experiencia previa sabe que no es algo trivial. Cuales son sus opciones:

1. Decidir el color ella misma. 
2. Preguntarme.
3. Acercarce a mi y proponerme las opciones sin dejar de explicar cuál es su recomendación. Ej: no recomiendp el rojo por su connotación negativa. El verde es mi selección, porque se lee claramente y en general se lo asocia a cuestiones positivas, que avanzan (como un semáforo).  

Por qué elijo la tercer opción? Voy descartando de a una:

1. Esta opción no representa una autonomía sana, porque no permite validar o modificar las opciones hasta que ya esté todo terminado. Si bien la persona trabajó en forma autónoma, no hay puntos de control, donde se pueda validar lo que se hizo hasta que ya no está terminado. A los efectos prácticos, es como un proyecto de una sola iteración.
2. En la segunda opción, la persona no es autónoma en absoluto. Necesita ayuda en la toma de decisiones porque no sabe cómo proceder. A esta persona, yo podría decirle algo así como... "bueno, vamos con el color azul".
3. La tercer opción es mi preferida, porque la persona muestra iniciativa, justifica las decisiones, pero las valida antes de consumir un tiempo que una vez transcurrido, no se podrá volver atrás. Además, al explicarme el por qué de las decisiones que tomó me facilita la comprensión cómo es su proceso mental y cómo toma sus decisiones, volviéndola más predecible, cosa que en definitiva, le brindará mayor confianza por mi parte, ganando autonomía.

Qué tipo de jefe tenés y cómo ayudarlo

Todos tenemos un jefe a quién reportar, y si bien nosotros no somos perfectos, tampoco lo son nuestros jefes. Ellos también tienen sus fortalezas y debilidades. En esta entrada voy a intentar enunciar algunas de sus características y cómo ayudarlos a mejorar, porque en definitiva, si a tu jefe le va mal, a vos seguramente no te vaya mejor...

Jefe laizzes-faire

Este tipo de jefe te deja hacer lo que quieras, prácticamente no te controla. Muy pocos check-points, dando rienda suelta a tu gestión. Si tenés reuniones planificadas con él de revisión de tu trabajo, posiblemente falte o quiera resolverlas rápidamente. 

Ventajas

• Tenés libertad de acción, podes trabajar a tu propio ritmo y con las herramientas que considerás mejores.
• Aumenta el nivel de responsabilidad de tu trabajo.

Desventajas

• Podés enterarte muy tarde de que estás yendo en la dirección incorrecta o que estás tomando decisiones erradas.
• Si fallás en tu trabajo, no te va a apoyar, porque no está comprometido con tu trabajo.

Qué hacer

• Tiene cosas más importantes. Asegurate que sienta importante tu trabajo
• Asegurarte de tener las reuniones de revisión. Llegar siempre con la información lista para presentarle. Tener identificados de antemano los puntos en los que su decisión es importante.
• Comprometerlo con tu trabajo, pidiéndole opinión y recomendaciones. Si lo participás de tus decisiones, él va a sentirse obligado a respaldarte al presentar los resultados del proyecto a terceros.
• Enviale email semanales con tus objetivos y logros. Si bien no necesariamente van a ser leídos, estás dándole la oportunidad de que los lean
• Puede ser que te conozca hace mucho y tenga plena confianza en vos. Asegurate que eso se mantenga dándole visibilidad del avance de tu trabajo

Jefe high definition

Este tipo de jefe estará atento de todos los detalles. Prácticamente no te dejará trabajar sin que sientas su mirada controladora por atrás de tus hombros.

Ventajas

• Difícilmente hagas algo que no le guste, o que se transforme en una sorpresa desagradable para él cuando lo presenten a terceros.
• Recibís feedback constantemente.

Desventajas

• Posiblemente no te deje trabajar tranquilo, y te esté interrumpiendo constantemente para ver cómo venís.
• Puede minar tu creatividad, al punto de anularla, transformándote exclusivamente en su brazo ejecutor.

Qué hacer

• Posiblemente no confíe en tu trabajo, para que empiece a confiar en vos tenés que volverte predecible para él. ¿Cómo lograrlo? Para cada punto que requiera de su intervención intentá plantear el tema lo más objetivamente posible, despojado de sentimientos y emociones, y sobre todo: presentá todas las posibles soluciones que encontrás, junto con la que considerás mejor y por qué. 
• Mostrale que el avance no se detiene si él no estuvo presente, porque por ejemplo, estuvo en reuniones toda la mañana. Si algo necesitaba de su conformidad para poder continuar, seguí con el siguiente punto de tu lista de prioridades (preparada por vos, pero validada con él ;)

Linus Torvalds era ágil desde 2004!

Una frase de Linus Torvalds (el creador de Linux):

“Nadie debe empezar un proyecto grande. Empieza con uno pequeño y trivial y nunca esperes que crezca; si lo haces solamente sobre diseñarás y generalmente pensarás que es más importante de lo que lo es en esta etapa. O peor, puedes asustarte por el tamaño de lo que tu esperas que crezca. Así que empieza pequeño y piensa en los detalles. No pienses acerca de la foto grande y el diseño elegante. Si no resuelve una necesidad inmediata, seguramente está sobre-diseñado. Y no esperes que la gente salte a ayudarte, no es así como estas cosas funcionan. Primero debes tener algo medianamente usable y otros dirán "hey, esto casi funciona para mí" y se involucrarán en el proyecto”.

Si bien es un comentario orientado a los desarrollos open source, la primer parte del texto aplica 100% a las metodologías ágiles.

Fuente: http://en.wikiquote.org/wiki/Open_source

Introducción a las metodologías ágiles

En el siguiente link podrán encontrar la presentación que usé para el seminario de Introducción a las Metodologías Ágiles, dictado en el MUG en mayo de 2009.

¿Por qué usar un Issue Tracker?

Sigo con mis listas de razones sobre las herramientas. En este caso un Issue Tracker.

Quizás deba empezar por una pregunta más básica: ¿qué es un issue tracker? Acá tienen una buena explicación, aunque en inglés.
La respuesta a esta pregunta puede simplificarse a su traducción: el seguimiento de ítems de trabajo.

Al utilizar una herramienta como Jira, Bugzilla, Trac, obtenemos los siguientes beneficios:

• un único punto de información de cada ítem de trabajo. No hay respuestas parciales en distintos mails y/o documentos.
  
• un punto centralizado para todas las pruebas y bugs detectados de una aplicación. Al ser web, se evita el problema de planillas que se van actualizando simultáneamente en distintas versiones.
• un punto objetivo de status actual de una iteración. La información que se visualiza en un issue tracker, si está actualizada es objetiva. Desaparecen las respuestas ambiguas de "vamos bien" o los porcentajes dudosos: estamos en un 75% del desarrollo completado.
• poder publicar a los usuarios/clientes, una herramienta para que ellos hagan su propio seguimiento y/o reporte de incidencias.
• poder revisar asignaciones y carga de trabajo de cada miembro del equipo
• poder saber cuanto nos está faltando de tiempo estimado de los issues pendientes para terminar la iteración
• poder llevar diverso tipo de estadísticas, por ejemplo: esfuerzo bug/esfuerzo total iteración, burndown chart, tiempo promedio de corrección los bugs, etc.

Mapa de desarrollo Open Source

redhat.com publicó un mapa de desarrollo open source (http://www.redhat.com/about/where-is-open-source/activity/) según un estudio de Georgia Institute of Technology (Georgia Tech). Esto se basa en la cantidad de usuarios y proyectos open source que están ocurriendo en el momento.

Algunas curiosidades:

• El primer país es Francia, seguido de Alemania y luego España.
• EUA está en la 9a posición
• China: 15
• India: 23
• Dentro de Latinoamérica, los principales son: Brasil 12, Venezuela 34, Perú 36 y Argentina 37

Jira + Confluence por u$s 5 cada uno

A todo aquel que esté interesado en conocer una excelente herramienta de issue tracking, le recomiendo acceder a este link (http://www.atlassian.com/) y acceder al Atlassian $timulus Package. La idea es que por 5 días (hoy finaliza el 4o) podremos acceder a la versión full de JIRA (aunque limitada la cantidad de usuarios a 5) por un año, renovable por otros u$s 5.

Creo que es una excelente forma de probar el producto en productivo.

Cada mañana en el Africa

Traigo a colación un proverbio africano que encontré en el libro: The world is flat de Thomas L Friedman, que dicho sea de paso, se lo recomiendo a cualquiera que quiera entender el mundo de los negocios, principalmente asociados a la tecnología, de hoy día.

Cada mañana en África, se despierta una gacela. Sabe que tiene que correr más rápido que el león más rápido o será atacada.
Cada mañana se despierta un león. Sabe que tiene que correr más rápido que la gacela más lenta o se morirá de hambre.

No importa si uno es un león o una gacela, cuando el sol sale, más vale que estés corriendo...

¿Hay algo más ágil que esto? ¿Ven el paralelo que veo yo con las metodologías ágiles?