Así no se hacen las cosas por Ernesto Kiszkurno

Leyendo el McKinsey Quarterly de Agosto 2010, que trae 10 tendencias de tecnología a seguir encontré un comentario que me alarmó: Electricity produced to power the world´s data centers generates greenhouse gases on the scale of countries such as Argentina or de Netherlands, and these emissions could increase fourfold by 2010. En realidad no parece que el tema sustainability deba estar en el nivel C de la agenda de las empresas. Más bien parece que los CIOs tendrían que meterse en el tema con rapidez. Seguimos pensando..

Para aquellos interesados en los temas de gestión del tiempo me gustaría hablar sobre The Pomodoro Technique . Francesco Cirillo, su creador, lo define de la siguiente forma: The Pomodoro Technique™ is a time management method. For many of us time is an enemy. The anxiety triggered by “the ticking clock” and deadlines to be met leads to ineffective work and study habits and procrastination. The Pomodoro Technique™ transforms time into a valuable ally. A muy grandes rasgos la técnica consiste en planificar cada día estructurándolo de una manera muy precisa: Trabajar en tareas divididas en bloques de 25 minutos de duración. Cada uno de estos bloques es llamado pomodoro. Descansar de 3 a 5 minutos entre pomodoro y pomodoro. Cada 4 pomodoros, hacer un descanso largo de 15 a 30 minutos. Registrar todo en una planilla para monitorear nuestra productividad y mejorar continuamente. Para poder respetar los tiempos, se sugiere el uso de un temporizador para cocina (de ahí el nombre

En este post hablé sobre una forma de hacer más efectiva una reunión cuando uno tiene el rol de moderador. Pero ¿qué podemos hacer cuando no lo somos? Preguntar quien será el moderador de la reunión cuando nos invitan y ofrecernos para tomar el rol si esta vacante. Preguntar si hay una agenda que incluye objetivo(s), temario (con tiempo asignado para cada tema) y material de apoyo. Proponer, antes de la reunión, hacer checkin y checkout. Anunciar a los participantes nuestras expectativas respecto de la reunión con anterioridad. Variante Talibán: decir que no iremos porque no están dadas las condiciones ;-). Llegar a tiempo Seguimos pensando..

El tema de "la estrategia" siempre divide aguas. Por un lado, están los improvisadores que piensan que se le da demasiado peso al tema. Estos creen que las cosas deben dejarse más libradas al azar y que la vida es un misterio que se va acomodando a medida que transcurre. Por otro, están los planificadores que creen en ella fervientemente. Estos piensan que es imprescindible y que es la única forma de garantizarse el éxito. En este caso, como en muchos otros, opino que es una cuestión de grises y no de blancos o negros. La sabiduría está en qué porcentaje de tiempo nos comportamos como planificadores y qué porcentaje de tiempo nos comportamos como improvisadores (el equilibrio está en algún lugar en el medio y no en los extremos). Dicho esto, lo que nadie debería poner en duda es que, ya sea durante la improvisación o durante la planificación, nos comportamos y que pensamos estratégicamente . Avinash Dixit y Barry Nalebuff  en su libro Thinking Strategically ,

Este fin de semana estuve jugando con 3 herramientas para implementar GTD: TiddlyWiki , D-Cubed y MonkeyGTD . La idea surgió a partir de una conversación en Google Buzz sobre el tema herramientas para implementar GTD . Y, si bien yo tengo una aplicación de cabecera que uso desde hace tiempo, siempre estoy mirando otras por curiosidad. Ahora bien, como MonkeyGTD y D-Cubed son variaciones de TiddlyWiki, hago una breve intro de la primera y luego comento algunos detalles de las demás. TiddlyWiki es un wiki personal de un único archivo HTML muy portable y flexible. Para los que conocen al viejo Wikidpad , es muy parecido solo que más lindo visualmente y por supuesto no es necesario instalar nada en la PC. Los que saben lo usan tirando el archivo en un pendrive o en un directorio Dropbox para luego poder accederlo desde cualquier máquina. Los que saben mucho más arman una prism app (gracias Alejandro por el tip!). Uno de sus usos más difundidos es implementar GTD . A partir de est

En mi opinión una empresa de servicios de consultoría está en el negocio de vender confianza todo el tiempo (algo mencioné sobre este tema en 10 cualidades de un buen consultor ). Gracias a Walter Risi tomé contacto con un artículo llamado The Anatomy of a Consultant Firm de David Maister. El artículo resulta muy interesante para cualquier persona interesada en cómo funciona el negocio de ese tipo de empresas y por supuesto recomiendo su lectura. A mí en particular me gustó la tipificación que hace de las distintas personalidades que podemos otorgar a una empresa de consultoría [1] y cómo eso se relaciona con el tema de la confianza . El autor menciona 4 tipos que comento a continuación. #1 El farmacéutico A Pharmacy practice is one where the client is trying to buy a relatively familiar service and does not require very much counseling, consultation or contact. Aquí el cliente quiere un proceso de calidad pero estándard (no creatividad) y de buen precio. Aquí el nivel de conf

Muchas veces me encuentro en la difícil situación de tener que explicar la actitud que un PM debe tener a la hora de involucrarse en un proyecto. Afortunadamente, el otro día leyendo aleatoriamente feeds en mi Google Reader, encontré una perlita de Seth Godin que me ayudará con esta tarea en el futuro. En un post titulado “ The difference between running and managing a projec t” dice: If you choose to manage a project, it's pretty safe. As the manager, you report. You report on what's happening, you chronicle the results, you are the middleman. If you choose to run a project, on the other hand, you're on the hook. It's an active engagement, bending the status quo to your will, ensuring that you ship. Running a project requires a level of commitment that's absent from someone who is managing one. Who would you rather hire, a manager or a runner? Mi respuesta a su pregunta es, obviamente, que yo prefiero una actitud de ejecución de proyectos por s

Las dos actividades que más tiempo consumen en el proceso de testing funcional manual, por lejos, son la definición de casos de prueba y la ejecución de casos de prueba. Es por ello que cualquier intento de medir productividad en este proceso debe involucrar medirla en estas actividades. Las dos métricas que usualmente propongo para esto son la Velocidad de Definición (definida como la Cantidad de Casos Definidos, dividida la Cantidad de Horas dedicadas a definición) y la Velocidad de Ejecución (definida como la Cantidad de Casos Ejecutados, dividida la Cantidad de Horas dedicadas a ejecución). Un equipo de testing con intenciones de mejorar debe recolectar estas mediciones sistemáticamente para su análisis. Al hacerlo además, siempre es útil observar cómo "dan los números" agrupándolas de distintas formas, como por ejemplo tipos de casos (complejos, normales o simples) o tipos de aplicaciones (web, mainframe, etc.). Tener claros estos números permitirá al equipo de testi

He hablado sobre los planes de carrera y lo que se puede esperar de ellos en general. En una empresa de consultoría en particular, es necesario conversar sobre la carrera pero no en términos rígidos (ese es uno de los dos problemas que tengo con el concepto plan de carrera). El trabajo fundamental en estas empresas es ejecutar proyectos relacionados con las necesidades de sus clientes actuales . A raíz de esto, su entorno resulta sumamente volátil: Los clientes actuales pueden cambiar. Y si estos no lo hacen, sus necesidades lo harán. Y si estas no lo hacen, sus proyectos lo harán. Y si estos no lo hacen, las personas cambiarán. En una empresa donde la realidad está cambiando permanentemente resulta bastante difícil establecer compromisos fuertes (fechas y tiempos) respecto a los planes de carrera de las personas. Por otro lado se asume que las personas que eligen una empresa de consultoría buscan dinamismo, posibilidades de cambio y experiencias variadas en distintos ejes (indus