Continuo con los aprendizajes que hemos obtenido en los últimos meses en la aplicación de la metodología de Programación Extrema en Imolko. En este post, comento sobre como mantener el foco en el cierre para lograr los resultados deseados.
Puedes ver el primer artículo aqui.
Foco en el Cierre
Nada más importante que lograr el cierre de una tarea o funcionalidad. Debemos obligarnos todo el tiempo a hacernos dos preguntas claves:
1) ¿Qué hace falta para cerrar lo que estoy haciendo?
Muchas veces cuándo se está desarrollando una funcionalidad se hace sin ningún plan específico. Simplemente voy desarrollando a medida que voy necesitando y no tengo claro cuál es el siguiente paso. Esto lleva a que termine invirtiendo demasiado tiempo y energía en cosas que realmente no me hacen falta. O que me desenfoque en otras tareas (investigar en Internet, ver otros problemas o terminar chateando con otra gente) y no tengo claro cuáles actividades me faltan para cerrar.
Por el contrario cuándo tengo un plan mental sobre las actividades faltantes, puedo administrar mejor mi tiempo e incluso pedir ayuda para tareas específicas que me ayuden a cerrar.
2) ¿Qué puedo posponer para cerrar más rápidamente la funcionalidad que estoy haciendo?
Esta pregunta es aún más dificil de hacer que la primera. Esta pregunta ayuda a definir claramente que es lo más importante en lo que estoy haciendo. Una vez qu entiendo que es lo más importante, puedo ver con claridad cuáles cosas se pueden posponer. Cada vez que posponemos podemos cerrar más rápidamente.
Y cada cierre es una victoria. Con cada cierre estamos entregando más valor a nuestros clientes. Por que al final del día, nuestro cliente nos agradece que le entreguemos una funcionalidad pequeña cada mes, en vez de sólo entregarle en dos años una mega funcionalidad.
Inicialmente estas dos preguntas las he estado haciendo todo el tiempo a todo el mundo. Pero realmente lo importante es que todo el equipo las haga todo el tiempo; consigo mismo y con todo el resto del equipo.
En el siguiente post (el último de esta serie) comento sobre el uso de versiones integrales o coherentes.
lunes, 27 de diciembre de 2010
viernes, 10 de diciembre de 2010
Aprendizajes Extremos (2da parte)
Este post forma parte de una serie de cuatro artículos sobre aprendizajes en la utilización de Programación Extrema. En el primer post, comentaba sobre el manejo de Versiones con Fecha Fija de Release.
Una sola tarea a la vez
Este me parece una de los aprendizajes más contra-intuitivos. Por lo regular uno piensa que mientras más tareas le asignes a una persona más posibilidades hay que se terminen las cosas. Cuándo se distribuyen las tareas tenemos la sensación que ya hemos avanzado y que estamos más cerca de terminar.
En mi experiencia resulta todo lo contrario.
A nível personal cuándo una persona tiene varias asignaciones por desarrollar termina menos cosas que recibiendo una asignación por vez. Creo que tiene que ver con la sensación de angustia que se genera al tener muchas cosas pendientes.
A nível grupal el efecto es aún más perverso; primero que la distribución del trabajo se realiza al principio del ciclo cuándo todavía no se tiene claro cuánto tiempo toma cada tarea. Entonces una persona podría acabar con mucho más trabajo que otras.
El grupo no se concentrar en cerrar sino en abrir. Lo más importante termina siendo "abrir" o comenzar con la nueva asignación en vez de concentrarse en "cerrar" la única que tenemos en cada momento.
En nuestro caso cada nuevo desarrollo es cerrado por el representante del usuario; cuándo un desarrollador tiene varias tareas pendientes sucede un ciclo totalmente antiproductivo. El ciclo se resume en estos pasos:
1) Desarrollador termina primera versión de una funcionalidad y la asigna al rep del usuario
2) Rep del Usuario está haciendo otras cosas, y le pide tiempo para hacer las pruebas
3) Desarrollador "abre" la próxima funcionalidad y comienza a trabajar. Saca de su mente el problema anterior e introduce este nuevo problema.
4) Rep del Usuario, realiza las pruebas y hace unas correcciones.
5) Desarrollador no quiere dejar de trabajar en su nueva funcionalidad (en la que ya está inmerso) y pide tiempo para realizar las correciones.
6) Vuelve al punto 1)
Despues de mucha energía y tiempo invertido se tienen muchas funcionalidades "abiertas" y ninguna cerrada.
Para romper con esta situación la solución es muy sencilla: Una sola asignación a la vez. Esta regla sencilla requiere mucha disciplina pero se gana full.
El ciclo queda así:
1) Desarrollador termina primera versión de una funcionalidad y la asigna al rep del usuario
2) Rep del Usuario está haciendo otras cosas, y le pide tiempo para hacer las pruebas. El tiempo solicitado se minimiza por que se entiende que el desarrollador no va a comenzar con más nada)
3) Desarrollador realiza pruebas de su funcionalidad, exactamente igual a como lo haría el rep del usuario. Si tiene errores corrige de una vez.
4) Rep del Usuario realiza pruebas, y se consigue con una versión más estable. Hace recomendaciones al desarrollador
5) Desarrollador termina correcciones y se cierra la funcionalidad.
6) Vuelve al punto 1)
Cada vez que se ejecuta este ciclo se tienen funcionalidades cerradas y la sensación de avance que a todos nos sube el auto estima. Y cada vez que cerramos tenemos ganar de seguir cerrando.
En la próxima parte, hablaré sobre como mantener Foco en el cierre.
Una sola tarea a la vez
Este me parece una de los aprendizajes más contra-intuitivos. Por lo regular uno piensa que mientras más tareas le asignes a una persona más posibilidades hay que se terminen las cosas. Cuándo se distribuyen las tareas tenemos la sensación que ya hemos avanzado y que estamos más cerca de terminar.
En mi experiencia resulta todo lo contrario.
A nível personal cuándo una persona tiene varias asignaciones por desarrollar termina menos cosas que recibiendo una asignación por vez. Creo que tiene que ver con la sensación de angustia que se genera al tener muchas cosas pendientes.
A nível grupal el efecto es aún más perverso; primero que la distribución del trabajo se realiza al principio del ciclo cuándo todavía no se tiene claro cuánto tiempo toma cada tarea. Entonces una persona podría acabar con mucho más trabajo que otras.
El grupo no se concentrar en cerrar sino en abrir. Lo más importante termina siendo "abrir" o comenzar con la nueva asignación en vez de concentrarse en "cerrar" la única que tenemos en cada momento.
En nuestro caso cada nuevo desarrollo es cerrado por el representante del usuario; cuándo un desarrollador tiene varias tareas pendientes sucede un ciclo totalmente antiproductivo. El ciclo se resume en estos pasos:
1) Desarrollador termina primera versión de una funcionalidad y la asigna al rep del usuario
2) Rep del Usuario está haciendo otras cosas, y le pide tiempo para hacer las pruebas
3) Desarrollador "abre" la próxima funcionalidad y comienza a trabajar. Saca de su mente el problema anterior e introduce este nuevo problema.
4) Rep del Usuario, realiza las pruebas y hace unas correcciones.
5) Desarrollador no quiere dejar de trabajar en su nueva funcionalidad (en la que ya está inmerso) y pide tiempo para realizar las correciones.
6) Vuelve al punto 1)
Despues de mucha energía y tiempo invertido se tienen muchas funcionalidades "abiertas" y ninguna cerrada.
Para romper con esta situación la solución es muy sencilla: Una sola asignación a la vez. Esta regla sencilla requiere mucha disciplina pero se gana full.
El ciclo queda así:
1) Desarrollador termina primera versión de una funcionalidad y la asigna al rep del usuario
2) Rep del Usuario está haciendo otras cosas, y le pide tiempo para hacer las pruebas. El tiempo solicitado se minimiza por que se entiende que el desarrollador no va a comenzar con más nada)
3) Desarrollador realiza pruebas de su funcionalidad, exactamente igual a como lo haría el rep del usuario. Si tiene errores corrige de una vez.
4) Rep del Usuario realiza pruebas, y se consigue con una versión más estable. Hace recomendaciones al desarrollador
5) Desarrollador termina correcciones y se cierra la funcionalidad.
6) Vuelve al punto 1)
Cada vez que se ejecuta este ciclo se tienen funcionalidades cerradas y la sensación de avance que a todos nos sube el auto estima. Y cada vez que cerramos tenemos ganar de seguir cerrando.
En la próxima parte, hablaré sobre como mantener Foco en el cierre.
lunes, 22 de noviembre de 2010
Aprendizajes Extremos (1era parte)
Buscando mejorar nuestra productividad en el desarrollo del software, en los últimos dos meses hemos implementado cambios en la forma en que estamos trabajando. Manteniéndonos en los principios básicos de XP, hemos hecho algunos ajustes menores y radicales en otros.
El objetivo fundamental de estos cambios es lograr cerrar la mayor cantidad de funcionalidades, y que éstas lleguen rápidamente a los clientes.
En la forma en que estábamos trabajando se venía presentando una situación dónde no teníamos el foco en hacer llegar las nuevas funcionalidades. El foco se trasladó al proceso del "cierre" de la funcionalidad pero esta funcionalidad no tenía que llegar al cliente para ser aprobada. Entonces se presentaban una situación dónde se podían cumplir las metas pero el cliente no veía ninguna mejora.
Versiones con Fecha Fija
El concepto de los User Stories en XP permite separar claramente cada nueva funcionalidad y manejarla como una unidad independiente. El riesgo que presenta este enfoque es que terminemos con una seria de funcionalidades inconexas que se van entregando al usuario en forma desordenada. Hasta hace un par de meses, estábamos sufriendo este síndrome. Las nuevas funcionalidades iban pasando sin ton ni son al ambiente de producción, pero no teníamos coherencia en cómo se generaban. Ni tampoco teníamos la sensación de Urgencia.
El primer cambio importante que aplicamos es definir exactamente las versiones, con su alcance mínimo y con fecha definida. La fecha se mantenía fija ("tallada en piedra") y se tiene flexibilidad con las funcionalidades que se deben incluir en la versión. Adicionalmente se implementó Maven (con el repositorio de Nexus) para ayudarnos a mantener claramente definidas las versiones con su numeración específica.
Asumimos la convención de que cada release se maneja después del primer punto y cualquier corrección que se haga sobre una versión específica en producción se le agrega otro punto. Entonces la primera versión que trabajamos con este esquema es la 4.1, y si hubiera algún Patch o corrección sobre esta versión sería la versión 4.1.1.
Este sencillo cambio creo que ha sido de gran importancia. El primer objetivo que se logra es que todos nos enfocamos en cerrar. Como la fecha está definida todo el mundo tiene la presión para cerrar su funcionalidad antes de ese período de tiempo.
Otro objetivo que se logra, es que realmente separamos lo "deseado" de lo "importante". Nos obliga a escoger entre constantemente entre distintas opciones. Y a pensar por qué vale la pena hacer esto o posponer aquello. No ponerles fechas fijas genera la falsa sensación que siempre se puede incluir de todo y nos obliga a enfocarnos. Cuándo tienes la fecha fija dejas de pensar con Gula y te concentras en lo realmente alimenticio.
En el próximo post, comentaré sobre como mantener una sola tarea asignada a la vez.
El objetivo fundamental de estos cambios es lograr cerrar la mayor cantidad de funcionalidades, y que éstas lleguen rápidamente a los clientes.
En la forma en que estábamos trabajando se venía presentando una situación dónde no teníamos el foco en hacer llegar las nuevas funcionalidades. El foco se trasladó al proceso del "cierre" de la funcionalidad pero esta funcionalidad no tenía que llegar al cliente para ser aprobada. Entonces se presentaban una situación dónde se podían cumplir las metas pero el cliente no veía ninguna mejora.
Versiones con Fecha Fija
El concepto de los User Stories en XP permite separar claramente cada nueva funcionalidad y manejarla como una unidad independiente. El riesgo que presenta este enfoque es que terminemos con una seria de funcionalidades inconexas que se van entregando al usuario en forma desordenada. Hasta hace un par de meses, estábamos sufriendo este síndrome. Las nuevas funcionalidades iban pasando sin ton ni son al ambiente de producción, pero no teníamos coherencia en cómo se generaban. Ni tampoco teníamos la sensación de Urgencia.
El primer cambio importante que aplicamos es definir exactamente las versiones, con su alcance mínimo y con fecha definida. La fecha se mantenía fija ("tallada en piedra") y se tiene flexibilidad con las funcionalidades que se deben incluir en la versión. Adicionalmente se implementó Maven (con el repositorio de Nexus) para ayudarnos a mantener claramente definidas las versiones con su numeración específica.
Asumimos la convención de que cada release se maneja después del primer punto y cualquier corrección que se haga sobre una versión específica en producción se le agrega otro punto. Entonces la primera versión que trabajamos con este esquema es la 4.1, y si hubiera algún Patch o corrección sobre esta versión sería la versión 4.1.1.
Este sencillo cambio creo que ha sido de gran importancia. El primer objetivo que se logra es que todos nos enfocamos en cerrar. Como la fecha está definida todo el mundo tiene la presión para cerrar su funcionalidad antes de ese período de tiempo.
Otro objetivo que se logra, es que realmente separamos lo "deseado" de lo "importante". Nos obliga a escoger entre constantemente entre distintas opciones. Y a pensar por qué vale la pena hacer esto o posponer aquello. No ponerles fechas fijas genera la falsa sensación que siempre se puede incluir de todo y nos obliga a enfocarnos. Cuándo tienes la fecha fija dejas de pensar con Gula y te concentras en lo realmente alimenticio.
En el próximo post, comentaré sobre como mantener una sola tarea asignada a la vez.
martes, 5 de octubre de 2010
Los fracasos enseñan más
Recientemente me topé con este artículo de Marc Hedlund que me pareció full interesante. Marc ha tenido una carrera muy variada, pero el tema del que se trata su artículo es sobre la empresa Wesabe y la empresa Mint.
Un poco de historia...
El primero de diciembre del 2005 se fundó la empresa Wesabe, cuyo objetivo principal era ayudar a las personas a administrar y mejorar sus finanzas personales.
En la primera ronda de financiamiento Wesabe consiguió 750mil U$D, y en una segunda ronda levantó 4Millones de los verdes.
El primero de Noviembre del 2006 (11 meses despues de Wesabe) se fundó la empresa Mint, cuyo objetivo era ayudar a las personas a administrar y mejorar sus finanzas personales.
En una primera ronda Mint consiguió 325mil U$D y posteriormente en dos rondas consiguieron 5.4Millones verdecitos.
Ambas empresas arrancaron en tiempos similares, contaron con similar financiamiento y se dedicaban al mismo objetivo. Pero hasta aquí llegan las similitudes.
En septiembre del 2009, Mint fué comprada por Intuit (el competidor más importante del sector de la "vieja escuela") por 170Millones U$D. En Junio del 2010 Wesabe cerró formalmente sus operaciones.
Tener dos empresas con condiciones similares y resultados tan dispares en un corto período de tiempo, permite hacer análisis sobre los factores de éxito en ambos casos.
Marc Hedlund fue el fundador de Wesabe, y en el artículo expone sus conclusiones sobre las razones que llevaron a tan dispares fin. Vale la pena leerlo.
Aunque estas empresas difieren de Imolko en su objeto de negocio, me parece que podemos extraer dos aprendizajes que se relacionan mucho con nuestra empresa.
Integra cuándo puedas
El primer de ellos es que Wesabe no utilizó los servicios de Yodlee que le hubieran permitido obtener información de muchos bancos. Prefirieron desarrollar una aplicación similar que les hizo invertir 6 meses de trabajo. Mint utilizó los servicios de Yodlee, y pudo enfocar sus energías en otras cosas y evitarse 6 meses de "desenfocamiento".
Este síndrome de querer hacerlo todo en casa puede afectar nuestra velocidad y no nos permite apalancarnos del trabajo que están haciendo otras empresas. Creo que, aunque algunas veces nos pega en el ego, debemos tener la disciplina de preguntarnos siempre si lo que estamos creando es vital para nuestro negocio y si no hay otro que ya lo tenga resuelto.
Experiencia sobre Funcionalidad
Mint desarrolló una mejor experiencia de uso, aunque no ofrecía mayores funcionalidades. Cosas como que te sugería valores para los campos de información, aúnque esa información no fuera muy útil o totalmente correcta, le hacían la vida más fácil al usuario y permitían que más usuarios se integrarán. Aunque Wesabe tuviera más funcionalidades (y de acuerdo a su creador, mejores ideas para ayudar a los usuarios) sólo se podrían mostrar a los valientes que eran capaces de hurgar aunque tuvieran una experiencia menos satisfactoria. Es decir, al no tomar en cuenta la experiencia de usuario se convierte en producto de nicho; sólo disponible para los usuarios más "duros" desde el punto de vista tecnológico.
Como buenos "Techies" muchas veces les damos más importancia a las funcionalidades y descuidamos la experiencia del usuario. Cosas como "se puede hacer, pero debes tomar este largo camino" para responder inquietudes de usuarios son indicios de sistemas con muchas funcionalidades que terminan siendo utilizado sólo por expertos.
Y el problema es que los expertos tienen muchas más opciones o peticiones mucho más específicas. Entonces al final terminas con muy poquitos usuarios que atentan contra la viabilidad de la empresa. Por el contrario, centrándonos en la experiencia del usuario podemos ir agregando funcionalidades y éstas van a salir fruto de la interacción directa con los usuarios. Creando un círculo virtuoso que permite el crecimiento orgánico de la empresa.
martes, 28 de septiembre de 2010
Contra los errores tome Bromine
Desde hace un tiempo estamos trabajando intensivamente con Bromine y Selenium para automatizar las pruebas en nuestras aplicaciones Web. La idea es contar con tests que se ejecuten periódicamente y que simulen lo que haría un usuario directamente en su Browser.
Al principio es un poco complicado, por que se deben ajustar ciertas cosas que no vienen en la instalación regular. Pero después de unas cuántas horas el sistema funciona bastante bien. Una vez que lo tienes instalado utilizas un plugin para Firefox llamado Selenium-IDE que te ayuda a hacer los tests.
Teóricamente, sólo reproduces los pasos que haces normalmente y luego le das play una y otra vez. De esta manera garantizas que todo lo que está funcionando, no deje de funcionar por cambios en el programa. Puedes chekar una introducción aqui.
En la práctica, toma un tiempo aprender los trucos para "grabar" bien los tests y reproducirlos posteriormente. Después que le agarras el truco, es bastante sencillo. Para que tengas una idea, grabar un test de algo que toma 10 minutos en hacer manualmente, puede llevarte una hora. Pero después que lo tienes grabado, la reproducción se hace totalmente automática y no necesitas invertir tiempo de gente haciendo las pruebas. Al final es divertido ver como una especie de robot repite los pasos que le indicas, y el explorador comienza a hacer clicks y tipear cosas por si sólo.
Hasta el momento llevamos unos 60 tests automatizados, y creo que todavía nos pueden faltar unos 10 casos más por automatizar. Estos tests se van a ejecutar todos los días en nuestro servidor de alfa (última versión en desarrollo) a la media noche. De esta manera garantizamos que si hay cualquier error podamos detectarlo al día siguiente que se generó.
Cuándo se desarrollen nuevas funcionalidades se le generaran los tests una vez que el desarrollo esté listo y antes de publicarlo para que lo vean los clientes. Estos tests son generados por el área de Gestión Comercial. Adicionalmente el área de Operaciones tambien genera los tests que considere necesarios para aprobar el pase a producción de una versión nueva.
Esto es parte importante de nuestra metodología XP (Extreme Programming) y probar constantemente todo lo que se desarrolla. Estoy convencido que esto nos va a ayudar disminuir los errores que llegan a producción (ambiente utilizado por los clientes) y de esta manera poder mejorar nuestro servicio.
lunes, 19 de julio de 2010
Convocatoria para 2do Taller Extreme Programming
Ya comenzó la convocatoria al segundo Taller de Extreme Programming dictado por Imolko, y organizado en conjunto entre el Sena, Intersoftware y Tecnoparque Medellín.
Este taller forma desarrolladores en la metodología ágil Xtreme Programming. Es parte del programa "Empresarios del software formando los nuevos empresarios" del Tecnoparque cuyo objetivo es el cerrar las diferencias entre los estudiantes universitarios y lo que requerimos las empresas de software.
Nuestra participación en estos talleres busca dos objetivos fundamentales:
1) Retribuir a la comunidad en general y a los estudiantes en específico, los conocimientos que hemos adquirido desde Internet. Como parte de nuestro programa de responsabilidad social creemos que el conocimiento se multiplica y agrega valor cuánta más gente lo tenga.
2) Crear una cantera de desarrolladores que nos enriquezcan como empresa innovadora. Los desarrolladores que estén interesados podrán formar de nuestra empresa y crecer profesionalmente.
Creo que esta iniciativa nos permite mantenernos alineados con nuestro valor de innovación, garantizando que todo el tiempo tengamos nuevas ideas y gente para implementarlas. Esto mantiene fresca a la empresa y nos ayuda a todos a estar en contacto con nuevas formas de ver la tecnología. La idea es que todos los años estemos dictando estos talleres, formando y buscando el mejor talento para nuestra empresa.
El primer taller lo dictamos entre Marzo y Junio con la participación de 25 personas. El espacio físico dónde se dictan las clases es muy grato e invita a la innovación. En este primer taller trabajamos desde requerimientos como "Construir casa de los tres cochinitos" hasta los tests necesarios para el requerimiento de "Como Milla quiero matar Zombies". Realmente fue muy divertido y enriquecedor esta primera experiencia.
Para esta segunda versión, hemos aprendido un montón de cosas y viene totalmente reloaded.
El taller es dictado en modalidad presencial y virtual (b-learning), utilizando la plataforma Moodle como sistema para las evaluaciones, materiales e interacciones. La parte presencial se dicta en el Edificio del Tecnoparque en Medellín y la parte virtual nos apoyamos con Skype y Webex.
El contenido lo desarrollamos en conjunto entre Imolko y Masaya, quién nos apoyó en la estructuración pedagógica.
Si estás interesado puedes echarle un ojo al programa y las condiciones para participar. El exámen de ingreso se realiza el 2 de agosto y el curso comienza el 16 de Agosto.
Este taller forma desarrolladores en la metodología ágil Xtreme Programming. Es parte del programa "Empresarios del software formando los nuevos empresarios" del Tecnoparque cuyo objetivo es el cerrar las diferencias entre los estudiantes universitarios y lo que requerimos las empresas de software.
Nuestra participación en estos talleres busca dos objetivos fundamentales:
1) Retribuir a la comunidad en general y a los estudiantes en específico, los conocimientos que hemos adquirido desde Internet. Como parte de nuestro programa de responsabilidad social creemos que el conocimiento se multiplica y agrega valor cuánta más gente lo tenga.
2) Crear una cantera de desarrolladores que nos enriquezcan como empresa innovadora. Los desarrolladores que estén interesados podrán formar de nuestra empresa y crecer profesionalmente.
Creo que esta iniciativa nos permite mantenernos alineados con nuestro valor de innovación, garantizando que todo el tiempo tengamos nuevas ideas y gente para implementarlas. Esto mantiene fresca a la empresa y nos ayuda a todos a estar en contacto con nuevas formas de ver la tecnología. La idea es que todos los años estemos dictando estos talleres, formando y buscando el mejor talento para nuestra empresa.
El primer taller lo dictamos entre Marzo y Junio con la participación de 25 personas. El espacio físico dónde se dictan las clases es muy grato e invita a la innovación. En este primer taller trabajamos desde requerimientos como "Construir casa de los tres cochinitos" hasta los tests necesarios para el requerimiento de "Como Milla quiero matar Zombies". Realmente fue muy divertido y enriquecedor esta primera experiencia.
Para esta segunda versión, hemos aprendido un montón de cosas y viene totalmente reloaded.
El taller es dictado en modalidad presencial y virtual (b-learning), utilizando la plataforma Moodle como sistema para las evaluaciones, materiales e interacciones. La parte presencial se dicta en el Edificio del Tecnoparque en Medellín y la parte virtual nos apoyamos con Skype y Webex.
El contenido lo desarrollamos en conjunto entre Imolko y Masaya, quién nos apoyó en la estructuración pedagógica.
Si estás interesado puedes echarle un ojo al programa y las condiciones para participar. El exámen de ingreso se realiza el 2 de agosto y el curso comienza el 16 de Agosto.
miércoles, 14 de julio de 2010
Foro "Del Emprendimiento Local al Emprendimiento Global"
Como gerente de Imolko, me invitaron a participar de ponente en un evento sobre Emprendimiento en Medellín. El evento fue organizado por la Cámara de Comercio de Aburrá Sur, Crece, la Gobernación de Antioquia y Creame.
El objetivo del evento es compartir con nuevos empresarios las experiencias de compañías que han salido de sus países para convertirse en empresas globales. Personalmente me sentí muy orgulloso que me invitaran y disfruté mucho participar.
Aburrá Sur es un conjunto de Municipios en el departamento de Antioquia; cuándo llegamos quedé gratamente sorprendido por el tamaño de la sede:
Al principio había unas palabras de los organizadores, y luego comenzamos con presentaciones de emprendedores. En el público había unas 350 personas que se mantuvieron muy atentos todo el tiempo.
Yo era el primer expositor, y esta fue la presentación que utilicé:
Fue como echarle el cuento a un amigo que va a montar una empresa fuera de su país sobre lo que hemos pasado en estos 4 años de internacionalización. Estuvo divertido poder compartir esas experiencias y sentir que pueden ayudar a otras empresas.
[Parte 2] [Parte 3]
Acompañándome como ponentes había casos full interesantes. La verdad me tripeé mucho oír las diversas experiencias y sentirme identificado con algunas de las vivencias, y sentir mucha envidia por otras :-)
Después de las presentaciones tuvimos un panel de preguntas y respuestas. A pesar del hambre que hacía por la hora (1pm pasadas), el auditorio continuaba lleno:
Después nos fuimos a almorzar y la pasamos muy bien profundizando más sobre las experiencias y conociendo más en detalle sobre algunos negocios. Despues del almuerzo ya conocía bastante más sobre mapas y GPS, cultivo de Palma Real y su aceite, y para completar: chalecos anti balas.
Aunque no estaban en el evento, también comentamos ampliamente sobre el Arequipe de Papas; había opiniones encontradas, algunos pensaban que el problema estaba en el producto y otros creíamos que estaba en el nombre. En todo caso, es interesante ver como la creatividad no conoce barreras :-)
Agradezco profundamente a los organizadores que me invitaron; la pasé muy bien y me encantó haber participado. Sentir que uno puede compartir su experiencia con gente de otros países es algo que le sube a uno el autoestima; y conocer experiencias tan diversas como innovadores es un cepillito para el alma emprendedora.
El objetivo del evento es compartir con nuevos empresarios las experiencias de compañías que han salido de sus países para convertirse en empresas globales. Personalmente me sentí muy orgulloso que me invitaran y disfruté mucho participar.
Aburrá Sur es un conjunto de Municipios en el departamento de Antioquia; cuándo llegamos quedé gratamente sorprendido por el tamaño de la sede:
Al principio había unas palabras de los organizadores, y luego comenzamos con presentaciones de emprendedores. En el público había unas 350 personas que se mantuvieron muy atentos todo el tiempo.
Yo era el primer expositor, y esta fue la presentación que utilicé:
Fue como echarle el cuento a un amigo que va a montar una empresa fuera de su país sobre lo que hemos pasado en estos 4 años de internacionalización. Estuvo divertido poder compartir esas experiencias y sentir que pueden ayudar a otras empresas.
[Parte 2] [Parte 3]
Acompañándome como ponentes había casos full interesantes. La verdad me tripeé mucho oír las diversas experiencias y sentirme identificado con algunas de las vivencias, y sentir mucha envidia por otras :-)
Después de las presentaciones tuvimos un panel de preguntas y respuestas. A pesar del hambre que hacía por la hora (1pm pasadas), el auditorio continuaba lleno:
Después nos fuimos a almorzar y la pasamos muy bien profundizando más sobre las experiencias y conociendo más en detalle sobre algunos negocios. Despues del almuerzo ya conocía bastante más sobre mapas y GPS, cultivo de Palma Real y su aceite, y para completar: chalecos anti balas.
Aunque no estaban en el evento, también comentamos ampliamente sobre el Arequipe de Papas; había opiniones encontradas, algunos pensaban que el problema estaba en el producto y otros creíamos que estaba en el nombre. En todo caso, es interesante ver como la creatividad no conoce barreras :-)
Agradezco profundamente a los organizadores que me invitaron; la pasé muy bien y me encantó haber participado. Sentir que uno puede compartir su experiencia con gente de otros países es algo que le sube a uno el autoestima; y conocer experiencias tan diversas como innovadores es un cepillito para el alma emprendedora.
martes, 29 de junio de 2010
Ayuda al planeta, no vayas a tu oficina hoy
Trabaja desde tu casa :-)
Según un montón de estudios, uno de las actividades con mayores emisiones de CO2 es el transporte terrestre propulsado por gasolina (carros, autobuses, etc). Las emisiones de CO2 contribuyen full al calentamiento global y a todas las pesadillas que eso conlleva.
Desde hace tres años comenzamos en Imolko a cambiar desde una empresa centrada en una oficina a una empresa centrada en Internet, dónde el sitio de trabajo pudiera ser escogido por cada uno de nosotros.
Hemos avanzado bastante en este sentido y actualmente casi todas las áreas pueden trabajar desde cualquier sitio. Tenemos todavía algunas áreas que requieren presencia física (sobre todo en el área de administración) pero en el resto de las áreas la presencia es opcional.
Al comienzo todos teníamos que ir a trabajar y vivir en la misma ciudad. El 100% de nuestros empleados trabajaban y vivían en Caracas.
Hoy en día trabajamos desde 8 ciudades distintas; varios de nosotros trabajamos desde la casa (total o parcialmente) y hemos logrado disminuir los viajes diarios a una oficina en un 70%.
De acuerdo un estudio publicado por la Consumer Electronic Association por cada día que se deja de ir a trabajar a la oficina y se trabaja desde la casa se ahorran entre 17 y 23 kilos de CO2.
Según estos números, con el trabajo remoto estamos ahorrando 3.6 toneladas de CO2 x mes, o 43.2 toneladas de CO2 anuales. Para tener una idea visual sobre este ahorro, esto es lo que significa una sola tonelada:
Con nuestra iniciativa de trabajo remoto, estamos dejando de generar 43 cajitas de estas de CO2. O puesto de otra manera, estamos ahorrando el consumo de 8 casas completas en un año (incluyendo aire acondicionado, televisión, computadoras, etc).
Alegra saber que con el aporte de cada uno efectivamente podemos hacer una diferencia. Personalmente estoy orgulloso de poder contribuir con el planeta y de paso, ser más felices y productivos.
Según un montón de estudios, uno de las actividades con mayores emisiones de CO2 es el transporte terrestre propulsado por gasolina (carros, autobuses, etc). Las emisiones de CO2 contribuyen full al calentamiento global y a todas las pesadillas que eso conlleva.
Desde hace tres años comenzamos en Imolko a cambiar desde una empresa centrada en una oficina a una empresa centrada en Internet, dónde el sitio de trabajo pudiera ser escogido por cada uno de nosotros.
Hemos avanzado bastante en este sentido y actualmente casi todas las áreas pueden trabajar desde cualquier sitio. Tenemos todavía algunas áreas que requieren presencia física (sobre todo en el área de administración) pero en el resto de las áreas la presencia es opcional.
Al comienzo todos teníamos que ir a trabajar y vivir en la misma ciudad. El 100% de nuestros empleados trabajaban y vivían en Caracas.
Hoy en día trabajamos desde 8 ciudades distintas; varios de nosotros trabajamos desde la casa (total o parcialmente) y hemos logrado disminuir los viajes diarios a una oficina en un 70%.
De acuerdo un estudio publicado por la Consumer Electronic Association por cada día que se deja de ir a trabajar a la oficina y se trabaja desde la casa se ahorran entre 17 y 23 kilos de CO2.
Según estos números, con el trabajo remoto estamos ahorrando 3.6 toneladas de CO2 x mes, o 43.2 toneladas de CO2 anuales. Para tener una idea visual sobre este ahorro, esto es lo que significa una sola tonelada:
Con nuestra iniciativa de trabajo remoto, estamos dejando de generar 43 cajitas de estas de CO2. O puesto de otra manera, estamos ahorrando el consumo de 8 casas completas en un año (incluyendo aire acondicionado, televisión, computadoras, etc).
Alegra saber que con el aporte de cada uno efectivamente podemos hacer una diferencia. Personalmente estoy orgulloso de poder contribuir con el planeta y de paso, ser más felices y productivos.
jueves, 20 de mayo de 2010
Productividad y Progreso
Durante mucho tiempo hemos vivido con la idea que en Latinoamérica los problemas más importantes son la extracción de recursos y la falta de inversión. El razonamiento más extendido es que nuestros recursos naturales han sido tomados por entes extranjeros que nos han dejado sin recursos y que luego estos recursos no son invertidos en la región. Este razonamiento tiene su máximo exponente en el libro "Las ventas abiertas de América Latina" escrito por los lejanos años de 1971.
Este razonamiento ha marcado profundamente nuestra forma de hacer políticas públicas pero también de actuar a nivel personal. Independientemente de lo veraz de este razonamiento, el problema es que deja el resultado de nuestra situación a factores externos (los que se llevan la riqueza, y los que no la invierten nuevamente), dificultando que podamos acciones para mejorarla.
Personalmente creo que uno de los mayores problemas que enfrentamos en latinoamérica es la falta de productividad que tenemos en líneas generales. Todos mis amigos europeos y norteamericanos trabajan menos tiempo que mis amigos latinoamericanos; y todos viven mejor. Trabajando menos logran obtener mejores ingresos y mejor calidad de vida. Y esto a mi me suena que tiene que ver con cuánto producen por cada hora trabajada.
Un reciente estudio publicado por el BID arroja como resultado que el principal problema de la región es la falta de productividad. Según la autora del informe Carmen Pagés:
Resulta que desde 1990 los países desarrollados han mejorado un 1.4% su productividad mientras que en latinoamérica sólo hemos mejorado un 0.1% (Estos son los números del sector servicios que ocupa un 70% de la fuerza laboral de la región).
Cualquier país que hubiera aumentado la productividad en el sector servicios a la misma velocidad que la región asiática hubiera duplicado su economía. O sea que si obtuviéramos más dinero por cada hora invertida, estaríamos contribuyendo enormemente al crecimiento de la región.
En Imolko estamos haciendo un esfuerzo por medir nuestra productividad para determinar que tan cerca estamos lograr de convertirnos en una empresa de clase mundial. Lo que queremos es ser una empresa latinoamericana con productividad de primer mundo. La forma en que lo estamos midiendo es dividir las ventas que tenemos entre la cantidad de horas que trabajamos, y eso nos da el indicador de Ventas por Hora Trabajada.
Para mejorar esta productividad invertimos en innovación tanto en nuestros productos como en nuestros procesos internos. La idea general es que si un proceso es repetitivo y no agrega valor debe ser automatizado; con este sencillo concepto hemos eliminado más de 25 procesos manuales que son sustituidos por mejores procesos o por procesos automáticos. De esta manera nuestra gente se puede concentrar en actividades enriquecedores y no repetitivas que agregan valor y nos hacen más productivos.
Creo que también podemos contribuir haciendo más eficientes las pequeñas y medianas empresas que son una gran parte del sector productivo en la región. Con herramientas innovadoras de mercadeo que ayudan a mejorar las ventas estamos contribuyendo a aumentar la productividad de nuestros clientes.
Aunque es cierto que hacen falta políticas gubernamentales que incentiven la productividad, también es cierto que es posible mejorar con el aporte de empresas e individuos que estén dispuestos a innovar para aumentar su aporte a la sociedad.
Este razonamiento ha marcado profundamente nuestra forma de hacer políticas públicas pero también de actuar a nivel personal. Independientemente de lo veraz de este razonamiento, el problema es que deja el resultado de nuestra situación a factores externos (los que se llevan la riqueza, y los que no la invierten nuevamente), dificultando que podamos acciones para mejorarla.
Personalmente creo que uno de los mayores problemas que enfrentamos en latinoamérica es la falta de productividad que tenemos en líneas generales. Todos mis amigos europeos y norteamericanos trabajan menos tiempo que mis amigos latinoamericanos; y todos viven mejor. Trabajando menos logran obtener mejores ingresos y mejor calidad de vida. Y esto a mi me suena que tiene que ver con cuánto producen por cada hora trabajada.
Un reciente estudio publicado por el BID arroja como resultado que el principal problema de la región es la falta de productividad. Según la autora del informe Carmen Pagés:
"Más que inversiones adicionales, los países de la región deben hacer un mejor uso del capital físico y humano existente"
Resulta que desde 1990 los países desarrollados han mejorado un 1.4% su productividad mientras que en latinoamérica sólo hemos mejorado un 0.1% (Estos son los números del sector servicios que ocupa un 70% de la fuerza laboral de la región).
Cualquier país que hubiera aumentado la productividad en el sector servicios a la misma velocidad que la región asiática hubiera duplicado su economía. O sea que si obtuviéramos más dinero por cada hora invertida, estaríamos contribuyendo enormemente al crecimiento de la región.
En Imolko estamos haciendo un esfuerzo por medir nuestra productividad para determinar que tan cerca estamos lograr de convertirnos en una empresa de clase mundial. Lo que queremos es ser una empresa latinoamericana con productividad de primer mundo. La forma en que lo estamos midiendo es dividir las ventas que tenemos entre la cantidad de horas que trabajamos, y eso nos da el indicador de Ventas por Hora Trabajada.
Para mejorar esta productividad invertimos en innovación tanto en nuestros productos como en nuestros procesos internos. La idea general es que si un proceso es repetitivo y no agrega valor debe ser automatizado; con este sencillo concepto hemos eliminado más de 25 procesos manuales que son sustituidos por mejores procesos o por procesos automáticos. De esta manera nuestra gente se puede concentrar en actividades enriquecedores y no repetitivas que agregan valor y nos hacen más productivos.
Creo que también podemos contribuir haciendo más eficientes las pequeñas y medianas empresas que son una gran parte del sector productivo en la región. Con herramientas innovadoras de mercadeo que ayudan a mejorar las ventas estamos contribuyendo a aumentar la productividad de nuestros clientes.
Aunque es cierto que hacen falta políticas gubernamentales que incentiven la productividad, también es cierto que es posible mejorar con el aporte de empresas e individuos que estén dispuestos a innovar para aumentar su aporte a la sociedad.
viernes, 5 de febrero de 2010
Enfrentando la Mediocridad
Esta es una presentación que hice para la reunión Mensual de Evaluación del mes de Enero.
El objetivo de la presentación es reflexionar sobre las conductas que atentan contra el trabajo en equipo. En nuestra cultura tenemos propensión a confundir la amistad con el profesionalismo; "cómo vas a decir que no soy bueno trabajando si somos amigos" son frases que en algún momento u otro repetimos o pensamos y que atentan contra nuestro crecimiento profesional.
Para convertirnos en un equipo de alta competencia, como queremos ser, debemos identificar estas conductas y reflexionar sobre como podemos cambiarla.
Cuándo el que las dice soy yo, pensar en mis expectativas hacia el futuro y cómo las voy a alcanzar. Pensar si estoy a gusto con mi trabajo y lo disfruto a plenitud. Si mi lugar para crecer es Imolko entonces debo cambiar esas conductas y prepararme para explotar al máximo mi potencial creativo.
Cuándo la dicen otras personas, debo tener el coraje para poder darles un feedback claro y permitirlas a esas personas que se den cuenta y cambien. Si no quieren cambiar, entonces ser lo suficientemente claro para que la organización se dé cuenta que esa persona no está aportando y está atentando contra el esfuerzo de todos.
En Imolko, ya hemos avanzado de una manera importante en convertirnos en un equipo de alta competencia, pero debemos mantener el esfuerzo y la disciplina para que nuestro sitio de trabajo nos permita crecer:
Lo importante es que todos mantengamos el esfuerzo para conseguir nuestras metas.
El objetivo de la presentación es reflexionar sobre las conductas que atentan contra el trabajo en equipo. En nuestra cultura tenemos propensión a confundir la amistad con el profesionalismo; "cómo vas a decir que no soy bueno trabajando si somos amigos" son frases que en algún momento u otro repetimos o pensamos y que atentan contra nuestro crecimiento profesional.
Para convertirnos en un equipo de alta competencia, como queremos ser, debemos identificar estas conductas y reflexionar sobre como podemos cambiarla.
Cuándo el que las dice soy yo, pensar en mis expectativas hacia el futuro y cómo las voy a alcanzar. Pensar si estoy a gusto con mi trabajo y lo disfruto a plenitud. Si mi lugar para crecer es Imolko entonces debo cambiar esas conductas y prepararme para explotar al máximo mi potencial creativo.
Cuándo la dicen otras personas, debo tener el coraje para poder darles un feedback claro y permitirlas a esas personas que se den cuenta y cambien. Si no quieren cambiar, entonces ser lo suficientemente claro para que la organización se dé cuenta que esa persona no está aportando y está atentando contra el esfuerzo de todos.
En Imolko, ya hemos avanzado de una manera importante en convertirnos en un equipo de alta competencia, pero debemos mantener el esfuerzo y la disciplina para que nuestro sitio de trabajo nos permita crecer:
- Profesionalmente: con un ambiente creativo y retador que me motive a desarrollar todo mi potencial
- Personalmente: con un trabajo que no me quite todo el tiempo, y contribuya a mi bienestar emocional, familiar y personal
- Materialmente: con una retribución económica que me permita desarrollar mis sueños
Lo importante es que todos mantengamos el esfuerzo para conseguir nuestras metas.
miércoles, 27 de enero de 2010
Fotos Taller Sobre Creatividad
Aqui están algunas fotos del Evento sobre Creatividad que hicimos en Galipán.
El equipo Ganador del Torneo, Felicitaciones!
El equipo Ganador del Torneo, Felicitaciones!
domingo, 17 de enero de 2010
Refactoring Week - Cierre
Terminó la semana del evento y estoy muy satisfecho de lo que logramos.
Hicimos algunos cambios en la agenda: se eliminó el track de planificación del 2010 y se acortó el torneo de programación eliminando el último evento. Como aprendizaje para el próximo evento hay que ser menos ambicioso en la agenda, tomando en cuenta los tiempos que se consumen en descanso, traslados, etc. Pero tambien creo que para los pŕoximos hay que ser más esctricto en el manejo del tiempo y tener más "amarrados" los aspectos de logística.
El espacio físico acondicionado antes del evento es clave para optimizar el uso del tiempo, asi como los temas de comida y traslado.
El torneo de programación se definió en la noche del viernes, despues de unas intensas discusiones del jurado. Se tomaron más de una hora para decidir quién sería el ganador; pero definitivamente los equipos no se la pusieron fácil.
Los tres equipos le pusieron mucho corazón y todos pudieron llegar a la meta en cada uno de los eventos. Trabajando enfocadamente pudieron resolver los problemas técnicos asociados y aportar ideas innovadoras. Creo que todos nos sorprendimos al ver lo que somos capaces de generar en tan poco tiempo cuándo nos enfocamos.
Me siento muy orgulloso de trabajar en una empresa con ese potencial de creación!
El Equipo A se llevó a su casa el premio del torneo; "un flamante Portaretrato Digital Cero Kilómetros" :-).
Los números finales del torneo:
La celebración estuvo a cargo del Sr Smirnoff, y luego algunos continuamos en El León. Creo que había mucho que celebrar; tenemos un equipo con gente de distintos países y que nos tripeamos lo que hacemos en un ambiente creativo.
Personalmente me siento muy contento de todo lo que alcanzamos y siento que los objetivos fueron logrados plenamente.
Hicimos algunos cambios en la agenda: se eliminó el track de planificación del 2010 y se acortó el torneo de programación eliminando el último evento. Como aprendizaje para el próximo evento hay que ser menos ambicioso en la agenda, tomando en cuenta los tiempos que se consumen en descanso, traslados, etc. Pero tambien creo que para los pŕoximos hay que ser más esctricto en el manejo del tiempo y tener más "amarrados" los aspectos de logística.
El espacio físico acondicionado antes del evento es clave para optimizar el uso del tiempo, asi como los temas de comida y traslado.
El torneo de programación se definió en la noche del viernes, despues de unas intensas discusiones del jurado. Se tomaron más de una hora para decidir quién sería el ganador; pero definitivamente los equipos no se la pusieron fácil.
Los tres equipos le pusieron mucho corazón y todos pudieron llegar a la meta en cada uno de los eventos. Trabajando enfocadamente pudieron resolver los problemas técnicos asociados y aportar ideas innovadoras. Creo que todos nos sorprendimos al ver lo que somos capaces de generar en tan poco tiempo cuándo nos enfocamos.
Me siento muy orgulloso de trabajar en una empresa con ese potencial de creación!
El Equipo A se llevó a su casa el premio del torneo; "un flamante Portaretrato Digital Cero Kilómetros" :-).
Los números finales del torneo:
- 800 líneas de código probadas
- 3 proyectos que se ejecutan en Facebook y se conectan con Imolko
- 3 proyectos que se ejecutan desde Z4 y se conectan con Flicr
La celebración estuvo a cargo del Sr Smirnoff, y luego algunos continuamos en El León. Creo que había mucho que celebrar; tenemos un equipo con gente de distintos países y que nos tripeamos lo que hacemos en un ambiente creativo.
Personalmente me siento muy contento de todo lo que alcanzamos y siento que los objetivos fueron logrados plenamente.
viernes, 15 de enero de 2010
Refactoring Week - ¿Como mejoraros nuestra creación de Software?
Como parte de la Refactoring Week desarrollamos una sesión para responder la pregunta ¿Como hacemos más productivo nuestro proceso de desarrollo - XQ ?
En esta sesión trabajaron las áreas de Desarrollo y de Gestión Comercial. La divimos en tres sesiones, en la primera hicimos dos grupos de trabajo mixtos (con personas de ambas areas) e hicimos una lluvia de ideas (estrenando herramientas aprendidas en el taller de creatividad :-) ).
En la segunda parte hicimos una revisión de la teoría básica de XP, para re-leer los conceptos y verlos a la luz de nuestra práctica cotidiana. Aqui se nos acabó la mañana y nos fuimos a almorzar.
En la tercera parte unificamos las ideas y las depuramos para convertirlas en tareas concretas.
Nuestro proceso de creación de software (Xtreme Quality) es un proceso central para nuestra estrategia. Para una empresa basada en la innovación, contar con un proceso de desarrollo excelente es básico para lograr nuestras metas. Nuestra cadena de valor se inicia creando innovaciones. Por eso creo que cualquier inversión que hagamos en nuestros procesos vale la pena.
Esta sesión que debía durar dos horas según la agenda, se extendió por todo el día. Todos estuvimos de acuerdo en que era muy importante seguir trabajando hasta llegar a las conclusiones finales.
Despues de todo un día de trabajo, generamos más de 40 tareas que corresponden a 12 objetivos puntuales.
Los objetivos a trabajar son:
(Se decidió hacer unos cambios en la agenda inicial del evento y dejamos por fuera lo relacionado a la planificación del 2010. Esto se trabajará remotamente en la semana siguiente)
En esta sesión trabajaron las áreas de Desarrollo y de Gestión Comercial. La divimos en tres sesiones, en la primera hicimos dos grupos de trabajo mixtos (con personas de ambas areas) e hicimos una lluvia de ideas (estrenando herramientas aprendidas en el taller de creatividad :-) ).
En la segunda parte hicimos una revisión de la teoría básica de XP, para re-leer los conceptos y verlos a la luz de nuestra práctica cotidiana. Aqui se nos acabó la mañana y nos fuimos a almorzar.
En la tercera parte unificamos las ideas y las depuramos para convertirlas en tareas concretas.
Nuestro proceso de creación de software (Xtreme Quality) es un proceso central para nuestra estrategia. Para una empresa basada en la innovación, contar con un proceso de desarrollo excelente es básico para lograr nuestras metas. Nuestra cadena de valor se inicia creando innovaciones. Por eso creo que cualquier inversión que hagamos en nuestros procesos vale la pena.
Esta sesión que debía durar dos horas según la agenda, se extendió por todo el día. Todos estuvimos de acuerdo en que era muy importante seguir trabajando hasta llegar a las conclusiones finales.
Despues de todo un día de trabajo, generamos más de 40 tareas que corresponden a 12 objetivos puntuales.
Los objetivos a trabajar son:
- Mejorar Plataforma Interna de desarrollo (ambiente Alfa)
- Aumentar la Programación en Parejas
- Refactoring Continuo
- Mejorar la definicón de los User Stories
- Cumplimiento de los formatos de las reuniones (diaria e interacciones)
- Mejorar las estimaciones
- Aumentar la Cobertura
- Evitar conductas que tienden a la propiedad individual del código
- Compartir la documentación de las investigaciones
- Eliminar la Resistencia al Cambio
- Facilitar el Feedback de los usuarios finales
- Aumentar el uso de Metáforas y Visión Global
(Se decidió hacer unos cambios en la agenda inicial del evento y dejamos por fuera lo relacionado a la planificación del 2010. Esto se trabajará remotamente en la semana siguiente)
jueves, 14 de enero de 2010
Refactoring Week - Taller sobre Creatividad
Para este taller nos desplazamos a Espacio Galipán, que queda cerca del pueblo Galipán en el cerro El Avila. El trayecto toma como 30 minutos desde Caracas, y vale la pena, por que al llegar te sientes en otro mundo.
Llegamos como a las 9 y nos fuimos a desayunar. Despues de la comida, arrancamos con las sesiones programadas por Patxi (Francisco Andrés) nuestro facilitador. El objetivo del taller era conversar sobre la creatividad y aprender a trabajar con las lluvias de ideas (brain storming).
Comenzamos con unos ejercicios físicos muy divertidos que nos ayudaron a calentar el espíritu y de paso, nos mostraron como las ideas preconcebidas o prejuicios nos impiden desarrollar soluciones a problemas cotidianos. Otra cosa importante, específicamente para mí, fue darme cuenta que la necesidad de controlar impide dejar a otros tomar iniciativas y resolver situaciones complejas; en el primer ejercicio, me la pasé todo el tiempo haciendo "shsssss" cuándo lo que se requería era que todos dijeran sus ideas. En algunas ocaciones lo mejor que se puede hacer es "Let it be"... como decía aquel Beatle.
Luego hicimos la primera lluvia de ideas para generar un Banco de Pet Projects. Hicimos una primera parte en parejas; en estas sesiones lo más importante es no limitar o juzgar ninguna idea y dejar que la creatividad fluya. En esta fase (media hora) generamos más de 70 ideas sobre posibles pet projects. Luego cada pareja, escogió las mejores 7 ideas y las publicamos en una pizarra. Despues de eso, cambiamos de pareja y cada nueva pareja escogió, de mutuo acuerdo, tres ideas para desarrollar más en profundidad.
Como parte final del ejercicio, cada equipo le colocó unas condiciones que debería cumplir cada idea para ser exitosa. Y le colocamos un puntaje a cada idea desarrollada en función a esos criterios. De acuerdo a ese puntaje escogimos las mejores ideas de cada equipo y se comentaron en conjunto. En menos de dos horas generamos 70 ideas a vuelo de pájaro, 27 ideas desarrolladas medianamente y 9 desarrolladas totalmente. Nada mal para un primer ejercicio :-)
Despues del almuerzo, hicimos un paréntesis para la presentación de los proyectos del torneo, y posteriormente continuamos con una sesión sobre el humor. El humor está relacionado con ver las cosas de una forma fuera de lo común. Lo peor que puede pasar con un chiste es que sea predecible. El humor tiene que ver con pensamiento "out of the box".
Para vivir en carne propia la relación entre las dos cosas, hicimos dos ejercicios donde cada uno (en equipo) debía crear una situación divertida. No es una tarea sencilla, pero lo más importante es que todos nos lanzamos y lo hicimos de la mejor manera. Fue realmente muy divertido ver lo que nos ocurrió a cada equipo. Hicimos dos ejercicios; uno en pareja y otro en grupos de 9 nueve personas. Interesantes lecciones sobre la creatividad y los ambientes que debemos crear para permitirnos explorar esa creatividad en cada uno.
Finalmente hicimos un segundo ejercicio de lluvia de ideas, pero esta vez orientado a encontrar un mensaje (podía ser un comercial, un informercial, una presentación en power point, etc) sobre como vender Zenkiu 4 en una convención de Turismo. Generamos un montón de ideas que podrían ser un comercial muy exitoso. Me gustó ver como todos hemos madurado los conocimientos sobre nuestro negocio y como podemos comunicarlo.
En Imolko hasta ahora no habíamos utilizado la herramienta de lluvia de ideas como una forma de resolver problemas. Definitivamente despues de este día, vamos a comenzar a utilizarla cotidianamente.
Desde aquí quiero hacer dos agradecimientos muy especiales: uno a Espacio Galipán que se portaron MUY BIEN. El sitio es un espectáculo, la comida toda una delicia y la atención estuvo excelente. Altamente recomendable para cualquiera que necesite un espacio dónde lograr la mayor productividad.
El otro es para Patxi, quién hizo un taller super interesante y muy provechoso para el equipo. Como siempre su excelente manejo de las dinámicas hizo que todo el equipo quedara muy satisfecho.
Cafeconser3
View more presentations from estebanreyes.
Llegamos como a las 9 y nos fuimos a desayunar. Despues de la comida, arrancamos con las sesiones programadas por Patxi (Francisco Andrés) nuestro facilitador. El objetivo del taller era conversar sobre la creatividad y aprender a trabajar con las lluvias de ideas (brain storming).
Comenzamos con unos ejercicios físicos muy divertidos que nos ayudaron a calentar el espíritu y de paso, nos mostraron como las ideas preconcebidas o prejuicios nos impiden desarrollar soluciones a problemas cotidianos. Otra cosa importante, específicamente para mí, fue darme cuenta que la necesidad de controlar impide dejar a otros tomar iniciativas y resolver situaciones complejas; en el primer ejercicio, me la pasé todo el tiempo haciendo "shsssss" cuándo lo que se requería era que todos dijeran sus ideas. En algunas ocaciones lo mejor que se puede hacer es "Let it be"... como decía aquel Beatle.
Luego hicimos la primera lluvia de ideas para generar un Banco de Pet Projects. Hicimos una primera parte en parejas; en estas sesiones lo más importante es no limitar o juzgar ninguna idea y dejar que la creatividad fluya. En esta fase (media hora) generamos más de 70 ideas sobre posibles pet projects. Luego cada pareja, escogió las mejores 7 ideas y las publicamos en una pizarra. Despues de eso, cambiamos de pareja y cada nueva pareja escogió, de mutuo acuerdo, tres ideas para desarrollar más en profundidad.
Como parte final del ejercicio, cada equipo le colocó unas condiciones que debería cumplir cada idea para ser exitosa. Y le colocamos un puntaje a cada idea desarrollada en función a esos criterios. De acuerdo a ese puntaje escogimos las mejores ideas de cada equipo y se comentaron en conjunto. En menos de dos horas generamos 70 ideas a vuelo de pájaro, 27 ideas desarrolladas medianamente y 9 desarrolladas totalmente. Nada mal para un primer ejercicio :-)
Despues del almuerzo, hicimos un paréntesis para la presentación de los proyectos del torneo, y posteriormente continuamos con una sesión sobre el humor. El humor está relacionado con ver las cosas de una forma fuera de lo común. Lo peor que puede pasar con un chiste es que sea predecible. El humor tiene que ver con pensamiento "out of the box".
Para vivir en carne propia la relación entre las dos cosas, hicimos dos ejercicios donde cada uno (en equipo) debía crear una situación divertida. No es una tarea sencilla, pero lo más importante es que todos nos lanzamos y lo hicimos de la mejor manera. Fue realmente muy divertido ver lo que nos ocurrió a cada equipo. Hicimos dos ejercicios; uno en pareja y otro en grupos de 9 nueve personas. Interesantes lecciones sobre la creatividad y los ambientes que debemos crear para permitirnos explorar esa creatividad en cada uno.
Finalmente hicimos un segundo ejercicio de lluvia de ideas, pero esta vez orientado a encontrar un mensaje (podía ser un comercial, un informercial, una presentación en power point, etc) sobre como vender Zenkiu 4 en una convención de Turismo. Generamos un montón de ideas que podrían ser un comercial muy exitoso. Me gustó ver como todos hemos madurado los conocimientos sobre nuestro negocio y como podemos comunicarlo.
En Imolko hasta ahora no habíamos utilizado la herramienta de lluvia de ideas como una forma de resolver problemas. Definitivamente despues de este día, vamos a comenzar a utilizarla cotidianamente.
Desde aquí quiero hacer dos agradecimientos muy especiales: uno a Espacio Galipán que se portaron MUY BIEN. El sitio es un espectáculo, la comida toda una delicia y la atención estuvo excelente. Altamente recomendable para cualquiera que necesite un espacio dónde lograr la mayor productividad.
El otro es para Patxi, quién hizo un taller super interesante y muy provechoso para el equipo. Como siempre su excelente manejo de las dinámicas hizo que todo el equipo quedara muy satisfecho.
lunes, 11 de enero de 2010
Refactoring Week - Torneo de Programación
El torneo de programación (realizado durante el Refactoring Week) busca retarnos a crear proyectos innovadores trabajando en equipo y con poco tiempo.
Reglas Generales
Evento Facebook
Evento Flickr
La puntuación se asignará por un Jurado compuesto por:
Equipos
Despues de asignar los equipos, se les pidió que definieran su nombre. Los equipos seleccionaron estos nombres:
Reglas Generales
- La puntuación se realizará por equipos
- Las parejas se escogerán al azar y estarán compuestas por un homeclub y un visitante y adicionalmente contarán con un consultor o padrino del área de Gestión Comercial
- Se realizarán 4 eventos con una puntuación de 5 puntos cada uno.
- En cada evento el primer lugar obtiene 5 puntos, segundo lugar obtiene 4 puntos y el tercero obtiene 2 puntos
- Se debe aumentar la cobertura del código en las clases seleccionadas (la cobertura se refiere a la cantidad de líneas de código que tienen tests automatizados)
- Se trabajará con una sola computadora por equipo
- En los eventos de Cobertura se toma en cuenta el delta en números de líneas
Evento Facebook
- Hacer una aplicación que se ejecute en Facebook, utilizando Facebook Connect.
- Se debe definir inicialmente el User Story a desarrollar. El mismo se debe entregar antes de la 2pm del día del evento.
- Contar con al menos una llamada a las funciones de Imolko
- La aplicación se debe entregar al día siguiente del evento antes de las 9am
- Aplicación funcional
- La cantidad de funciones que se utilicen de Imolko. Como mínimo debe utilizar una llamada
- "Stickness"
Evento Flickr
- Hacer una aplicación que se conecte con Flickr
- Se debe definir inicialmente el User Story a desarrollar. El mismo se debe entregar antes de la 2pm del día del evento.
- Contar con al menos una llamada a las funciones de Imolko
- La aplicación se puede ejecutar en cualquier ambiente (IosFramework, Standalone, Página Web, etc).
- La aplicación se debe entregar al día siguiente del evento antes de las 9am.
- Aplicación funcional
- La cantidad de funciones que se utilicen de Imolko. Como mínimo debe utilizar una llamada
- "Stickness"
La puntuación se asignará por un Jurado compuesto por:
- Karina
- Giancarlo
- Miurika
- Diana
- Beatriz
Equipos
Despues de asignar los equipos, se les pidió que definieran su nombre. Los equipos seleccionaron estos nombres:
- Equipo A: Adriana, Nora, Gustavo y Carlos
- Los Gochos: Lorena, Marco y Joselyn
- Bug Killers: Yohany, Ricardo, Daniel y Juan
sábado, 9 de enero de 2010
Refactoring Enero 2010
Desde el 11 hasta el 15 de enero, estaremos realizando la tercera edición del Refactoring Week de imolko. Las otras ediciones se han centrado en aspectos técnicos, y para esta versión hemos cambiado el formato para integrar más a todas las áreas
Lo que queremos lograr se resume en estos objetivos:
Nos encontraremos en Caracas y vendrán personas de 5 ciudades distintas: San Cristobal, Barquisimeto, Valera (venezuela), Medellin (Colombia) y Lleida (España).
Ha sido complicado cuadrar las venidas de todos, especialmente para los que vienen fuera de Venezuela. Creo que se han disminuido las frecuencias de vuelos a venezuela.
Tuvimos que esperar casi hasta ultimo momento para conseguir cupo desde Colombia; afortunadamente se pudo conseguir a tiempo y en las fechas que queríamos.
Este evento me ha tocado planificarlo a mi, y he propuesto una agenda bastante ambiciosa.
Tendremos tres tracks:
En el primer track participaran Gestión Comercial y Desarrollo, y en los demás participaremos todos.
El evento va a ser en la oficina de Caracas, excepto el evento de creatividad que va a ser en Galipan-El Avila. El horario queda un poco apretado, arrancaremos a las 8.30 y terminaremos a las 6pm todos los días. Espero que nos alcance el tiempo para hacer todo lo planeado.
Estoy muy emocionado por reunir gente de tan diversas ciudades y espero que todo salga full bien.
Lo que queremos lograr se resume en estos objetivos:
- Definir la planificación para el 2010
- Aumentar la cohesión grupal
- Aumentar nuestra Creatividad
- Revisar y Mejorar XQ
Nos encontraremos en Caracas y vendrán personas de 5 ciudades distintas: San Cristobal, Barquisimeto, Valera (venezuela), Medellin (Colombia) y Lleida (España).
Ha sido complicado cuadrar las venidas de todos, especialmente para los que vienen fuera de Venezuela. Creo que se han disminuido las frecuencias de vuelos a venezuela.
Tuvimos que esperar casi hasta ultimo momento para conseguir cupo desde Colombia; afortunadamente se pudo conseguir a tiempo y en las fechas que queríamos.
Este evento me ha tocado planificarlo a mi, y he propuesto una agenda bastante ambiciosa.
Tendremos tres tracks:
- Técnico: torneo de programación y reuniones para conversar sobre xq
- Comercial: taller sobre creatividad y reuniones sobre mercadeo
- Planificación 2010: reuniones sobre nuestra estrategia.
En el primer track participaran Gestión Comercial y Desarrollo, y en los demás participaremos todos.
El evento va a ser en la oficina de Caracas, excepto el evento de creatividad que va a ser en Galipan-El Avila. El horario queda un poco apretado, arrancaremos a las 8.30 y terminaremos a las 6pm todos los días. Espero que nos alcance el tiempo para hacer todo lo planeado.
Estoy muy emocionado por reunir gente de tan diversas ciudades y espero que todo salga full bien.
Suscribirse a:
Entradas (Atom)
