Ahora dispongo de dominio propio "softinspain.com" y desde allí reemprenderé este blog.
Muchas gracias a blogia por su servicio desinteresado durante el tiempo que lo he utilizado, gracias a Roberto por su dedicación.
Nos vemos en http://softinspain.com
Estoy viendo que se avecina una nueva decisión "drástica", similar a la ocurrida cuando se pasó de programar para MS-DOS a Windows. Ahora nos toca pasar del API de Windows (Win32) a otra "plataforma". Microsoft se ha empeñado que sea .NET, y parece que lo va a conseguir, pues nada, habrá que ponerse las pilas, remangarse y meterse en harina.
Pero... ¿Que lenguaje utilizamos? ¿Que entorno de desarrollo? Hay muchas opciones, como lenguaje parece que la "estrella" es C#, aunque ya hay implementaciones para .NET de Python, Ruby, Delphi, y unos cuantos más (lista completa aquí)
En la empresa trabajamos con Delphi, por lo que debería ser la elección natural, pero dadas los últimos fiascos con Borland, dada la baja popularidad de Delphi respecto a otros lenguajes, me estoy planteando si no deberíamos ver otras posibilidades, que creo se reducen a C#.
Luego está, para complicar un poco más la decisión, el tema de mono, que aporta la multiplataforma, que dados los últimos movimientos de Apple igual dentro de un par de años es muy interesante.
Resumiendo, que otra vez toca reciclarse o morir, es lo que tiene el progreso.
P.S.: Estoy unos meses sin publicar y el mismo día dos... Bueno, lo prometido, una vez a la semana.
Bueno, muchos meses sin escribir (casi un año) y lo primero que pongo es uno de esos "meme" que van de blog en blog... Juanjo (mas que código) tiene la culpa.
Me gusta el cine, pero mis gustos son muy normales, nada "raros", a mi me tira más la lectura.
Vamos allá:
Número de películas: Buff... antes muchas, ahora menos. A ver, si desde los 16 hasta los... 30 vi una media de 1 al mes en el cine, pues salen unas 168, si sumamos que desde los 27 (desde que me casé) y contando que tengo 36, habre visto una cada dos semanas en VHS/DVD pues... unas 240 mas. Total unas 400
Última comprada: Pues he de decir que ... ninguna. No he comprado nunca un DVD o VHS de película.
Última que vi: En el cine "La venganza de los sith", en DVD/DIVX ;) "Ocean's twelve"
Próxima que voy a ver: En el cine seguramente será "La guía del autostopista galáctico", y en DVD/DIVX/SVCD, pues no se, seguramente "El reino de los cielos"
Cinco pelis que re-veo un montón o que tienen algún significado para mí: "Forrest Gump", coincido con Juanjo en "El violinista en el tejado", "Matrix" (las tres), "Sin perdón",
Cinco víctimas más: Esto va a ser complicado... Xavi Caballé, Mundo Geek, "El Faristol" de Jordi Mas, Enrique Dans, y ya está.
Ah! Prometo que voy a volver a escribir, por lo menos una vez a la semana. Gracias Juanjo.
Leyendo un post de hace unos días en Cyberf ,aqui, me recuerda una "batalla" que he tenido siempre con mis jefes, clientes, empleados, etc. el tema de facturar, cobrar, vender "horas".
Ahora que estoy en el bando de "los jefes" entiendo porque se hace, hay varios motivos:
Comodidad, me explico, controlar horas es fácil, entras a las 09:00 y sales a las 14:00, son cinco horas.
Igualdad, cinco horas son cinco horas para todo el mundo, medimos a todos con la misma medida.
Cultura, la gente está acostumbrada a trabajar dentro de un horario, de hecho obligan a las empresas a tener el calendario laboral donde se especifica el horario de trabajo.
Ojo, no digo que esté de acuerdo con esto, sino que ahora lo comprendo. Controlar el trabajo mediante horas y horarios es más cómodo y sencillo para todos, controlar el trabajo por objetivos implica que el jefe debe entender lo que hacen los empleados, deben existir indicadores claros del trabajo realizado y tanto la empresa como los trabajadores deben aceptar el retribuir/cobrar de forma variable, a tanto trabajo realizado tanto dinero, y eso es complicado.
Al implementar un sistema de retribución por objetivos hay que ir con mucho cuidado de retribuir a quien haya que hacerlo y no que unos se tapen con la manta de otros. Los objetivos deben ser claros, medibles y que no entren valoraciones personales, sólo trabajo realizado, teniendo en cuenta los factores de cantidad y calidad. Los objetivos deben entenderlos, comprenderlos y aceptarlos, tanto los que realizan el trabajo como quienes lo controlan.
En el desarrollo de software no me gustan los objetivos que se basan en la cantidad de líneas, lo encuentro absurdo, es como pagar al albañil por ladrillos colocados, cuando lo que debe hacer son metros de muro, suena parecido, pero no es lo mismo. Si un programador es más eficaz reutilizando código y con menos líneas resuelve un problema, ¿debe cobrar menos, según la cantidad de líneas? Al revés, porque al haber escrito poco seguramente habrá introducido menos errores en el código.
Mucho mejor veo un combinado de número de errores introducidos (cuantos menos mejor), dificultad de la tarea (establecer un sistema de puntuación/pesos/ponderación) y cumplir con las fechas. Es importante el establecer unos objetivos de grupo y unos personales, de forma que se recompense tanto los resultados globales como los particulares.
Claro que para medir todo eso, no se puede hacer de forma manual, hay que tener unas herramientas que lo controlen de forma automática y, a ser posible, integradas dentro del entorno de desarrollo.
Nosotros de momento continuamos buscando la mejor forma de hacerlo.
Desde hace tiempo sigo una web sobre programación (www.marteens.com), escrita por Ian Marteens, un profesional como la copa de un pino, por lo que yo se, cuyos conocimientos técnicos y agudeza liguistica no paran de impresionarme. Pero últimamente me está fastidiando un pequeño aspecto de su web, quiero dejar claro que es su web, su medio para escribir lo que quiera, al igual que éste es mi blog, ultimamente hace muchas referencias a temas políticos, a frases que dice tal o cual ministro, tal o cual presidente, que, sinceramente, a mi me importan poco, porque lo que yo busco en su página son sus comentarios técnicos, sus trucos y los anuncios de nuevos libros y nuevos cursos.
No se, creo que no hay que mezclar temas. Esta claro que es una opinión totalmente personal.
Lo siento Ian, pero que los dos primeros párrafos de la página hablen de Jose Luis Rodriguez Zapatero... prefiero cuando agudizas el ingenio para hablar de las empresas de software que tanto hemos "amado"/"odiado" (lease Borland).
No se puede decir que sea muy prolijo escribiendo en este blog :), a diferencia de otros, no tengo la presión de publicar a diario, como explica Enrique Dans, el puede hacerlo por su "modus vivendi", utilizando sus palabras, y yo creo que tiene necesidad de hacerlo, incluso raya en el "mono" ;) de publicar diariamente. Cada vez me gusta más lo que escribe este hombre.
PDAs
Me ha llamado mucho la atención que en el ayuntamiento de Madrid los policias vayan a poner las multas en PDAs (Noticia)... Eso me ha recordado a como empezó la empresa, dedicados a los PDAs y a la movilidad, cosa que terminó mal, como ya he comentado por aquí. Realmente las/los (nunca he sabido que género utilizar) PDAs tienen mucha utilidad, el problema es que (pienso yo) mucha gente lo ve como una agenda, cuando realmente es un ordenador, también es verdad que 400 por un aparatito era dinero, pero ahora puedes encontrar PDAs de Palm por la mitad de eso. Yo por ejemplo utilizo el PDA principalmente, como agenda (sincronizada con el Outlook de mi equipo), como listín telefónico, como almacén de contraseñas (SplashID) y para controlar en que utilizo el tiempo (PunchClock).
Herramientas de control de proyectos
En un comentario a uno de los post que hice sobre el control de proyectos, Vicente Egea comenta de una herramienta llamada TUTOS que he empezado a evaluar, me gusta bastante, más que las otras que había probado hasta el momento. Continuaré probando y publicaré las conclusiones.
No es habitual en este blog comentar estas cosas, pero me ha llamado mucho la atención que al intentar hacer una búsqueda en Google me salga esto.
¿A alguien más le ha ocurrido?
Si para una empresa "normal", que caigan sus servidores o servicios es una catástrofe, para una empresa como Google lo que hace es dañar su imagen, está claro que no de forma irremediable ni grave, pero si esta situación perdurara en el tiempo, seguro que si que pasaría a tener más repercusión, estoy convencido que incluso a nivel de medios de comunicación.
Me resulta curioso la cantidad de veces que se compara el desarrollo de software con la industria automovilística. Coloquialmente comparamos la venta de un programa con la venta de un coche en cuanto a que la formación no se incluye con el vehículo, hay que pagarla aparte (Auto escuela). Comparamos el proceso de diseño de un coche con el de diseño de una aplicación, las pruebas de calidad que utiliza la industria del automóvil con las que utilizamos quienes hacemos programas. Pero nos equivocamos, como dice Alejandro Sanz, "no es lo mismo".
Además de las diferencias "palpables" y obvias, un automóvil no es como un programa. En un automóvil se gasta mucho dinero durante el proceso de diseño, se gasta dinero durante el lanzamiento y durante la producción física del mismo. En el desarrollo de un programa se gasta mucho dinero en el proceso de diseño, pero no en el de producción, al menos no con el software "empaquetado".
Durante el diseño de un vehículo los ingenieros se atienen a una serie de normas, tanto internas de la casa (estilo, tamaño, motores, etc.), como de las autoridades, en materia de seguridad, apariencia (dos faros, luces traseras, emisiones contaminantes, ruidos, etc.). Se hacen planos, se hacen cálculos, se montan maquetas, un prototipo, se hacen unidades de prueba que ser testan y se van corrigiendo, cada parte del vehículo se somete a una serie de pruebas de desgaste, de especificaciones funcionales (¿A que no sabías que la palanquita que sirve para abrir o cerrar las bocas de ventilación debe tener una resistencia indicada entre un mínimo y un máximo? Si está por debajo del mínimo puede vibrar, puede moverse "a su antojo" y si supera el máximo es difícil de manejar, requiere más atención, no lo puede hacer un niño. Algún día contaré porque se esto.), paralelamente mientras se terminan de pulir aspectos del vehículo, en las factorías se van preparando los procesos para la llegada del nuevo modelo, se van adquiriendo las herramientas necesarias, se reprograman los robots, muchas cosas. Finalmente un día, se empieza a producir el vehículo, se van cogiendo las piezas y se van montando, después de un periodo de tiempo, al final de la cadena de montaje, van apareciendo los vehículos montados y se llevan a los concesionarios para que los vendan.
Con un programa algo similar al inicio. Los analistas describen que es lo que ha de hacer el programa, pero... ¿Hay alguna autoridad que les indique que normas ha de cumplir el software, que indique un mínimo de calidad, de funcionalidad...? lo dejo en el aire. Luego se diseñan los objetos, las tablas, las pantallas, listados, informes, enlaces con bases de datos, protocolos, etc. (dependiendo del tipo de aplicación), luego los programadores hacen prototipos, empiezan a codificar el programa, se hacen pruebas, se verifica que todo funciona según lo previsto, se hacen las últimas modificaciones, y a producir, pero resulta que ésta producción es muy sencilla: grabar CDs y empaquetar, y si se distribuye por internet, ni se graba ni se empaqueta.
Es decir, que durante la fase inicial en los dos casos hay mucho recurso y mucho trabajo, pero luego en la fase de producción, en un caso continuan los gastos y en otro casi insignificantes.
Y no terminan ahi las diferencias...
continuará ...
Una de las cosas más dificiles que se le pueden pedir a una persona es que estime el tiempo que empleará para concluir una tarea, y eso porque tiene que predecir el futuro, tiene que anticiparse a los imprevistos, a las complicaciones. Normalmente nos basamos en los fallos y los aciertos de otras veces que hemos tenido que estimar cosas similares, es decir, en las experiencias pasadas.
Para un programador esto se convierte en un suplicio, al menos para mi. Joel Spolsky dice que "sólo un programador puede estimar el tiempo que empleará en hacer una tarea", vale, pero hay tantos factores a tener en cuenta que estimar el tiempo se convierte en poco más que decir una cifra al azar... entre 5 y 15 horas... Está claro que mas o menos sabes cuanto te puede costar, pero ... SI TE DEDICARAS SOLO A ESO, si no tuvieras interrupciones, si el ordenador no se quedara colgado cuando menos lo espera, si no encuentras un bug en una librería que estás utilizando, si... si...
Si lo que estas haciendo es planificar todo un proyecto, la cosa se complica, peor, es imposible acertar. Dependencias entre tareas, varios programadores, vacaciones por el medio, un infierno.
Como dije en otro post anterior, estoy evaluando varias herramientas de planificación, pero me he dado cuenta que no son las herramientas lo que fallan (bueno salvo que algunas tienen carencias), sino la metodología. Estoy buscando algún método que me ayude a acertar más con los plazos, con los tiempos.
Ahora, en la empresa, hacemos lo siguiente:
1) Nos reunimos para ver que nuevas funcionalidades ha de tener el programa. En base a las incidencias recogidas de los clientes (bugs, problemas, etc.), en base a conversaciones con ellos, comparandonos a la competencia, detectando posibles mejoras, ideas nuevas, etc.
2) Decidimos cuales de ellas se han de implantar en la próxima versión, sabiendo que tenemos 6 meses (más o menos) de plazo, y teniendo en cuenta que utilizamos los 2 últimos para pruebas, empaquetado y distribución, disponemos de 4 meses de desarrollo.
3) Repartimos las funcionalidades entre los programadores, en base a varios criterios, cosas que ya han hecho, cosas relacionadas, etc.
4) Pedimos a los programadores que estimen el tiempo (yo soy uno de los programadores), y aqui es donde fallamos.
5) Metemos el tiempo estimado en una lista de tareas de Outlook para tenerlo en un sitio, hasta que encontremos la herramienta adecuada.
Respecto al punto 4, que es donde "estimamos tiempos", creo que fallamos en que no analizamos profundamente las funcionalidades, en que no detallamos lo suficiente cada tarea, que lo hacemos a ojo de buen cubero.
Como comenta Joel en su famoso artículo: Planificación indolora de proyectos, deberíamos dividir una tarea en pequeñas partes hasta que cada una de ellas fuera de una duración entre 1 y 16 horas, y para poder hacerlo hay que parase a analizar muy profundamente lo que vamos a hacer.
Hemos pensado que una forma de hacerlo es estandarizar los tiempos, me explico, al analizar profundamente una tarea, granularizar el trabajo hasta el nivel de decir que necesitamos una tabla nueva con X campos, un campo nuevo en tal tabla, un procedimiento almacenado que haga "noseque", un par de clases con estas propiedades y estos métodos. ¿Con ello que hacemos? Pues tendríamos una tabla con tiempos que dijera: Por cada tabla nueva Y horas, por cada campo modificado X, por cada procedimiento almacenado T si es sencillo, T2 si es medio, T4 si es complejo, etc.
Luego ir recogiendo los tiempos reales empleados en cada tarea y comparlarlos con los estandarizados y ver las desviaciones, y cada X tiempo (cada año por ejemplo) ir ajustando los tiempos estándar para que reflejen la realidad.
¿Que os parece? ¿Una chorrada? ¿Conoceis o utilizais algún método para estimar tiempos?
Estoy buscando herramientas que me ayuden en la gestión de proyectos de software.
En el apartado de gestión de tareas y tiempos:
He probado dotProject y php-collab, pero no terminan de satisfacer mis necesidades, porque no controlan determinados factores que para mi son básicos, como la sobrecarga de un programador, las incidencias (bajas por enfermedad, días libres, etc...). Tampoco me gusta que al ir añadiendo tareas tenga que tener en "la cabeza" cuando empieza una y cuando termina otra, yo lo que quiero es indicarle las tareas y subtareas a realizar, quien las tiene que hacer, la duración estimada, el orden de ejecución y si hay dependencias entre tareas y que el software se encargue de ponerlas en el calendario, sin tener que decirle yo la fecha de inicio y la de fin. No me permiten mucha flexibilidad a la hora de reorganizar un proyecto.
En el apartado de gestión de bugs, funcionalidades, mejoras, etc...:
He empezado a probar Mantis, y este si que cumple con mis necesidades, continuaré informando.
Para tema de control de versiones:
Utilizamos el FreeVCS que se integra con Delphi, ahora estamos mirando de utilizar el CVS estándar de Linux y ver como podemos integrarlo con el IDE de Delphi.
Luego voy a estudiar sistemas de wiki para ver si nos pueden servir para organizar la documentación de los proyectos. Definir glosarios, funcionalidades, especificaciones, etc.
¿Que herramientas utilizais vosotros?
He recibido hoy el último Zumo de red de Baquía, cuando estaba leyendo este artículo parecía que estaban hablando de mi empresa.
Empezamos dos amigos que teníamos inquietudes similares, los dos con un puesto de trabajo más o menos estable y con un buen sueldo, empezamos con cierta reticencia por parte de nuestros familiares.
Juntamos entre los dos 12.000 euros, que despues se demostraron totalmente insuficientes, falta de preparación financiera por nuestra parte, y arrancamos.
Después de dar muchas vueltas sobre a que podríamos dedicarnos, los dos habíamos trabajado de desarrolladores de software, decidimos que el tema de lo "mobile" (PDAs, WiFi, etc...) estaba muy bien, estaba empezando y se le veía buen futuro. Craso error, el viejo refrán de: "Zapatero a tus zapatos" es una verdad como una casa. Si haces bien una cosa, la dominas y hay negocio, y no tienes recursos suficientes para dar el giro, mejor dedicate a lo que sabes.
El primer año fue penoso, el segundo empezamos a tomar el rumbo, éste es el tercero y empezamos a ver las cosas con claridad, hemos conseguido el apoyo financiero necesario para llegar a donde queremos, si como dice el artículo hasta el quinto no se estabiliza, todavía nos quedan dos años y medio hasta entonces.
Me ha gustado mucho una frase, leída en los comentarios del artículo, que dice: "la innovación es ideas y sudor, mucho sudor..." Que gran verdad.
Y sobre el capital "riesgo", debería llamarse, al menos en España, capital seguro, porque no quieren arriesgar NADA, así con mayúsculas, quieren invertir en empresas que facturen de 10 a 50 millones de euros anuales y la inversión mínima es de 1 millón. Eso se sale de la mayoría de "start ups" que hay. Y hablo con experiencia de haber contactado con varias empresas inversionistas.
Respecto a las ayudas públicas, que decir, muy dificiles de conseguir, por no decir imposible, para todo el papeleo que se necesita para presentarse a NEOTEC, por ejemplo, se requiere que una persona se tire un mes preparándolo, cosa imposible para una empresa que empieza sólo con los dos emprendedores.
En fin... Como nos dijo una persona que nos orientó al inicio de todo esto: es una carrera de fondo, hay que aguantar.
El pasado jueves, 6 de mayo, estuve en el BorlandDay, en Madrid, fue bastante indicador de hacia donde van las cosas en el desarrollo de software en Windows. No voy a descubrir nada nuevo cuando digo que todo pasa por .NET, no tengo experiencia directa sobre desarrollar para esta plataforma, por lo que no me puedo hacer una opinión bien fundamentada al respecto, pero por lo visto, oido y leído parece que tiene buena pinta, que han conseguido un framework bastante amplio (para todo tipo de aplicaciones) y han simplificado (bueno ahí tengo mis dudas) el API de Windows.
Lo que me llama la atención es que según pasa el tiempo, programar es cada vez más complejo, cada vez se necesita más información, cada vez hay que tener en cuenta más cosas, cada vez es más necesario el trabajo en equipo, el programador solitario cada vez lo tiene más complicado. Recuerdo mis tiempos de Clipper, en MSDOS, cuando todo era más sencillo, es verdad que habían menos posibilidades (no había Internet, no había interfaz gráfica), pero era más fácil programar. Ocurre como en los automóviles, antes la gente podía reparase su propio vehículo, con un poco de maña se ajustaban la carburación, cambiaban las pastillas de freno, etc... Ahora, con tanta electrónica, es imposible que una persona ajuste nada sin las herramientas adecuadas y con la preparación necesaria. Se van consiguiendo mayores prestaciones y funcionalidades, pero a costa de una mayor complicación, al menos para los programadores.
Volviendo al BorlandDay, prácticamente todo estaba orientado a empresas que se dedican ha proyectos para clientes, no a empresas como la mía que nos dedicamos a empaquetar software, aún así, hubo ponencias muy interesantes donde explicaron como mejorar la calidad del software utilizando las herramientas existentes, como se implantó el CMM5 en Coritel, vimos el Delphi .NET, vimos herramientas que ayudan a los directores de proyectos a llevar un control mejor sobre lo que está ocurriendo, etc... Pero, como dijo un compañero: "Todo esto es como si un equipo de Formula 1 presentara lo que hace a unos mecánicos de pueblo", salvando las distancias fue así, porque no todas las empresas tienen los recursos necesarios para implantar esas metodologías, como presentación de ideas y de como se puede (y se debe) controlar un proyecto, estuvo bien, pero alejado de la realidad de la mayoría de los presentes.
Se me olvidaba... Otra conclusión... Tengo que aprender C#, porque es el lenguaje que va a triunfar dentro de .NET, aunque hay alternativas muy interesantes como Freya, aquí y aquí
Actualmente en la empresa estamos buscando como comprar tiempo, es decir, como ganar tiempo al tiempo.
Me explicaré: Al producto que tenemos, sabemos que le faltan una serie de funcionalidades para que cumpla con las expectativas de nuestros clientes y, sobre todo, de los posibles clientes. La forma de solucionarlo es dedicarle más tiempo, como ahora en la empresa parte de nuestros recursos se dedican a otras tareas que generan dinero a corto plazo, no estamos dedicando el 100% de nuestro esfuerzo al producto que realmente queremos comercializar, por ello nos hemos decidido a buscar financiación que nos ayude a evolucionarlo, haciendo que no sea necesario hacer otras cosas para "tirar palante".
Pero nos hemos encontrado con varios problemas, en general, las entidades financieras no entienden que es eso de una empresa de software, al menos en la zona donde vivimos, se creen que hacemos webs, que hacemos programas a medida y cuando les explicas que lo que haces es un software que luego empaquetas y vendes no lo terminan de ver, claro que esto nos pasa por no estar en una capital, ya no digamos Madrid o Barcelona, donde si que es más común que un director de banco se encuentre con este tipo de empresas.
Acudimos a una SGR (Sociedad de Garantía Reciproca), donde nos dicen que no ven futuro en lo que hacemos, bueno, lo han dicho en otras palabras pero viene a ser lo mismo. Estamos pensando en buscar socios inversionistas, pero nos da un poco de miedo meter a otras personas dentro de la empresa, por aquello de perder el control.
Yo me estoy tomando ésto como unas pruebas que hay que superar y que al final está el premio, porque si no lo tomas de esa forma (o de otra pero que te ayude a no decaer) lo más sencillo es enviarlo todo al garete y ponerte a trabajar para otros, pero que le vamos a hacer, cabezón que es uno.
A mi personalmente me gusta que el código que escribo tenga una buena "apariencia" y lo digo en el más puro sentido estetico. Primero el código debe funcionar correctamente, eso no hay duda, pero además me gusta que esté bien estructurado, bien indentado, con nombres de variables que tengan sentido.
Esto lo vengo haciendo desde que escribía programas en Clipper, en la empresa que trabajaba, "heredé" un código de una aplicación de gestión, que si bien funcionaba, era casi imposible de "leer" el código, así que lo primero que hacía cuando abría un nuevo módulo era "reorganizar" el código de forma que me fuera más sencillo entenderlo y así poder modificarlo. De ahí me quedó ciertas "manías":
-Las indentaciones las hago a 3 espacios (aunque ahora en la empresa acabamos de estandarizarlo a 2)
-Todas las variables tienen una "notación hungara" que indican que tipo de datos contienen. En Clipper TODAS las variables eran de cualquier tipo, es decir, no estaban tipificadas, el mismo identificador servía para un entero, para una cadena o un array, pero yo insistía en que debíamos ser estrictos en esto.
-Cuando tengo una secuencia de instrucciones iguales, por ejemplo asignación de campos, alineo los paréntesis, los iguales, todo para que sea más sencillo el leer el código. Ejemplo (en pseudolenguaje):
Es una cosa obvia, pero que, no se porque, no todo el mundo comparte o es capaz de conseguir: Las cosas sencillas funcionan mejor que las complejas.
En mi carrera profesional he compartido desarrollo con mucha gente y siempre he encontrado una tendencia absurda a complicarse la vida escribiendo código, es decir, para resolver un determinado problema casi siempre se seleccionaba el camino más complejo y rebuscado. Tenía un compañero que compartía la misma "visión" que yo, y me hizo gracia una frase que me dijo respecto al tema (con ironía): "¿Para que hacerlo dificil si se puede hacer imposible?"
Una vez escuché una historia, me imagino que será una fábula, pero:
En una empresa querían mejorar un proceso, resulta que les llegaban unas piezas por una cinta transportadora, llegaban cada una de una forma, por lo que un operario tenía que reordenarlas para que una máquina pudiera cogerlas y empaquetarlas. Resulta que durante el periodo de vacaciones del jefe de mantenimiento de la empresa, llaman a unos "expertos" para que les ayuden, los "expertos" montan un sistema de visión artificial con unos brazos robotizados para que hicieran el trabajo del operario, 100.000 de coste, precio actualizado a euros, porque a mi me lo contaron en pesetas ;). Cuando volvió el jefe de mantenimiento y vió aquello se quedo perplejo, lo desmontó todo, puso una madera inclinada de forma vertical para que tumbase las piezas que venía de pie y otra madera inclinada de forma horizontal para que la pieza se acercase al borde de la cinta y con el movimiento se pusiera en la posición adecuada, coste 100 (contando con la mano de obra y materiales).
He tenido compañeros que pensaban que cuando más código, más complejo y más sofisticado mejor era el programa... Normalmente, al cabo del tiempo, cuando tenían que revisar su propio código, ya no digamos el código ofuscado de otros, se daban cuenta del "problema" y empezaban a "entender" mi postura.
Repito, no se porque pero de entrada no todo el mundo lo ve, sobre todo los que vienen directament de la universidad, parece que allí los profesores premian más el número de líneas de código que el resolver el problema. Aunque me imagino espero que no todos.
En momentos como éste es muy complicado decir no a la violencia, porque a todos nos ha pasado por el pensamiento que a las bestias (porque no son personas, no son humanos) que han hecho lo de Madrid les tendríamos que aplicar el mismo final, por favor, no caigamos en el mismo saco que ellos.
No sirve el decir que ellos lo hicieron primero, no sirve decir que lo hacemos en defesa propia. Matar es matar, nadie tiene el derecho a quitar la vida a nadie, por el motivo, causa o razón que se quiera.
Igual diciendo esto puedo pecar de ingenuo, puedo pecar de débil, me da igual, prefiero ser débil que asesino.
¿Porque y para que tanto dolor? ¿Es éste el único camino hacia sus objetivos que ven los terroristas?
Es una escusa demasiado manida, pero la verdad es que en las últimas 4 semanas no he tenido tiempo para escribir nada decente, y por lo tanto no lo he hecho.
He estado muy liado con la planificación de la nueva versión del producto que llevamos en la empresa, porque esta nueva versión va a ser un auténtico bombazo respecto a su predecesora. Hasta ahora nos habíamos dedicado a solucionar problemas con el código ("heredado" de otra empresa y, por cierto, código bastante malo) y a añadir funcionalidades básicas que no tenía, pero la nueva versión añade herramientas que los clientes necesitan realmente, aspectos que supondrán un gran paso en la evolución del producto y un gran avance en la forma que nuestros clientes gestionan su negocio.
Además hemos asistido como expositores a un par de "Jornadas" que realiza el gremio al que nos dirigimos, hemos realizado unas presentaciones del producto por varias ciudades españolas y ha sido muy gratificante: primero el ver que la gente aprecia tu esfuerzo por tener un buen producto y segundo el contacto directo con los clientes y posibles clientes, escuchándo, porque si una cosa hay que hacer es escuchar a las personas que van a utilizar tú producto. Hay que escucharles con una amplitud de miras muy generosa, sin prejuzgar nada, tomando notas de todos los detalles grandes y pequeños que aportan, porque de ahí vas a obtener hacia donde has de dirigir el producto para que llege al público objetivo.
Durante la planificación de la nueva versión surgió la necesidad de utilizar componentes de terceros para solucionar algunos aspectos del programa, que importante es seleccionar bien los componentes, primero han de cumplir perfectamente con tus necesidades, eso es evidente, segundo han de ser robustos, es decir, bien programados porque vas a confiar en ellos una parte de tú aplicación, tercero han de tener continuidad, es decir, quien los haya hecho debe continuar manteniendolos y mejorándolos, y cuarto debes de tener el código fuente del componente por si la empresa/persona que lo comercializa deja de dar soporte a dicho componente. Esto ya lo comentamos, en Diciembre de 2003, en un post de Jose Luis Sanchez, en
avemundi.
En esta versión, a diferencia de las anteriores, va a primar más el resultado que el tiempo, me explico: en las versiones anteriores hemos "sacrificado" funcionalidades para poder sacar la versiòn en las fechas previstas, pero esta vez nos hemos marcado unas metas basadas en conseguir unas funcionalidades, sin importar la fecha, bueno, tampoco es que vayamos a estar 3 años con dicha versión, sino que la fecha final no está tan fijamente marcada con las otras veces.
Errores, errores, errores... No se porque, desde pequeños nos educan que no debemos cometer errores, que son malos, nos castigan por ello. Cuando cometes un error el profesor te pega un puro, tu jefe (mal jefe) te echa la bronca, pero ninguno pregunta: ¿Porque has cometido el error? ¿Que harás para no volverlo a cometer? y, la más importante, ¿Que has aprendido?
A mí me encanta un proverbio romano (al menos tengo entendido que es así) que dice:
"De la ignorancia nos equivocamos, de los errores aprendemos".
Todo esto viene a cuento de un artículo de Eric Sink llamado Make More Mistakes donde cuenta los errores que ha cometido en su empresa de desarrollo de software.
No habla de los errores de desarrollo, sino de errores de estrategia, de decisiones equivocadas, de productos fallidos... esos errores de los que es complicado levantarse, pero de los que se debe aprender mucho para ver que fue mal y aprender, para que si se producen de nuevo las mismas circunstancias ver anticipadamente que se va mal y corregir antes de que sea tarde.
Mi empresa la formamos al principio dos personas que nos hemos dedicado al desarrollo de software desde hace un tiempo, por eso, estábamos "cansadas" de ello y quisimos dedicarnos a otra cosa. Como nos gustan las novedades, como a casi todo informático, nos decantamos por los PDAs, buscamos productos, buscamos software y nos pusimos a visitar a empresas que pudieran estar interesadas... Pero al mismo tiempo (con más personal claro) manteníamos unas aplicaciones a medida (que ya he hablado de ellas) y un producto estándar. Resultado, al cabo de un año, ¿sabéis cuantas aplicaciones para PDAs vendimos?.... ninguna!!!! ¿Cuantos PDAs?.... tres!!! Sin embargo las aplicaciones a medida y el producto estándar ahí estaban, dando el callo.
Conclusión: Dedícate a lo que sabes hacer bien, y si quieres hacer otra cosa, aprende antes a hacerlo tan bien como lo que sabes.
Uno de los fallos más graves que cometimos fue el calcular mal cuanto dinero nos hacía falta, claro que esto se vio agravado porque el primer año apenas facturamos, porque nos equivocamos con el producto (PDAs) o no supimos comercializarlo.
Eso nos ha hecho tener una política de costes muy agresiva, no se compra nada que no vaya a aportar beneficios, NADA. Este es el beneficio del error cometido.
Según he leído en algún sitio, cuando en la NASA algo falla, se nombra a un comité para que estudie que enseñanzas se pueden obtener de dicho fallo. No se si es cierto o no, pero así es como deberíamos afrontar los errores, como una oportunidad de aprender.
Así que... ¡¡¡ Más errores por favor !!!
Un post en Chochurro y otro en UDJAT - lo que el ojo no ve, me han hecho pensar sobre "vender software" o "vender servicios".
Mi opinión es que hay que hacer una mezcla, porque hay muchos clientes y cada uno entiende esto del software de una forma diferente. Volvemos a viejo dilema de propiedad si, propiedad no, ¿de quien es el software?
Como dice Nicholas Negroponte, nosotros vendemos bits no átomos, y de ahí radica parte del problema de la venta del software. Nadie duda de quien es una impresora, un monitor, un ratón, pero el software no tiene cuerpo, no es tangible, es fácilmente copiable, por lo tanto se necesita un nuevo paradigma para venderlo.
Personalmente creo que el mejor es el "alquiler de software", el usuario paga por utilizarlo, a traves de un ordenador suyo. Es algo similar a la telefonía, o a Internet, tu tienes un dispositivo que te permite utilizar un servicio que es por el que pagas una cuota en función del tiempo, del uso, o una cuota fija. Claro que entonces te topas con la barrera cultural de la propiedad, que está muy arraigada en la cultura latina.
Yo siempre pongo el ejemplo del coche: Lo importante no es tener un coche, lo REALMENTE importante es utilizarlo, el beneficio es el uso, me permite desplazarme de forma independiente, el tenerlo en propiedad no me aporta valor. Poco a poco el renting de vehiculos esta calando en nuestra sociedad por ese motivo.
Yo me compre un coche hace 7 años, me costó 2.800.000 pesetas (16.828,34 EUR), ahora mismo si lo quiero vender no me dán más que 3.000 EUR (como mucho), por lo tanto he "perdido" 16.828,34 - 3.000 = 13.828,34 EUR, si durante este tiempo le he cambiado de ruedas, aceite y otras reparaciones que, pongamos, suben 2.000 EUR (me he quedado corto) y he pagado 7 años de seguro a 600 EUR (mas o menos) = 4.200 EUR más, total 6.200 EUR adicionales que he "tirado". Total 13.828,24 + 6.200,00 = 20.028,24 que divididos por 7 años = 2.861,18 EUR / año = 238,43 EUR / mes
O sea, más o menos el coste me supondría tener el vehículo en renting.
Con los vehiculos directamente se puede prestar el servicio, no es necesario que el cliente haya adquirido nada previamente, no es así con la telefonía, por ejemplo, debe haberse realizado una instalación previa y haber adquirido, o alquilado, un teléfono. Con el software ocurre algo similar, primero han de comprar el software sobre el que funcionan los servicios. De ahí que sea necesario un "mix": venta primero, servicios despues. Lo que no quita que la venta se realice a coste cero o casi.
Uno de los servicios que más agradecen los clientes es el soporte, estoy detectando una tendencia hacia valorar dicho servicio y estar dispuestos a pagar por él. En mi empresa damos 3 meses de soporte gratuito con la adquisición del producto, pasado este periodo hay que contratar el soporte, puedo decir que el 90% de los clientes lo contratan. Una recomendación, cuida muy mucho el servicio postventa, es lo que te va ha hacer tener clientes en lugar de compradores. También es uno de los servicios que consume más tiempo, por lo que hay que tenerlo en cuenta, y tampoco sirve cualquiera para dar soporte porque muchas veces llaman los clientes un poco "alterados" y hay que saber capear el temporal. Creo que me estoy desviando del tema.
En definitiva estoy totalmente de acuerdo con los dos artículos citados al principio, a medio plazo veo que el software se va a convertir en un servicio y no en un producto. Servicio que se presta a través de ordenadores (y demás dispositivos), igual, repito, que las comunicaciones se prestan a través de teléfonos, fax, etc.
... dejemos de lado las guerras, las confrontaciones, dejemos los enfados y los caprichos, las envidias y los recelos.
Aunque sólo sea por unos días, aunque suene "infantil", intentemos ser felices con los nuestros. Demos un abrazo a esa persona con la que llevamos medio año discutiendo, demos un beso a las personas que queremos y a las que no queremos demoslé la mano por lo menos. Intentemos ser un poco mejores durante estos días, a ver si le cogemos gustito y lo podemos ser todo el año.
Un fuerte abrazo a todos.