Publicidad
User Interface Workshop en Madrid – 23 al 27 de octubre.
5 dÃas, 5 temas, Ajax y Javascript avanzado, Diseño de interfaces, Usabilidad, Móviles…
Imparten: JoaquÃn Cuenca, Miquel Nieto y Eduardo Manchón.
Desarrollo ágil es una filosofÃa, no una metodologÃa
El desarrollo ágil no es una metodologÃa con pasos establecidos, es simplemente una manera de pensar y de trabajar.
El desarrollo ágil se puede resumir en una frase â??ejecuta rápidamenteâ?. La rapidez no es un método infalible a aplicar a rajatabla, es una manera de enfocar las tareas enfocada a dar prioridad a la ejecución sobre la planificación.
Planificas o actúas
El tiempo no es infinito. No puedes hacer todo al mismo tiempo, optar por una opción o la otra conlleva muchas cosas. Claro, puedes hacer ambas cosas, pero entonces harás ambas a medias.
Especular o probar en real
¿Funcionará una web que busca en 23 webs de vuelos simultáneamente como Trabber? A priori la idea tiene sentido, pero quién sabe si funcionarÃa, si captarÃa tráfico, si generarÃa fidelidad… A posteriori se ha visto que sÃ, que funciona, pero a posteriori todo parece siempre evidente. La única manera de saberlo ha sido desarrollar el proyecto.
En un entorno donde las innovaciones envejecen en apenas meses, donde todo evoluciona a la velocidad de la luz, no está siempre clara la utilidad de dedicar excesivamente tiempo a investigar que puede funcionará y qué no, o a planificar al detalle. Es divertido especular con ideas en el aire, pero no se obtiene nada en concreto.
Investigar e innovar
Innovar también es investigar
Innovación significa crear algo que no existÃa antes, ejecutar para obtener algo fÃsico. Investigar es averiguar información útil para el proyecto, crear algo intangible, conocimiento.
La ventaja de innovar sobre investigar, es que a la vez que obtienes algo fÃsico funcionando, también puedes averiguar información útil para el proyecto, en muchos casos una información mucho más fiable que te proporciona la pura investigación. En conclusión, innovando también investigas.
Tras investigar y planificar puedes tardar 8 meses en tener la primera beta impoluta para lanzarla a público o tardar 1 mes con algo hecho rápidamente sin refinar. En la segunda opción 7 meses más tarde puedes tener cientos o miles de usuarios, una versión refinada y mucha más información real, no especulaciones. En la primera opción nada te garantizarÃa que la beta impoluta no sea después un fiasco.
Internet facilita innovar y hacer experimentos con usuarios reales, basta con públicar la web y tener un poco de tráfico.
Reacción rápida
Rectificar puede ser percibido negativamente, significa que has cometido un error o lo puedes percibirlo positivamente como que has aprendido y eres capaz de reaccionar rápidamente para arreglarlo.
Cuanto más rápidamente ejecutes, antes descubrirás qué es bueno, qué es malo, qué es suficientemente bueno y podrás hacer mejoras. Rectificar no es fácil, conlleva ser humilde y modesto.
Cuando el área del proyecto está muy trillada y se conoce bastante sobre lo que funciona, si puede tener sentido investigar y planificar para mejorar lo que ya existe. La filosofÃa de desarrollo ágil funciona mejor cuando se trata de hacer algo desde 0 o rediseñarlo totalmente, por el contrario es menos recomendable cuando quieres mejorar algo que ya sabes que funciona.
Ideas sobre desarrollo ágil
Lo mejor es enemigo de lo bueno
¿Cuando tienes algo suficientemente bueno para sacar a público? En cuanto funcione de manera técnicamente aceptable.
Lo mejor es enemigo de lo bueno, pero lo mejor aún es peor enemigo cuando ni siquiera sabes qué es. No dudes, sácalo a real y verás si funciona o no.
Resuelve los problemas cuando los tengas
No tiene sentido preocuparse de problemas de escalabilidad en el futuro al principio de un proyecto, deberÃas preocuparte de las cosas más urgentes en ese momento. Además de quitarte tiempo muy valioso, seguramente las soluciones a las que llegues distarán de ser óptimas. Por ejemplo, hasta que no sepas exactamente que problemas de escalabilidad vas a tener no sabrás cuál será la mejor opción.
Lo mismo pasa con los temas legales. Si no hay ingresos, ni pagos, ni información personal muy delicada almacenada no creo que valga la pena que te quiten el sueño. La última cosa de la que me preocuparÃa serÃa de como declarar una pequeña cantidad de ingresos de Adsense.
Los grandes planes nunca funcionan
No es una ley de Murphy, pero como si lo fuera. Planificar excesivamente aleja de la realidad, es muy fácil escribir en un papel ideas, pero muy difÃcil ejecutarlas. Conforme una planificación se complica es más probable que no funcione como se espere.
Es positivo tener unas ideas básicas y generar algunos documentos concisos, pero hay que evitar la complicación excesiva. Jesús Encinar cuenta como redujeron el plan de negocio de Idealista de 150 páginas a solo 7.
Logs y estadÃsticas de servidor
Para saber qué funciona y qué no funciona de los cambios realizados, tu gran aliado serán las estadÃsticas. Son la manera más rápida, ágil y barata de obtener información fiable del mundo real.
No se trata de manejar mil datos estadÃsticos, sino centrarte en los realmente relevantes y sensibles a los cambios. Los test de usuarios de guerrilla son útiles especialmente cuando tienes dudas o hay grandes cambios.
No es algo nuevo
La filosofÃa de desarrollo ágil no es nueva en absoluto. Cualquiera que comienza un proyecto puede optar por planificar bien o actuar rápido, ya sea construyendo un puente o diseñando una web. Simplemente en algunos proyectos puede ser más adecuado hacerlo que en otros.
No es recomendable arriesgarse a tener accidentes construyendo un puente, todo tiene que estar bien planificado y aguantar mucho más de lo necesario. Sin embargo una web inicialmente no la creas para resistir mucho más tráfico del necesario y si un dÃa cae un par de horas se puede resolver fácilmente.
Es un medio, no un fin
La metodologÃa de desarrollo web ágil, como cualquier otra metodologÃa es un medio, no un fin. No se trata de aplicarla a rajatabla, sino cuando nos ayude a conseguir nuestro objetivo. Nadie deberÃa seguir esta filosofÃa en su proyecto porque lo ha leÃdo este artÃculo, ni en ningún otro, sino porque es lo más adecuado para su proyecto en ese momento y en esas condiciones.
Hay servicios que deben funcionar perfectamente desde el primer dÃa porque por su propia naturaleza solo aportan si funcionan bien, no se les darÃa una segunda oportunidad, para esto no vale el desarrollo ágil. Si desarrollas un servicio de pago tampoco te recomiendo experimentar demasiado con desarrollo ágil.
Sin marketing masivo
Hacer cambios de manera rápida no significa forzosamente la presencia de bugs, pero ciertamente con desarrollo ágil puede ser más proclives a tenerlos. Además puede que el aspecto del sitio no sea muy refinado cuando lo sacas a público tras un mes de desarrollo.
Por estas razones no es bueno aparecer en grandes medios porque entonces como comentaba Joel on Software en Massive Frontal PR is incompatible with Ship Early and Oftenâ? tendrÃas dos problemas a) un proyecto inacabado b) todo el mundo lo sabrÃa.
Para un proyecto que utiliza desarrollo ágil es mejor el marketing de guerrilla, de blogs, el boca-oreja y en general cualquier técnica enfocada a un público más pequeño y limitado. Este público especialmente interesado en la idea es más comprensivo y da mucho feedback, sugiere, comenta, etc.
Motivación y abandono
El desarrollo ágil disminuye la probabilidad de abandono del proyecto porque lo hace más motivador.
Cualquier proyecto desde 0 requiere un volumen de motivación impresionante, no es extraño que un proyecto se abandone sin ser completado, lo que sucede mucho más frecuentemente en proyectos que tardan muchos meses en salir a público.
Un desarrollo ágil tiene una primera versión mucho antes con lo que minimiza el riesgo de abandono previo. Luego al no parar de sacar cambios y recibir feedback de los usuarios se obtiene más motivación positiva y se reduce la probabilidad de que sea abandonado.
Con pocos recursos es más fácil
Cuanto menos tengas, menos tienes que perder. Si no tienes inversión más que tu tiempo, eso será lo único que perderás si te arriesgas. Si te alguien te paga mucho dinero o invierte en tu proyecto, te dará más miedo arriesgarte a experimentar y probar cosas nuevas.
La conclusión es sencilla, aunque paradójica, tu escasez de recursos te abre la puerta de grandes oportunidades. Para llegar a innovar radicalmente hay que experimentar y probar haciendo cosas que grandes empresas ni podrÃan, ni se atreverÃan a hacer.
Utilizando desarrollo web ágil un equipo pequeño y sin recursos convierte sus debilidades en ventajas. Hay que evitar entrar a competir con las grandes con sus mismas armas y sus mismas metodologÃas de trabajo, es muy complicado tener opciones entrando en su terreno.
Equipo inicial minúsculo
No hablo de un equipo pequeño de 5 o 6, me refiero a un equipo minúsculo de 2 o 3 personas inicialmente.
Si hay mucha gente tardas demasiado en ponerte de acuerdo y sobre todo es complicado que nadie se moleste cuando parece que das â??bandazosâ? con tanto experimento y cambio de opinión. A menos gente más agilidad de implementar y menos discusiones.
Lo que no recomiendo en absoluto para un proyecto asà es depender de patas fÃsicas, de acuerdos con terceros, de demasiada gente, etc. es complicado utilizar desarrollo ágil en esas circunstancias.
¿Es serio un proyecto llevado as�
Sucede que algunas personas no toman en serio un proyecto que cambia cada dos por tres, donde algunas cosas no son tan estables como debieran y que no tiene inicialmente un nivel de refinamiento muy alto. Se puede llegar a pensar que es un proyecto de â??amiguetesâ?, algo poco serio, un juego.
En realidad nada tiene que ver una cosa con la otra. Cualquier experimento tiene mucho de juego, de descubrir que funciona y que no funciona, de ser como un niño curioso que prueba y prueba.
En realidad es positivo que sea divertido y que el ambiente sea relajado porque es solo es posible tener ideas nuevas y atreverse a implementarlas rápidamente en un ambiente flexible y donde se acepte la alta incertidumbre como normal, justamente lo que no sucede en un ambiente de trabajo clásico. Creo que no serÃa positivo para un proyecto desarrollado de manera ágil el parecer â??serioâ?. Las camisetas y la ausencia de trajes no son casualidad o una moda en este ambiente.
El desarrollo ágil no es para siempre
El desarrollo ágil es especialmente útil al principio del proyecto, cuando hay que crear algo de la nada y aprender lo antes posible.
Más tarde, al cabo de un año o dos, cuando ya empiezas a tener claro lo que funciona y lo que no, la filosofÃa forzosamente cambia. Empieza a haber más gente en el equipo, se empieza a discutir más y se hace menos. Es normal e inevitable, no es lo mismo jugarte perder usuarios cuando empiezas y solo tienes un par de miles que más tarde cuando tienes un par de cientos de miles.
Cuando tienes muchos usuarios además se complican los cambios, la gente se acostumbra a las cosas y prefieren estabilidad, no les gustan los cambios, aunque realmente sean positivos para ellos.
Una filosofÃa de trabajo que no es para todos ni para todo
Tu carácter personal es importante
Para aplicar desarrollo ágil debes tolerar niveles altos de incertidumbre e incluso de caos en ocasiones. No te debe poner excesivamente nervioso no saber qué va a pasar en el futuro. Es una filosofÃa que funciona bien con personas que necesitan respuestas rápidas, hacer algo y ver los cambios, que no les gusta esperar.
Si tu estilo de trabajo es muy organizado y planificado, te incomoda la incertidumbre, pero por el contrario eres capaz de mantener alta tu motivación en un largo proyecto donde los resultados no se visualizan hasta meses más tarde, seguramente esta filosofÃa de trabajo no es para ti.
Cuando tienes ideas muy claras, te entusiasman ciertos autores y te encantan las metodologÃas, seguramente encajarás muy bien en otros proyectos, pero no en uno de desarrollo web ágil. Al contrario, la gente más óptima para desarrollo ágil, es la que peor encaja en grandes organizaciones con muchas jerarquÃas y procesos. No opino que un perfil sea mejor que otro, simplemente son diferentes para casos diferentes.
El caso de Panoramio
El caso de Panoramio es bastante claro de las ventajas que tiene aplicar metodologÃa de desarrollo ágil.
Comenzó con un equipo de solo 2 personas, , que ahora es de 3 personas con la reciente incorporación de José Florido. Más serÃa una multitud en un proyecto asÃ.
Los cambios y rediseños han sido constantes en Panoramio, por ejemplo, hemos cambiado 3 veces radicalmente de homepage en un año, el último hace 4 dÃas escasos.
En un tema como las mash-ups que usan el API de Google Maps no hay estándares porque están siendo inventadas ya mismo. No se sabe lo que funciona y lo que no, no hay referencias. En nuestro caso no hay más de 5 webs que posicionen fotos en mapas. Supongo que esto habrá facilitado que Google Earth recomiende Panoramio en su página de descarga, nos esté ayudando con el hosting y nos invitase al Googleplex.
Ningún método de investigación te dirá si una idea como la de Panoramio funcionará, es demasiado nueva, es más rápido obtener información de la gente que utiliza la web realmente.
Por la evolución del proyecto y su rápida salida a público en etapas muy iniciales, quizás algunas personas han tomado poco en serio el proyecto como de â??amiguetesâ? o como un juego. Ciertamente lo pasamos bien, es divertido, pero eso no quita que trabajemos en Panoramio más horas que tiene el dÃa y que nuestro nivel de implicación sea muy alto.
Panoramio salió sin modelo de negocio claro lo que puede parecer inadecuado. Por supuesto nosotros pensamos que lo ideal es tener un modelo de negocio claro desde el principio, pero siendo un equipo inicialmente de dos personas, o te centras en crear un proyecto útil y que funcione, o te centras en crear un modelo de negocio, no puedes estar en todo. Si creas algo útil seguro que luego hay una manera de rentabilizarlo. Actualmente con la publicidad Adsense el sitio cubre costes y da beneficios, lo que no es banal en un sitio que hospeda fotos.
Si hubiéramos utilizado el método clásico de desarrollo hubiéramos tardado 6 meses como mÃnimo en salir a público. Sin embargo en ese tiempo ya tenÃamos 15.000 fotos y muchos miles de usuarios probando algo en real y dándonos información. El número de fotos actual es cercano a las 60.000.
La ventaja de haber salido a público tras solo dos meses de desarrollo no es solamente que a dÃa de hoy tenemos mucho más tráfico, miles de fotos y de usuarios que si lo hubieramos hecho más tarde. La gran ventaja es que además de eso hemos aprendido mucho, un año es un mundo en estas áreas y este aprendizaje nos permitirá hacer grandes mejoras en un futuro próximo que de otro modo hubieran llegado mucho más tarde.
Respecto al marketing, hasta ahora nos habÃamos limitado al marketing de guerrilla, puesto que inicialmente habÃan muchas cosas que corregir y mejorar, no era conveniente saltar a grandes medios. El boca a boca nos permitió aparecer citados en más de 800 blogs lo que nos trajo muchas personas interesadas y motivadas para dar mucho feedback e información para mejorar el sitio. Ciertamente, aún queda mucho que mejorar, pero ahora el proyecto esta mucho más definido y preparado para salir en grandes medios masivamente, de hecho ayer lo hizo por primera vez (Panoramio en Google News)
A partir de ahora las cosas irán cambiando en Panoramio, pero no tan radicalmente y muchos cambios lo serán en la parte invisible, por ejemplo la velocidad de interacción de las fotos con el mapa. Más allá de preferir unas filosofÃas de trabajo u otras lo importante es ser flexible y buscar la mejor manera de alcanzar los objetivos buscados.
Publicidad
User Interface Workshop en Madrid – 23 al 27 de octubre.
5 dÃas, 5 temas, Ajax y Javascript avanzado, Diseño de interfaces, Usabilidad, Móviles…
Imparten: JoaquÃn Cuenca, Miquel Nieto y Eduardo Manchón.
Referencia:
– Getting Real. Este libro en formato PDF de la conocida consultora 37Signals se ha convertido en una pequeña Biblia del desarrollo ágil. Varios capÃtulos se pueden descargar de manera gratuita.