Tu puesto de trabajo no está disponible…

Esta fue la noticia que me dieron el martes por la tarde, que mi puesto de trabajo no estaba ya disponible. Me recordó un poco a la película de Up in the Air.

En estos tiempos en los que has visto como despedían incluso a gente perfectamente válida y muy profesional, porque no había trabajo, no extraña a nadie que también le toque a uno.

Hay muchas formas de afrontarlo y no voy a negar que te genera una cierta sensación de intranquilidad.

Pero ahora toca mirar hacia el futuro y adecuarse a la nueva situación. De las formas de afrontar esta nueva situación que conozco la que me parece más adecuada es en la línea de la marca personal de que soy una «empresa» sin cliente. Es casualidad que justo el día siguiente, miércoles, salía una entrada, que estaba programada desde el fin de semana,  en este blog sobre la mejora continua en los ciclos, tanto en los momentos de bonanza como en los de escasez.

Cuando estas trabajando, por cuenta ajena como era mi caso, obviamente no dedicas muchos esfuerzos a buscar nuevos «clientes». Pero en esta nueva situación obviamente si que lo tengo que realizar.

Toca revisar y reforzar la estrategia de comunicación, ya que aunque desde hace un tiempo tengo este web, con su twitter y mi perfil en LinkedIn, ahora se hace más importante para poder tener una visibilidad adecuada y conseguir que si alguien tiene que elegir un profesional de la industrialización del desarrollo de software o de la arquitectura de aplicaciones Web sea yo el elegido.

También tengo que diseñar una estrategia de «networking» para conseguir dos objetivos: poner en valor el «networking» actual y que me pueda ayudar a conseguir mis objetivos, como yo he ayudado a otros compañeros en el pasado. Y por otra parte ampliar la red de contactos de profesionales y empresas que pueden en un momento necesitado requerir mis servicios.

Estas dos áreas son las más prioritarias, pero tampoco puedo dejar de prestar atención a cual es mi producto. Tengo que revisar si lo que ofrezco tiene salida en el mercado o si necesito complementarlo con alguna cosa más. Alguna idea ya tenia desde algún tiempo de complementar, digamos que mi «portfolio», con herramientas, métodos y procedimientos de testing.

Para poder tener claro este planteamiento me ha resultado de mucha utilidad el haber leído este verano el libro de marca personal de Andrés Pérez Ortega, y todo el material que tiene disponible. También me ha servido bastante el libro de «Tu modelo de Negocio«.

Pero en ambos casos estos libros y su filosofía subyacente lo que te proporciona es el QUE hay que definir, no tanto el COMO (creo que Andrés está preparando un libro sobre este aspecto). Tiene una cierta similitud en la industria del software con los modelos CMMI, ISO, etc que te dicen el QUE y las metodologías como SCRUM, ciclo de vida en cascada, etc. que te dicen el COMO.

Así que la pregunta es: ¿Como me organizo todo el trabajo que tengo que hacer?. No quisiera caer en el error del «parálisis por análisis» que tanto se menciona en los artículos sobre emprendimiento y en la ingeniería del software. Esto se me asemeja mucho al ciclo de vida en cascada, en el que no empiezo a programar hasta que no tengo perfectamente claro el diseño, y este no lo empiezo a hacer hasta que no tengo perfectamente claro el análisis, etc.

El problema es que no tengo perfectamente claro todo, no hay Yesterday Weather.

¿Y si me organizo de forma ágil? Con todo lo que estoy aprendiendo en el MOOC de Agilismo de Javier Garzás y en el libro Métodos ágiles y scrum. Sprints, BackLog, etc…

Si una familia se pudo organizar utilizando Scrum, ¿porque no va a servirme a mi para organizar mi nueva situación laboral?

Decidido, lo voy a intentar así. Una marca personal ágil…

Los ciclos y la mejora continua

El otro día leí en un libro que la economía es cíclica, eso todos los sabemos. Hay épocas de bonanza y otras de escaseo.

Eso lleva a hacer un planteamiento muy sencillo. Cuando las cosas van mal, como en esta época hay que pesar que tarde o temprano se acabará y llegará otra época de bonanza. También cuando las cosas van viento en popa hay que pensar que vendrán mal dadas.

Y esta situación no es algo que nosotros como individuos podamos controlar. Lo que podemos hacer es estar preparados. Cuando las cosas van mal hay que seguir intentado mejorar para que cuando se salga del bache podamos estar en mejor situación para aprovechar la mejoría. Y cuando las cosas van bien hay que mejorar, todavía con mas ahínco, porque sabemos que vendrán mal dadas, y cuanto mejor nos hayamos preparados mejor podremos soportar el golpe.

En resumidas cuentas, siempre hay que mejorar, y más en un negocio como este de las tecnologías de la información en las que el dinamismo es tan grande.

Discutir es bueno

En todos estos temas del agilismo se hace mucho hincapié en la comunicación. Recuerdo una conversación con uno de los máximos jefes de donde trabajaba en la me decía que discutir era bueno. Que obligaba a la otra parte a plantearse las cosas.

La conversación venia a raíz de un compañero jefe de proyecto que tenia como jefe a una persona con mucho carácter y al que no contradecía.

En algunos otros post he tratado este tema, me parece que es positivo el aportar ideas, siempre intentando ser constructivo y poniendo mucho cuidado en no aportar tonterías y que ese aportar se vuelva en tu contra, porque dejes una impresión de inmadurez.

Probar vs validar

La primera vez que escuche que el cliente/usuario no probaba la aplicación sino que solo la validaba no entendí nada.

Total si es lo mismo, pensaba yo, entrar en la aplicación y comprobar que funciona bien… Pero no, no es lo mismo probar que validar.

Sin ponerme muy academicista, con un ejemplo se entenderá mejor.

Un cliente/usuario no tiene que entrar en la aplicación y comprobar que si no mete un dato en un campo obligatorio la aplicación le saca un mensaje de error sin «petar». Eso es probar la aplicación, es tarea del programador y del responsable que da el visto bueno en caso de que exista. Os dejo una entrada sobre pruebas que no podemos fallar.

El cliente/usuario si tiene que entrar a la aplicación y comprobar que la lógica es la correcta, es decir que, si por ejemplo, es una aplicación de venta, cuando se vende un producto este se descuenta del almacén y se genera la factura y si hay poco stock envía una notificación a compras para que …

Es importante distinguir esos dos conceptos. Hay clientes que ya se están incluso negando a probar la aplicación en producción, por el tiempo que les lleva…

¿Cada vez menos programadores?

Unas reflexiones a raíz de una entrada en el blog de Javier Garzás sobre si se va a necesitar cada vez menos programadores.

En los casi 15 años que llevo en la profesión lo que si que he visto es que se ha ido modificando la tarea del programador.

En aquella época lo que se hacían eran Webs, lo que hoy serían portales. Se hacían a medida. Hoy día existen multitud de herramientas, tanto gratuitas como de pago que te permiten montar un portal en un periquete, con muchísima funcionalidad. Tres cuartos de lo mismo ocurre con el tema del comercio electrónico, etc.

Esto hace que se empiecen a necesitar menos programadores y más parametrizadores de paquetes.

También hace que se empieze a necesitar más profesionales de integración de diferentes paquetes.

Es cierto que cada vez el desarrollo es más de producto y de nicho.

De producto porque alguien tiene que desarrollar esos gestores de portales, por ejemplo. Es decir se ha ido pasando del traje a medida al traje estándar. Por dos motivos. Porque el traje a medida es muy caro y tampoco hay tantos sastres buenos para tanto traje y porque al final todos tenemos un cuerpo más o menos a medida.

De nicho porque siempre habrá alguien que tenga una necesidad no cubierta por paquetes estándar.

También dentro de la programación hay un cambio ya que cada vez existen más librerías o herramientas que te ayudan a construir tu aplicación. Por ejemplo hay multitud de librerías para el acceso a datos, que hace 15 años no existían.

Es decir hasta en la programación cada vez se necesita tirar menos líneas de código y más el conocer librerías y sus peculiaridades.

Pruebas de cobertura

Las pruebas de cobertura son una herramienta útil para poder bucear en nuestro código. Supongamos que disponemos de una aplicación desarrollada que vamos a probar, bien de forma automatizada bien de forma manual.

Nos pueden surgir dos dudas. ¿Hemos probado todos los casos posibles? o bien ¿Existe código muerto, es decir que no se usa nunca?

Para ayudarnos a despejar estas dos dudas existen herramientas que nos permiten hacer pruebas de cobertura. Es decir, en el caso de Java, ponen la máquina virtual en un modo que va indicando que líneas de código va ejecutando. Con esa información podemos saber si hay alguna línea de código por la que no se ha pasado nunca y averiguar si es que nuestro juego de ensayo no es suficientemente exhaustivo o por el contrario hay código muerto, que sobra.

Dentro de las herramientas gratuitas para Java la más popular es JaCoCo, aunque existen otras que están descontinuadas o con muy poco soporte.

Lo que la gente se imagina

El otro día una amiga y compañera de trabajo me comentó que escribía cosas muy raras aquí. Esta entrada no le va a defraudar…

A veces es curioso el mecanismo que tiene el cerebro para asociar ideas. Resulta que estaba buscando por Internet información sobre productos de «grooming», vamos el aseo personal de toda la vida, ya que aparte del tema del afeitado, tengo un problema para encontrar un desodorante que no me irrite la piel, sea efectivo y no me destroce las camisas.

Acabé en el web de Lóccitane . No he probado todavía ninguno de sus productos, pero me gustó el planteamiento que exponen. Viene a ser un preferimos productos naturales, pero en algunos casos como no hay un equivalente natural de calidad, usamos productos sintéticos. Digamos que un naturismo/ecologismo práctico.

Eso me hizo recordar una vez, al principio de mi carrera profesional, que tuve el privilegio de tener una entrevista, casi una clase particular, con uno de los profesionales de la zona más respetados en la selección de personal.

Me comentó muchas cosas, una de ellas es que había que intentar ser lo más normal del mundo, y concretamente me dijo que nada de enviar los curriculums en papel reciclado, porque corría el riesgo de que el destinatario se pensase que era un ecologista que le iba a andar luego con que la moqueta de la oficina no era ecológica y cosas de esas.

Este planteamiento va en contra de los planteamientos de marca personal, de diferenciarse para aportar valor y no ser un profesional de marca blanca.

Los curriculums contestan a tres preguntas (Esto también me lo contó el):

  • Quien soy, es decir mis datos personales.
  • Que se, es decir mi formación académica y no académica.
  • Que he hecho, es decir los trabajos y las tareas que he realizado.
El problema es que no contestan a preguntas fundamentales, como que es lo que pienso, en que creo, cuales son mis valores, etc.
Puedo enviar un curriculum en papel reciclado porque me preocupa cuidar el medio ambiente y la diferencia de coste entre un papel y otro es despreciable, sin que ello implique que soy un activista ecológico que voy a colgar pancartas a la entrada de la oficina.

Para coger hay que dejar

Hace tiempo trabajé en una empresa en la que era la punta de lanza en cuanto a tecnología de desarrollo de Web con Java.

Un jefe que tuve me solía decir que para coger cosas nuevas tenia que dejar parte de las que ya tenia, porque sino no iba a poder.

Es decir, si eres el que sabe de un tema (tecnología, producto,…) y no traspasas ese conocimiento a otra persona, todas las dudas o necesidades que existan sobre ese tema vas a tener que atenderlas tu y eso te va a quitar tiempo para poder coger nuevos conocimientos sobre otros temas.

No me parece un mal planteamiento, siempre y cuando tengas claro que ese traspasar conocimiento es porque efectivamente vas a coger otro nuevo y no para que puedan prescindir de ti.

En aquellos tiempos de principios del 2000 el desarrollo de web con Java era una materia relativamente abarcable por una persona. Hoy día no lo es. Ha crecido mucho y se hace complicado el poder mantener un nivel, ya no alto sino aceptable en tantas áreas.

En aquellos inicios del 2000 básicamente podías desarrollar en el modelo 1 o modelo 2, es decir hacías una jsp con todo o la jsp solo tenia le presentación y la lógica de negocio la implementabas en un servlet.

Actualmente hay multitud de frameworks, incluso alguno son diferentes sabores.

Hoy día tienes que renunciar conscientemente a ser un experto en ciertos temas para poder mantener un nivel aceptable en otros, sino caes en el riesgo de no saber de nada.

Desarrollo vs Integración

Cuando diseñas una infraestructura para industrializar el desarrollo de software hay que tener en cuenta las diferencias entre el entorno de desarrollo y el entorno de integración. En ambos quieres compilar y probar el software, pero los requisitos son diferentes.

En el entorno de desarrollo, donde están trabajando los desarrolladores es muy importante el tiempo. Es decir hay que ser muy ágil en el ciclo de hacer una modificación y se probarla. La falta de agilidad hace que se pierda mucho tiempo en un ciclo de modificación y prueba que se realiza muchas veces a lo largo del día.

En cambio en el entorno de integración, en el que el compilar y probar se va a realizar una vez que la modificación ya se ha dado por terminada, no es tan crítico el tiempo, obviamente dentro de un orden.

Es en este entorno de integración en el que podemos invertir más tiempo en realizar más comprobaciones.

En tu repositorio o en el mio

Esta no es una entrada de la línea de que le pido a un repositorio de código, porque no siempre es un requisito el disponer de un repositorio de código distribuido.

Pero si que es cierto que alguna vez he estado en discusiones con los clientes en las que ha salido el tema de que repositorio utilizar, si el del cliente o el del proveedor. Es una decisión un poco estéril ya que el cliente puede imponerte entregar el producto que ha comprado en su repositorio, y tampoco tiene normalmente potestad para prohibirte el utilizar tu propio repositorio.

El problema suele venir por el hecho de que muchas veces la conexión con tu cliente se hace por medios no transparentes, es decir mediante VPN o similares, que hacen que el trabajar contra la infraestructura del cliente sea algo engorroso.

Aparte hay que tener en cuenta que aunque la propiedad intelectual del producto construido sea del cliente normalmente las empresas suelen querer tener una copia del trabajo realizado, simplemente para en caso de reclamación poder demostrar si ha habido o no modificaciones ajenas al desarrollo realizado.

En estos casos el utilizar un repositorio distribuido como es el caso del Git aporta bastantes ventajas, ya que permite diluir esa discusión de si utilizar el repositorio del cliente o el del proveedor. Puedes utilizar el de tu empresa y luego empujar los cambios al del cliente.