En Imolko estamos trabajando en aumentar la cantidad de Registros que tenemos en el site. Los registros son muy importantes como primer paso en una relación basada en Internet y definen en el corto plazo cuántos prospectos están cerca de comprar tu producto o servicio. En este artículo comparto 10 ideas sobre como mejorar los registros en un sitio web, que creo que son universales y pueden ayudar a cualquier empresa.
1) Disminuir la cantidad de campos que solicitas en el registro: creo que un problema podría ser que la persona se asustara (o le diera flojera) por la cantidad de campos y no haga el registro. Es importante que pienses que el registro es el primer paso y que si hay "corazón" o razones para continuar en la relación habrá otros momentos para solicitar más información. Si te pones muy avaro, puedes ahuyentar personas que más adelante podrían convertirse en tu cliente.
2) Si estás utilizando anuncios de Facebook o Google, prueba colocando un titulo y texto directo orientado a un tipo de negocios en especial. Algo como "Notificaciones y Alertas para Gimnasios" podría ayudarte a conseguir más clicks de gente interesada. Recuerda que estos casos estás pagando por cada click, y mientras más claro sea tu anuncio mayor son las opciones que haga click alguien interesado.
3) Colocar el chat en la página de registro o en la de Facebook y estar pendiente cuando alguien entre para conversar con esa persona. Algunos sitios, como el nuestro, utilizan un sistema de Chat en línea para ayudar a los visitantes. Si tienes la posibilidad tecnológica, coloca el chat en la página de Registro para ayudar a responder preguntas o a convencer a los indecisos a culminar el registro.
4) Ofrecer un Regalo por Registrarte; en el caso de Imolko, este regalo podría ser un white paper sobre mercadeo electrónico. Es muy probable que regularmente generes contenido de interés para tus usuarios, y si no lo haces estás perdiendo una gran oportunidad. Si puedes generar este material, lo podrías enviar una vez que las personas terminen su registro. Además tendrías otra oportunidad para iniciar una conversación.
5) Coloca un botón claro en tu home page para el registro. Aunque parece obvio, muchas veces se nos olvida o colocamos demasiada información en el web site y el registro pierde importancia a los ojos del usuario.
6) Conversa con tus usuarios más fieles y solicitales ayuda. En conversaciones informales solicita que te ayuden pidiendole a sus amigos que se registren. Genera un URL corto con la dirección de tu Registro y pideles que la envíen en sus cuentas de Twitter y Facebook. Un usuario agradecido puede ser muy potente para distribuir tu mensaje.
7) Haz un video corto explicando por que es bueno registrarse en tu aplicación; si lo haces con humor se convierte en una herramienta viral para que otros te ayuden a distribuir tu mensaje. Hacer un video no es muy complicado hoy en día; sólo tienes que ponerle un poco de imaginación y pasar el mensaje. Si no funciona muy bien, igual tienes un material para compartir y que se burlen tus amigos :-)
8) Organiza un concurso con estudiantes de mercadeo; acercate a alguna universidad o instituto que tenga cursos de mercadeo y coordina con un profesor para crear un concurso sobre qué campaña puede traer más registros a tu site. Ofreceles un ipad + la opción de tener una referencia en tu sitio web de agradecimiento. De esta manera puedes conseguir ideas frescas y estás dándole un chance a lo estudiantes de poner en práctica sus conocimientos en el mundo real.
9) Crea un mensaje claro para motivar a los registros y pidele a tus compañeros de trabajo que lo coloquen como footer en sus correos. De esta manera, aprovechas los correos que envían todos en tu empresa como forma de llevar tráfico al sitio.
10) Si tienes alguna base de datos antigua de clientes que hayan desistido, es un buen momento para contactarlos nuevamente y comentarle sobre los cambios recientes en tu servicio. Incluso puedes pensar en hacerle un descuento de tu servicio a cambio que se registren y prueben nuevamente el servicio.
lunes, 13 de febrero de 2012
martes, 4 de enero de 2011
Aprendizajes Extremos (y 4ta parte)
Este es el último post de una serie de cuatro artículos sobre Programación Extrema y los aprendizajes que hemos tenido en estos meses. Puedes ver el primer artículo aqui.
Versiones Integrales
Con versiones integrales me refiero a un conjunto de funcionalides individuales que apuntan todas en la misma dirección. El contrario es cuándo se hacen versiones con un montón de funcionalides pero cada una apuntando a dirección distinta.
Cuándo todo el equipo se concentra en un mismo "tipo" de funcionalidades se logra una sinergia dificil de lograr cuándo se realizan funcionalidades inconexas. Esta sinergía además se transmite a toda la empresa, puesto que es mucho más fácil comunicar un concepto que agrupa a todas las funcionalides que cada una de las funcionalidades independientes. Incluso comercialmente es mucho más fácil de comunicar.
Para lograr esto es necesario que en la definición de la versión se defina el objetivo a lograr y se agrupen todas las funcionalides que apuntan a ese objetivo. La forma de agrupar puede variar en cada caso, pero es importante que se tenga un concepto para transmitir.
Creo que como ejemplos de estas versiones integrales podrían ser cosas como "Mejoramiento del API" (todo el mundo concentrado en mejorar el API), "Conexión con Facebook" (todo el mundo concentrado en crear funcionalidades relacionadas con Facebook), etc. En las dos últimas versiones hemos tenido foco en "Optimización en manejo de Volúmen" e "Implementación de Campos Relacionales".
La sinergía se logra en que todo el mundo resuelve problemas similares en el mismo período de tiempo; entonces las soluciones encontradas por los primeros se transmiten más fácilmente a los demás. El código se puede encapsular más fácilmente. Los problemas se pueden resolver fácilmente entre varios. Se evita el retrabajo, etc.
Este concepto tambien a ayudar a definir más fácilmente que se puede posponer. Todo lo que no apunta en el concepto de esta versión se puede pasar a otra versión.
Versiones Integrales
Con versiones integrales me refiero a un conjunto de funcionalides individuales que apuntan todas en la misma dirección. El contrario es cuándo se hacen versiones con un montón de funcionalides pero cada una apuntando a dirección distinta.
Cuándo todo el equipo se concentra en un mismo "tipo" de funcionalidades se logra una sinergia dificil de lograr cuándo se realizan funcionalidades inconexas. Esta sinergía además se transmite a toda la empresa, puesto que es mucho más fácil comunicar un concepto que agrupa a todas las funcionalides que cada una de las funcionalidades independientes. Incluso comercialmente es mucho más fácil de comunicar.
Para lograr esto es necesario que en la definición de la versión se defina el objetivo a lograr y se agrupen todas las funcionalides que apuntan a ese objetivo. La forma de agrupar puede variar en cada caso, pero es importante que se tenga un concepto para transmitir.
Creo que como ejemplos de estas versiones integrales podrían ser cosas como "Mejoramiento del API" (todo el mundo concentrado en mejorar el API), "Conexión con Facebook" (todo el mundo concentrado en crear funcionalidades relacionadas con Facebook), etc. En las dos últimas versiones hemos tenido foco en "Optimización en manejo de Volúmen" e "Implementación de Campos Relacionales".
La sinergía se logra en que todo el mundo resuelve problemas similares en el mismo período de tiempo; entonces las soluciones encontradas por los primeros se transmiten más fácilmente a los demás. El código se puede encapsular más fácilmente. Los problemas se pueden resolver fácilmente entre varios. Se evita el retrabajo, etc.
Este concepto tambien a ayudar a definir más fácilmente que se puede posponer. Todo lo que no apunta en el concepto de esta versión se puede pasar a otra versión.
lunes, 27 de diciembre de 2010
Aprendizajes Extremos (3era parte)
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.
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.
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.
Suscribirse a:
Entradas (Atom)
