Archivo
Business Model Canvas para Google Docs en español
El Business Model Canvas o Canvas de Osterwalder es una herramienta para el análisis de modelos de negocio de nuevas iniciativas. Está teniendo mucha repercusión entre los emprendedores y se toma como modelo en muchas actividades o cursos de creación de empresas o negocios. Puedes encontrar más información en su entrada de la wikipedia.
En mi opinión es una herramienta muy práctica para hacer brainstorming de manera completa de toda una idea o modelo de negocio, evitando dejar flecos e intentando llegar y completar todos los posibles aspectos o detalles del modelo. Me parece especialmente útil a la hora de trabajar en equipo para elaborar estos modelos.
Encontré hace poco una entrada de David Bland en el que compartía el Business Model Canvas como documento de Google Doc. Algo que es muy práctico porque permite compartirlo y editarlo en grupo de manera colaborativa.
He traducido el documento de David (todo el mérito es suyo) para tener una versión del Business Model Canvas en castellano, aquí. Si quieres editarlo, puedes hacerlo creando una nueva copia.
El documento original de Business Model Generation se encuentra bajo licencia de Creative Commons con reconocimiento de la autoría y derivación bajo las mismas condiciones de licencia.
Un saludo,
Esta entrada de Juan Francisco Adame Lorite está bajo una licencia Creative Commons Atribución-CompartirIgual 3.0 Unported.
Coursera, formación de universidades americanas gratuita
Coursera es una iniciativa para llevar la educación de algunas universidades americanas de manera libre al público general. El motto del proyecto puedes leerlo aquí.
La idea es permitir el acceso público a recursos como son las clases (lectures) y, en parte, la tutoría y los trabajos de evaluación de algunas asignaturas de universidades como Michigan, Berkeley o Stanford. Las asignaturas actualmente disponibles o que se están impartiendo, así como las futuras las puedes encontrar en su página. Por lo general, son materias técnicas relacionadas con el mundo de la computación, pero también existen otras como Anatomía, Teoría de Juegos o Arquitectura Ecológica. Cada una tiene sus propios tiempos y plazos, si tienes interés en alguna asignatura comprueba dichos plazos para estar pendiente.
Llevo desde marzo cursando una de las asignaturas y puedo hablar desde dentro de qué me parece la iniciativa. Las asignaturas se van dividiendo en semanas, hasta un total de 8 a 10 semanas que estimo que durará cada una. Cada semana se publica el temario para dicho periodo:
- Temas que se van a tocar durante esa semana, que suelen ser 2 o 3 capítulos de la bibliografía de referencia del curso.
- Lectures o videos de las clases impartidos por el profesor. Cada capítulo del temario suelen ser 4 o 5 vídeos de 8 a 15 minutos de duración en inglés. Creo que se esfuerzan por ser entendidos porque no me parece un nivel de inglés muy complicado. Aún así tienen también disponibles para descarga los subtítulos de los vídeos.
- Transparencias que se utilizan durante las lectures.
El ver los vídeos con las transparencias y buscar alguna referencia de algún concepto en Internet puede llevar en torno a 2 o 3 horas por semana. La verdad es que los profesores se esfuerzan por ser didácticos y que el temario sea accesible. Le dan un enfoque muy práctico orientado a resultados sin dejar a un lado la teoría, pero sin sobrevalorarla. Aún así, sí que se requiere un nivel básico de matemáticas de nivel universitario para seguir algunos de los aspectos que se tocan. El temario abordado en el curso por ahora es muy parecido al del libro de referencia de la asignatura impartida por ambos profesores en la universidad, por lo que entiendo que habrá diferencias de temario y alcance, pero que no tienen que ser muy grandes respecto a la asignatura presencial.
A continuación existen dos pruebas de evaluación del temario tocado cada semana:
- Test de preguntas, relacionadas con el temario de la semana. No se orientan a demostraciones o disertaciones teóricas, si no a la aplicación práctica de los conceptos explicados. Suelen ser la aplicación de fórmulas y conceptos a ejemplos muy sencillos y concretos. Son 4 o 5 preguntas por test y tienes 5 opciones para aprobarlo. Se graba aquella en la que has obtenido mayor puntuación. No suele llevar más de 30 minutos o una hora resolverlo.
- Ejercicio de desarrollo. Se plantea la resolución mediante desarrollo de un ejemplo o problema relacionado con el temario de la semana. Dan un código base de ejemplo ya funcional y te piden que modifiques o implementes el método de alguna clase en especial; para no perder el tiempo en aspectos del desarrollo fuera del objetivo de aplicación específico. El mismo desarrollo evalúa la eficiencia de nuestro código para resolver el problema y se puntúa conforme a unos criterios. El código podemos subirlo todas las veces que queramos para evaluar y se guarda la puntación máxima que obtengamos. Según las prácticas, me ha llevado de 5 a 10 horas de trabajo.
Existen dos fechas límites: una primera para que la actividad, sea test o problema puntúe al 100%; y otra segunda o deadline, en la que lo entregado puntúa al 50%. Si no llegamos a entregar una actividad en ambos plazos, no se nos dará el curso como completado. El primer límite son 3 o 4 semanas desde la publicación del temario y el segundo en torno a 6 u 8.
Junto con todas estas herramientas, también hay unos buenos foros con mucha participación. Los profesores y encargados del proyecto no dan a basto para atender todas las dudas. Pero no es necesario, el número de personas apuntadas es muy grande y hay un ambiente colaborativo muy sano y generoso. Cualquier duda que pongas será resuelta pon un compañero en muy poco tiempo, incluso las soluciones a tests y ejercicios.
Una dedicación semanal de 5 a 10 horas, puede ser suficiente para llevar de manera holgada la asignatura.
En definitiva, la iniciativa me ha parecido muy buena y creo que está funcionando muy bien, para ser la primera vez y para ser el número de inscritos tan grande. Permite formarte en temas específicos de muy alto nivel de forma guiada y con recursos de mucha calidad, de manera totalmente gratuita. A lo largo de este tiempo se han unido a la iniciativa nuevas universidades y asignaturas, por lo que parece que tendrá continuidad.
Un saludo,
Esta entrada de Juan Francisco Adame Lorite está bajo una licencia Creative Commons Atribución-CompartirIgual 3.0 Unported.
Feedback y canales de comunicación en interfaces de usuario (UI)
Leía y veía esta entrada hace poco en Genbeta:dev y me pareció muy recomendable.
En relación con lo que hablábamos en la entrada anterior la exposición de Bret es muy buena. Comienza ganándose al público con golpes de efecto: los prototipos que presenta son muy llamativos y representativos de lo que quiere mostrar, nos enseña un buen conjunto de ellos y están enfocados al auditorio para el que habla, que seguro que son desarrolladores en su mayoría.
Una vez tiene el público ganado, desarrolla toda su exposición de manera lineal, como si fuese una historia, explicando cuál es el motivo y motor de su trabajo hasta llegar al concepto del principio (principle) que, según él, mueve toda iniciativa creadora o emprendedora. Este es el punto álgido de la exposición en el que con un entusiasmo contagioso y una credibilidad envidiable cierra su exposición. Lo que trata tiene sustancia y cuerpo (no es humo) y además, en mi opinión, lo presenta muy bien. Si tuviera que sacar un pero, el tiempo, se me antoja un poco larga; pero posiblemente le pidieron intervenir durante una hora.
De lo que trata Bret es de los tiempos de respuesta o feedback de los interfaces de usuario. Se centra en los entornos de desarrollo, pero es extrapolable a otros ámbitos. Si aplicamos la Teoría de la Comunicación Humana, en toda comunicación existe un emisor (el usuario), un receptor (el sistema), un mensaje (qué quiere hacer el usuario), un canal y un código (ambos representados en el interfaz de usuario). El primer axioma de Paul Watzlawick dice «Es imposible no comunicar», pero esto no es siempre es verdad cuando el receptor es una máquina («¿esto se ha quedado colgado?», «¿cuánto falta para que acabe?»). El hilo conductor que mantiene toda conversación es la retroalimentación del receptor al emisor. Los interfaces de usuario llevan trabajando las últimas décadas en este sentido: el relojito de espera de los entornos Windows se creó para indicar al usuario que el equipo estaba realizando una tarea y que no estaba colgado, la barra de estado y de progreso se crearon a continuación para indicar el estado de realización de dicha tarea y hoy en día existen opciones que dan información más completa del estado de la máquina y sus tareas a su interlocutor, como cuadros de diálogo que aventuran una tiempo de finalización.
Volviendo al punto de vista del desarrollo es muy común estar resolviendo problemas en los que, o bien porque su solución es muy compleja o porque la plataforma utilizada no es lo suficientemente eficiente, el retorno que recibimos no llega a tiempo o no nos da suficiente información. Los tiempos de compilación son muy grandes, como para probar cada pequeño cambio; o el despliegue de la solución y el camino a seguir para replicar la situación que queremos comprobar es muy largo. Esto ocasiona que el desarrollador no tenga retorno por parte del sistema del trabajo que está haciendo y reduzca mucho su productividad, puesto que la vuelta atrás en caso de error puede venir muy tarde.
Existen soluciones como hacer un buen diseño en profundidad, pero el trabajo del desarrollador sigue siendo principalmente creativo y un diseño no puede cubrirlo todo. Otras alternativas más adecuadas y elegantes son el uso de pruebas unitarias de restrinjan el alcance y ámbito a probar al punto de desarrollo en que nos encontramos. Su ejecución es mucho más sencilla y rápida que el despliegue y ejecución de toda la solución y nos pueden estar dando feedback incluso en segundo plano mientras desarrollamos. Pero el desarrollo de estas pruebas unitarias, de los conjuntos de datos para lanzarlas y de los mockup necesarios para emular las situaciones a probar requieren un tiempo de desarrollo para nada despreciable y muchas veces análogo al de la solución en ciernes. Es en este punto donde se centra la solución propuesta por Bret, que sea la plataforma la que provea de mecanismos rápidos para la definición en el propio código del alcance de la prueba unitaria y para establecer la condiciones de entorno de la prueba (parámetros de entrada, estado del aplicativo y respuesta esperada). Una idea que mejoraría muchísimo la productividad de los entornos de desarrollo.
Un saludo,
Esta entrada de Juan Francisco Adame Lorite está bajo una licencia Creative Commons Atribución-CompartirIgual 3.0 Unported.
Bytes & Chips 