Developing Frogtek

El blog del Departamento de Tecnología

Oferta programador Android Senior (ABIERTA)

SOBRE NOSOTROS
El Grupo Frogtek es una empresa social con ánimo de lucro cuyo propósito es iluminar con información el canal tradicional para hacerlo más competitivo (y de paso ayudar a los tenderos de países emergentes y del tercer mundo a competir en mejores condiciones). Lo hacemos, principal aunque no únicamente, ofreciendo una aplicación Android que el tendero puede usar para gestionar y optimizar su negocio, y sostenemos el proyecto a través de la venta estudios de mercado basados en los datos de ventas de los tenderos que almacenamos y procesamos en nuestros servidores en Google y en Amazon.

Nuestra empresa es global y trabaja de forma distribuida. Las operaciones de venta, formación y soporte a tenderos están en México pero la creación de tecnología se ha hecho hasta la fecha en España aunque cada día más trabajamos en remoto y es menos importante dónde puedas estar. Buscamos una persona que venga a reforzar al equipo de tecnología y nos ayude a dar un salto de calidad.

RESPONSABILIDADES
– Mantener y evolucionar nuestra principal app Android/Web para gestionar pequeñas tiendas.
– Crear otras soluciones Android/Web para tenderos que fomenten y faciliten la recolección, procesado y explotado de datos.
– Participar en las iniciativas de diseño de nuevas soluciones con el resto del equipo de innovación: desde el análisis de problemas y soluciones hasta el prototipado rápido de productos.
– Participar en nuestro proceso de desarrollo de código ya sea para crear nuevas funcionalidades, para optimizar nuestra infraestructura o para resolver incidencias, un trabajo variado que permite tratar con múltiples tecnologías tanto en el lado cliente como en el servidor.
– Colaborar en la definición de objetivos del equipo.
– Desarrollar y/o validar requerimientos.
– Crear, solo o en compañía, código de calidad, legible y cubierto por tests.
– Revisar y leer el código de otros compañeros.
– Probar funcionalidades.
– Colaborar en el despliegue de los productos.
– Asesor técnicamente dentro y fuera del equipo.

CUALIFICACIONES
– Experiencia demostrable con Android
– Conocimientos web y/o Python
– Experiencia con Fabric / crashlytics o similar
– Experiencia con Parse / Firebase o similar
– Material design
– SQLite
– Uso de patrones de diseño (MVP, MVI, MVC…)
– Experiencia en metodologías ágiles (Scrum, Kanban, Scrumban…) y extreme programming (pair programming, TDD…)
– Interés por la mejora continua
– Alto nivel de inglés
– Capacidad para trabajar de manera remota y flexible

OFERTA
– Sueldo en función de experiencia.
– Grandes posibilidades de desarrollo y aprendizaje.
– Integración en un equipo dinámico, sin miedo a aprender, cambiar y mejorar.
– Formar parte de un proyecto puntero a nivel mundial
– Horario flexible (aunque hay que reservar un rato para solaparnos con México todos los días).
– Entre 80% y 100% de tele-trabajo. Si estás cerca nos vemos en Huesca un día a la semana, si no una semana al trimestre.
– Buen ambiente.
– Experiencia internacional y multicultural… y si te gusta viajar quizá puedas visitar México o algún otro país.

Si te interesa tener una primera entrevista con nuestro equipo, por favor envíame un mensaje y CV actualizado a guillermo arroba frogtek punto org

Oferta Ingeniero de Datos (ABIERTA)

Job description

Rol: Ingeniero de Datos

Industria: Retail Technology

Localización: España (remoto)

Salario: En función de experiencia

——————-

SOBRE NOSOTROS

El Grupo Frogtek es una empresa social con ánimo de lucro cuyo propósito es iluminar con información el canal tradicional para hacerlo más competitivo (y de paso ayudar a los tenderos de países emergentes y del tercer mundo a competir en mejores condiciones). Lo hacemos, principal aunque no únicamente, ofreciendo una aplicación Android que el tendero puede usar para gestionar y optimizar su negocio, y sostenemos el proyecto a través de la venta estudios de mercado basados en los datos de ventas de los tenderos que almacenamos y procesamos en nuestros servidores en Google y en Amazon.

Nuestra empresa es global y trabaja de forma distribuida. Las operaciones de venta, formación y soporte a tenderos están en México pero la creación de tecnología se ha hecho hasta la fecha en España aunque cada día más trabajamos en remoto y es menos importante dónde puedas estar. Buscamos una persona que venga a reforzar al equipo de tecnología y nos ayude a dar un salto de calidad.

RESPONSABILIDADES

Como Ingeniero de Datos de Frogtek éstas son algunas de las actividades que te podrían ser encomendadas:

  • Responsabilizarse de la ejecución del proceso punta a punta de adquisición, limpieza, transformación y entrega de datos (ETL) en tiempo y forma.
  • Asegurar la escalabilidad del proceso, liderar una estrategia para su evolución futura.
  • Estudiar la calidad y completitud de los datos priorizando acciones para la mejora de ambos parámetros.
  • Gestionar un pequeño equipo de extracción y tratamiento de datos.
  • Extraer y analizar datos ad-hoc, también, personalmente.
  • Co-liderar el equipo de Algoritmos y Machine Learning.
  • Gestionar la relación con el equipo técnico de partners y clientes con contactos frecuentes y periódicos.
  • Gestionar el roadmap trimestral del equipo de datos, monitorizando su avance y priorizando las tareas.
  • Co-liderar la evolución de la infraestructura tecnológica de la compañía.

CUALIFICACIONES

Éstas son algunas de las habilidades que consideramos claves para poder ser un Ingeniero de Datos en Frogtek:

  • Interés por los datos, facilidad con los datos, datos y más datos. 😉
  • Conocimientos de programación Python-Pandas
  • Conocimientos de R
  • Conocimientos MySQL
  • Experiencia con las plataforma Google App Engine, Google Big Query, AWS EC2 y AWS RDS
  • Soltura con Linux
  • Conocimientos de Scripting (ruby, bash, python)
  • Experiencia en la plataforma de integración continua Jenkins
  • Gestión de la configuración con Chef
  • Experiencia en metodologías ágiles (Scrum, Kanban, Scrumban…) y extreme programming (pair programming, TDD…)
  • Alto nivel resolutivo, capacidad para manejar varias tareas en paralelo
  • Interés por la mejora continua
  • Alto nivel de inglés
  • Capacidad para trabajar de manera remota y flexible

También hay cosas que no conocemos demasiado, o no en profundidad, y nos llaman la atención:

  • Amazon Redshift, etc
  • Amazon Kinesis
  • Spark
  • Scala
  • Hadoop
  • Arquitecturas lambda
  • Cualquier otra tecnología que venga a mejorar lo que ya tenemos

OFERTA

  • Sueldo en función de experiencia.
  • Grandes posibilidades de desarrollo y aprendizaje.
  • Integración en un equipo dinámico, sin miedo a aprender, cambiar y mejorar.
  • 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…) con altas posibilidades de iniciar un crecimiento internacional en los próximos meses.
  • Horario flexible (aunque hay que reservar un rato para solaparnos con México todos los días).
  • Entre 80% y 100% de tele-trabajo, nuestra oficina está en el Parque Tecnológico Walqa, en la encantadora ciudad de Huesca al pie de los espectaculares Pirineos. Si vives cerca nos vemos allí una vez a la semana, si no también podemos hacerte un hueco en nuestros standups virtuales y vernos las caras una semana cada 3 o 4 meses en nuestras reuniones trimestrales.
  • Buen ambiente.
  • Experiencia internacional y multicultural… y si te gusta viajar quizá puedas visitar México o algún otro país.

Si te interesa tener una primera entrevista con nuestro equipo, por favor envíame un mensaje y CV actualizado a guillermo arroba frogtek punto org

Job offer: Product Manager (OPEN)

Role: Product Manager

Industry: Retail Technology

Location: Mexico City or Spain (remote)

Gross Salary: Competitive with market

——————–

ABOUT US

Frogtek is a for-profit social venture that provides technology for small shopkeepers in development markets (abarroteros or tenderos). Our goal is to help tendero families to manage better their business and earn a higher income. We develop our own mobile applications for small shops, designed specifically for customers at the base-of-the-pyramid. We also maintain a platform on the cloud with services for partners like market researches, consumer packaged goods companies and payment providers

RESPONSIBILITIES

If you were to join Frogtek, here are the kinds of things you would do over the course of a typical month:

  • Figure out what technologies shopkeepers in development markets will use to manage better their business. By technologies we mean: hardware, android apps and peripherals
  • Identify shopkeepers needs through a combination of field research, collecting feedback from our field trainers, diving into data, and competitive analysis
  • Translate needs into product prototypes that are easy-to-use and intuitive. Consider that our customer is not technology-savvy
  • Define product vision and strategy, and inspire people with it across the company
  • Build products with our technology department
  • Prioritize product evolution. Manage the backlog of features
  • Ship releases quickly, measure impact through data (mixpanel and research) and iterate again
  • Define metrics for success and failure. Analyze and create dashboards for key metrics.

QUALIFICATIONS

Here are the eight critical things that we consider critical to being the Frogtek Product Manager:

  • Experience: Have led android product initiatives, preferably for base of the pyramid customers
  • Field-orientation: Love to be on the ground, listen to non-technology savvy customers and convert needs into super easy-to-use products
  • Cross-functional: Capable of working with a diverse team of field trainers, psychologists and engineers, you bring all ideas together, build consensus and prioritize
  • Technical: Prototyping tools (e.g. Marvel, A/B testing); Analytics (funnels, retention charts, segmentation charts, etc); UX design for Android; Notions of SQL
  • Data-fanatic: You are used to measure product releases with data and take decisions based on it  
  • Self-motivated: Team player who is able to work in a small and fast-paced environment without much oversight
  • Seamless executor: You plan what you and the team will do, and you are held accountable for it. You hold the team to this standard
  • Education: Academic Background in Computer Science, Engineering, Mathematics, or other technical or analytical fields

Interested candidates please send updated CV to guillermo at frogtek dot org.

Amazon Aurora: primeras experiencias

Este post es un resumen de como ha sido nuestra transición de un MySQL gestionado por nosotros mismos a Amazon Aurora: las cosas que nos han gustado mucho, las que nos han gustado menos, y cómo hemos tenido que cambiar algunos de nuestros procesos para adaptarnos a las particularidades y oportunidades de esta manera de acceder a los datos.

En febrero de 2016 ya había leído algunas cosas sobre Aurora: que era un servicio MySQL compatible, que prometía rendimientos muy superiores, más concurrencia, poder tener copias read only con latencias bajísimas y todo esto sin tener que preocuparte de desplegar instancias EC2 ni configurar servicios. Sonaba bien…Nombro febrero de 2016 porque en ese mes acudí al evento Data Analytics at AWS en Barcelona  y allí nos dijeron que Aurora era el servicio que más rápidamente había crecido en la historia de AWS y toda una suerte de bondades. Está claro que en un evento patrocinado por la empresa que lo desarrolla van a subrayar sus fortalezas frente a sus debilidades, pero con todo y con eso debo confesar que me volví en el tren pensando “y por qué no pasamos de nuestro MySQL y empezamos a usar Aurora”.

Creo que aquí vendría bien dar un poco de contexto. En Frogtek usamos diferentes tecnologías dependiendo de las preguntas que queremos hacer a nuestros datos. Una de ellas es MySQL. Antes de Aurora, teníamos un cluster master slave gestionado por nosotros mismos corriendo sobre instancias EC2. Este escenario cubría una doble necesidad: darnos alta disponibilidad y poder lanzar determinados procesos pesados contra la instancia slave.

Sin embargo este modelo nos causaba algunos problemas:

  • El nodo esclavo fundamentalmente lo usábamos para contestar SELECT pesados sin “molestar” al master. Pero teníamos problemas de sincronización, sufríamos desfases entre los datos que manejaba el master y el slave, algunas veces de minutos. Esto, aunque no era muy común nos generaba incertidumbre y una sensación de “no me puedo fiar de los datos del esclavo” por lo que ese nodo perdía gran parte de su funcionalidad.
  • Debíamos gestionar nosotros las copias de seguridad. Hacerlas, comprobarlas, almacenarlas. No son tareas muy complejas pero llevan tiempo.
  • Debíamos tunear nosotros la base datos.
  • Ocuparnos de la actualización del MySQL y del SO que corría por debajo. Gestionar el tamaño de las particiones, los EBS…

A priori Aurora tendría que solucionarnos estos problemas, así que en marzo del año pasado nos liamos la manta a la cabeza y migramos nuestra infraestructura MySQL a Aurora. El proceso de migración no fue muy doloroso: restauramos una copia de seguridad en Aurora, suscribimos nuestro nodo Aurora al MySQL gestionado por nosotros y cuando comprobamos que todo estaba bien lo promocionamos a master. Antes de hacerlo nosotros a mano, probamos el AWS Database Migration Service  pero no nos acabó de convencer. Seguramente porque cuando lo probamos nosotros estaba en beta, pero las pruebas que hicimos no nos acababan de funcionar bien.

Nuestro Aurora tiene un nodo master y un reader. Al poco de empezar a usarlo se nos presentó el primer problema. El endpoint del cluster no balanceaba automáticamente las peticiones entre nuestros nodos. Realmente no es que funcionara mal, nosotros pensábamos que lo haría y resultó que no, por lo que necesitábamos seguir configurando a mano nuestras aplicaciones para balancearlas. Este comportamiento lo solucionó ya AWS  en septiembre del año pasado y ahora puedes apuntar todo al endpoint del cluster y el solito va mandando las SELECT a alguno de los reader.

Esta son algunas de las cosas que nos han gustado del servicio, se van incluyendo nuevas funcionalidades periódicamente. Por ejemplo, desde que nosotros empezamos a usar Aurora hasta ahora han añadido:

  • Clonado de instancias.
  • Balanceo automático entre instancias.
  • Llamadas a una función de AWS Lambda desde un procedimiento almacenado.
  • Cargar datos desde AWS S3.

La gente de Percona, que inicialmente fueron bastante críticos con Aurora hicieron un test de rendimiento en 2015 y lo repitieron unos meses después y vieron una evolución positiva en el servicio.

Y ya que estamos con lo que nos ha gustado:

  • Servicio 100% gestionado. Dedicamos poquísimo tiempo al mantenimiento de la BBDD. Por ejemplo, la ampliación del disco es automática  y escalar horizontal y verticalmente es realmente sencillo.
  • Antes hacíamos las copias de seguridad con dumps que podían necesitar horas para terminar. Con los snapshot lo hemos reducido a minutos. En las restauraciones ganamos incluso más.
  • Poder levantar una base de datos exactamente igual a la de producción en minutos para poder hacer pruebas.
Pero no todo ha sido bueno, hay cosas que no nos han gustado y que hay que tener en cuenta si migras a Aurora desde un servicio gestionado por ti:
  • No vas a tener el privilegio SUPER de la base de datos. Así que no vas a poder matar conexiones o consultas de otros usuarios. Aurora soluciona eso con CALL mysql.rds_kill(ID) y
    CALL mysql.rds_kill_query(ID).
  • No vas a tener el permiso FILE. Si vas a poder seguir haciendo esto, por ejemplo: “LOAD DATA LOCAL INFILE ‘/home/ficherocarga.csv’” pero no vas a poder hacer un “SELECT * FROM really_big_table INTO OUTFILE ‘fichero’”.
  • Como no tienes acceso al sistema de ficheros que está usando por debajo, hay herramientas de MySQL que no vas a poder usar. Por ejemplo, XtraBackup (aunque si puedes restaurar una copia hecha con esa herramienta en Aurora), sin embargo  podrás seguir usando otras muy útiles como pt-online-schema-change
  • El precio. No es un servicio barato precisamente.

Desde el punto de vista del rendimiento, cuando nos planteamos Aurora, además de quererlo para quitarnos trabajo de gestión de la BBDD queríamos ver si era posible usarlo como base de datos para consultas analíticas sobre tablas de tamaño medio (decenas de millones de tuplas). Típicas consultas con agregaciones más o menos complejas usando ventanas temporales amplias. Vimos que no, que Aurora en este caso de uso no aportaba mucho a lo que ya habíamos vivido con el MySQL gestionado por nosotros. La sensación (confirmada con los test que hicieron en Percona) es que es un servicio que admite mucha concurrencia de consultas y conexiones pero el que una única consulta no va a ser más veloz o mucho más veloz que un MySQL normal. Por lo que nosotros seguíamos teniendo consultas que tardaban horas en finalizar. Cómo resolvimos esto lo contaremos en otro artículo, pero diré a modo de resumen que en nuestro caso Aurora no nos sirvió como BBDD analítica. Además, en este sentido, se echa de menos que la implementación SQL de Aurora no incluya, por ejemplo, funciones de ventana.

En definitiva,  estamos contentos con la decisión que tomamos. Nos ha ahorrado mucho tiempo en tareas de gestión y sobre todo nos ha dado tranquilidad y confianza en la capa de almacenamiento. No sustituye una base de datos OLAP, pero esto era un extra y aún sin eso, en nuestro caso, tenía sentido la migración.

Sobre la descentralización del talento

A principios de septiembre incorporamos a dos programadores nuevos al equipo, hasta la  semana pasada no nos conocimos en persona (en 3D), ésta semana ya se han ido y no volveremos a coincidir, como pronto, hasta enero.

Frogtek España es un equipo distribuido que trabaja en remoto. Probablemente hace ya años que lo somos porque, aunque sólo hace dos años que nos instalamos en el 80%-100% de teletrabajo, desde siempre hemos colaborado con latinoamérica separados, inevitablemente, por miles de km de distancia y unas 7 horas de diferencia. Y los últimos hechos no hacen sino confirmar esta afirmación ya que hemos unido al equipo a dos personas de la provincia de Córdoba que ni siquiera viven en la misma ciudad. Así que en los stand-up matutinos nos hablamos desde Huesca, Zaragoza, Vitoria, La Orotava, Córdoba y Añora… y por la tarde ya le ponemos el toque exótico añadiéndole cuatro personas en la Ciudad de México que, aunque no forman parte de Frogtek España, sí lo hacen del equipo de Tecnología.

Llegar hasta aquí no ha sido un camino rápido, ni siquiera premeditado. Frogtek, como casi todas las empresas, nació con una sede que visitábamos cinco días a la semana, mañana y tarde. Una sede en un pequeño Parque Tecnológico de una ciudad sin una gran cantera de programadores, cercana a la ciudad-región por antonomasia (Zaragoza) mucho mejor dotada en cantidad de casi cualquier cosa (excepto restaurantes con estrellas Michelín). Pero hacer 75 km dos veces al día, día sí y día también es bastante cansado y caro y pronto le fuimos perdiendo el miedo, unos (ellos), a pedir días de teletrabajo, otros (yo principalmente), a trabajar con un equipo que no ve. Primero cayeron los viernes, el eslabón más débil de la cadena. Al tiempo cayeron los lunes y así estuvimos una temporada con un 40% de teletrabajo que circunstancialmente llegaba a convertirse en un 60% o un 80%, cuando no quedaba otro remedio. Pero fue a principios de 2015 cuando tomamos la decisión de reducir nuestras visitas a la oficina a un solo día a la semana, opcional y sólo de la gente que vivimos a menos de una hora de Huesca, dejando que el resto practique un 100% de teletrabajo. La excepción a esta regla es cuando, una semana cada tres o cuatro meses, nos juntamos todos para vernos en persona e irnos de cena y de excursión por la montaña (también hacemos retros, priorizamos tareas y hasta curramos, pero eso es secundario). Todo esto que nació de a) la tozudez del que “fundó” Frogtek España en Huesca porque él vivía allí (hay gente pa tó) y b) la “pereza” de los de Zaragoza para hacer 75km de autovía, se ha acabado convirtiendo en, primero, una gran ventaja competitiva para nosotros y, segundo, un pequeño ejemplo de lo que a muchos nos gustaría que fuera más normal en España.

La ventaja competitiva es clara y empieza por dejar de preocuparte por dónde están las personas en el equipo. Si uno de ellos se quiere volver a Tenerife, si otro tiene que pasar un año en Tortosa, si a la pareja del de más acá la destinan a Vitoria o si cualquiera se quiere ir un mes en verano a su pueblo, ninguna de esas situaciones tiene por qué convertirse  en un problema para nadie. Por otro lado está el tan manido acceso al talento allá donde esté, aunque yo le daría la vuelta a la frase: más que acceder al talento allá donde esté, se trataría de permitir que el talento vaya allá donde quiere estar y no me refiero a una empresa, me refiero a una ciudad, a un pueblo o a donde sea que se quiera vivir. Si algo me ha enseñado este último proceso de selección es que hay mucha hambre, en el buen sentido, por poder trabajar en proyectos interesantes sin tener que sacrificar tu vida en el altar de Madrid y/o Barcelona, con perdón de quienes consideran que son ciudades estupendas para vivir. Hemos recibido candidaturas, por supuesto, de Huesca y Zaragoza, pero también de almerienses que no querían ir a Madrid, o de lucenses o extremeños que querían salir de Barcelona o Madrid y a los que sus empresas, la mayoría multinacionales, solo les ofrecía uno o dos días de teletrabajo. Hemos recibido un gran porcentaje de candidatos atraídos principalmente por estas dos palabras: “trabajo remoto”. Semanalmente veo las ofertas que aparecen en la Bonilista, por poner un ejemplo de ofertas de empresas talentosas y atractivas, y lo cierto es que son realmente imaginativas e interesantes: horario flexible, días de teletrabajo, comida saludable (y de la otra) gratis, mesa de ping-pong, tráete tu mascota, date un masaje, aprende idiomas… eso sí, hay pocas que digan: Trabaja dónde quieras. Todos los días. Punto. ¿Por qué? Con las grandes empresas y sus enormes y, las más de las veces, burocratizados departamentos el panorama no es muy distinto. Seguramente a los snacks gratis se les una un plan de pensiones, un seguro de salud privado y  los consabidos uno o dos días de teletrabajo pero, en estos casos supongo que pasar de esos simbólicos días en casa al remoto total es mucho más complicado. Y no lo estoy criticando, el teletrabajo parcial es muy útil, nos ha permitido a muchos organizarnos mucho mejor y conciliar el trabajo con todas esas otras cosas que te pasan antes, durante y después del trabajo, la vida, e imagino que es muchísimo más agradecido si vives en una gran ciudad en la que moverse para hacer cualquier gestión, o simplemente ir al centro, cuesta el mismo tiempo que desde Huesca, bajar a Zaragoza, plantarte en Ordesa o pasar la ITV+cambiar tu empadronamiento+pasar por el banco+renovar DNI+pasaporte del tirón (sí, en hora y media, es posible). El teletrabajo parcial es un avance pero, para muchas personas, no ataca el problema fundamental y es que la gente quiere trabajar en su casa, entendiendo “su casa” en sentido amplio, es decir, aquel sitio que te permite realizarte mejor como persona… o, simplemente, allá donde te apetece estar en cada momento. Así que, aunque no ha sido premeditado, aunque ha sido por pura comodidad, el hecho ser un poco pioneros en el trabajo 100% distribuido en España, es una de nuestras grandes ventajas competitivas. Genial.

Sin embargo, dejando al margen lo que le interesa a Frogtek y centrándonos en lo que nos interesa a los profesionales del sector y, por qué no decirlo, en lo que le interesa a la España vacía, creo que estamos ante una gran oportunidad que no deberíamos dejar escapar. Se habla mucho de todos los puestos de trabajo que la tecnología va a dejar obsoletos pero no tanto de todas las oficinas que podría vaciar, y menos aún del proceso de descentralización del talento que podría conseguirse. Huesca es la segunda ciudad de Aragón, sin embargo es sólo la quinta ciudad con más aragoneses de España: Madrid, Barcelona, Valencia suman muchas Huescas en su interior (y alguna que otra Zaragoza). Huescas compuestas por personas que tuvieron que marcharse de casa ya para formarse y que acabaron “exiliadas” para poder trabajar de lo suyo. Y quien dice Huesca, dice Teruel, dice Soria, Segovia, Cuenca, Zamora, Palencia, Lugo… dice Cáceres… ciudades donde se vive bien y se trabaja mal eclipsadas por ciudades donde se vive mal pero se trabaja bien. Resulta paradójico todo el tiempo, dinero y talento que invertimos muchos en formarnos para ganarnos una vida peor y pasarla anhelando una mejor, con los nuestros o adondequiera que nos apetezca estar y que no suele coincidir con donde tenemos que estar. Por eso, en un sector como el TIC, casi completamente digital, con un gran valor añadido, llamado a liderar la economía, en un sector en el que sí se puede estaría bien empezar a pensar en volver a casa, en devolver ese conocimiento y esa riqueza a unas zonas que han aportado tantas ausencias, tanto tiempo, tanta nostalgia y soledad y que a cambio solo reciben una visita los puentes largos y lo que nos sobra de las vacaciones que nos hemos ganado con nuestro destierro remunerado en la capital.

¿Se va realmente a producir esta descentralización? No lo sé. ¿Se puede ayudar a que esto pase de alguna manera (aparte de predicando, con el ejemplo, en el desierto… demográfico)? No lo sé. ¿Defenderé lo mismo si un día nuestro equipo es de 50 o 100 personas en lugar de 12? No lo sé. ¿Podré seguir trabajando en remoto el día que no esté en Frogtek? No lo sé. ¿Será mi primera prioridad a la hora elegir un nuevo proyecto? Eso sí lo sé.

Oferta programador Android (trabajo en remoto) (CERRADA)

El Grupo Frogtek es una empresa social con ánimo de lucro cuyo propósito es iluminar con información el canal tradicional para hacerlo más competitivo (y de paso ayudar a los tenderos de países emergentes y del tercer mundo a escapar de la pobreza). Lo hacemos, principal aunque no únicamente, ofreciendo aplicaciones Android que el tendero puede usar para gestionar y optimizar su negocio, y sostenemos el proyecto a través de la venta estudios de mercado basados en los datos de ventas de los tenderos que almacenamos y procesamos en nuestros servidores en Google y en Amazon.

Nuestra empresa es global y trabaja de forma distribuida. Las operaciones de venta, formación y soporte a tenderos están en México pero la creación de tecnología, innovación y datos se gestionan principalmente desde España aunque cada día más trabajamos en remoto y es menos importante dónde puedas estar. Buscamos una persona que venga a integrarse al equipo de tecnología y nos ayude, entre otras cosas, a reforzar el equipo Android para el desarrollo de nuevos productos y la evolución de los existentes.

¿Qué tipo de cosas hacemos en el departamento de tecnología, innovación y datos de Frogtek?:

  • Mantener y evolucionar nuestra principal app para gestionar pequeñas tiendas. Aplicación que permite registrar todos los movimientos de sus negocios con un dispositivo móvil y un escáner de códigos de barra.
  • Crear otras soluciones para tenderos que fomenten y faciliten la recolección, procesado y explotado de datos. ¿Qué otras tareas hacen manualmente que podrían ser mejoradas con el uso de tecnología?
  • Mantener y evolucionar un back-end que se encarga de almacenar y procesar toda la información que obtenemos de las tiendas para ponerla, con la mayor calidad, en tiempo y forma, a disposición de nuestros clientes y de los propios tenderos.
  • Desarrollar herramientas internas para que nuestros compañeros de los departamentos operativos puedan monitorizar el estado de las tiendas, asegurando que todos los tenderos usan nuestras soluciones de la mejor manera posible, y reaccionando ante las alertas que nuestros algoritmos de calidad generan en tiempo real.
  • Crear prototipos o productos finales para que nuestros clientes puedan visualizar datos de mercado de una calidad y granularidad inédita en nuestro sector.

¿Y cómo hacemos todo eso?

  • Ayudando a entender las peticiones y diseñando las soluciones que nuestros compañeros de otras áreas nos hacen, participando en los distintos comités multi-departamentales que tenemos.
  • Participando en nuestro proceso de desarrollo de código ya sea para crear nuevas funcionalidades, para optimizar nuestra infraestructura o para resolver incidencias, un trabajo variado que permite tratar con múltiples tecnologías tanto en el lado cliente como en el servidor. Esto implica:
    • Colaborar en la definición de objetivos del equipo.
    • Desarrollar y/o validar requerimientos.
    • Crear, solo o en compañía, código de calidad, legible y cubierto por tests.
    • Revisar y leer el código de otros compañeros.
    • Probar funcionalidades.
  • Colaborando en el despliegue de los productos.
  • Asesorando técnicamente dentro y fuera del equipo.
  • Aprendiendo de los demás y enseñando a los demás.
  • Integrandonos en la cultura de mejora continua del equipo basada en los datos y en algunas pinceladas de EFQM.

¿Qué buscamos?

En esta ocasión buscamos alguien que colabore en el desarrollo de nuestras soluciones Android, que nos ayude a poner en manos de los tenderos nuevas soluciones o evoluciones de las que ya tenemos que les resuelvan la vida y que nos ayuden a hacer nuestro proyecto más sostenible y escalable. Buscamos una persona inquieta, flexible y con capacidad para adaptarse, aprender y enseñar. Os ponemos aquí el tipo de cosas con las que trabajamos y que esperamos que los candidatos conozcan en mayor o menor medida.

  • Datos, datos, datos y más datos (que no te den miedo las mates y los números).
  • Aplicaciones Android
  • Programación Python, CherryPy, Django…
  • Programación web
  • MySQL y SQLite
  • Herramientas de analíticas de producto (estilo MixPanel o Google Analytics…)
  • Metodologías ágiles y extreme programming (pair programming, TDD…)
  • Mejora continua
  • Alto nivel de inglés
  • Trabajo remoto y flexible

También hay cosas que no son imprescindibles para este puesto o que no conocemos demasiado, o no en profundidad, pero nos llaman la atención:

  • Experiencia con las plataforma Google Cloud y AWS
  • Soltura con Linux
  • Conocimientos de Scripting (ruby, bash, python)
  • Experiencia en la plataforma de integración continua Jenkins
  • Conocimientos de R
  • Google Big Query, Amazon Redshift, etc
  • Amazon Kinesis
  • Spark
  • Scala
  • Hadoop
  • Arquitecturas lambda
  • Cualquier otra tecnología que venga a mejorar lo que ya tenemos

 

¿Qué ofrecemos?

  • Sueldo en función de experiencia.
  • Grandes posibilidades de desarrollo y aprendizaje.
  • Integración en un equipo dinámico, sin miedo a aprender, cambiar y mejorar.
  • 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…) con altas posibilidades de iniciar un crecimiento internacional en los próximos meses.
  • Horario flexible (aunque hay que reservar un rato para solaparnos con México todos los días).
  • Entre 80% y 100% de tele-trabajo, nuestra oficina está en el Parque Tecnológico Walqa,  en la encantadora ciudad de Huesca al pie de los espectaculares Pirineos. Si vives cerca nos vemos allí una vez a la semana, si no también podemos hacerte un hueco en nuestros standups virtuales y vernos las caras una semana cada 3 o 4 meses en nuestras reuniones trimestrales.
  • Buen ambiente.
  • Experiencia internacional y multicultural… y si te gusta viajar quizá puedas visitar México o algún otro país.

 

Si te interesa tener una primera entrevista con nuestro equipo, por favor envíame un mensaje y CV actualizado a guillermo arroba frogtek punto org

De trellos a métricas (y tiro porque me toca): nuestro Balanced Scorecard

Ya sabemos gracias al post de Miky que  en Frogtek somos adictos a Trello y a sus múltiples columnas y tarjetas. Primero porque es una manera fácil de casi “documentar” procesos complejos y con muchas fases, pero  también porque es la manera más sencilla de que todo el mundo siga la metodología, o porque da visibilidad a todo el equipo o muchas otras razones… la última, pero no por ello la menos importante, la comenta el propio Miky en su post:

Pero lo bueno viene ahora. La historia de usuario terminada, la petición la mueves a terminada también. Empieza la diversión. La US se contabiliza, se archiva en otro Trello que lleva las US asociadas a las diferentes versiones de los productos. Se envía un email para pedir feedback sobre la resolución de la incidencia. Se trasmiten los comentarios, se agregan las valoraciones. La persona que ha hecho la petición percibe que alguien, y no algo, ha hecho el trabajo. Buenas ideas. Y la mejor idea de todo este párrafo: algunas cosas están automatizadas, pero todas son transparentes al desarrollador.

La contabilización de USs es una tarea en parte manual y mecánica pero da unos frutos muy interesantes cuando empiezas a mirar en los datos. El principal es nuestro Balanced Scorecard (también llamado Cuadro de Mando Integral) que integra, entre otros muchos datos, todos los indicadores de satisfacción de peticiones y de la implementación de historias de usuario. Tiene una pinta tal que así.

bsc1

Para el que no haya visto nunca un Mapa Estratégico o un Balanced Scorecard se puede resumir más o menos en lo siguiente:

  • Un Mapa Estratégico es una como una representación de la estrategia de la compañía en un conjunto de objetivos en diferentes perspectivas (la financiera, la de clientes, la de procesos y la de equipo). Básicamente se podría reducir como las respuestas que hay que dar consecutivamente a las siguientes preguntas.
    • ¿Cuales son las expectativas financieras de la empresa? Facturar X, conseguir una inversión Y…
    • ¿Qué ofrece el negocio a los clientes (que le llevará a satisfacer las expectativas financieras)? Un producto con un gran valor o con un valor diferencial, una atención al cliente excelente…
    • ¿Qué tiene que hacer el negocio para cumplir con los clientes? Tener un desarrollo de producto ágil y eficaz, gestionar las incidencias de manera magnífica…
    • ¿Qué garantiza la ejecución óptima de los procesos? Un equipo satisfecho (ésta es un clásico), conocimientos sobre desarrollo de producto, una plataforma de atención al cliente puntera… lo que sea.
  • Y un Balanced Scorecard, según mi personal punto de vista, viene a ser exactamente lo mismo pero sustituyendo esos objetivos en cada una de las perspectivas por indicadores (KPIs).

bsc2

Normalmente un Mapa Estratégico tiene la perspectiva financiera arriba del todo, ya que ganar pasta suele ser el fin último de todas las empresas… en el caso de Mapa Estratégico del Departamento de Tecnología de Frogtek nosotros lo hemos colado abajo ya que hacer pasta no es nuestro objetivo del área… pero bueno eso en el fondo es debatible y no es tan importante para este post en particular. En la siguiente imagen podéis ver un boceto del Mapa Estratégico del nuestro departamento.

Básicamente muestra que nosotros consideramos que habremos hecho un buen trabajo si:

  1. Ayudamos proactivamente con tecnología y datos al resto de departamentos a mejorar sus KPIs y alcanzar sus objetivos.
  2. Mantenemos los sistemas siempre up & running y evolucionamos la infraestructura para asegurar la escalabilidad.
  3. Creamos productos de valor para tenderos.
  4. Resolvemos cualquier problema técnico de manera puntual y eficaz.

El resto de objetivos en procesos, equipo y finanzas tienen que servir a estos cuatro.

Y luego viene cuando pasamos del Mapa Estratégico, una slide estática en una presentación, a la parte que mola… un Balanced Scorecard colgado en la web con KPIs que se actualizan en tiempo real (o casi). La razón por la que un servidor dedica unas 2 horas al mes a contabilizar USs, peticiones, incidencias u otras cosas. No hay mucha magia tecnológica detrás de esto: Clicdata, Spreadsheets, Google Forms, Trello… le das las vueltas con Zapier, lo aderezas con una pizquita de amor… et voilà: una de indicadores para el proceso de gestión de peticiones y colaboraciones (lo que nosotros llamamos Roadmap).

bsc3

No se queda ahí la cosa. Haciendo click en cada indicador puedes entrar en un segundo nivel con la evolución mensual de la duración del ciclo de vida, el cumplimiento de expectativas (esas cosas que se piden para ayer), el número de peticiones, la satisfacción o el desglose de peticiones por cliente y/o épica. Todo ello filtrado por fecha, cliente, producto, épica…

bsc4

Y lo mismo para el segundo Trello (proceso) que mencionaba Miky en su post, el proceso de desarrollo de USs.

bsc5

Con sus pertinentes desgloses.

bsc6

Adicionalmente para cada dashboard de segundo nivel tenemos una tabla con las iniciativas de mejora relacionadas que hemos llevado a cabo en el periodo. Una buena manera de ver si las mejoras que propones tienen algún impacto en la mejora de los indicadores. Mejoras que, por cierto, también tienen su propio Trello, sus propios KPIs y sus propios indicadores. En Frogtek España todo tiene un Trello.   😉  😛 😕  … No es broma.

Y como todo en Frogtek España tiene un Trello nuestro Balanced Scorecard no sólo tiene KPIs para Roadmap y Desarrollo, también para el rendimiento de nuestro proceso de entrega de datos punta a punta, el uso de nuestro producto por parte de los tenderos, la gestión de incidencias, la gestión de despliegues de nuevas versiones, la valoración del trabajo del responsable del equipo, la gestión de las iniciativas de mejora, la satisfacción del propio equipo e incluso el cómo y dónde nos gastamos el dinero. Para no alargarnos no vamos a entrar en todos y cada uno de ellos (al menos no en este post) pero que sepáis que tenemos Trellos para aburrir (alrededor de una veintena para gestionar Tech) y que podría estar escribiendo sobre ellos hasta 2020.   😛

Trello y nuestro workflow de trabajo

Ya contamos en un post anterior parte del proceso de selección en el área de tecnología de Frogtek. Pero todavía podemos desvelar algún secreto más, y es que una de las primeras cosas que recibes al entrar el grupo de tecnología es una cuenta de Trello. Hasta ese momento podías conocer Trello o no; podías haberlo usado un poco para algunos proyectos, o tal vez para gestionar tus propias tareas. Pero ahora, con el acceso a los tableros de Frogtek… ya no hay vuelta atrás.

Fue una de las cosas que más me impactó: todo tiene una tarjeta de Trello. Y sí, lo admito, al principio es un poco overwhelming, tantos tableros, tantas notificaciones. Pero ahora ya está en el ADN, ya forma parte de uno mismo. Y si no está en Trello, seguramente, no ha pasado. De todas los procesos que tenemos trellificados me gustaría centrarme hoy en uno: las peticiones que se realizan a tecnología.
Seguir leyendo

Somos ágiles, hacemos stand-ups

Como crítica constructiva o destructiva, la frase se utiliza muchas veces. Uno lee artículos, escucha podcasts, ve charlas, … Stand-up para arriba, stand-up para abajo. Uno ya no sabe que pensar, casi mejor me quedo en la cama un rato más, que ahora en invierno se está muy “agustico”. ¡No! analicemos nuestros stand-up.

PRIMERO UN POCO DE REALIDAD

La realidad es que desde el teletrabajo los stand-ups solemos hacerlos sentados. Pero conservan el nombre. Y sí, a veces se alargan. En lugar de ver un círculo de gente rodeada de post-its y tareas en los cristales, veo los caretos de todos mis compañeros en primer plano (un porcentaje muy alto no nos hemos peinado, pero los auriculares lo disimulan). Eso sí, en lugar de post-its tengo mi libreta y un tablero de Trello con lo que he hecho, las siguientes tareas y lo que quiero comentar.

Empieza el stand-up, suele empezar el que ha compartido el enlace, tradición (todavía no es automático, ¡por el amor del MEV!).
Lo normal:
– Sujeto 1: Ayer hice esto y aquello, me queda pendiente esto que lo hago ahora por la mañana. Luego me pongo con aquello. Hoy trabajaré a partir de las 11:00 que me voy al médico.

Normalmente la cosa acaba aquí. Pero hay diferentes casuísticas interesantes.
Seguir leyendo

Sobre código, revisiones y despliegues

Lo sé. Lo admito. Me encanta la sensación de acabar de programar algo a las 5 de la mañana. Satisfecho. Orgulloso. Tal vez con un exceso de cafeína. Mergeas, despliegas y a dormir con una sonrisa. En tus sueños un cowboy se monta en su caballo, llega al pueblo y desmonta bajo la mirada de los pueblerinos. Captura a los malos, se sacude el polvo y se va triunfal con los suspiros de aquellos y aquellas a sus espaldas. Sí, ese desarrollador cowboy que es capaz de hacerlo todo, sin hablar con nadie, sin consensuar nada.

Te levantas con la sonrisa todavía en la boca (dejemos de lado babas y otros sucesos paranormales). Vas al ordenador y ¡boom!, algo ha ido mal. La explosión despierta hasta al cowboy de tus sueños, que se tapa con una piel y se acurruca junto a la hoguera, ahora hay miedo en ojos del valiente cowboy. Creo que esta historia nos suena a muchos y a muchas. Y sí, los sueños y las sonrisas, e incluso las risas molan; pero mejor dejar las explosiones para nuestros proyectos locos y no para los serios, o para el trabajo.

Historias de usuario públicas. Ramas. Revisión de código. Pruebas manuales. Pruebas automáticas. Despliegues. El cowboy puede hacer lo que quiera, que vamos a hacer que esto no explote (o mejor dicho, que explote cuanto menos, mejor).
Seguir leyendo

« Siguientes entradas