Pero todo tiene su límite, y esta vez salimos si o sí. Tenemos que salir. Aunque tengamos que sacrificar algo de funcionalidad o seamos conscientes de que algunas cosas son mejorables. ¡Qué duro es tener que escoger qué entra y qué no!. Pero si no ponemos un límite no terminaríamos nunca. Lo expresa muy bien en una entrevista Jim Collins, uno de los habitantes de una de nuestras ciudades favoritas, en una entrevista de hace un par de meses en la revista Inc:

If you accept the idea that work is infinite and time is finite, you realize you have to manage your time and not your work. You need a laserlike focus on doing first things first. And that means having a ferocious understanding of what you are not going to do.

Hacer esto trabajando para otros es difícil, pero hacerlo para tí es durísimo, porque añades los miedos y dudas sobre si acertarás o no, sobre si el trabajo realizado y el sacrificio pasado habrá merecido la pena. La parte buena es que eres tú quién escoge, para bien o para mal.

Un prototipo visual completo (estático o dinámico) no sólo ayuda al cliente a entender claramente lo que está comprando y a mejorar la conversación con él, sino que también es mucho mejor para nosotros como equipo de desarrollo que una especificación funcional de 80 paginas (ademas todos sabemos ya que una especificación funcional no tiene nada de funcional).

El resultado de experiencias pasadas gestionadas de esta manera, como la Rails Rumble o el desarrollo de Trourist comparado con el resultado de otras ideas y proyectos nos ha llevado a ser más radicales en esta idea y dejar de excusarnos a nosotros mismos. De hecho no somos los únicos que vemos la prioridad que el Front End/UI tiene en el desarrollo de software.

Dedicando el tiempo y esfuerzo necesario a pensar el sistema o la aplicación en esta fase se consiguen múltiples ventajas:

• Reducir las indefiniciones y los malentendidos entre todos los miembros del equipo (AI, diseñadores, desarrolladores y el propio cliente).
• Un estado de desarrollo más real y palpable, dejando a la vista que queda por hacer.
• Un entorno de desarrollo más motivador, viendo el resultado final de tus avances.
• Esfuerzo más focalizados, con una meta clara y palpable (No more over-engineering!).
• Requiere la implicación del cliente que tiene que ir más allá de validar un documento que probablemente no ha leído y comprendido por completo.

Todo esto hace que finalmente avancemos más rápido, con más seguridad y viendo lo que estamos construyendo.

El prototipado y la interface de usuario no es obviamente la única fuerza directriz, puesto que finalmente todas esos elementos e interacciones se deben convertir en funcionalidades que a su vez ayudan de nuevo a enfocar y dirigir los esfuerzos… pero quizás si es la más importante. Al fin y al cabo es la parte en la que más personas intervienen… ¡y la que finalmente utilizará el cliente!

¿Quiere esto decir que es la forma ideal de trabajar?… ¿En cualquier tipo de proyecto?… ¿Para cualquier empresa?… Quizás no, pero sus ventajas hacen interesante que al menos lo probéis -posiblemente en un pequeño proyecto interno de bajo riesgo- y veáis si realmente es factible en vuestro contexto. En nuestro caso esta funcionando realmente bien y lo hemos adoptado como práctica estándar… ¿que opináis vosotros?.

rails rumble 2009 teaser

Ya se ha anunciado la fecha de la edición 2009 de la Rails Rumble: 22 y 23 de Agosto. Nosotros ya tenemos apuntada la fecha.

Tras nuestra presencia en el Rails Day 2006, la pausa en 2007, nuestro aceptable puesto 33 con Ostraka en la edición 2008, esperamos con ciertas ganas esta nueva edición. De hecho nos gustaría combinarlo con un viaje en grupo de cuatro días -2 para la rumble y 2 para descansar- de todo el equipo, con lo que la ganas de rumble -si finalmente conseguimos reservanos esos dias- aumentan XD.

Este año la organización quiere solventar algunos de los problemas que han detectado en otras ediciones como el absentismo de muchísimos grupos inscritos. Según la encuesta que nos han pasado, se están planteando requerír un pago simbólico (que iría a recibir algo de merchandising o a algún proyecto opensource hecho en Rails) con el fin de asegurarse que la gente que se apunta realmente tiene interés en participar.

También están valorando cambios en el modo de votación. Personalmente el del 2008 me parece un buen camino -votación popular- pero no creo que el resultado fuera del todo justo y no por nuestro puesto, sino por los pocos proyectos que conseguían un “aprobado” en cualquier categoría. Parece que es difícil que el publico que vota tenga en cuenta que es un esfuerzo tremendo realizado en solo 48 horas y eso si no duermes, comes ni… bueno… si no haces nada más que desarrollar. Por nuestra experiencia sabemos que terminar algo que simplemente funciona, ya es un triunfo. Muchas de las aplicaciones del año pasado no solo hacian eso sino que de hecho eran muy buenas ideas implementadas de manera más que solvente.

Sea como fuere la Rails Rumble se acerca un año más y esperamos que esta vez nos lo pasemos aun mejor (finde incluido XD).

As we’ve said before we’re sponsoring the european Ruby event: EuRuKo 2009. We’ve one ticket that we want to give you, as our way to say thanks for your time and fidelity reading this humble blog. To get the ticket you just need to leave a comment telling us why do you like Ruby (or maybe why do you want to know more about the language).

We’ll pick up the lucky man that will receive the ticket between all the comments published before Apr 30, 2009 24:00 (GMT+1).

Good luck everybody!

es_

Como dijimos en su momento somos patrocinadores de el evento europeo sobre Ruby: la EuRuKo 2009. Tenemos una entrada para sortear entre aquellos que leéis nuestro blog para agradeceros vuestro tiempo y vuestra fidelidad. Para participar en el sorteo lo único que hay que hacer es dejar un comentario sobre por qué te gusta Ruby (o quizás porque quieres aprender más sobre él).

De entre toda la gente que participe antes de las 24:00 (GMT+1) del jueves 30 de Abril de 2009 saldrá l afortunado que recibirá su entrada para la conferencia.

Buena suerte a todos!

Y es que después de retrasos, de implementaciónes que más se parecían a proyectos que a productos, hemos realizado nuestra primera venta real de producto con stage!. Antes del lanzamiento oficial hemos decidido hacer una última prueba en real con el mad 009 organizado por domestika.org, y ¡ya se han empezado a vender los tickets!.

Un pequeño paso, pero que nos acerca un poquito más a lo que queremos ser. Días duros, pero buenos.

Pero no tengáis miedo, no voy a dedicar el post a hablar sobre mi hijo, sino el impacto de algo así en una microempresa como es la nuestra. Y es que por distintas circunstancias que no vienen al caso, soy yo la persona que está con él (que disfruta de él, para ser sinceros) la mayor parte del día.

Conciliar el cuidado de un bebé con el trabajo no es fácil. No os voy a mentir. Al principio, una de cada tres horas las gastas con él en el ciclo biberón-pañal. Una de cada tres al menos, y según crece, va a más, porque pide más, necesita más. Al principio es “relativamente fácil”, ciclos cortos de comida y cambio, paseo/s diario, pero la mayor parte del tiempo la pasa dormido. Según pasan las semanas, pasa más tempo despierto y requiere que pases tiempo con él, jugando. Tiempo que disfrutas, pero tiempo que tienes que sacar de algún sitio.

La parte buena es que trabajar para tí en una microempresa hace que puedas ajustar tu vida laboral para asumir este cambio sin causar demasiado dolor a nadie. En mi caso personal: mis jornadas normalmente están partidas (siempre hay días distintos, por diversas cuestiones). Hasta las 11 aproximadamente trabajo sin demasaidos problemas (he tenido la suerte de que duerme como un bendito toda la noche desde muy pronto), de esta hora hasta las 8 depende de los días (de como se porte él, de la posibilidad de que lo cuide mi mujer), es el momento más difícil porque aunque puedes hacer cosas por momentos, constantemente el niño te rompe el ritmo (sigue necesitando ayuda para comer, pasear y jugar XD). Después del baño y la cena,  a partir de las 10 se puede volver a trabajar tranquilo un par de horas. Depende del día no llego a lo que tengo previsto, y el esfuerzo es un poco mayor, o me reorganizo con Claudia, o tengo que mover parte del trabajo al fin de semana, siempre hay soluciones.

A primera vista podría parecer que trabajo mucho, y bueno, sólo puedo decir que (seguramente) es menos que antes, sólo que distribuido de otra forma. También es cierto que los días se pueden hacer duros, y más llevando el trabajo al fin de semana en ocasiones, pero tengo la suerte de que Mario nos deja dormir y lo cierto es que no me parece demasiado alto precio por lo que obtengo: pasar la mayor parte del día con el niño.  A mi me compensa con creces. Lo único que me duele es que hay algunos aspectos de la empresa que los tengo un poco más descuidados, pero por suerte ahí están Aitor y Roberto para solucionarlo.

No quiero convencer a nadie de que esto es lo mejor, nada más lejos de mi intención, pero si tengo claro que esto no lo podría vivir trabajando para otros. O trabajando en otro tipo de empresa.

Marcelino Llano ha tenido la increíble amabilidad de no solo responder a mi pregunta sino de redactar una completísima guía sobre dónde y qué primeros pasos dar para ser un buen diseñador industrial. Agradecimientos para @marze en los comentarios por favor.

A continuación transcribo su interesante email:

“Vamos a ver, solo puedo hablar por mi experiencia, como te comentaba son dos cosas muy distintas, me voy a centrar en diseño industrial, porque el gráfico que conozco lo he aprendido de libros (teoría espacial, color, tipografía, forma…) si estás interesado en ello puedo pasarte libros, me invitas a algo en Madrid y te comento, porque es largo…

El diseño industrial va de otra cosa, yo estudié Ing. Téc. en Diseño Industrial en Valladolid, en realidad te enseñan algo parecido a ser un Ing. Téc. Mecánico, no te enseñarán el trabajo de un diseñador industrial moderno, como en Ideo (vía @denegro), aunque el video es de finales de los 80 creo… (míralo ahora si no lo has visto):

Proceso de diseño en IDEO

Si escoges el sendero del diseñador industrial este será tu problema diario…

En España puedes ir a la universidad a estudiar diseño industrial en Valladolid y Galicia son más hardcore con las mates, física y los procesos industriales (yo considero que dan una buena formación de base, pero tendrás que andar mucho camino por ti mismo)

Otros son (dentro de la universidad) más ejem “flexibles” o menos anclados al tema industrial, es el caso de Zaragoza o Valencia En Valencia tratan más el tema de juguetes, calzado y cerámica (sorprendente), si que tienen carencias en plan clases de software, me han comentado.

Luego está el asunto dejarse pasta tienes dos templos cool como son Elisava y IED. Apenas verás software potente de CAD o mecánica/electrónica pero presentarás tus proyectos estupendamente. Trabajan mas el concepto y solo tiene el problema de que tendrás menos vocabulario a pie de fábrica, o sabrás menos de los detalles de la fabricación

Si hablamos de EEUU esta guía es mandatory

Los mejores son los japos pero es un asunto que no controlo y que puede ser dificil de llevar a cabo

En UE las mejores son como un búnker para entrar tiene el RCA o la escuela de Glasgow con un montón de historia. Si consigues entrar en el RCA has tocado el cielo.

Yo estudié 6 meses en Amberes, aceptable, barato y moderno.

Puedes buscar más escuelas en core77, el mejor sitio sobre diseño industrial.

A modo de cierre te hago una lista de lo que hay que aprender para ser diseñador industrial (bajo mi punto de vista):

1. conocer los procesos industriales, son pocos los esenciales
2. conocer los materiales (plásticos, maderas, cerámicos, metales…) y sus propiedades, es un mundo enorme y apasionante
3. dibujar con rotuladores en un estilo comunicativo
4. conocer la historia detrás de la profesión (poca pero la tiene)
5. ser buen comunicador y dotes para vender en general
6. CAD y CAID (UGX, Catia, SolidWorks, Alias Studiotools, Rhino…)
7. CAM
8. tendencias actuales en general
9. habilidad para sintetizar y resolver problemas
10. que te guste trabajar en equipo (MUY importante)

puede que sean más.. ha sido lo primero que se me ha ocurrido”

Básicamente se trata de otra iniciativa del Gobierno Vasco y el SPRI para “fomentar la innovación” entre las PYMES. Hasta aquí todo bien, quizás un poco chirriante utilizar la palabra innovación teniendo en cuenta quienes son los anquilosados padrinos del invento, pero bueno… soportable.

El via crucis llega cuando te topas con la verdadera naturaleza del asunto. Todo parece preparado para una sociedad del siglo XXI con los cimientos culturales y empresariales de una factoría de hilo del XIX. Así, te encuentras con todo tipos de contrastes incomprensibles que chirrían con solo pasar la vista por encima.

Por una parte dicen:

A largo plazo, sobrevivirán sólo aquellas empresas que sepan diferenciarse de manera permanente a través de innovaciones continuas. No sobreviven las empresas más grandes, sino las que mejor se adaptan. El tamaño no importa: todas las empresas necesitan planificar la innovación.

Por otra:

Los servicios incluidos en el Programa BERRIKUNTZA AGENDAK están dirigidos a PYMEs que tengan al menos un centro de actividad en la Comunidad Autónoma del País Vasco y ocupen al menos, a 6 personas.

¿6 Personas?. ¿Por qué no 5?. Quizás 7. No, mejor 13 que también es numero primo. ¿Acaso es necesario un numero mínimo de empleados para que el cerebro humano asimile el concepto de innovación?, ¿por qué se aparta a empresas como la nuestra de los planes para crear una agenda de innovación?.

Que alguien mire el porcentaje de empresas vascas con menos de 6 empleados y me razone por qué deberíamos dejar a todo ese tejido fuera de los servicios del programa para la innovacion. Por favor.

Tambien se explayan con:

BERRIKUNTZA AGENDAK coloca a las personas como eje central de la transformación de la PYME hacia la innovación sistemática.[...]. La implementación de proyectos que favorezca el desarrollo de personas que lideren la innovación en la empresa y la participación en equipos.

Sin embargo:

El Foro de innovación esta dirigido a “directivos de empresas vascas con al menos 6 trabajadores pertenecientes a cualquier sector de actividad económica.”

Vamos que deben ser los directivos, con su gran visión, los que en su gran sabiduría tracen las lineas maestras de qué, cómo y cuándo se cambian las cosas en su empresa. Nada dicen, en cambio, sobre cómo fomentar estructuras más flexibles en la empresas, cómo acabar con fuerte departamentalidad que asfixia a cientos de empresas tradicionales del País Vasco o como vencer el estigma del “no hecho aquí” tan frecuente por estos lares.

Todo esto, teniendo en cuenta que hablamos de innovación, no deja de ser una interesante paradoja. De hecho… ¡hasta iconografía vacía y hueca hay en el documento oigan!:

En fin. No es que en Linking Paths seamos la bomba a todos los niveles -ni siquiera en algunos- pero sí que creo que nos diferenciamos de otras empresas IT, es nuestra capacidad para estar abiertos al cambio, a la mejora y al resultado de ambos: la innovación. Y creo que en gran parte esto es producto de una de nuestras características mas básicas: nuestro diminuto tamaño.

Somos livianos, ligeros. Entramos en una habitación. Comemos todos por menos de lo que cuesta un taxi del centro de Madrid a Barajas. Decidimos en minutos. Averiguamos que nos hemos equivocado en horas. Podemos instalar (o desmontar) una oficina en cualquier ciudad del mundo en horas. No tenemos ataduras. Podemos cambiar de rumbo sin que todo se tambalee. En resumidas cuentas, nosotros también pensamos que solo sobreviven las empresas que mejor se adapten.

Sólo que nosotros nos lo creemos.

Me da en la nariz que la intención de estas y otras empresas está mucho más cerca de utilizar la “etiqueta” del software libre y sus bajos costes de infraestructura que de impulsar y promover el software libre.

Es muy fácil descargar proyectos y herramientas creadas por la comunidad Open Source y desarrollar proyectos sin que ese abaratamiento de costes -generado gracias al esfuerzo altruista de muchas personas- repercuta de nuevo en la comunidad. Esto es aun más sangrante cuando hablamos de proyectos -casi siempre multimillonarios- relacionados con la Administración Pública y pagados con el erario público.

Para nosotros el software libre es un equilibrio entre lo que recibo y lo que aporto a la comunidad. Para que ésta mejore y crezca (y nuestro negocio con ella) hay que reinvertir, ya sea en proyectos propios, en herramientas para que otros construyan nuevos proyectos o simplemente aportando el conocimiento y documentación que nos sea posible para que otras personas se acerquen y contribuyan con la comunidad Open Source. Se trata de compartir y regalar y no de… acaparar.

Y me consta que no somos los únicos que vemos así el uso de software libre. Nos son cercanos ejemplos como el de Xavier Noria y el equipo que hay detrás las nuevas Rails Guides que están construyendo de manera desinteresada una de las mejores documentaciones técnicas que haya visto jamas, siendo ésta una tarea poco agradecida. O desarrolladores como Raul Murciano que convencen e impulsan entre sus clientes la liberalización de software que ellos han pagado.

Eso es software libre. Y la verdad, dudo que muchas empresas lo entiendan.