bitácora de uno

Hablo mucho con mi amigo Fernando sobre fotografía, y más desde que está hiendo a un curso bastante largo y parece que profundo; de volumen. Siempre discutimos sobre si es necesario tener una cámara de 1.000, 3.000 o 6.000 euros en lugar de algo con precios más asequibles.

Made with Slideshow Embed Tool

A mi me parece que en estas cosas, y en tantas otras, estamos más preocupados por los detalles que por la esencia de las cosas. El otro día me contaban que con la cámara ACME-100 podías sacar fotos de “2 por 4 metros con una calidad acojonante, tío”. Ya, ¿pero cuántas fotos has ampliado de esos tamaños?

Y así docenas de ejemplos: que si los objetivos, que si los flashes, que si el software de retoque, que si mil millones de mierdas. Cuando una fotografía te ha salido bien, le pasas los retoques y casi no cambia, no mejora.

Esto es lo que creo que pasa en más de un campo; nos vamos a los accesorios, a lo accesorio, cuando con una buena esencia lo demás casi no importa.

Pienso en equipos de trabajo, pienso en empresas, pienso en el diseño de base de un buen software y tengo la misma sensación.

Además todos esos accesorios, alimentan un mercado. ¿Cuántas cursos o artículos no hay sobre recetas para triunfar en el área que sea?

• 10 consejos para ser un buen líder
• Cómo conseguir inversión para tu empresa tecnológica
• 20 puntos para hacer una buena presentación
• 3 reglas para hacer fotografía
• Lista de software para triunfar como emprendedro
• Cómo petarlo todo, todo

Y así sin parar. Hombre un vistazo a este tipo de artículos y un filtrado por el tamiz del sentido común no viene mal, pero si empiezas a leer más de tres de estas recetas sobre un mismo tema, verás que se contradicen. Claro.

Unas palabras de Fernando Pessoa en el “Libro del Desasosiego” vienen al pelo:

Hacer, esa es la inteligencia verdadera. Seré lo que quiera. Pero tengo que querer lo que sea. El éxito está en tener éxito y no en tener condiciones para el éxito.

Menudo personaje este Pessoa, ¿eh?

Fue Andrés Leonardo desde Telefónica I+D y más en concreto desde el Proyecto Morfeo quien nos ofreció hace unos meses impartir un seminario sobre Osmius y hacerlo público.

Lo que inicialmente iba a ser un mini-curso privado para los administradores de la plataforma de Servidores y Servicios de Morfeo, se convirtió en un seminario de dos horas al que asistieron varias docenas de personas, y algunas más en sedes remotas gracias al apoyo técnico y a la retransmisión del vídeo y del sonido.

Seminario Osmius from morfeo on Vimeo.

Desde el equipo de Osmius impartimos formación sobre el producto que consiste en un par de días de teoría con prácticas diversas y acaba con un exámen para quienes quieran certificarse y acceder al grado de Partner Platino. Normalmente, claro está, cobramos por ello.

En este caso no hemos cobrado, cierto, pero indirectamente sí es así por las siguientes razones (según se me ocurren las escribo):

• Difusión: Más gente nos conoce, y esto es bueno porque Osmius es un buen producto.
• Contactos de Negocio: Al menos hay planes para dos contactos con entidades nuevas para nosotros
• Experiencia: Nos hemos visto obligados a preparar un seminario de dos horas al menos decente y han participado varios miembros del equipo
• Material: Tenemos, gracias a TI+D, un vídeo que puede servir como introducción a Osmius sin que se requiera a ningún humano desde uno de los lados.
• Críticas y Mejoras: Al hacerlo delante de “gente” ha habido preguntas y sugerencias que ya se están implementado en los ciclos de desarrollo Scrum

Así que gracias a Andrés, a Irenka, a la gente de Morfeo y a Telefónica I+D y a la iniciativa de fomentar y soportar tantos proyectos software libres interesantes (sólo me han faltado, en plan Nadal, los recoje-pelotas).

En el equipo de desarrollo de Osmius utilizamos como metodología Scrum, que como ya he mencionado no es más que sentido común estructurado.
En alguna ocasión hemos usado Google Wave para hacer las reuniones diarias de Scrum, pero como éstas siguen un orden cronológico claro es mucho más sencillo utilizar culaquier herramienta de Chat y dejar Wave para cuando queremos “discutir” algo a base de teclado.

Os pongo la reunión diaria de hoy, cuarto día del Sprint de Osmius para la versión de julio de 2010 (Osmius 10.07):

[08:16:38] Joselu: Bueeeenossssss diiiiiiiaaaas!!!
[08:17:02] Cesar: buenasss
[08:17:12] jpan: hola;
[08:17:17] Joselu: César: Ayer y hoy;
[08:18:13] Cesar : ayer: empecé la migración de los datos de la .com pero no me dió tiempo a verlo con David todo asi que me puse con otras pantallas: agents y formularios
[08:18:22] … problemas: 0
[08:18:29] … retrasos: 1 hora de adelanto
[08:18:43] Joselu: Ok. Jesús?
[08:18:47] Cesar: hoy: terminar agentes y documentación que no me queda nada
[08:19:05] … y dependiendo de si viene David seguiremos viendo lo de la migración y si cojo otra pantalla
[08:19:10] … si no
[08:19:17] … ;
[08:19:20] jpan: Ayer: Terminacion mediante eventos windows de procesos servidor y master agent
[08:19:31] … Hoy: Terminacion mediante eventos windows de agentes
[08:19:36] … Problemas No
[08:19:39] … Retrasos 0
[08:19:41] … ;
[08:19:49] Joselu: Ok, Chico?
[08:19:54] Chico: ayer: test migración JDBC Template y Acentos Consola
hoy: Acabar Acentos Consola y Librería ficheros .ods
problemas:no (pero en mis pruebas con 2 equipos no consigo que me peten los acentos)
retrasos: 5 horas adelanto;
[08:20:15] Joselu: (usa el de Jeśus ). Manuel?
[08:20:22] Manuel: ayer: oracle, soporte e instaladores
hoy: oracle, soporte
problemas: no
retrasos: no
[08:20:33] Joselu: Ok, yo?
[08:21:00] … Ayer: Terminé de definir los eventos y me enteré mejor de lo que van los aparatos eléctricos.
[08:21:32] … Hoy: Desarrollar uno de los agentes (si me da tiempo hago dos, sino lo vemos en el siguiente Sprint).
[08:21:39] … Problemas: No
[08:21:44] … Retrasos: 0
[08:21:46] … FIN
[08:21:55] … Preguntas, temas?
[08:22:06] jpan: Nonaino
[08:22:13] … a currar
[08:22:14] … besos;
[08:22:36] Joselu: Daos de alta en el Campus de Escuela de Groovy, si queréis;
[08:22:43] … Bye;

Osea que en 6 minutos ya sabemos como vamos y nos ponemos a currar, a tachar tareas.

Parte de las labores en el departamento de I+D en el que desarrollamos Osmius son las de decidir hacia dónde vamos.

En nuestro caso trato de plantearlo, de forma profunda y sin permitir tabúes, al menos una vez al año. La idea es no casarnos con nosotros mismos y tampoco con ninguna tecnología, o dicho de otro modo dejar que surjan dudas y luego intentar resolverlas con argumentos.

Algunas preguntas tipo que nos hacemos son:

• ¿Tenemos que cambiar profundamente alguna parte del desarrollo?
• ¿Debemos orientarnos hacia el Software como Servicio?

Pero de igual manera trato también de que nos replanteemos la tecnología que utilizamos y no sólo el roadmap de producto, aunque es verdad que en el desarrollo de software están bastante relacionados.

En una de éstas me di cuenta de que el desarrollo de la parte Web de Osmius, era lento, pesado, poco ágil y no por la gente de equipo sino porque es algo farragoso, editando 15 xmls para hacer una pantalla de mantenimiento de toda la vida y otras lindezas imperdonables. Un salto atrás en el tiempo si pensamos que con Visual Basic 3.0 ya era fácil desarrollar pantallas hace tropocientos años (unos 10, que en TI representan eones).

En éstas contacté con Álvaro y Nacho de Escuela Groovy para que primero nos convencieran razonando para utilizar Grails y Groovy y, segundo, para contratarles un curso que nos sirviera de comienzo. Finalmente hicimos el curso y estamos trabajando para aprender e incorporar la tecnología a nuestros desarrollos.

La razones de la elección se apuntan en las siguientes líneas:

El Producto: Osmius es un software de Monitorización de Sistemas y Servicios que tiene componentes:

• Procesos del “core” para monitorizar a toda velocidad y con poca carga -> C++
• Consola Web Java + Spring + Hibernate + JQuery + Spring Security con más de 50 pantallas y Web Services.
• Más 130 tablas en el Modelo de Datos.
• Metodología de trabajo Scrum

Necesidades a cubrir:

• Aunar la agilidad que ya disfrutamos en la metodología con el desarrollo.
• Peticiones de los usuarios: Más rápido, J2EE es muuuuyyyy lento.
• Actualizar a los Dinosaurios (equipo C++) y a los Cromagnones (equipo Java)

Grails y Groovy porque:

• La sintaxis de groovy no es extraña para Dinosaurios ni Cromañones.
• Podemos integrar Scripts de groovy en la monitorización (cuando el rendimiento salvaje no sea un problema).
• Reutilizamos conocimiento de Cromagnones: Spring, Hibernate, etc.
• El rendimiento no nos preocupa porque el core es C++ y tenemos muy optimizadas las sentencias a BBDD.

Curiosidades:

• Cromagnones: Están encantados, sobretodo con no tener que tocar quince XMLS cada vez.
• Dinosaurios: Están horrorizados. “El desarrollo Web es un infierno” (Vienen de Visual Basic: Arrastro control, click, código).

Ahora estamos dos del equipo en el evento sobre Spring y Grails en Madrid 2010: Spring2GXDay

El año que viene volveremos a ponernos en duda. Ya os contaré. ¿Roo, quizás? (No creo)

Este pasado viernes por fin nos reunimos para discutir y tratar un tema que llevábamos tiempo con ganas de compartir:
“Buenas Prácticas para Empresas con Producto Software”

Lo que inicialmente iba a ser un café técnico con Daniel López de BitRock, acabó siendo una reunión de 15 personas en el Bar Arrebato en Madrid,que Fernando tuvo la amabilidad de abrir en exclusiva para nosotros. El formato no estaba claro pero sí queríamos evitar que cualquiera, yo el primero, les diera una charla unidireccional al resto; no queremos Conferencias, queremos Des-conferencias.

Aunque finalmente no se des-organizó como tal si creo que cumplió aquello de ser concreta y que permitiera exponer inquietudes y escuchar a todo el mundo.

Algunos temas que se trataron:

• ¿Hay un modelo de negocio para el OpenSource?
• ¿Es posible no abrir al menos parte del producto sin dañar demasiado las posibilidades de éxito?
• La nube ¿es una moda? ¿cómo aprovecharse o mejorar o preparar nuestros productos para ella?
• Seguimiento de potenciales clientes en la Web: ¿Cómo seguirlos? ¿qué herramientas nos ayudan?
• Software como Servicio: ¿Es lo que va a quedar? ¿Cuándo entrarán las grandes empresas españolas?
• Producto y Estrategia ¿Cómo definimos objetivos y el plan anual (y presupuestos)?
• Reparto de esfuerzos y recursos: Desarrollo - Marketing - Ventas
• [usad los comentarios, si queréis para completar esta lista]

Todo en un ambiente relajado pero no por ello dejó de ser atento, intenso.

Tuvimos participaciones de fuera del Grupo TiBi como la de Justo Hidalgo y la de Marc Fleury y creo que para las siguientes vamos a abrir esto a más gente interesada aunque siempre con invitación y nunca multitudes. El “Community Management” amenaza ya como tema para una desconferencia en Marzo de este año.

Volviendo al título del post y en lo que respecta al secreto, éste - si es que existe - sigue siendo un secreto. Cuánta gente y consultoras no viven de la consultoría de la obviedad: dicen obviedades que por obvias parecen interesantes y así justifican facturas desorbitadas cuando al final no suele haber más secreto que trabajo, sentido común y suerte.

En el último año he conocido a varios emprendedores que han conseguido el éxito de sus productos, y en todos los casos han hecho referencia a la suerte. Trabajo, buen hacer y cariño seguro que no han faltado pero todos coinciden en no basta con eso y que el ingrediente que falta muchas veces no depende de nosotros y por eso lo llamamos suerte.

El cierto momento de la desconferencia, se habló de invitar a diez personas a las que les ha tocado la lotería para unas “Jornadas de Secretos para el Éxito en los juegos de Azar”.

A buen entendedor ….

-

Algunos links:

• The Four Steps to Epiphany de Steve Blank
• Lean startup de Steve Blank
• HeadCount en Joel on Software
• ¿Ideas o trabajo? (via I. de Gracia)
• [más en los comentarios, quizás]

Ya viene siendo tradición quedar con el amigo Miguel para que nos ilustre con sus incisivos comentarios a cada versión del producto, dado que tanto él como Alberto (otro de sus secuaces) dominan aquello que se conoce como Monitorización de Sistemas.

En este caso vamos a mostrarle a él y a otros (estáis invitados quienes leéis este texto) un Osmius muy evolucionado en el que hemos acentuado la usabilidad - vamos que sea fácil de usar y de entender - y sobretodo queremos enseñarle el manejo de traps SNMP en particular y en general a Osmius como herramienta de Monitorización amplia. Capaz.

El plan es como sigue:

• Quedamos es mi casa a la hora de comer
• Mostramos la aplicación: Respaso de Conceptos y Puntos fuertes
• Vemos cómo funcionan los traps y cómo le damos una pana a los productos de HP o IBM o a Nagios, etc
• Tomamos notas de las cŕiticas y las sugerencias; Y sin rechistar
• Dejamos que la conversación vaya a donde tenga que ir

En esta ocasión el vino es Caliza 2006 D.O. de pago Dominio de Valdepusa

Empezaremos a eso de las 15:00 y nos solemos liar hasta las 20:00 en casa y sin límite fuera de casa.
Eres bienvenido/a con la sóla condición de que avises para la intendencia y que te guste o aguantes una reunión entre técnica y dispersa, de creativa a friki.

Siempre he sido un defensor de la regla 80-20 que en el fondo no es regla sino concepto.

Para quien no se haya tropezado ya con ella, una forma de expresarla aplicándola a un producto software, cambie el lector el objeto a su antojo, sería que de todas las funcionalidades o características deseables del producto hay un 80% que le van a dar el máximo de amplitud, de clientes, de usuarios, y que el 20% restante te va a añadir pocos usuarios y que sin embargo el esfuerzo en implementarlo es mucho mayor.

Basándonos en esta regla, en el equipo de Desarrollo que coordino, priorizamos las funcionalidades más básicas y sencillas sobre las más específicas y complicadas. Así y a lo largo de los años, conseguimos un producto: Sencillo y Evolutivo.

Esto, en un proyecto complejo, no es ni bueno ni malo: Es necesidad.
Hay tanto que hacer que de esta forma evitas perderte en marasmos y haber echado medio año del trabajo del equipo en no sé qué característica que añadida.

Osea, una vez que tenemos las funcionalidades básicas, bien implementadas, con una buena ingeniería de componentes, usable y extendible, evitamos la especialización cuando es dolorosa y larga de desarrollar.

Además, en el caso de Osmius, estamos hablando de Software Libre, y esto quiere decir que tu modelo de negocio se basa en servicios, uno de los cuales es precisamente desarrollarle a alguien esa funcionalidad “Tipo 20%” de forma remunerada. Tienes una base, ese 80% o una parte de él, libre y dejas las personalizaciones o las tareas complicadas para quien las pague. Es un asunto de retorno de la inversión o de optimización del esfuerzo, que viene a ser lo mismo.

El problema es cuando se convierte uno en un Ochentacentista para todo. La regla anterior está bien, pero en ese 20% final está la diferencia entre la mediocridad y la excelencia, y cada una de ellas tiene su momento.

En el caso anterior queda claro que la mediocridad tiene su momento y su utilidad. Nos ha permitido priorizar y crecer de forma que mejoremos las posibilidades de éxito del proyecto, pero no podemos mantenernos en la misma línea en otros casos.

Rafael Nadal no deja de ir a por el 20% de las bolas en un partido de tenis. Va a por todas, busca el 99% de efectividad. Por eso es un top10.
Creo que de igual forma hay que comportarte ante otras situaciones como el desarrollo personalizado a un cliente, la preparación de una charla de venta importante sobre el producto, la redacción de una oferta o el soporte a alguien que tiene un problema.

Ahí no quieres ser mediocre, o yo no quiero o no me parece buena política para ser sostenible, rentable; no quiero dar un soporte al 80%, ahí no quiero ser del montón porque ser diferente es lo que vendo, pero igual que lo venden los demás. Qué comercial no dice de su producto X que los profesionales son los mejores, que si bli, que si bla.

Resumiendo: La regla 80-20 está muy bien, pero hay momentos y situaciones en que puede ser contraproducente, puede coartar buenas ideas y puede ser un impedimento para hacer algo realmente bien y que además sea lo que marca la diferencia en entornos competitivos en los que a menudo nos encontramos.

Detonante | Why the 80 20 rule is wrong
Detonante | For CIOs: 2010 will require new emphases on customers, revenue, external information, and a passion for rapid change

Vamos a presentar los resultados del trabajo conjunto del último año entre la Facultad de Informática de Universidad Complutense de Madrid y el Departamento de I+D de Peopleware.

En este caso se trata de aplicar la predicción de tendencias y el reconocimiento de patrones a los elementos monitorizados por Osmius para responder a preguntas como:

• ¿Qué elementos de entre todos los monitorizados tienden a tener problemas a la vez?
• ¿Qué es más probable que se caiga en las próximas dos horas en función del histórico de datos de Osmius?
• ¿Hace el sistema lo que tiene que hacer? (Validación formal)

El título en inglés del artículo con la discusión y los resultados del trabajo es:

Trend prediction in network monitoring systems:
performing sequential pattern mining in Osmius
monitoring tool

Lugar:
Facultad de Informática - Aula 6
Universidad Complutense de Madrid

Cuándo:
Jueves 15 de octubre
11:00 AM

Estáis tod@s invitad@s
En breve pondremos por aquí el artículo completo.

Montones de nuevas funcionalidades gracias a:

• Un equipo de gente con cierta responsabilidad y cierto control
• No somos demasiados
• Foco y metodología Ágiles

Vamos como Motos | Osmius 9.09 1

A veces estas cosas entran más por los ojos que porque le expliques a alguien todo el curro que hay por detrás.

Todos los del equipo de Osmius estamos empujando detrás de esto, pero es justo que haya mención especial a César Silgo.

Más | Osmius Móvil::Wiki

¿Mola?