<- Volver al listado
Un fracaso y un éxito en Plastic SCM: -1 el duro negocio import/exportEl 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.
Era 2010, nuestro cuarto año de empresa y de desarrollo de Plastic SCM. Teníamos algunos clientes fuera de España desde 2008 y llevábamos 1 año con inversión de Venture Capital (Bullnet). Estábamos ansiosos por capturar más clientes y demostrar el potencial del producto… y del negocio.
Y para eso, ¿qué mejor que poder facilitar la vida a la gente que malvivía con Subversion? ¿No estarían mucho mejor en Plastic? Así que desarrollamos un importador. Ya sabes, una de esas cosas que coge los datos de un sitio y los mueve a otro. Muy fácil.
Bueno, ya sabes lo difícil que es explicar a tu familia a qué te dedicas cuando trabajas en software, pues imagina cuando haces un control de versiones. Así que, por aquellos días, recuerdo que casi todos decíamos que nos dedicábamos a la importación. Porque lo de importar datos de otro sistema, al menos de un control de versiones diferente, de fácil no tiene nada.
Los importadores son el infierno, lo mejor que puedes hacer es lo mínimo que el usuario espera: que esté todo bien. Es decir, para ti, como desarrollador, que esté casi todo, con lo que te ha costado, ya es mucho. Así que cuando ves una importación que va perfecta te esperas por lo menos una ovación del usuario y entonces ves que te mira (aunque sea por email, lo ves) con cara de “vale, está todo, qué menos, ¿no?”.
Y la mayoría de las veces no está todo, falta algo. 1 rama de las 2500 que tenía. Unos pocos ficheros. Algo. Así que: “falla”. Que esté 95% bien, en realidad, para el usuario es que falla. Punto. Luego, si se mete de lleno en el sufrimiento y quiere usar el producto, igual hasta empatiza y ve estupendo un 95%, pero de primeras es que falla.
El bueno de SVN se parece a Plastic por dentro en que ambos son software, y los ha hecho gente, pero poco más. Así que encajar una “rama-directorio” de SVN con una “rama-mundo- paralelo” de Plastic muchas veces es un dolor. No vale con “select * from SVN” y “insert into plastic”, no. Hay que aplicar heurísticas, adivinación, artes oscuras…
Como digo, lo mejor que puedes hacer es que funcione normal.
¡Ah! Y si logras que funcione normal, que haga lo que tiene que hacer… es muy posible que sea lento… ;-)
Vamos, que no te metas.
¿Qué sacamos en claro? No hagas importadores.
Vale, eso no era posible del todo, porque la gente seguía esperando que les ayudases a migrar a tu mega sistema… ¡¡y no querían programarlo ellos!! :-)
Así que:
Desliga la evaluación de la importación. Si tu importador tiene riesgo de no ser perfecto/trivial, es muy posible que pierdas al cliente antes de que haya visto tu producto de verdad. ¿Cómo lograrlo?
Recomienda completar una serie de pruebas X antes de importar. Aquí soporte/preventa/documentación/”primeros pasos de tu producto” son cruciales. Recomienda (por cualquier medio) que prueben A, B y C antes de ponerse a importar, para ver lo bien que va todo, para ver si les encaja. La gente lo entiende, tiene sentido. Todos han importado antes, casi seguro.
Pero no crees la falsa expectativa de “se importa en un momento” si no es verdad. Controla también al cliente: muchas veces la gente quiere probar sus 3TB de repositorio antes de ver cualquier otra cosa, y a veces hasta teniendo dudas de si realmente quieren toda esa historia.
Ofrece ayuda durante la importación: mejor “perder” tiempo en soporte, que perder al posible cliente. Déjalo claro: te ayudamos a importarlo, y te conectas con ellos en remoto y lo haces. Mejor eso que un ping-pong infinito de correos que hacen que el posible cliente esté harto de ti cuando todavía ni ha visto para qué quería el producto.
Usa un estándar (si puedes): en nuestro caso nos cargamos el importador de SVN y de CVS y nos quedamos con un soporte del formato fast-import/export de Git. Estándar, todo el mundo lo usa… estupendo. Y pudimos probar con +20mil repositorios open source para ver que iba bien.
Por supuesto, esto no habría valido tanto en 2010, ni nos vale muchas veces para mover equipos de Perforce con “teras y teras” de datos (especialmente en videojuegos). La primera opción sirve en estos casos :-)
Puse las expectativas muy altas con el título, ¿no? Import/export y los cohetes.
Pues el fracaso de los importadores se materializó de forma bochornosa de la siguiente manera...
Un buen día de mayo de 2010 nos contactó una empresa de Estados Unidos diciendo que querían migrar su SVN a Plastic, pero que estaban probando el importador en Linux y que no había manera.
La empresa debía ser pequeña, no la conocíamos de nada. Es más, por el nombre parecía uno de esos sitios web porno o algo, un espacio raro, y buscando no salía nada. Estaría en montaje.
Así que un par de correos para arriba, para abajo, que no va, que sí, que cambia este parámetro, que te hacemos una demo, mejor primero terminamos de importar, vale, nos conectamos para ver por qué no va, es viernes por la noche, venga, vale, se conecta alguien, esto no va… y nunca más se supo de ellos.
La empresa, como os dije, tenía nombre raro. SpaceX.
Me tiro de los pelos cada vez que me acuerdo.
Me estoy tirando de los pelos ahora mismo.
El tío firmaba así: F9 Software RE – SpaceX.
Este es el ejemplo de fracaso, el siguiente post contará un éxito!
Pero si quieres conocer más sobre cómo trabajamos, mientras esperas al próximo post, hemos escrito hace poco una serie de posts contándolo
Y si quieres conocer al equipo que hace posible Plastic SCM y SemanticMerge, puedes echar un vistazo aquí.
Finalmente, siempre estamos buscando gente nueva para el equipo así que si te interesa trabajar con nosotros.
