Una de las cosas que tenemos que tener claras a la hora de emprender nuestra aventura, es saber cuanto es suficiente. En todo. Cuanto tiempo puedo aguantar con la idea si no despega o cuanto tengo que desarrollar para poder empezar a vender son algunas de las cuestiones que tienen que exigir nuestra atención para no desperdiciar ni tiempo ni esfuerzo. Parece una perogrullada, pero no es así.
Michael A. Cusumano es un interesante autor de varios libros muy interesantes, entre ellos The Business of Software: What Every Manager, Programmer, and Entrepreneur Must Know to Thrive and Survive in Good Times and Bad. En este libro vuelve a mencionar una ida que ya le he leído en otras ocasiones. Según él (y yo comparto), y aunque admite la extravagancia de las generalizaciones (y yo también), existen diferentes culturas empresariales en distintas zonas, incluso las punteras, como puede ser Estados Unidos, Europa y Japón. En concreto, respecto al software, comente que los japoneses van a lo suyo y cuesta que salgan de su isla o área de influencia. Los europeos somos demasiado académicos, y nos gusta demasiado la excelencia y nos preocupamos más de lo que deberíamos de temas de ingeniería, etc. Sin embargo los americanos son mucho más orientados al negocio. No creo que muchos duden de esto, teniendo en cuenta que es una generalización (por ejemplo de los europeos, no siempre aplicable a España), pero apunta a una idea muy importante: aprender de los que saben hacerlo, en este caso los americanos (perdón por referirme así a los estadounidenses, sé que no es correcto). Ellos saben cuanto es suficiente.
Y es que lo que deberíamos tener es el plan de lo que queremos hacer. No deberíamos pensar en terminar las millones de funcionalidades de nuestro software antes de empezar a promocionarlo/venderlo (o intentarlo). Obviamente tenemos que guardar ciertas balas (fallar puede suponer que nos ignoren la siguiente vez), pero no esperar a que todo sea perfecto, porque puede ser demasiado tarde. Los americanos para eso son geniales, y esto va más allá de fiebre de betas que inunda internet ahora mismo. Son capaces de saber el momento en que pueden empezar a vender con ciertas garantías, que es lo que les va a conseguir el dinero suficiente para terminar el resto.
También tenemos que tener claro que no es un fracaso que una idea no cuaje. En la cultura española parece gustar mucho que una idea no funcione, de no premiar a quién lo intenta. Parece que nos tomamos como una ofensa que otro lo consiga mientras nosotros no nos hemos atrevido ni a intentarlo. Esto no debería ser así, pero tampoco tenemos que ser cabezones hasta el final. Tenemos que tener claro cuando la idea no resulta, tener paciencia con ella, pero no tenerla infinitamente. El límite depende de cada uno, pero si queremos aprender algo de la experiencia, tenemos que salir cuando no es demasiado tarde. Reconocerlo y aceptarlo.
El tener claro esto, el tener claro que no es una cuestión de todo o nada, de blanco o negro, sino que hay grises, puede hacer que nuestra aventura sea una experiencia más o menos agradable.
Archive for December, 2006
Beta, muy beta, o más. Pero puesto que ya lo estamos utilizando hace unas semanas, hemos puesto online una versión de pruebas del gestor de proyectos que hemos estado realizando en los ratos libres y que ya comentamos en parte en el pasado. La parte más interesante, la que enlaza el trabajo con la rentabilidad (lease, los dineros) aún no tiene interface gráfica, pero ya es usable para el seguimiento del trabajo.
La idea que sigue es sencilla. Un proyecto tiene grupos de tareas o áreas de trabajo. Cada una de ellas tiene tareas, y cada tarea puede tener bugs. ¿Por qué un bug tiene que ir siempre asociado a una tarea (eso melo han preguntado)?, básicamente porque no debería haber errores en algo que no se ha realizado, ¿no?. Si una tarea o un bug es “trabajable”, entonces se puede introducir partes de trabajo sobre ellas, sólo de las últimas dos semanas, un requisito para que nos vayamos acostumbrando a utilizarlo.
La parte económica, pues bueno, básicamente mide el coste del proyecto, lo compara con el coste de producción, y con el coste de oportunidad, así como ir aprendiendo de estas desviaciones, intentar ver porque se producen, para después detectarlas lo antes posible y dar recomendaciones. Como veís, se nota que tengo más problemas que la simple programación. De esto, como he dicho, nos falta mucho (casi de todo) de la interface de usuario, aunque ya tenemos implementada la lógica en gran parte.
Simplificar la interface de usuario, añadir comentarios varios, control de roles y nuevas opciones, son algunas de las cosas que nos faltan por hacer.
¿Licencia?. La verdad es que es una buena pregunta. No lo tenemos decidido :-D. Opciones:
- liberarlo.
- regalarlo pero no entregar el código, a todos o sólo a empresas pequeñas
- venderlo a todo el mundo.
Como no nos veo con fuerzas para realizar las labores comerciales, la tercera opción no creo que sea (no espero retirarme con este producto). La primera… pues bueno, tampoco quiero perder el control sobre el producto, aunque es un opción. Aunque seguramente sea la segunda opción. El software se podrá descargar gratuitamente, al menos para empresas de menos de 10 personas, y ofrezcamos modificaciones y adaptaciones pagadas porque no ofreceremos el código libremente (notese, no lo haremos libremente ;-) ).
Casi lo olvido…. la URL: http://demo.projectio.com, usuarios admin, pm o employee, todos con password projectio. El tomcat dónde está me esta haciendo algunas cosas raras, pero bueno, no lo tengáis en cuenta, en teoría funciona ;-).
Se aceptan todo tipo de sugerencias, por supuesto, en la parte inferior de la demo tenéis un link para enviar sugerencias.
Aunque no suelo hacerlo, hoy voy a hacer una review de un libro que he leído, que acabé ayer concretamente: Behind Closed Doors, Secrets of Great Management de Johanna Rothman y Esther Derby, parte de la ola de The Pragmatic Programmers. Ya que cada vez mi biblioteca crece más, quizás intente hacerlo de vez en cuando con algunos libros que merezcan la pena.
Me regalaron este libro hace 5-6 meses, poco antes del verano si no recuerdo mal. Libro cortito, 190 páginas, de las cuales sólo unas 115 son texto (si no recuerdo mal) y el resto son recomendaciones, checklist, etc sobre los temas de los que habla el libro. Pero aún así merece la pena por los 25 USD que cuesta (+envío), o los 17 USD que cuesta ahora mismo en Amazon.
De una forma amena, el libro habla de las primeras siete semanas de un nuevo jefe de proyecto en una empresa de desarrollo de software, en las que va pasando por personal descontento con sus tareas, problemas de trabajo en grupo, de planificación, de imposiciones de sus jefes, etc y va proponiendo soluciones. Me escama que siempre le sale todo bien, pero bueno, es un libro ;-). El libro no te va a enseñar a crear listados de tareas, ni a dibujar diagramas de Gantt, ni a supervisar el trabajo de otros, eso cambia de empresa a empresa, lo que va a hacer es mostrarte como afrontar las situaciones a las que tendrás que enfrentarte, la implementación la decides tú.
Si tu experiencia en la dirección de proyectos es pequeña, es un libro lo suficientemente sencillo de leer para que te inicies, aunque con la (desafortunada) fiebre que hay en España por el project, quizás te sientas decepcionado (no esperes una “guía paso a paso para ser jefe de proyecto”). Si por el contrario ya tienes algo más de experiencia, creo que también puedes aprender de ello, porque no creo que apliques la mitad de las cosas que comentan las autoras y que en su mayoría tienen bastante sentido. En todo caso, es barato y se lee rápido, de modo que solo puedes obtener beneficios por leerlo.
En cualquier caso, ten en cuenta que no es un libro para leer y dejar que críe polvo. Es de esos libros que si quieres aprovecharlo tienes que tenerlo cerca, releerlo, consultarlo, absolverlo, hasta que apliques sus técnicas de forma natural.
Conozco pocos casos en las que una empresa pequeñita con varios socios no haya sufrido problemas de diversos tipos entre los socios. Muy pocos. Por eso lo más habitual es que este tipo de empresas tenga un único socio, aunque la mayoría tendamos a intentar evitar esta situación. Dejare para otro día volver a tocar el tema de los socios, aunque ya ha sido tratado en parte. Pero aunque tuviéramos un socio, el sentimiento que tendremos más habitualmente es el de soledad. Soledad antes nuestras familias, antes lo bancos, ante todo. Los problemas son todos para nosotros, las alegrías en seguida las quieren compartir. Porque lo más normal es que nadie acabe de entender porque nos hemos decidido a emprender una aventura de este tipo, o desconozcan lo suficiente sobre nuestro negocio/mercado como para que nos sintamos más arropados.
Es por eso que tendremos que aprender a vivir con esa soledad, con la responsabilidad (el día que contratas a alguien envejeces cinco años a nada que tengas un mínimo de conciencia), con los problemas. Tenemos que evitar que nos desborde, que nos afecte a otros planos de la vida, tenemos que aprender a que no nos bloqueen.
Una vez me contó una persona que conocí, que eres realmente empresario cuando teniendo dos empresas puedes dormir tranquilamente por las noches. No sé si es para tanto, pero en parte tiene razón.
Uno de los objetivos que tenía en mente al crear javaconganas era el de crear una serie de cursos online en los que a través de una lista de correo fomentar el aprendizaje de algunas herramientas interesantes y novedosas. Básicamente se trataría de un temario X, una lista de correo, y mi interés en que la gente aprenda, proponiendo unos ejercicios y alguna cosa más. Algo al más puro estilo de javapassion, aunque de momento los temas serían más cortos y concretos.
La idea sería empezar después de reyes (el 8-10 de Enero?), sin estresarnos demasiado una duración de 2-3 meses, y el primer tema saldría de la siguiente lista:
- Java Server Faces: conceptos básicos, personalización, creación de componentes.
- Spring: Contenedor IoC, AOP, DAO y alguna cosa más.
- JDO/JPA: uso, implementaciones, etc.
Si los amables visitantes de esta web interesados en tomar alguno de estos cursos se molestan en votar sería de gran ayuda. De alguna forma hay que empezar.
Este post puede parecer una obviedad (¡debería ser una obviedad!), pero la experiencia me dice que no es así. Y es que como diría mi padre, en España se estila mucho eso de prometer hasta meter, y una vez metido, olvidar lo prometido (perdón por la grosería machista).
Según las estadísticas y manuales sobre el tema (perdón por no tener un link, cosas del google) conseguir un cliente nuevo cuesta tres veces más que mantener uno que ya tienes. Esto se debería traducir inmediatamente para nosotros en que tenemos que mimar a los clientes que tenemos si es que queremos vivir del software.
Pero esto tiene otras consecuencias. Y es que ese trabajo (si, es un trabajo) nos consumirá también parte del tiempo del que disponemos, de modo que tenemos que hacerlo lo mejor posible. Deberíamos disponer de herramientas de comunicación con los clientes, aunque eso empiece con una base de datos con sus correos bien organizados así como un mínimo seguimiento de nuestras conversaciones con ellos. No hace falta que sea un CRM complejo, pero si demostrarles que nos interesamos por ellos.
Pondré un caso de ejemplo. Projectio PM es un software de simulación de exámenes para una certificación que mi empresa sacó a la venta en compañía de otra especializada en gestión de proyectos. Es muy poco probable que un cliente que compre repita, pero sin embargo un cliente que compre si puede promocionar la herramienta para que se produzcan más ventas. Nosotros nos encargamos de hacer un seguimiento de las ventas y comunicarnos con ellos pasado un mes para preguntar sobre como van en su camino hacia la certificación, de preguntarles posibles mejoras, de explicarles las cosas que no entienden, de felicitarles cuando obtienen la certificación, etc. Eso hace que tengamos buenas críticas, y que aparezcan empresas como PMV con interés en distribuir la herramienta, lo que genera más mercado.
Si nuestro software tiene el suficiente empaque para que nuestros clientes lo usen a diario, lo más normal es que acabemos haciendo más dinero gracias al mantenimiento y las actualizaciones que a la venta de nuevas licencias o adquisición de nuevos clientes. Deberíamos tener desde el principio en nuestra cabeza la necesidad de mantener cierta comunicación con ellos, pero sin olvidarnos de todo lo referente a sus derechos para dejar de participar en ella, etc. Para facilitarnos este tipo de cosas podemos usar productos de pago por uso como por ejemplo GraphicEmail (¡no me llevo nada!, es un ejemplo).
Pero además de venderles el producto, tenemos que hacer que lo usen sin ningún tipo de problema. Como somos buenos profesionales, seguro que nuestro software funciona bien, no tiene problemas, etc. Seguro. Pero lamentablemente en el mundo imperfecto de la informática nuestros clientes tendrán configuraciones tan variopintas en sus sistemas que harán que nuestro software no funcione tan bien como debería.
Un ejemplo sobre esto dentro de Projectio PM sucedió con Jane Klein, una cliente brasileña. Una mala configuración en su ordenador impedía que se pudiera activar correctamente la herramienta (tenía configurado el Word como navegador WWW por defecto). Comprensiblemente, este problema justo después de pagar 100 Euros por un producto, le llevó a escribirnos al correo de soporte un mail quejándose de que no podía prepararse para su muy cercano examen. Tres mails después su enfado se había convertido en agradecimiento y su review sobre el producto era muy satisfactoria.
Las labores de soporte, por ásperas y desagradables que parezcan en ocasiones, son vitales en el apoyo al punto anterior de este mismo post: hacer que tus clientes vuelvan a comprarnos o nos recomienden. Por muy bien que nos parezca que hemos explicado el funcionamiento de nuestro programa, por muy sencillo que sea de usar, por mucho tiempo que hayamos invertido en realizar un vídeo paso a paso, el cliente tiene su propio contexto (sistema, experiencia, conocimientos, etc.) y puede tener problemas. Deberíamos tener muy claro que un simple RTFM o tardar tres días en contestar un email no es una opción para alguién que ha pagado la cantidad que sea por nuestro software.
Otro día más. Simplemente recordad que para vivir del software, alguien tiene que querer comprarlo, y eso se consigue sumando muchas cosas.
Cuando empiezas tu aventura empresarial, se suele decir que no es lo mismo crear un negocio que un trabajo para ti. Lo primero sería una empresa en el estilo tradicional, lo segundo una forma en la que tú ganes dinero (no quiero decir que no lo puedas ganar de la primera forma). No hay nada intrínsecamente malo ni en una opción ni en la otra, simplemente tienes que saber que estas creando, porque las necesidades son distintas.
Si lo que hacemos, sea lo que sea, no puede sobrevivir sin nosotros, no estamos creando un negocio, estamos creando un trabajo para nosotros mismos. Un negocio no para, esta en marcha y continuamente tiene que producir. Si trabajas para ti, tienes tu tiempo, y tú decides en que te metes porque no podrás hacer más.
Puede parecer lo mismo, pero no lo es. Aunque de cualquiera de las dos formas seas (casi) imprescindible, al crear un negocio tienes que tener claro el camino que sigues, lo que haces/vendes y dónde quieres llegar. Si trabajas para ti, simplemente realizas una función (formar, vender un software, etc. lo que sea) para aprovechar una oportunidad, pero no podrás crecer. Es una cuestión de chip mental, simplemente tienes que ser consciente de ello. Si trabajas para ti sin creer que es eso lo que haces, o si eres un negocio sin un objetivo claro, lo que te sucederá es que estarás siempre escuchando cantos de sirena, sobre otras opciones, otros trabajos.
Por supuesto nada impide evolucionar de un estado a otro, de hecho con recursos limitados y simplemente una idea, es difícil empezar en cualquier caso, pero dentro de la idea de centrarse que ya hemos comentado, el saber lo que eres y dónde quieres ir es el primer paso.
Lo tengo que reconocer, y es que al tercer intento (uno incluso publicado), estoy viendo algo en Eclipse y empiezo a sentirme a gusto con él, entendiéndolo más o menos. No quiero decir con esto que sea la herramienta definitiva, pero ha ganado puntos en mi consideración, lo tengo que reconocer.
¿Pero que ha cambiado esta vez respecto a las dos anteriores?. El tiempo, la dedicación. Esta vez lo he podido usar sin la presión de tener que realizar otras cosas, sino con la única intención de aprender a hacer cosas con él. La verdad es que la colección de plugins esta muy bien, hay poca cosa que eche de menos respecto a Netbeans, que es lo que más he usado en muchos años.
Lo que menos me gusta es que me parece que en Mac OS X sigue estando por debajo respecto a Windows en algunas cuestiones, pero bueno, nada vital a día de hoy. Eso y que quizás es menos usable (entendido como poco natural) que Netbeans, pero bueno, es cuestión de acostumbrarse.
Hace ya unos meses, mi autodeclarado familiar y un servidor hicimos el experimento de usar screencast para enseñar algunas cosas en el master de la universidad de Deusto en el que damos clase. Si no recuerdo mal, hicimos alguno sobre el uso de eclipse, implementación de algunos patrones de software y alguna cosa más, no recuerdo exactamente.
El caso es que la experiencia nos mostró varias cosas…
- Son mejores que PPTs y pantallazos.
- El hecho de que haya partes menos útiles, les resta “interés” para mostrarlos en vivo.
- La mayoría de los proyectores tienen una resolución muy mala.
A pesar de todo esto… les encuentro mucho interés como material de apoyo. Sobre todo para su consulta de cara al futuro, aunque habría que añadirles algunos comentarios, hablados o escritos, o como poco una pequeña explicación del vídeo. Pero cuando te estás iniciando en algo, me parecen bastante interesantes.
Además tienes la ventaja de tener que realizar el ejemplo completo, con lo que:
- Te aseguras que el ejemplo tiene un mínimo de sentido.
- Como has hecho el ejemplo, puedes entregarlo a los alumnos, y si es comentado, mejor.
Pero repito, casi mejor que no te empeñes en darle al play y quedarte mirando, hay demasiadas partes poco interesantes. El caso es que he realizado unos screencast más, sobre varias partes Spring, y estaba pensando en publicarlas en java con ganas, pero me da cierto reparo. Estaba considerando varias opciones para publicarlos, por ejemplo S3 de Amazon o el propio YouTube. A ver si tardo poco en tener una conexión a internet decente aquí en Madrid y puedo subirlos.
Ultimos comentarios
Darwin, Yomismo, Marcelo, ibon, oscar ordoñez
» Flatee.com o cómo crear un proyecto en internet, ¿Buscas un piso compartido? at Linked, » Trabajando con Linking Paths, ¿Qué queréis saber de Linking Paths? at Linked, alberto, Jose, aitor, Jose, De Linking Paths a la Formula1 at Linked, Dani [...]
plunchete, M@k, el Buscaimposibles
¿Buscas un piso compartido? at Linked
Jesus Chuda Contreras, Angeles, Ger, Pedro, Alfonso, Windzor, javier, xelha
Cerramos el trimeste (2/2008) at Linked, Goio Telletxea, Sergio, el primo, alberto, raultxi