6 charlas de protagonistas de todo el país y 6 experiencias de empresas de la región.
Queremos que la conferencia sea un ejemplo de cómo es el desarrollo real de un proyecto, lleno de complicaciones, lecciones
aprendidas y algún éxito.
Organizan:
Ponentes
Javi Santana
CTO - CARTO
Javi Santana es un programador de provincias. Desarrolla software para agricultores desde hace 9 años cuando fundó agroguía.
Desde entonces sigue creando herramientas que hacen la vida más fácil a los agricultores.
Durante ese camino se cruzó con CARTO donde se encarga de que el software que ayuda a la
NASA, Twitter, Wall Street Journal y otras grandes empresas a contar sus historias sobre mapas funcione como un reloj.
Jorge Barroso es Android expert en Karumi y Android GDE.
Trabajó en Tuenti entre 2009 a 2013 siendo en su última etapa tech lead del equipo de Android. Ha participado en
varios proyectos móviles de la compañía como j2me, Blackberry y Android. Antes de Tuenti trabajó en varias empresas
desarrollando juegos para dispositivos móviles y juegos multiplayer.
Project Manager - Liquid Squad at Accenture Digital
Inicio mi carrera en Bilbao como programadora web dónde estoy 5 años antes de venir a Madrid a trabajar en Tecnilógica,
dónde llevo más de 10 años.
En Liquid Squad (antigua Tecnilógica) he desarrollado proyectos web y móviles, y ahora me reparto entre la jefatura de proyectos y la
dirección
adjunta de operaciones.
Félix López es actualmente Director de Ingeniería en ShuttleCloud, una startup cuya tecnología es usada por instituciones
como Stanford y Harvard, y compañías como Google, Comcast, Yahoo! o TimeWarner.
Félix lleva 15 años desarrollando software en los que ha pasado por desarrollo web, programación de videojuegos,
aplicaciones para cambio de moneda y sistemas distribuidos. Pasa los días leyendo sobre sistemas distribuidos y como pasar
entrevistas técnicas para cuando llegue el momento :D
Su labor es crear una visión compartida y asegurar que stakeholders, product owners y equipos de desarrollo distribuidos en varios
países,
trabajen de forma colaborativa y remen en la misma dirección. Lo consigue gracias a su pasión por Visual Thinking&Management, las
Metodologías Ágiles y la Productividad Personal.
Confía en las buenas prácticas, los hábitos, la mejora continua y en su aperitivo favorito: los mejillones en escabeche con patatas
fritas y
una caña bien fresquita.
Más conocido como oyabun, es un vascomeño que se gana la vida como UX / Product manager en Sngular ayudando a optimizar
procesos y a diseñar experiencias.
Sin embargo cuando se enfunda su floreado uniforme es el escriba visual en eventos molones. Tanto tomando apuntes de manera
silenciosa entre el público como sketchnoter, como dejando testimonio visual en tiempo real del discurso del ponente como
graphic recorder.
Si tienes un problema y te lo encuentras, quizá pueda dibujarlo.
Soy Dani Latorre, uno de los 3 fundadores de Jobsket. Cuando no estoy de cañas trabajo haciendo software para terceros en los Coding
Stones y soy socio en Outreach Tool llevando todo lo relacionado con lo tecnológico.
Desde el corazón de Vallecas, meri ha trabajado desde en los conductos de ventilación de la estrella de la muerte, diseñando en secreto
las interfaces que luego usas para pulirte el sueldo en Amazon. Te podría contar su secreto pero tendría que matarte, y no queremos eso
¿verdad?
Ingeniero Técnico de Telecomunicaciones, experto en
Televisión Digital Interactiva, en dirección de equipos de trabajo, gestión de proyectos, metodologías ágiles de
desarrollo y metodologías de desarrollo de productos.
Antes de Argotec, ha desempeñado su labor profesional durante 5 años en el Centro
Tecnológico Cedetel, en el que dirigía el área
de la Televisión Digital Interactiva.
Desde 2010, ha trabajado en Argotec, realizando inicialmente tareas técnicas de programación a
bajo nivel, desarrollo de hardware, prototipado electrónico. En una segunda fase se dedicó más a tareas de consultoría técnica, alguna
labor comercial y dirección de equipos de trabajo. En la actualidad desempeña labores de dirección general y estratégica de Argotec.
Chief Engineering Officer y fundador - Codice Software
Pablo es el fundador de Codice y el líder de ingeniería.
Cuando no está diseñando nuevas funcionalidades o programando cosas obscuras en el servidor, puedes encontrarle blogeando y escribiendo
sobre todo lo relacionado con el control de versiones.
Solía ser un profesor asociado en la Universidad de Burgos (UBU), enseñando gestión de proyectos a estudiantes del cuarto año
de Ingeniería Informática. Es también un speaker habitual y bloguero.
Pablo ama las motos, especialmente Kawasaki, y sobre todo si fueron construidas en los 90 (ZXR power), pero se está acostumbrando a
quemar una Aprilia también.
FlowUp es nuestro primer proyecto y estamos muy orgullosos de él. Hablaremos de como gestionar el tiempo, de como usar las
herramientas y como tomar decisiones. Pero no todo es bonito, también hablaremos de piedras en el camino y como las solventamos.
De todo producto sale un aprendizaje, espero que el nuestro os ayude
En Argotec nos dedicamos desde 2010 a desarrollar productos electrónicos a medida dentro del mercado del Internet de las Cosas.
Hemos creado una gama de productos bajo la denominación comercial Qampo que están orientados a optimizar la productividad y la
calidad de cultivos. Es un producto íntegramente diseñado y fabricado por nosotros, de hecho toda la electrónica se fabrica
actualmente en nuestra cadena
de producción en Valladolid. Durante la charla hablaremos de los aciertos y los errores cometidos a lo largo de todo el proceso
de desarrollo de producto, desde la concepción de la idea y el diseño hasta su comercialización, pasando por la fabricación del
mismo.
Voy a contar como un proyecto que hemos hecho que iba muy mal por una serie de circunstancias y decisiones tomadas, finalmente
se da la vuelta a la situación y se convierte en un proyecto exitoso.
Porqué casi morimos de éxito y cómo nos reinventamos
Kiuwan proporciona una analítica del software, mediante una plataforma que analiza el código y la configuración, y nos dice cómo
está hecho el software por dentro.
Este devenir no ha sido suave: el camino está jalonado de errores y traspiés. En el 2008 estábamos en modo "on-premises" a punto
de morir de éxito. La Gran Recesión nos hizo replantearnos el modelo. Este "casi morir de éxito" sería el fracaso a exponer.
La charla expone cómo, manteniendo el mismo "motor" tecnológico, cambiamos nuestro enfoque para internacionalizar el producto,
situándolo "en la nube". Este sería el caso de éxito.
Del caos al equilibrio pasando por el precipicio de puntillas
Este es el viaje de una empresa que empieza con un producto destinado a usuarios finales; firma un contrato con Google (SAS)
que le lleva a casi morir de éxito y ahora tiene lo que se consideraría un éxito real: es rentable y con clientes como Google
(Gmail,
Google Contacts), Yahoo, Comcast o GoDaddy... seguimos creciendo y mantemos el mismo equipo desde hace más de 3 años
Da igual el tamaño de la empresa , el presupuesto que tengas o lo que planifiques: al final siempre hay factores que hacen que
todo eso no resulte. ¿cómo superarlos en la estrella de la muerte? Desde el departamento de UX del imperio, hicimos lo que mejor
se nos da: ser creativos buscando soluciones para poder llegar a tiempo y con la máxima calidad.
De cuando íbamos a poner patas arriba el sector recruiting
Jobsket fue una startup que vivió entre 2008 y 2013. Igual está mal que yo lo diga, pero conseguimos ser una de las compañías
más innovadoras en el sector del recruiting en cuanto a producto a nivel internacional. Evolucionando de una herramienta de
análisis del mercado laboral y de CVs a un software de Applicant Tracking System (ATS). Por el camino introdujimos cosas como:
procesado de lenguaje natural, búsqueda semántica, matching de candidatos, multiposting... y aún así acabamos cerrando.
En esta pequeña charla hablaré de las diferentes fases que pasamos y el aprendizaje que vivimos en esos 5 años y pico de master
startupil.
+1 liberando artistas, -1 el negocio import/export.
Up: ¿sabías que en los estudios de videojuegos el 95% vive sometido a las decisiones de un maligno 5%? Nosotros tampoco hasta
que descubrimos que los artistas *odian* los controles de versiones que eligen los programadores. Son mayoría, pero viven
sometidos. Nuestro gran éxito fue crear Gluon, un control de versiones pensado para ellos.
Down: cuando importas datos desde otro control de versiones tu techo, lo mejor que puedes llegar a hacer, es lo mínimo que el
cliente espera: que esté todo :-(. Hay partidos que es mejor no jugar, pero a veces no hay más remedio. Sangre, sudor y muchas
lágrimas cuando la liamos importando un Subversion de unos que pensábamos que eran un videoclub chungo: SpaceX.
Llevaba más de dos años trabajando con Metodologías Ágiles, cuando se decidió crear una comunidad de práctica para los Product
Owners
cuya facilitadora era yo. Al principio, había muchas experiencias del día a día y prácticas que compartir, después algunos
compañeros
empezaron sólo a escuchar, hasta que se perdió la comunidad y la práctica. Me llevé a lo personal la falta de interés de los
demás y
sufrí mucho. Por suerte, mis experimentos en el rol de Programme Manager estaban dando buenos resultados, tanto, que otras
líneas de
negocio empezaron a observar y a adoptar algunas de las prácticas puestas en marcha hace 2 años, prácticas que ya son un hábito
en
nuestro día a día.
En esta charla corta me gustaría compartir con vosotros el caso de TEAMS, una StartUp en la que llevamos dos años trabajando y
en la que nos encontramos en ese punto en el que no tenemos claro si es un éxito o un fracaso. En concreto compartiré con
vosotros lo que consideramos que ha sido el mayor aprendizaje y lo que pensamos que, de haberlo sabido antes, nos hubiera
ayudado a estar más cerca del éxito, o por lo menos haber validado el modelo de negocio antes.
El optimista irredento que aprendió a decir que no
He tenido que sudar sangre y superar un master de más de tres años que costó más de 300.000€ para aprender que la mejor
base para crear un producto digital de éxito es saber cuando no merece la pena intentarlo. En esta charla conoceréis uno de mis
fracasos más estrepitosos y un épico triunfo que me hizo volver a creer en mi mismo. Uno cerró y otro siguió adelante, pero
seguro
que nunca acertaríais cuál. Y es que, a veces, las cosas no son como parecen... ni como nos cuentan.
El objetivo es compartir un fracaso y un éxito. Uno de esos que te ponen rojo al acordarte, y otro que deje buen sabor de
boca. Y en este post contaremos el fracaso :(
¿Qué vas a sacar en claro si te lees esto? Conocer un poco a qué nos enfrentamos
desarrollando un control de versiones, pero sacando lecciones aprendidas que se pueden
aplicar en cualquier otro proyecto.
Lo resumiría en: no juegues partidos que no puedes ganar y escucha a tus clientes.
Cuando diseñamos Plastic, la primera versión, queríamos que fuera muy, muy bueno con
ramas, y buenísimo haciendo merges. Ese ha sido nuestro foco durante años. Ramas cortas y
frecuentes, muchísimas, y muchos merges. Con esto podías sacar versiones muy a menudo.
En algún momento todos hemos escuchado eso de “the right tool for the job”, y más aún en el mundillo tecnológico. Tendemos a orientar
este concepto
a las cosas tangibles, pero este consejo se puede aplicar mucho más allá de herramientas de desarrollo, frameworks o librerías.
Cuando nos propusieron escribir este post sobre éxitos y fracasos, nos reunimos todo el equipo e hicimos un proceso de análisis de estos
ocho meses de vida que tenemos.
Bueno, ocho meses de cara al público porque el proyecto
comenzó hace dos años cuando todavía no teníamos oficina, no había equipo y mi
hermano Alfonso y yo trabajábamos en pijama desde casa.
El Ticketing es un negocio donde los picos de tráfico extremos son la norma en lugar de la excepción. Para Ticketea esto
significa que nuestro tráfico puede incrementarse en un factor de 60x en cuestión de segundos. Normalmente sucede
cuando grandes eventos (que tienen una ‘fecha de inicio de venta’ fija y anunciada con anterioridad) salen a la venta.
Se requiere que todos los asistentes, ponentes, patrocinadores y voluntarios de nuestra conferencia
acepten el siguiente código de conducta.
Los organizadores harán cumplir este código a lo largo del evento. Esperamos la colaboración de todos los participantes para ayudar
a asegurar un ambiente seguro para todos.
¿Necesitas ayuda?
Tienes nuestros detalles de contacto en los correos electrónicos que hemos mandado.
En concreto estaremos disponibles durante toda la conferencia en info@lechazoconf.com y el
teléfono 675 215 114.
Nuestra conferencia se dedica a ofrecer una experiencia libre de abusos para todos, independientemente de su género, orientación
sexual,
discapacidad, apariencia física, talla, raza o religión. No toleramos abusos de los participantes de la conferencia en ninguna de
sus
formas. El lenguaje e imágenes sexuales no son apropiados para ninguna sala de la conferencia, incluyendo charlas, talleres,
fiestas,
Twitter y otros medios online. Los participantes de la conferencia que violen estas reglas pueden ser sancionados o expulsados de la
misma
sin reembolso a discreción de los organizadores.