Developing Frogtek

El blog del Departamento de Tecnología

Autor: Guillermo Caudevilla (página 2 de 7)

Buscando un diseñador UX para unirse al equipo de producto en México

Os copio aquí lo que hemos publicado en el blog corporativo, ¡si algún lector de este blog se anima a hacer las américas no tiene más que decirlo!

We have a small and multi-disciplinary product team that is very focused on data and is led by our founder David (that’s me!). Our goal is to make the shopkeeper successful, generating more profits in her store by following the advice from the Tiendatek Coach (every star needs a coach!). We therefore need to understand really well the way a shopkeeper thinks and build a flawless and smooth experience for her. As with other aspects of our business, we aim to work as professionally as any startup in the Silicon Valley but it is key that to keep our mission at heart.
The UX Designer will help us drive the product forward by developing a deep understanding of how a shop works and how their first computer (our tablet) can help it work better. This key role will define workflows, build wireframes for rapid prototyping and run usability tests. The job is more about designing fluid interfaces than pretty ones. The challenge is to design a tool that becomes the shopkeeper’s second hand on a mobile computer that is used all day long, ensuring the many required features still feel simple and intuitive. You need to create emotions in our users and make them feel at home. And you will strive for perfection at all phases of the design process, from the initial conception and quick validation all the way through the implemented code running on shops’ tablets.
If you want to take on such a challenge or can think of someone that would, please drop us a line! You can check the full job description here.

¡Saludos!

Procesos de selección (actualización)

A mediados de diciembre lanzábamos en Frogtek un proceso de selección de dos ingenieros con experiencia y un becario de formación como programador, a finales de enero a esas ofertas uníamos la de la beca de formación como científico de datos. En total cuatro personas para reforzar nuestro equipo de desarrollo y empezar a edificar nuestro equipo de datos.

Ya hemos llegado a un acuerdo con dos personas que se incorporarán como ingenieros al grupo en los próximos días, siguen, sin embargo disponibles las becas de formación. Os recordamos los detalles:

BECA – PROGRAMADOR JUNIOR:

Ofrecemos para la oficina de Huesca, en Walqa, una beca de formación de un año, con altas posibilidades de incorporación a su finalización, el comienzo de la beca sería inmediato.

Requisitos exigidos:

  • Estudiante de los últimos tres años o de postgrado o a falta del proyecto fin de carrera de las universidades de Zaragoza o San Jorge.
  • Programador con buena base de programación, con conocimientos de programación orientada a objetos.
  • Con potencial, motivado y con ganas de aprender.
  • Alto nivel de inglés.
  • Inteligencia, curiosidad, meticulosidad y atención a los detalles.
  • Ganas de trabajar en una start-up y poca aversión al riesgo.
  • Facilidad para la comunicación y el trabajo en equipo.

Se valorará conocimientos o interés en alguna/s de las siguientes áreas:

  • Conocimientos en tecnologías web HTML, JavaScript, CSS, jQuery.
  • Conocimientos de Java y/o Android.
  • Conocimientos de Cloud Computing, en especial Google App Engine.
  • Conocimientos en Big Data y bases de datos.
  • Conocimientos de metodologías ágiles y programación extrema.
  • Haber realizado un Erasmus.
Tareas:
  • Integración en el ciclo de vida de desarrollo de producto de Frogtek junto con el resto del equipo
  • Desarrollo de nuevas funcionalidades y soporte técnico para validación de hipótesis de negocio (filosofía lean startup)
  • Programación XP: TDD, revisión de código, pair-programming, integración continua…

Se ofrece:

  • Beca del IAF/Walqa
  • Involucrarse en un proyecto social.
  • Grandes posibilidades de desarrollo, aprenderás Android, Cloud Computing, Big Data y programación extrema entre otras muchas cosas.
  • Formar parte de una empresa joven usando las metodologías y tecnologías de desarrollo más avanzadas.
  • Horario flexible, posibilidad de realizar parte en teletrabajo y buen ambiente.
  • Experiencia internacional y multicultural
  • Posibilidades reales de incorporación como empleado al finalizar la beca en función de la valía y la disponibilidad de la empresa.
**********************************

BECA  DE FORMACIÓN COMO CIENTÍFICO DE DATOS:

Ofrecemos para la oficina de Huesca, en Walqa, una beca de formación de un año, con altas posibilidades de incorporación a su finalización, el comienzo de la beca sería inmediato.

Requisitos exigidos:

  • Estudiante de los últimos tres años o de postgrado o a falta del proyecto fin de carrera de las universidades de Zaragoza o San Jorge.
  • Licenciado o grado (o cursando) en Empresariales o Económicas, Matemáticas, Estadística, Ingeniero…
  • Amante de la tecnología.
  • Amante de los datos y de las matemáticas.
  • Conocedor del mundo de la empresa (inventarios, demanda-oferta, elasticidades, gestión de costos y precios, márgenes, categorización de productos…)
  • Con potencial, motivado y con ganas de aprender.
  • Alto nivel de inglés.
  • Inteligencia, curiosidad, meticulosidad y atención a los detalles.
  • Proactividad y autonomía.
  • Ganas de trabajar en una start-up y poca aversión al riesgo.
  • Facilidad para la comunicación y el trabajo en equipo.
  • Disponibilidad para viajar y hacer estancias en otros países.

Se valorará positivamente conocimientos o interés en alguna/s de las siguientes áreas:

  • Herramientas estadísticas (SPSS, programación en R…)
  • Herramientas de procesado matemático (MATLAB, Mathematica…)
  • Dominio avanzado de Excel
  • Conocimientos en Big Data y bases de datos (mySQL)
  • Herramientas de BI (QlikView)
  • Conocimiento de algoritmos matemáticos de aplicación a la empresa

Tareas:

  • Ayudarnos a entender mejor a nuestros tenderos
    • Cuánto venden y cuánto ganan por mes y qué márgenes manejan
    • Cuáles son sus principales suministradores y categorías de productos
  • Ayudarnos a mejorar nuestra proposición de valor al tendero
    • Motor de comparación de precios entre proveedores
    • Motor de recomendación de productos y precios
    • Mejora de algoritmos de predicción de ventas y adivinación de precios
  • Trabajar con el equipo de BI de México para crear y mejorar informes de mercado para fabricantes y tiendas
    • Incluyendo alertas para tiendas en peligro
    • Mecanismos para evitar el sobre e infra estocaje

Se ofrece:

  • Beca del IAF/Walqa, cantidad de la beca a convenir
  • Involucrarse en un proyecto social.
  • Enormes posibilidades de desarrollo, al ser mentorizado por profesores de la Universidad de Zaragoza y expertos mundiales en el tema.
  • Formar parte de un proyecto puntero a nivel mundial que está recibiendo los más altos reconocimientos (menciones en el MITpremios de Vodafone en el NewYork Times…)
  • Horario flexible, posibilidad de realizar parte en teletrabajo y buen ambiente.
  • Experiencia internacional y multicultural en un equipo de alto rendimiento liderado por graduados de universidades como Columbia y Harvard.
  • Altas posibilidades de incorporación como empleado al finalizar la beca en función de la valía y la disponibilidad de la empresa.
  • Formación en el que va a ser uno de los perfiles más demandados en el futuro, el científico de datos.
Interesados mandar correo a guillermo arroba frogtek punto org, incluir si se opta la beca de datos o a la de programación.

Beca de formación como Científico de Datos

Como ya sabéis los que nos leéis periódicamente en este blog, Frogtek empezó siendo una empresa con un producto basado en Android, producto que se vende a tenderos en países emergentes y del tercer mundo, para que éstos lleven la contabilidad y operen de forma más eficiente pero que además se usa para recabar datos de todo lo que se compra y se vende en estos mercados, datos que se procesan, elaboran y venden a grandes empresas fabricantes de productos. Es decir, Frogtek es, en el fondo, una empresa de big data que está dando sus primeros pasos en el mundo de los datos en 2013.

En enero de 2013 hemos registrado cerca de 550,000 ventas en nuestra red, número que crece mes a mes y que en el último año hemos multiplicado por diez. Disponemos de una base de datos con todos los productos, nivel de inventario, costos, precios, compras y ventas de todas las tiendas de nuestra red. Se trata de datos de enorme valor para todas las entidades que participan en la cadena de distribución de productos en estos países, datos que se actualizan en tiempo real y que pueden revolucionar el funcionamiento de fabricantes, distribuidores y pequeñas tiendas.

En México ya estamos trabajando con algunas de las grandes marcas del mercado por todos conocidas para poner en valor la información que estamos atesorando. Para ello nuestro departamento de tecnología ha desplegado en los últimos meses una herramienta  de BI (Business Inteligence) como QlikView sobre nuestra principal base de datos.

Además contamos con la impagable ayuda del departamento de Contabilidad y Finanzas de la Universidad de Zaragoza con quienes hemos empezado a trabajar en 2012 generando algoritmos que usando nuestros datos ayuden al tendero en su vida diaria, por ejemplo aconsejándole sobre cuánta cantidad comprar de cada producto o adivinando el precio de los productos que inventaría para que no tenga que introducirlo manualmente.

Necesitamos reforzar nuestro conocimiento de los datos y necesitamos dedicar más tiempo y esfuerzo a bucear en ellos, es por esto que queremos crear un perfil distinto en nuestro departamento de tecnología y producto en Huesca: el del científico de datos.

Ofrecemos una beca de formación de un año, dentro del equipo de tecnología y producto de Frogtek y mentorizado por el profesor Carlos Serrano de la Universidad de Zaragoza. Los detalles:

*******************************

BECA  DE FORMACIÓN COMO CIENTÍFICO DE DATOS:

Ofrecemos para la oficina de Huesca, en Walqa, una beca de formación de un año, con altas posibilidades de incorporación a su finalización, el comienzo de la beca sería inmediato.

Requisitos exigidos:

  • Estudiante de los últimos tres años o de postgrado o a falta del proyecto fin de carrera de las universidades de Zaragoza o San Jorge.
  • Licenciado o grado (o cursando) en Empresariales o Económicas, Matemáticas, Estadística, Ingeniero…
  • Amante de la tecnología.
  • Amante de los datos y de las matemáticas.
  • Conocedor del mundo de la empresa (inventarios, demanda-oferta, elasticidades, gestión de costos y precios, márgenes, categorización de productos…)
  • Con potencial, motivado y con ganas de aprender.
  • Alto nivel de inglés.
  • Inteligencia, curiosidad, meticulosidad y atención a los detalles.
  • Proactividad y autonomía.
  • Ganas de trabajar en una start-up y poca aversión al riesgo.
  • Facilidad para la comunicación y el trabajo en equipo.
  • Disponibilidad para viajar y hacer estancias en otros países.

Se valorará positivamente conocimientos o interés en alguna/s de las siguientes áreas:

  • Herramientas estadísticas (SPSS, programación en R…)
  • Herramientas de procesado matemático (MATLAB, Mathematica…)
  • Dominio avanzado de Excel
  • Conocimientos en Big Data y bases de datos (mySQL)
  • Herramientas de BI (QlikView)
  • Conocimiento de algoritmos matemáticos de aplicación a la empresa

Tareas:

  • Ayudarnos a entender mejor a nuestros tenderos
    • Cuánto venden y cuánto ganan por mes y qué márgenes manejan
    • Cuáles son sus principales suministradores y categorías de productos
  • Ayudarnos a mejorar nuestra proposición de valor al tendero
    • Motor de comparación de precios entre proveedores
    • Motor de recomendación de productos y precios
    • Mejora de algoritmos de predicción de ventas y adivinación de precios
  • Trabajar con el equipo de BI de México para crear y mejorar informes de mercado para fabricantes y tiendas
    • Incluyendo alertas para tiendas en peligro
    • Mecanismos para evitar el sobre e infra estocaje

Se ofrece:

  • Beca del IAF/Walqa, cantidad de la beca a convenir
  • Involucrarse en un proyecto social.
  • Enormes posibilidades de desarrollo, al ser mentorizado por profesores de la Universidad de Zaragoza y expertos mundiales en el tema.
  • Formar parte de un proyecto puntero a nivel mundial que está recibiendo los más altos reconocimientos (menciones en el MIT, premios de Vodafone en el NewYork Times…)
  • Horario flexible, posibilidad de realizar parte en teletrabajo y buen ambiente.
  • Experiencia internacional y multicultural en un equipo de alto rendimiento liderado por graduados de universidades como Columbia y Harvard.
  • Altas posibilidades de incorporación como empleado al finalizar la beca en función de la valía y la disponibilidad de la empresa.
  • Formación en el que va a ser uno de los perfiles más demandados en el futuro, el científico de datos.

Interesados enviad CV actualizado a guillermo arroba frogtek punto org

Se buscan ingenieros

En las próximas semanas, aparte de disfrutar de los turrones, queremos incorporar en Frogtek dos tres nuevos ingenieros, uno dos con cierta experiencia y otro interesado en obtenerla mediante una beca de formación, todos con la idea de integrarse y reforzar el equipo de desarrollo de producto de Huesca. Éstas son las ofertas:

EMPLEADO – INGENIERO PROGRAMADOR:

Ofrecemos para la oficina de Huesca, en Walqa, un dos puestos de ingeniero programador, incorporación inmediata.

Requisitos exigidos:

  • Programador con buena base de programación, con conocimientos de programación orientada a objetos y experiencia profesional en el campo de los dispositivos móviles.
  • Con potencial, motivado y con ganas de aprender.
  • Alto nivel de inglés.
  • Inteligencia, curiosidad, proactividad, meticulosidad y atención a los detalles.
  • Ganas de trabajar en una start-up y poca aversión al riesgo.
  • Facilidad para la comunicación y el trabajo en equipo.

Se valorará conocimientos y experiencia en alguna/s de las siguientes áreas:

  • Tecnologías web, HTML, JavaScript, Jquery, Django, CSS.
  • Conocimientos de Java y/o Android.
  • Conocimientos de  C++ y Linux, programación de drivers.
  • Conocimientos de Cloud Computing, en especial Google App Engine (Python) o Amazon WS.
  • Conocimientos de metodologías ágiles y programación extrema: Scrum, TDD.
  • Experiencia en entornos que hayan aplicado Contabilidad de la Innovación.
  • Conocimientos de Business Intelligence: QlikView.
  • Experiencia con bases de datos relacionales (MySQL) y no relacionales (Google Big Table).
  • Experiencia en BigData.
  • Conocimientos como administrador de sistemas en entornos de integración continua: JENKINS, MAVEN…
  • Experiencia en Usabilidad de dispositivos móviles.
  • Experiencia internacional.

Tareas:

  • Integración en el ciclo de vida de desarrollo de producto de Frogtek junto con el resto del equipo
  • Desarrollo de nuevas funcionalidades y soporte técnico para validación de hipótesis de negocio (filosofía lean startup)
  • Programación XP: TDD, revisión de código, pair-programming, integración continua…

Se ofrece:

  • Sueldo a negociar.
  • Interesante paquete de acciones.
  • Involucrarse en un proyecto social.
  • Grandes posibilidades de aprendizaje y desarrollo avanzado.
  • Formar parte de una empresa joven usando las metodologías y tecnologías de desarrollo más avanzadas.
  • Horario flexible, posibilidad de realizar parte en teletrabajo y buen ambiente.
  • Experiencia internacional y multicultural

*******************************

*******************************

BECA – PROGRAMADOR JUNIOR:

Ofrecemos para la oficina de Huesca, en Walqa, una beca de formación de un año, con altas posibilidades de incorporación a su finalización, el comienzo de la beca sería inmediato.

Requisitos exigidos:

  • Estudiante de los últimos tres años o de postgrado o a falta del proyecto fin de carrera de las universidades de Zaragoza o San Jorge.
  • Programador con buena base de programación, con conocimientos de programación orientada a objetos.
  • Con potencial, motivado y con ganas de aprender.
  • Alto nivel de inglés.
  • Inteligencia, curiosidad, meticulosidad y atención a los detalles.
  • Ganas de trabajar en una start-up y poca aversión al riesgo.
  • Facilidad para la comunicación y el trabajo en equipo.

Se valorará conocimientos o interés en alguna/s de las siguientes áreas:

  • Conocimientos en tecnologías web HTML, JavaScript, CSS, jQuery.
  • Conocimientos de Java y/o Android.
  • Conocimientos de Cloud Computing, en especial Google App Engine.
  • Conocimientos en Big Data y bases de datos.
  • Conocimientos de metodologías ágiles y programación extrema.
  • Haber realizado un Erasmus.
Tareas:
  • Integración en el ciclo de vida de desarrollo de producto de Frogtek junto con el resto del equipo
  • Desarrollo de nuevas funcionalidades y soporte técnico para validación de hipótesis de negocio (filosofía lean startup)
  • Programación XP: TDD, revisión de código, pair-programming, integración continua…

Se ofrece:

  • Beca del IAF/Walqa 810€/mes
  • Involucrarse en un proyecto social.
  • Grandes posibilidades de desarrollo.
  • Formar parte de una empresa joven usando las metodologías y tecnologías de desarrollo más avanzadas.
  • Horario flexible, posibilidad de realizar parte en teletrabajo y buen ambiente.
  • Experiencia internacional y multicultural
  • Posibilidades reales de incorporación como empleado al finalizar la beca en función de la valía y la disponibilidad de la empresa.

Para más información o para enviar CV y participar en el proceso de selección enviad un correo electrónico a guillermo arroba frogtek punto org.

¡¡Gracias!!

¿Para qué sirve ser ágil en una start-up?

Mucho agile, mucho agile… pero si te descuidas puedes acabar en una empresa en la que lo único agile es el motor y para de contar, más cuando el equipo de producción, como en nuestro caso, está aislado del resto o directamente, como pasa en las consultoras, no hay resto. Ésta es un poco la conclusión que he obtenido tras leer los libros “Lean Start-up Method” de Eric Ries, “The four steps to the epiphany” de Steve Blank y después de conocer un poco el mundillo éste del agilismo en España… y por experiencia propia, por qué no decirlo.

Supongo que en parte es porque el mundo del software ibérico está principalmente orientado a programar para terceros y en ese caso ser ágil es “tan fácil” (y tan difícil) como pegarte unos años hasta que haces scrum, tdd y demás como Dios manda y conseguir que el cliente acuda a las reuniones y se involucre en el proceso de cada sprint. Pero la realidad es que detrás de los métodos ágiles hay mucho más y es algo de lo que no se oye hablar demasiado. Hace mucho que no acudo a ninguna AOS, ni CAS (siempre me coinciden con algo que no puedo dejar para otro momento), pero la primera CAS a la que acudí (2010) me encantó, sabíamos tan poco de métodos ágiles que cada charla era un nuevo mundo de conocimientos y posibilidades. Desde entonces si no yo, siempre alguien de Frogtek ha acudido a estos eventos y trasladado lo que allí ha aprendido. Últimamente, sin embargo, me empezó a sorprender que si bien toda la comunidad está muy interesada en ser técnicamente ágiles, no parece haber tanta ebullición, o al menos yo no la he detectado, una capa por encima de eso. Está bien tener un método de producción iterativo-incremental, está bien ofrecer al cliente (que muchas veces no es el usuario final, desgraciadamente) un proceso súper adaptable a sus cambios de humor y requisitos… pero estaría mejor dotarnos de los procesos, que tiene que haberlos, para utilizar este gran método para crear el producto que el usuario final necesita. Para ello no basta con que el equipo de desarrollo sea ágil, hay que aprovechar esa agilidad para que los equipos de marketing y ventas (o el product owner, o los encargados de desarrollo de cliente, o quien sea) puedan, a su vez, realizar sus propios experimentos, implementar sus propias métricas y tener sus propios objetivos iterativos e incrementales que nada tengan que ver con el desarrollo y sí con el negocio. Por eso, echo de menos, conceptos que Ries maneja en su libro como “indicadores vanidosos”, “indicadores accionables”, “análisis de cohortes”, “contabilidad de la innovación“… conceptos sin los que scrum, tdd, los sprints y todo lo demás no sirven más que para tener un proceso de desarrollo flexible y adaptable… lo cual no tiene porqué evitar que se acabe construyendo de forma eficiente y completamente flexiblemente un producto totalmente inútil. Supongo que, en España, el principal problema es precisamente que no existen muchas start-ups y hay, sin embargo, demasiadas factorías de software… y en una factoría de software es difícil vislumbrar nada más allá de lo técnico (por no hablar ya de meter baza) y suficiente se tiene con lidiar con el cliente.

Frogtek no es una software factory pero también hemos sufrido en parte ese problema. Tras varios años de trabajo teníamos un equipo de tecnología muy “agile” y muy “kaizen” que implementaba las “ocurrencias” de la empresa de manera eficiente y puntual. Ocurrencias, dicho en el mejor de los sentidos y con todo el cariño, que trataban de ser lo más meditadas posible y que suponíamos beneficiosas para los tenderos y que, lo fueran o no permanecían en el producto sine die. El problema de esta aproximación es que no es todo lo científica que debería ya se basa en asunciones que habría que comprobar, pero que rara vez se comprueban, por falta de tiempo y de proceso principalmente. No basta con implementar User Stories por muy bien definidas que estén, el cementerio está lleno de productos técnicamente impecables. Para solucionar esto en Frogtek vamos a utilizar una capa más de abstracción, basada en Épicas, que iría sobre los sprints de User Stories. Una Épica no es más que un objetivo del product owner para un sprint determinado. Algo así como el objetivo estratégico de alto nivel de mejorar el indicador X de la empresa en un x% (p.e. “hay que conseguir que el 80% de los tenderos levanten su inventario en menos de 2 horas”). Muchas veces, este tipo de mejoras no es cuestión de una sola User Story es, más bien y por limitarlo al producto, un conjunto de historias (“el producto debe adivinar los precios”, “el producto debe adivinar los costes”, “el producto debe proponer los productos más comunes”, “el interfaz debe cambiar así o asá”…) que se pueden desarrollar durante un sprint (de forma ágil, claro), la diferencia con nuestra aproximación pasada es que terminado el sprint el trabajo del product owner no ha hecho más que empezar y a la vez que se empieza a pensar en el sprint siguiente, tiene que echarle un ojo al indicador asociado a la Épica del sprint pasado con el objeto de aprender si los cambios en el producto están teniendo el efecto deseado en el comportamiento real de los usuarios o, por el contrario, no han servido para nada y se necesitan más cambios (volver a iterar).

 

El trabajo del product owner se complica, ya que como se ve en el dibujo el contenido del sprint N empieza a analizar incluso antes de que empiece el sprint N-1.  La secuencia es la siguiente:

  1. Recoger indicadores.
  2. Analizar indicadores y Épicas en evaluación para decidir los objetivos (creando nuevas o modificando Épicas).
  3. Desglosar las Épicas en historias de usuario.
  4. Preparar la historias de usuario (mock-ups, pruebas de usabilidad con clientes, más mock-ups…).
  5. Estimar historias de usuario.
  6. Ejecutar el sprint (incluyendo pruebas, instalación en friendly users, etc).
  7. Instalar nueva versión en usuarios.
  8. Vuelta a 1.

Normalmente los indicadores a recoger y analizar necesitan un tiempo hasta que se generan, al menos en nuestro caso, así que no será extraño que las Épicas que se evalúen en un momento dado se hayan implementado hace dos, tres o más sprints. Por lo tanto el PO, no sólo tiene que estar pendiente del sprint actual sino que tiene que pensar en las Épicas (objetivos estratégicos del producto) que querrá definir para el sprint siguiente, mientras que monitoriza meticulosamente los indicadores asociados a las Épicas que están ahora mismo en evaluación y que pueden seguir así por uno o varios sprints. Porque una Épica, como una User Story, tiene un ciclo de vida ¡e incluso su propia tabla! (se proponen, se discuten, se diseñan, se implementan, se evalúan y si están bien se archivan, muy propio para una tabla de kanban) pero a diferencia de una User Story la evaluación no depende de factores meramente técnicos, si no que es función del valor que aporte al usuario final (si está bien definida y si se monitoriza usando datos reales). El paralelismo con las User Stories también tiene otras ventajas, se puede medir el throughput en Épicas de un equipo, es decir, la velocidad de la empresa para poner hipótesis a prueba y aprender de la realidad, concepto directamente relacionado con las posibilidades de la empresa de sobrevivir.

Al final como en muchos aspectos de la vida, se pueden extraer unas cuantas enseñanzas muy interesantes: No llega más lejos la empresa que hace más User Stories, sino la que hace User Stories como consecuencia del aprendizaje validado de otras User Stories. Es importante tener un framework de gestión del trabajo ágil, pero más importante es integrar en el proceso de producción herramientas de medida como Google Analytics o Flurry que permitan obtener información sobre la utilización de las distintas funciones y que permitan discriminar entre distintos grupos de usuarios con distintas versiones para poder relacionar causas y efectos usando el análisis de cohortes (¿a los usuarios de la versión x+1 les ha ido mejor que los de la version x?). Así que ahí estamos en Frogtek, peleándonos, como buenos novatos, con Analytics y con nuestras propias métricas, discutiendo las métricas que debemos aplicar a las Épicas y tratando de encajar su ciclo de vida con el de definición e implementación de los sprints. Este post, más que una realidad, es una declaración de intenciones acerca de lo que queremos hacer para conseguir ser una “agile data-driven company” para lo cual es necesario ser ágil pero, visto lo visto, no suficiente.

Frogtek se alía con Kiva para financiar TiendaTeks

Hoy no vamos a hablar de tecnología, ni de organización de equipos. Vamos a hablar de algo bastante distinto.

Como todos sabéis Frogtek trata de llevar la última tecnología a las pequeñas tiendas de países emergentes y del tercer mundo. Pues bien, una de las preguntas que más nos hacen es la siguiente ¿cómo paga un tendero de México o de Ghana una tableta Android de última generación?. La respuesta no es fácil.

Para empezar, tratando de que la última tecnología sea lo más asequible posible.  Para ello en el departamento de tecnología nos hemos esforzado y nos seguimos esforzando en buscar tecnología de bajo coste que pueda funcionar con nuestro software. A menudo eso supone rastrear el mercado asiático en busca de la última tableta que tiene todo lo que necesitamos (que no es poco) a un precio razonable, lo mismo con impresoras, lector de códigos de barras y lectores de tarjeta magnética. Afortunadamente esto, que al principio era infernal (teléfonos que se ponen en chino al quedarse sin batería y otras lindezas por el estilo) es ahora algo más sencillo. Otras veces se trata de exprimir al máximo las posibilidades técnicas del hardware que nos llega, descendiendo al nivel del sistema operativo para poder crear nuestros propios drivers USB y deshacernos de los periféricos basados en bluetooth que eran mucho más caros.

Pero sólo con hardware barato y bien utilizado no es suficiente. Hemos tenido que explorar otras opciones más del mundo financiero. ¿Cómo podemos hacer para que el tendero pueda permitirse adquirir TiendaTek?. Resulta obvio pensar en ofrecer al cliente una vía de financiación, la posibilidad de pagarlo a plazos pero ¿quien financia todo eso?. Frogtek no tiene dinero suficiente para adelantar el coste de cientos o miles de tabletas, impresoras, lectores para luego esperar pacientemente a que los tenderos plazo a plazo vaya pagando. Existen otras opciones, muchas de ellas las hemos explorado o las estamos explorando: conseguir que una gran empresa interesada financie a nuestros tenderos, conseguir que un fondo de impacto compre las tabletas por nosotros y nos las preste para venderlas que ya le devolveremos el dinero conforme lo vayamos recuperando, colaborar con una microfinanciera que ofrezca sus créditos en la base de la pirámide para que los tenderos puedan invertir en una herramienta de productividad como la nuestra.

Todo esto y mucho más son los quebraderos de cabeza que parte de nuestro equipo tiene para conseguir que esta aventura de Frogtek sea, no sólo sostenible y viable, sino también escalable. Hoy estamos muy contentos de anunciar que una de las opciones en las que hemos trabajado ha visto la luz, de una forma muy bonita, porque hemos llegado a un acuerdo con una “micro-financiera” pero no cualquier micro-financiera, hemos llegado a un acuerdo con Kiva. A partir de ahora tenderos que quieran adquirir TiendaTek para su negocio en México se empezarán a anunciar en Kiva para obtener el dinero necesario y lo precioso del caso es que serán otras personas a miles de kilómetros las que  prestarán ese dinero directamente. Porque Kiva es una de las principales plataformas de crowd-funding, o lo que es lo mismo, sirve para que cualquier persona preste unos pocos euros a gente que lo necesita para financiar sus humildes proyectos, para que muchos pocos hagan un gran mucho. La tecnología consigue lo que hasta hace bien poco era totalmente inviable, que tú y que yo con 25€ podamos ayudar directamente a una persona a miles de km a conseguir un préstamo para invertir en algo que mejore su vida.

Lo curioso del caso, además, es que el equipo de Huesca lleva ya muchos meses invirtiendo el dinero del bote del cerdito en emprendedores anónimos de Kiva. Ahora tendremos la oportunidad de cerrar el círculo, invirtiendo lo que obtenemos de nuestras pifias en los tenderos para los que trabajamos.

Así que tenemos el placer de anunciar que nuestra primera cliente en Kiva es Ana Karen y ójala sea la primera de muchas.

Avances en burn-down charts: la “burn-up-down” chart

Hacemos Scrumban y eso nos ha obligado a hacer alguna que otra cosa curiosa. Una de ellas consistía en tener dos gráficas el burn-down para nuestras historias de Scrum (las planificadas) y el burn-up para nuestras historias de Kanban (las no planificadas). Básicamente se trataba de poner un objetivo de historias planificadas y una especie de tope a las historias no planificadas… planificar el trabajo que te va a llegar de forma no planificada tiene algo de absurdo, pero se puede hacer. No hay que medir el pasado y esperar que el futuro se comporte. Tener dos gráficas resulta un poco incómodo, aunque no es un gran problema. Reservar ya desde el principio una parte de tu ancho de banda a Kanban denota que tenemos unos POs un poco “volubles”. Tampoco pasa nada.

En cualquier caso en la última vuelta de tuerca a nuestro sistema hemos decidido superponer ambas gráficas para así poder saber de un vistazo cómo va el Sprint independientemente de haya habido mucho o poco Kanban. Aquí os pongo un ejemplo de nuestra “burn-up-down chart”:

En este caso la línea azul señala el ritmo ideal de completado de US de Scrum del Sprint. En rojo vemos la realidad, como la parte de Scrum lleva un pequeño retraso; en amarillo el Kanban real, las historias no planificadas que se han ido terminando. De esta gráfica podemos obtener la siguiente conclusión, la primera semana a pesar de que se acumuló retraso entre las historias planificadas el equipo de desarrollo cumplió con su objetivo (ya que lo que faltó de Scrum se hizo de Kanban), la segunda semana la cosa fue peor.

Al final la manera de leer esta gráfica es sencilla.

  • Si las gráficas amarilla y roja se cortan antes de terminar el Sprint el equipo de desarrollo ha cumplido su objetivo.
  • Cuanto más suba la línea amarilla peor planificación se hizo.

Scrum, Kanban y la matriz de Eisenhower

Érase una vez un Scrum Master que controlaba el proceso Scrumban que un equipo seguía. ¿Le pitan a alguien los oídos?. Dicho de otro modo, para que no se diga que aquí sólo escribimos para los “talibanes agilistas” ;P.

Erase una vez un gestor de un equipo encargado de llevar a cabo tareas planificadas y no planificadas en un periodo de tiempo determinado y cíclico. No sé cual de las dos introducciones es peor.

Érase, también, una vez un Product Owner malvado que no hacía más que meter Kanban en el sprint, haciendo sufrir al Scrum Master y poniendo a prueba la velocidad del equipo. El Scrum Master le insistía al equipo para que no dejara abandonadas las tareas de Scrum, mantuviera una velocidad de Scrum aceptable y consiguiera los objetivos del sprint. Y en estas llegó la retrospectiva y el equipo le afeó al Scrum Master que priorizara el Scrum frente al Kanban, ya que todos son hijos de Dios (del Product Owner en este caso). Así que el Scrum Master se puso a pensar y sacó las siguientes moralejas además de escribir este post.

  • El equipo tiene razón, en teoría, el Kanban es tan válido como el Scrum. La suma de todo nos da la velocidad total del equipo y si los puntos totales al final del sprint son iguales o mayores que los planificados el equipo habrá cumplido con su papel.
  • El Scrum Master también tiene razón, en la práctica, el Product Owner siempre, salvo cambios grandes de requerimientos, espera que todo el Scrum esté acabado en la fecha final de sprint. Si el Scrum se termina, el Scrum Master habrá cumplido con su papel.
  • El hecho de no tener definidos claramente las prioridades del Kanban (FIRE, PRIO, ASAP) puede fomentar estos problemas. El Kanban en Frogtek entra directamente en la pila de producto del sprint y se empieza antes o después en función de lo arriba que entre en la columna. Es decir, es priorizado junto con lo demás (hasta ahí bien), pero luego cuando entra y navega por las diferentes fases no tiene ni más, ni menos prioridad que el resto de lo que está en desarrollo. De ahí que el Scrum Master en algún caso acabe defendiendo lo planificado y el programador quiera que todo se valore por igual, ambos defendiendo su trabajo. Pero ¿debe hacerse?.

Aquí es cuando entra en juego la relación entre las tareas de Scrum, Kanban y la matriz de Eisenhower. Eisenhower se ve que era un tío muy organizado y las malas lenguas dicen que inventó el típico plano cartesiano con cuatro cuadrantes, con un eje señalando la importancia y otro la urgencia. Así tras analizar una tarea en un momento dado podía decidir qué hacer con ella:

  • Urgente e importante. Consejo de Eisenhower: ¡Hazla ya!. Consejo ágil: Normalmente esto es Scrum (en el peor de los casos esto entrará como Kanban de alta prioridad a mitad de sprint pero en ese caso es bastante fácil poner al Scrum Master y al equipo de acuerdo en lo importante que es sacarla la tarea cuanto antes adelante).
  • No urgente pero importante. Consejo de Eisenhower: Planifícala. Consejo ágil: Vuelve a analizarla en la siguiente ronda de planificación y métela como Scrum en el siguiente sprint cuando ya sea urgente e importante.
  • Urgente pero no importante. Consejo de Eisenhower: Delega. Consejo ágil: Normalmente esto es Kanban, ya que su urgencia suele salir a relucir a mitad de sprint y nunca tendrá la importancia suficiente para entrar como Scrum. Este tipo de tareas son las que crean conflicto a veces y las que acaban retrasando los sprints.
  • Ni urgente, ni importante. Consejo de Eisenhower: ¡A la basura!. Consejo ágil: si ves muchas de estas en tu tabla, cambia de Product Owner.

Simplificando un poco se podría asimilar Importante con Scrum y Urgente con Kanban. Es por eso que como Scrum Master creo que Scrum casi siempre debe ir por delante que Kanban. Siendo flexibles, claro. 🙂

Curso de Iniciación a Android en Walqa, Huesca

Si habéis estado atentos al blog os habréis dado cuenta que de arriba, al lado del Disclaimer ha aparecido una nueva sección de nombre “Formación“. No son necesarias demasiadas explicaciones ¿verdad?.

Esto no es nuevo. En Frogtek ya llevamos tiempo dado cursos de Android, pero hemos decidido hacerlo de forma un poco más continua y con el tiempo añadir nuevos cursos con los que nos sintamos cómodos (todos, sin falta, son cursos sobre cosas con las que trabajamos en el día a día).

En este caso ofrecemos un Curso de Iniciación a la programación en Android que vamos a dar en Walqa, estos son los datos:

  • Duración: 25 horas en 5 días.
  • Fechas: Del 26 al 30 de Marzo.
  • Lugar: Sala de formación de AST en Walqa.
  • Precio: 250€
  • Número de alumnos: alrededor de 12.
  • Temario: click aquí.
  • Inscripciones e información sobre el pago: mandando un correo a walqa@ptwalqa.com

¡Os esperamos!.

Feedback público todos con todos

Hacía tiempo que tenía pendiente escribir sobre el feedback en una start-up. El feedback sí, bueno, hablando en cristiano, cuando te dicen las cosas que haces bien y las que no tanto. Un ejercicio de sinceridad que es muy necesario si se quiere mejorar en cualquier entorno, ya sea el trabajo o alguna otra faceta de la vida. Necesario pero incómodo. No siempre resulta fácil que tu jefe o que uno de tus compañeros resalte esas cosas que haces mal ya sea en privado en incluso en público.

Es por eso que alrededor del feedback hay mucho… ¿cómo decirlo?, ¿artificio?, ¿tontería?. Una de mis favoritas es esa que dice que para dar una mala noticia primero tienes que dar dos buenas, luego la mala y acabar con otra buena. La técnica del ++-+ (sí, existe, no me lo estoy inventando a mi me la contaron en Vodafone aunque no he encontrado rastro de ella en internet) ó “cómo dar feedback negativo y que nadie salga herido“, imagino que las más de las veces la persona que recibe el feedback entre tanta cháchara no se entera del problema, sí de las alabanzas que lo envuelven y sale de la sesión sin entender nada. Da hasta para un chiste malo:

“Era un programador tan malo, tan malo, tan malo que en lugar de programar en C, programaba en C++-+”.

En fin, antes de que se me aplique directamente el lanzamiento de pomodoro, por el chiste, seguiré con lo del feedback. Al final todo se reduce a acudir a una reunión de esas con actitud constructiva tanto por un lado como por el otro, ser respetuoso y sincero.

El pasado Enero en Frogtek hicimos la primera sesión de feedback pública todos con todos. Consistió en lo siguiente, hacer una ronda en la que primero uno contaba de sí mismo cual era su rol en la empresa, que cosas se le daban bien y qué cosas se le daban mal. A continuación el resto del grupo hacía lo propio con la persona que había iniciado la ronda, es decir contarle cual pensábamos que era su rol, y cuales sus puntos fuertes y sus áreas de mejora. Al acabar la primera ronda una persona había recibido feedback de todo el resto de compañeros sobre su trabajo. Obviamente es importante que el feedback se traiga preparado de casa, ya que de lo contrario en seguida se cae en el “yo lo mismo que fulanito“. De hecho en Frogtek lo trajimos escrito en fichas de forma que al final de cada ronda la persona “objeto de análisis” se hacía con 7+1 (la propia) fichas con un buen surtido de ideas interesantes. Una vez recibido el feedback los “expertos” recomiendan tener a mano a SARAH y no, Sarah no es una encantadora señorita que nos consuele, si no las fases por las que vamos a pasar inevitablemente. A saber:

  • Fase 1: Shock “¿¡pero este tío qué dice!?”
  • Fase 2: Anger “¿¡pero este tío qué dice!?”
  • Fase 3: Resistance “¿¡pero este tío qué dice!?
  • Fase 4: Acceptance “mmmm
  • Fase 5: Help “oye tío, ¿me explicas cómo hacer eso tan bien?”

Después de un buen rato (hay que tomarse su tiempo, este ejercicio se lleva toda una mañana) y de las ocho rondas de rigor. Habíamos intercambiado 64 opiniones todos con todos en un ejercicio que, realizado con buen rollo, honestidad e interés (y con Sarah), resulta muy enriquecedor.

Además, para hacerlo todavía más interesante nosotros le pedimos a todo el mundo que se auto-clasificara y clasificara a sus compañeros de más identificado a menos identificado en las siguientes categorías (basado en el método de los 6 sombreros):

  • Orientación cooperadora (verde)
  • Orientación organizadora (azul)
  • Orientación emprendedora (rojo)
  • Orientación sociable (amarillo)

De forma que al final del día todos descubrimos cómo nos veíamos a nosotros mismos y cómo nos veía el resto del equipo. Afortunadamente en Huesca tenemos un equipo multicolor en el que no falta de nada.

Antiguas entradas Recientes entradas