Artículos inspiradores:
Loogic: ¿Has empezado ya a vender?
es muy importante que cuanto antes puedas te pongas a vender tu aplicación, a enseñarla, a sacarla en beta. Pero incluso puede ser muy interesante hablar de ella antes de tener ni siquiera la beta. Ese proceso de “venta” previo te hará localizar enfoques, ideas, aplicaciones en las que no habías pensado antes y que pueden enriquecer muchísimo tu aplicación.
Leer el artículo…
Armando un grupo de beta testers para Partitur.es
Como comentaba el otro día, el planteamiento del desarrollo iterativo requiere que al final de cada iteración se pruebe todo con usuarios reales. Son ellos los que indicarán que se ha hecho bien o mal, y ayudarán a decidir cuales son los siguientes pasos a dar.
Por ello, en Partitur.es estamos montando nuestro grupo de beta-testers, formado por gente con la que hicimos el primer estudio de mercado, gente a la que le hemos hablado del proyecto y dijeron «me gusta, cuenta conmigo». Realmente muchas de estas personas ya han dado ideas de lo que la plataforma puede ser y sus ideas se han apuntado en la lista de funcionalidades, y además nos han ayudado ya a centrarnos, encontrar las funcionalidades centrales y entender y descubir algunas cosas que no conocíamos del mercado en que nos estamos metiendo.
El grupo aún está abierto, buscamos gente del mundo de la música: compositores, músicos, cantantes que sepan solfeo o que trabajen con partituras habitualmente. Si quieres ser beta-tester y participar en el desarrollo de Partitur.es, de nuestra plataforma para compartir partituras musicales, no dudes en mandarnos un correo a info@amorodio.es.
Tendremos reuniones mensuales presenciales con la gente que tenemos cerca, como cierre de cada iteración, para tener un trato directo (nos servirá para detectar la usabilidad y nos podrán dar respuestas mas directas). Además habrá otras vías de comunicación constante: encuestas, un panel en UserVoice.com y el email.
Ahora toca finalizar la primera iteración y empezar a preguntarles a los usuarios como lo ven. Ahora veremos si todos estamos pensando en lo mismo, veremos si cumple con sus expectativas.
Artículos interesantes al respecto:
Música, ciencia y tecnología
Interesante programa de tres14 (programa de divulgación científica de RTVE) que emitieron el pasado febrero en el que se habla de la música en todos sus aspectos. Desde los primeros instrumentos musicales humanos hasta los programas informáticos de reconocimiento de canciones.
Desarrollo iterativo
Esa es la traducción mas cercana a «lean developing» que he podido encontrar y que descubrí con la lectura de Getting Real de 37 signals, aunque la idea tiene mas de 10 años. Significa establecer ciclos cerrados de trabajo a corto plazo, con pocas funcionalidades. Al terminar el ciclo se prueba con usuarios lo realizado y se establecen las funcionalidades del siguiente ciclo.
De esta manera, se enfoca el trabajo en dar las funcionalidades clave que dan valor a tu plataforma y no se pierde el tiempo con una cantidad abrumadora de funcionalidades, alguna de las cuales nadie va a usar. También se logra tener una plataforma funcionando desde el final de la primera iteración, aunque tenga pocas funcionalidades (lo cual es especialmente importante en el caso de una start-up en internet).
Una ventaja frente al clásico modelo de desarrollo en cascada, es que al final de cada iteración se han tenido que resolver todos los problemas de la misma para darla por concluida, con lo cual se detecta cualquier punto de bloqueo antes y se detecta de una manera mas clara donde se produce y a que afecta.
Otra ventaja es que los programadores son mas eficientes cuando la meta está cerca.
Desarrollar para un ciclo corto no significa perder de vista a largo plazo para donde se quiere llevar el proyecto. Se puede plantear una lista tan grande como se quiera de funcionalidades al principio del proyecto con ideas mas o menos complicadas y se irán seleccionando las que son prioritarias de este listado.
Una parte sorprendente del desarrollo iterativo es que NO hay que pensar en como se resolverán problemas/funcionalidades futuros/as. En cada iteración puede haber cambios en cualquier parte de la aplicación: diseño, modelo de datos, controladores… Por ello, habrá que buscar las herramientas que: 1) permitan una abstracción de las distintas capas para que los cambios se propaguen de manera sencilla; 2) tengan una buena batería de pruebas para comprobar que cambios en las siguientes iteraciones no estropean algo realizado anteriormente.
Mas sobre desarrollo iterativo y programación extrema: