La necesidad de descansar y desconectar

Una cosa que he aprendido desde que comencé a trabajar es que la productividad crece si se consiguen introducir períodos de descanso y de desconexión a lo largo del día y de la semana. He tardado mucho en aprender la lección y todavía sigo cayendo en muchas ocasiones en el error de no parar y tener siempre en la cabeza tareas que tengo pendientes de realizar o problemas sobre los que hay que intentar buscar una solución. Cuando esto sucede la culpa es exclusivamente mía, aunque mi profesión dificulte en demasiadas ocasiones el proceso de desconexión.

Es necesario para poder renovar las ideas y para fomentar la creatividad tener períodos de descanso, no puedo dar una fórmula sobre cuando es más apropiado tomar esos descansos, ya que cada persona es un mundo y conoce cuáles son sus límites y cuáles son sus necesidades. Acumular horas y más horas de trabajo sin dedicarnos un mínimo de tiempo, termina tarde o temprano pasando factura y cada vez se es menos productivo debido al cansancio y porque el trabajo cada vez más genera más ansiedad y menos satisfacción.

Es cierto que no siempre somos dueños de nuestro tiempo y que las circunstancias laborales y el entorno pueden provocar que buscar esos oasis de tiempo sea complicado, pero aunque sea difícil necesitamos buscar ese resquicio de aire fresco que proporciona descansar y desconectar, ese oasis permitirá que al ser más productivos y saber valorar mejor el tiempo, se consiga cada vez encontrar con más facilidad ese paréntesis tan necesario para cada uno de nosotros.

La respuesta a muchos problemas que se presentan en el trabajo se resuelven a partir de la creatividad, si ésta se ve anulada por el cansancio quiere decir que no seremos capaces de resolver esos problemas, que los resolveremos peor o que tardaremos más en resolverlo, lo que a su vez genera más trabajo y se cae en un círculo vicioso de difícil salida. Si echar más y más horas no permite salir de esta laberinto, ¿por qué no probar a descansar y desconectar un poco más y ver cuáles son los resultados?.

Software libre IV

En cualquier caso y esto es importante, todo software que sea desarrollado para la administración pública debe ser liberado con una licencia libre (lo ideal sería que se acogiera a alguna auspiciada por la Free Software Foundation). En España y en algunas de sus Comunidades Autónomas se han dado avances significativos en este sentido, pero lejos, muy lejos todavía de que el mayor porcentaje de software desarrollado para las mismas sea accesible libremente. Aqui queda mucho por mejorar y no solo en lo anterior, sino en la participación de las administraciones ya sea económicamente, a través de empresas de desarrollo de software o con personal interno en comunidades de desarrollo de software libre, seguro que darían un impulso importante a bastantes proyectos que son de gran interés y por supuesto una alternativa tan buena o mejor que las soluciones propietarias que se puedan adquirir y más baratos y efectivos que soluciones que la administración quiera desarrollar desde cero.

También soy partidario de que las administraciones (con su debido plan de migración y gestión del cambio correspondiente y sin precipitaciones) deben abordar una paulatina incorporación de soluciones libres dentro del ámbito del puesto de trabajo. Por supuesto que no es nada sencillo un plan de estas características, por supuesto que es necesario analizar caso por caso, por supuesto que puede requerir mucho tiempo hacerlo, por supuesto que habrá componentes software que no serán recomendables migrar (y no se deberán por tanto migrar), pero creo que es un ejercicio de responsabilidad por lo menos intentar esta evolución y no lo digo solo por el ahorro de costes, por motivos de seguridad, etc…, sino como una forma de apoyar a una causa justa y que lleva consigo unos beneficios muy importantes para la sociedad.

Eso sí, hay una cosa en la que no estoy de acuerdo y es en la proliferación del desarrollo y mantenimiento de distribuciones Linux (aún basadas en otras) en las distintas comunidades autónomas. La iniciativa de acercar Linux a las aulas, de promocionar este sistema operativo me parece fantástica a la par que necesaria, pero no necesariamente el camino debe ser el desarrollo de distribuciones particulares, ya que existen suficientes distribuciones Linux para que no sea necesario utilizar este tipo de estrategias. Ese dinero que se invierte en el desarrollo de estas distribuciones, perfectamente podría ser utilizado para fomentar otros proyectos de software libre, para formación en la materia o si se quiere para ayudar o contratarle soporte a la comunidad, empresa u organización que ha desarrollado la distribución Linux elegida.

Lo comentado sobre el uso del software libre en las administraciones lo extrapolo al conjunto de instituciones privadas, ya que si los deberes se realizan adecuadamente, se identifica que es migrable, que no es migrable, se establece un plan para hacerlo, una gestión del cambio adecuada y se elige un momento óptimo a partir del cual comience este proceso (que puede durar años) no tendría necesariamente que provocar problemas a la empresa y los beneficios aplicables al uso de esta estrategia no tardarán mucho en llegar. ¿Por qué digo que las administraciones deben migrar y con las empresas no soy tan tajante? Pues porque en el primer caso pago yo y asumo por tanto mi margen de responsabilidad y en el segundo porque las empresas se nutren de capital privado y ellas mejor que nadie saben qué es lo que tienen que hacer con su dinero y cuáles son sus prioridades.

Desde siempre se ha considerado a Microsoft como el enemigo público número uno del software libre, como suele pasar, estas calificaciones no se regalan. En este caso tuvo muchísimo que ver la actitud y visión comercial de Bill Gates y el comportamiento del gigante de Redmond a lo largo de los años. No obstante, como he indicado en algún post anterior, Microsoft es sólo uno de tantos y son esos tantos los que están sacando una gran tajada de que la atención y la “mala fama” se la lleve esta empresa, ya que gran parte del éxito de una empresa lo da su imagen.

Software libre III

Para muchos la visión de la “pureza de sangre” del software libre (o todo libre o nada) hacen que la Free Software Foundation y Richard Stallman sean considerados unos extremistas. Yo no comparto completamente su doctrina (una cosa es que entienda que el concepto de software libre sea estrictamente ese y otra bien distinta es que considere que aunque el software libre sea la meta (tal vez utópica) a la que debemos llegar, no tenga en cuenta otras alternativas) y hago uso de software no libre tanto en sistemas operativos libres como en sistemas operativos no libres, así como puedo llegar a entender (y compartir) estrategias comerciales de empresas de desarrollo de software que no se basen en software libre. Más adelante explicaré mis razones. Pero independientemente de eso, veo necesaria la existencia de personas e instituciones que defiendan el software libre, su progresiva expansión y nos prevengan de riesgos próximos y futuros sobre la integridad y accesibilidad de la información, sobre la continuidad de la filosofía del software libre, etc… que pueden ser provocados por diferentes tecnologías, tendencias o concepciones. Además, como bien argumenta Stallman, la lucha por el software libre, debe ser constante y sin bajar los brazos. Su organización, él, personas que llevan años aplicando esta filosofía y participando activamente en la comunidad tienen la fuerza, la constancia y la fé necesaria para luchar por esta idea, yo no tengo su experiencia personal, ni tampoco una visión tan preclara como ellos, como para adaptar mi forma de utilizar o concebir el uso del software 100% a su manera.

Alguno pensará, y con razón, que no predico con el ejemplo y es cierto, como comenté en el párrafo anterior en la práctica hago uso de software no libre (o no extrictamente libre, ya que si un software tiene algún componente propietario ya no es libre al necesitar esa pieza necesariamente para funcionar (aplicando el principio de que toda cadena es tan fŕagil como el más débil de sus eslabones)), al fin y al cabo ejerzo mi libertad individual para hacerlo, ¿por qué? pues tal vez en la mayoría de los casos sea por comodidad, este es el programa que estoy acostumbrado a utilizar y no se me apetece buscar una alternativa completamente libre (o no me pongo a analizar su nivel de pureza), en otros casos (los menos) porque la solución propietaria es mejor o no hay alternativa.

También comenté que puedo entender y compartir estrategias empresariales o de negocio basadas en la creación de software no libre (de la misma manera que no puedo compartir, bajo ningún concepto estrategias empresariales o de negocio que no se basen en sistemas abiertos), ¿por qué? pues porque desgraciadamente las personas no somos justas, sobre todo si hay o puede haber dinero de por medio. En ocasiones para proteger y recuperar la inversión en una determinada solución es necesario aplicar prácticas de software propietario y aunque existen prácticas basadas en software libre, desde vender la solución hasta cobrar por servicios, siempre puede aparecer la empresa buitre de turno coger tu código y quitarte negocio o incorporarlo a su solución propietaria (aunque incumpla la licencia y por tanto no sea lícito) y ni te enteres. Esto que comento ha pasado, pasa y pasará en el mundo real, no podemos tener vendas en los ojos, por mucho que tengamos en consideración el software libre. Otra cosa bien distinta es que apoye que un software sea eternamente propietario, desde mi punto de vista, una empresa que ya ha obtenido el retorno de la inversión y unos beneficios aceptables debe liberar el código, llámese como se llame la empresa y por mucho que ese software sea el núcleo central de su negocio (por lo menos, si no quieren liberar la última versión, deberían liberar versiones anteriores, como forma de devolver a la comunidad de usuarios y clientes, lo que esa comunidad de usuarios y clientes le ha dado). Yo lo veo así, evidentemente mucha gente estará en un completo desacuerdo conmigo y seguro que tienen sus razones, tanto en un lado como en otro, ya que los responsables de una empresa que desarrolla soluciones software propietarias, me dirán que hablo así porque no me estoy jugando mi dinero o mi trabajo y yo le contestaría que es posible, pero que también entre el negro de la no liberación del software como libre y el blanco del libera todo y ya, hay una gama interesante de alternativas, además de que la empresa ha podido desarrollar otros productos u otras líneas de negocio gracias a los beneficios obtenidos que permitan seguir otra senda (sin necesariamente tener que perder la abierta con el producto software que han liberado).

Software libre II

Tal y como comenta la Free Software Foundation, un software se considera libre si para los usuarios verifican los siguientes principios:

- Tiene la libertad de ejecutar el programa para cualquier propósito.
- Tiene la libertad de adaptar el programa de acuerdo a sus necesidades.
- Tiene la libertad para redistribuir copias, tanto gratis como por un precio.
- Tiene la libertad para distribuir versiones modificadas del programa, de modo que la comunidad pueda beneficiarse de sus mejoras.

Para que se cumplan estas premisas es necesario el acceso al código fuente del programa. Un aspecto muy importante es diferenciar el concepto de Open Source respecto al de software libre, ya que aunque resulten parecidos tienen un enfoque diferente, a grandes rasgos un software que sea libre es Open Source (por definición), pero todo software que sea Open Source no tiene por qué ser libre. La diferencia está en que el Open Source se basa en la accesibilidad al código fuente, pero no asegura los cuatro principios enumerados anteriormente.

La Free Software Foundation se desmarca del concepto de Open Source, no lo critica abiertamente, ni lo considera un enemigo (como podréis ver en el enlace, para la FSF el enemigo es el software propietario), al contrario, considera que muchas aportaciones del movimiento Open Source han sido beneficiosas para el movimiento del software libre. No obstante, el hecho de que dentro del concepto de Open Source pueda entrar software libre, software semilibre y software propietario, provoca importantes recelos, ya que se considera que para que la filosofía del software libre se imponga el concepto no puede verse contaminado por interpretaciones inexactas o incorrectas del mismo.

Otro aspecto que ha hecho daño al software libre es la asociación del término inglés free con gratis, ya que un software gratis no tiene por qué ser libre, ni un software libre tiene por qué ser gratis. La confusión gratuidad/software libre, ha provocado y provoca que muchas personas consideren software freeware, incluso shareware, como software libre, además de otras modalidades de licencia que distan de las cuatro premisas del software libre.

Puede resultar paradójico, pero una de las cosas que más daño ha hecho al software libre es la aparición de soluciones software propietarias y gratuitas, ya que el software libre requiere un compromiso mayor, la libertad, y esa visión de libertad se pierde cuando tenemos la posibilidad de utilizar una buena solución tecnológica de forma gratuita (aunque sea propietaria). Es como si nos dejásemos vencer por el reverso tenebroso de la fuerza. Es por eso que hay muchas voces dentro del movimiento del software libre que muestran su temor hacia la orientación a la nube de los servicios software, ya que la mayor parte de esos servicios son gratuitos y además propietarios y están viendo como diariamente su número de usuarios crece de forma exponencial. Por mucho que Google y otras empresas del sector financien software libre (lo que evidentemente es de agradecer), en esencia son empresas cuyo funcionamiento gira alrededor del software propietario.

Para proteger el software libre de un uso inapropiado del mismo (la adición de componentes propietarios) o malicioso (la apropiación de dicho software dentro de soluciones propietarias), Richard Stallman desarrolló el concepto de copyleft a través de la licencia GPL (General Public License) de GNU. A grandes rasgos el copyleft viene a decir que todas las modificaciones que se puedan incorporar a un programa que sea software libre deben estar basadas en soluciones libres y que la distribución de la aplicación resultante debe ser también copyleft.

Software libre I

El concepto de software libre es interpretado de diferente forma por desarrolladores de software, usuarios, medios de comunicación, etc…, ya que dentro de cada uno de esos grupos hay personas que le dan un significado distinto al concepto, en unos casos de forma interesada, en otros casos de oídas, en otros por desconocimiento y en otros porque se está convencido de que ese debe ser el significado. De esto ha tenido mucha culpa el hecho de que haya sido un concepto muy manido y demasiado utilizado que ha provocado por un lado la expansión de su interpretación y por otro ha contribuido también a vaciarlo, paradójicamente, de contenido.

Para mi, el concepto de software libre es de la Free Software Foundation, en primer lugar porque es el más se acerca a la esencia de lo que supuso el inicio de la informática moderna, a ese concepto de hacker que después se deformó con connotaciones negativas, a esa persona curiosa por la tecnología que tenía afán por aprender y probar cosas nuevas y que sabían que para su aprendizaje era fundamental acceder al conocimiento incipiente que se estaba generando, ya estuviera en formato papel o en formas de líneas de código en un programa de ordenador. Por ese motivo compartir no era extraño para estas personas, era una práctica habitual para seguir progresando y evolucionando técnicamente. En segundo lugar, porque este concepción del software libre está intimamente ligada a la libertad ya que resultaba fundamental para mejorar la experiencia la posibilidad de utilizar y modificar las aplicaciones sin ningún tipo de restricción, sin ningún tipo de cuerda atada a la cintura que impidiera el avance del conocimiento y la innovación.

He utilizado como argumentos la utilidad que para un conjunto de personas tenía esta concepción del software libre en esa revolución de la informática que hubo a principios de los ochenta, aunque perfectamente podrían ser aplicables las mismas hoy día.

Esta visión romántica del software en general y del software libre en particular me caló desde la primera vez que tuve la oportunidad de leer el siguiente artículo de Richard Stallman.

El derecho a equivocarse

Dentro del proceso de aprendizaje uno de los factores más importantes son los errores, siempre y cuando se sea consciente y se admita la equivocación (si se ha fallado y no se admite, no se habrá aprendido nada).

De la misma forma que nosotros nos equivocamos (y nos equivocamos todos, algunos con más frecuencia y otros con menos, porque nadie es infalible), tenemos que admitir que los demás, nuestros compañeros, nuestros superiores y las personas que están a nuestro cargo se equivoquen. Evidentemente ni todos los errores son iguales ni tampoco puede haber barra libre, el umbral estará en el impacto del error, en el número de errores previos, la responsabilidad de la persona en el mismo y el puesto que ocupe dentro de la organización.

Siendo conscientes de la existencia de límites si queremos que nuestro equipo de trabajo evolucione, hay que darle la oportunidad de que además de desempeñar su trabajo habitual asuman decisiones, realicen tareas de una complejidad mayor a las que venían realizando y/o efectúen actividades complementarias. Estos saltos, estas salidas de la rutina generarán sin dudas errores y equivocaciones, pero hay que entender que éstos son consecuencia de una evolución normal del personal en la organización y ya es tarea de los responsables de dichas personas impedir el error antes de que se produzca o paliar los efectos si no se detecta a tiempo. Si no se permite esta evolución por miedo a los errores se estará tirando, desde mi punto de vista, piedras contra nuestra propio tejado, ya que la experiencia también se mide en responsabilidades y en vivencias y si nuestro equipo de trabajo no las tiene, está condenado a madurar mucho más lentamente, a acomodarse y a tener menos posibilidades de crecimiento en la organización, ya que se tenderá a buscar en el mercado lo que no se ha podido generar dentro de la misma y en mi opinión debe existir un equilibrio entre los fichajes (muchas veces necesarios y otras porque el mercado permite acceder a un recurso o a unos recursos muy valiosos) y la promoción interna del personal, ya que si los trabajadores ven pocas posibilidades de evolucionar, surgirá desmotivación y una reducción de la productividad, además de una posible marcha de algunos de ellos buscando otras alternativas.

Perfiles del contratante sin RSS

Una de las vías importantes para conseguir ingresos por parte de las empresas de desarrollo de software es la contratación pública con la Administración, ya sea central, autonómica o local. De hecho hay muchas empresas donde la mayor parte de la facturación se realiza contra este tipo de clientes.

El artículo 42 de la Ley de Contratos del Sector Público establece la obligatoriedad de que los órganos de contratación difundan en los perfiles del contratante la información relacionada con las diferentes licitaciones relacionadas con ellas.

De esta manera se pretende facilitar el acceso a la información relacionada con las licitaciones públicas, al homogeneizar la forma en que esta información debe ser publicada, intentando corregir de esta manera ese suplicio que era localizar la información de licitación en las diferentes webs de Administraciones que tenían a bien publicar este tipo de información o tener que recurrir a la lectura de los Boletines Oficiales.

Hay muchas empresas que tienen contratadas a algunas empresas especializadas el suministro de información sobre las diferentes licitaciones públicas que van apareciendo, pudiendo seleccionar la temática sobre la que les interesa ser informados. Quien no desee utilizar esos servicios, necesita acceder a los diferentes Perfiles del Contratante.

Dada la gran cantidad de Administraciones Públicas y que el Perfil del Contratante de la Administración General del Estado no recoge todas las licitaciones públicas, hace que la consulta manual a los diferentes perfiles del contratante sea un auténtico suplicio, es decir, se ha homogeneizado dónde se accede a la información, pero sin ningún tipo de solución técnica hay que seguir entrando uno a uno en cada Perfil del Contratante.

Este suplicio, se reduce considerablemente cuando la información de las licitaciones se publica también en RSS o protocolo similar, ya que no hace falta acceder a los perfiles del contratante debido a que el agregador hace ese trabajo por ti, te avisa cuando se publica algo nuevo y además te da la oportunidad de organizar a tu antojo el acceso a las diferentes páginas o consultas.

El problema se produce por tanto cuando los perfiles del contratante no tienen publicada la información de esa manera, obligandote a entrar para consultar la información, algo que como comenté antes resulta demasiado tedioso si el espectro de búsqueda de información de licitaciones es amplio. El uso de otras soluciones, como por ejemplo, Page2RSS, para intentar paliar el problema, funciona de manera desigual en función de donde se utilice.

De todas los perfiles del contratante que he visitado, el más simple y a la vez potente de consultar es el de la Junta de Andalucía, que además, tiene implementado el acceso por RSS.

Permitir el acceso por RSS a la información es una acción sencilla y que simplifica muchísimo la consulta de la misma, por esa razón, no termino de entender como muchísimos (la mayoría) de los perfiles del contratante no comparten la información haciendo uso de ese protocolo u otro similar, ya que si lo que se pretende es dar facilidades para el acceso a la información, la no utilización de esa estrategia provoca el efecto contrario o al menos no ayuda, lo que debería ayudar.

Automatiza, reutiliza y prueba que algo queda

Todo lo que sea huir de métodos artesanales en los procesos de desarrollo de software supone tiempo y dinero o lo que es lo mismo dinero y dinero.

1) Intenta que todos los desarrollos de la empresa sigan un mismo framework siempre que sea posible (en ocasiones las imposición de una determinada arquitectura o tecnología por el cliente lo impide, pero en el resto de casos, siempre que se pueda, haz uso del framework). El framework además es recomendable que esté recogido en un libro blanco de desarrollo (que va más allá del framework, lógicamente) y mantener ese libro blanco actualizado. Este framework único facilita la movilidad de los programadores entre proyectos y la mantenibilidad de los sistemas. No tengas miedo en actualizar el framework o el libro blanco, si aparece o encuentras alguna librería, componente, arquitectura, etc… mejor que la que usas, más estable, más robusta y/o que te permite una mayor productividad no dudes en cambiar el framework, eso sí, debe hacerse con prudencia y con un espacio de tiempo razonable entre cambio y cambio.

2) Intenta que el framework se base en estándares.

3) Si además del framework base, se tienen componentes software concretos y completos que resuelven problemáticas cada uno de ellos en diferentes tipos de proyectos, mejor que mejor.

4) Si se tienen productos completos que simplemente requieren su personalización en función del cliente, todavía mejor.

5) Siempre se habla de reutilizar código, pero si se consiguen reutilizar requisitos de proyectos o lo que es lo mismo la experiencia, también resulta de gran importancia. Para esto hay que documentar y establecer mecanismos que permitan localizar en la documentación de proyectos lo que se quiere y de esta forma obtener conocimiento.

6) La documentación de los proyectos queda obsoleta por la evolución de los mismos y resulta muy costosa mantenerla, por lo tanto, lo mejor es tener poca documentación pero buena y mantenerla actualizada. Por otro lado, toda aquella documentación que se pueda automatizar bienvenida sea y toda aquella documentación que se pueda sustituir mediante la aplicación de ingeniería inversa sobre cualquiera de los elementos del programa, sustitúyase.

7) Si existe software de gestión de versiones, MAVEN y herramientas software para definir entornos de integración continua, utilícense. Eso sí, bien. De nada te vale tener los fuentes en SVN si no tienes una buena política de etiquetado, de nada te vale usar MAVEN si no estrujas su potencial para automatizarte tareas, etc…

Independientemente de que se definan buenas prácticas hay que verificar que se siguen. Si puedes ten uno o más arquitectos que vayan sondeando el estado tecnológico de cada proyecto.

9) Ten documentado como es el proceso de implantación de software en tus clientes, permitirá ahorrar mucho tiempo.

10) Nunca es una pérdida de tiempo cada minuto que dediques a probar la aplicación antes de entregarla al cliente.

Aprovechar el momento

Durante mis vacaciones coincidí en mi hotel con un actor que hace unos nueve o diez años tenía una gran popularidad gracias a su papel en un serie de televisión de moda en aquel momento. No tenía noticias de él desde hace bastante tiempo, por lo que cuando llegué a casa miré por curiosidad cuál había sido su trayectoria estos últimos años y en el mundo de la televisión o del cine su presencia había sido testimonial. Seguro que él sigue ganándose sus habichuelas de manera muy digna, haciendo teatro o cualquier otro tipo de actividad, pero evidentemente ya no es lo mismo que antes.

¿Por qué cuento todo esto? Porque es un ejemplo más de lo importante que es aprovechar el momento, aprovechar cuando tienes éxito e intentar conseguir todo lo posible mientras te encuentras ahí. Esto lo tienen muy claro, por ejemplo, los futbolistas de primera división que pese a que ganan cantidades desorbitadas de dinero (por mucho que ellos sean los protagonistas del espectáculo futbolístico, nunca compartiré ni lo que se paga por ellos, ni lo que cobran (pero eso es otra historia)), miran hasta el último céntimo de euro que pueden ganar, porque saben que su vida tras el fútbol es un tanto incierta y están acostumbrados a un tren de vida al que les resulta complicado renunciar.

El éxito puede ser efímero o muy duradero y en cualquiera de los dos casos, hay que sacar todo el beneficio que se pueda. Algunos ejemplos de personajes que tuvieron un éxito relativamente (digo lo de relativamente, porque algunos de los que voy a mencionar estuvieron varios años en la cresta de la ola) efímero y que por el motivo que fuera (ellos mismos, el público, malos consejeros, saturación, no haber conseguido evolucionar, aparición de competidores que ocuparon su puesto en el mercado, etc…) dejaron de tener un éxito similar al que tuvieron en su momento más álgido, los tenemos en Ralph Macchio (Karate Kid), Macaulay Culkin (Solo en casa), Jaleel White (Steve Urkel/Cosas de casa), el grupo Take That, etc… Si ellos supieron sacar el máximo beneficio económico durante el tiempo en que estuvieron en lo más alto habrán podido paliar épocas donde su repercusión fue más discreta y lo mismo pudieron hacer inversiones que les asegurasen una estabilidad económica futura (esto no sucede en muchos casos y habremos visto o leído situaciones de personajes que fueron muy populares en un momento dado y que se arruinaron después).

Lo que quiero decir con este artículo es que evidentemente cualquier persona u organización debe intentar sacar el máximo rendimiento posible cuando se tiene éxito, en primer lugar porque el presente es lo único que existe realmente y en segundo lugar porque el mañana es lo único que existirá realmente, es decir, es como si te dicen, tienes una hora para coger todas las monedas que quieras de esa piscina de monedas de oro y te limitas a coger monedas sólo durante diez minutos pensando en que mañana, pasado y el otro te van a dar la oportunidad de seguir cogiendo otras monedas, si eso no es así y se termina cerrando tu acceso a la piscina, te acordarás de no haber aprovechado la oportunidad que se te brindó.

Aprovechar el momento no debe consistir sólo en ganar dinero, ya que tan negativo como quedarte dormido y no aprovechar tus momentos álgidos es quedarte dormido en una situación de autocomplacencia. Yo entiendo que el éxito se tiene que aprovechar para asegurar en la medida de lo posible lo que vendrá mañana y dar una estabilidad a tu persona o a tu organización y ambas cosas son compatibles (aprovechar y vivir el momento, mirando de reojo al día de mañana). Vivir el éxito con los ojos cerrados debe ser directamente proporcional a recordar con los ojos abiertos lo que tuviste y ya has dejado de tener. Un ejemplo claro de lo que acabo de contar lo tenemos con el ladrillo, donde muchas personas y empresas han ganado mucho dinero y otras muchas después de ganar mucho dinero lo han perdido todo e incluso más. Si el éxito permite abrir puertas, evolucionar y crear bases sólidas, ¿por qué no se intenta aprovechar esas oportunidades?.

Muy pocas empresas o personas pueden disfrutar de un éxito estable, ya que la vida es muy senoidal y hoy estás arriba, mañana abajo, pasado un poco más arriba y así sucesivamente, por ese motivo si no se aprovechan las épocas donde las cosas van de cara no tendremos solidez o estructuras que permitan paliar o reducir los efectos de aquellas eṕocas donde las cosas no nos vayan tan bien.

Se desarrolla para el usuario final

Otro error muy común en el proceso de desarrollo de software (y en el que yo también he caído) es olvidar que el producto que se está implementando no es para nosotros sino para el usuario final e independientemente de que tengamos la sensación de que conozcamos perfectamente lo que quiere el usuario o que dominamos la materia, tenemos que buscar hasta donde sea posible la implicación del usuario, no solo durante el proceso de definición del sistema, sino durante el proceso de construcción.

Si los que nos dedicamos al desarrollo de software, que ya tenemos una cierta experiencia en abstraer problemas, nos encontramos con dificultades en numerosas ocasiones para llevar a un programa de ordenador un determinado proceso y nos damos cuenta muchas veces cuando se está construyendo que hay piezas que no encajan, ¿podemos pedir al usuario que tenga esa misma capacidad de abstracción?, algunos pensaréis: “era obligación del usuario leerse el análisis”, ¿de verdad pensáis que el usuario puede llegar mucho más allá del análisis de requisitos, de la descripción de casos de uso, de la revisión de las interfaces de usuario y su navegación?, salvo que el sistema no sea excesivamente grande, que los entregables que acabo de indicar se realicen de la forma más completa, exacta y clara posible, y que el usuario se esmere en repasarlos (y aún así), quedarán resquicios que cuanto más se tarden en corregir más costosos serán para el desarrollador.

Lo que acabo de comentar en el párrafo anterior no es un vale todo para el usuario, es decir, éste debe asumir su responsabilidad en el proyecto y de alguna u otra forma se lo tenemos que hacer ver. El desarrollo de software no se hace con una pizarra y una tiza, donde se puede borrar y volver a escribir libremente, es un proceso tan complejo en el que no vale la barra libre. Lo que vengo a comentar es que en el desarrollo de software se debe ser consciente de que cuanto más se tarde en detectar un error más vale corregirlo y que los usuarios en la mayoría de los casos no toman conciencia del programa y de los problemas hasta que se enfrentan a él. Como podéis ver se trata prácticamente de dos extremos, de hecho cuanto peor se hagan las cosas (por parte del desarrollador y del usuario (por no hacer frente, este último, a su responsabilidad)) se cumplirán ambos extremos, lo que provocará que el proyecto salga caro (lo cual puede repercutir sobre el usuario o sobre el desarrollador (más bien, sobre este último)) y que la calidad del mismo se vea muy perjudicada.

Por tanto, es importante que no olvidemos que las aplicaciones se desarrollan para los usuarios y que por tanto hay que buscar la mayor implicación posible por parte de los mismos en todo el proceso de desarrollo de software. ¿Qué el usuario no se implica? Hay que intentar que siempre quede patente este hecho (evidentemente hay que saber hacerlo con tacto), ya que más adelante si el proyecto no ha salido como debía y hay que empezar a parchear, que todo el gasto de ese parcheo no repercuta directamente sobre el desarrollador.