¡¡ Soy RICO !!

Si la verdadera medida de la riqueza es el tiempo, como dice Tim Ferriss en su libro "La semana laboral de 4 horas", hoy soy infinitamente más rico que ayer.

Hoy es el día en el que he llegado a un acuerdo con la empresa en la que trabajaba (una Consultora a medio camino de ser cárnica) para poner fin al contrato que nos unía. No es para ponerse triste aunque todos los que me aprecian han puesto un poco cara de "como es posible" o bien de "con lo mala que está la cosa".

El mundo está lleno de oportunidades para quien sepa encontrarlas y yo voy a salir en su busca.

A partir de ahora me he hecho un propósito:

Nunca volveré a ser tan pobre como he sido hasta hoy, que durante tres meses al año no veía la luz del sol.

A forrarse, que estamos en crisis

Un título contradictorio sin duda, pero es cierto, hay quien está aprovechando la crisis para ganar su buen dinerito.

Explicaremos hoy "La técnica del oso".

Se llama así porque es como le llaman (bear, en inglés) a quienes la practican.

Consiste en alquilar a su propietario un paquete de acciones de una determinada empresa y devolvérselas cuando termine el plazo acordado pagando un porcentaje por el alquiler.

Una vez que tiene las acciones en su poder el oso las vende y espera a que el plazo de alquiler termine para recomprarlas, devolvérselas a su propietario y quedarse con la diferencia. Esta técnica se utiliza con valores que se supone que van a bajar, ya que ahí está el beneficio.

En principio, podría parecer poca cosa, pero teniendo en cuenta que algunos bancos, inmobiliarias, etc. han caído a plomo en los últimos meses no es tan poco.

Para saber más

Un poco más

¿Cultura de la Presencia o del Cumplimiento?

En pleno siglo XXI, todavía seguimos en muchos aspectos como a finales del XIX a pesar de la enorme transformación que ha sufrido toda la sociedad, particularmente acelerada en los últimos años en todo lo referente a formas de comunicación, de trabajo y de relaciones personales con la aparición de Internet.

Refiriéndome al caso concreto de las empresas de base tecnológica (TIC's), aunque hoy todas las empresas son de alguna forma TIC's , hay algunas que se han dado cuenta del cambio y lo intentan aprovechar y otras (la mayoría) que se siguen gestionando como si fabricaran tornillos. Se trata de que cada persona (recurso, le llaman) esté en su puesto las horas que debe estar y controlar ¡en fracciones de cuarto de hora! qué hace cada una. Es como tener a Frankenstein de jefe de proyecto.

Si fuera el caso de la fábrica de tornillos se entendería, porque en una cadena de montaje no hace falta pensar para producir. Pero en el desarrollo de software o en la economía del conocimiento en general, lo más importante no es la presencia física sino el talento.

Una persona podría trabajar desde su casa, con un ordenador y una línea ADSL y ser productivo para una empresa o estar en su sitio desde el amanecer y no producir absolutamente nada, porque está pensando en el problema que tuvo ayer con su novia.

Un paso más hacia el siglo XIX o hacia el XXI, la cuestión.

Para saber más sobre

• Nueva filosofía laboral
• El futuro que ya está aquí
• Oficina móvil
• La oficina del siglo XXI
• Gestión del talento
• Retos de la empresa en RR. HH.
  

Las tres respuestas

Para todo en la vida hay 3 respuestas, y a nosotros nos corresponde elegir.

La primera, consiste en no hacer nada; en pensar: “Así es la vida. No hay nada que pueda hacer”. Es la respuesta de la resignación.

La segunda respuesta consiste en enfadarse frente a lo que ocurre; en pensar: “Qué estúpida es esta gente, que solo sabe hacer estas tonterías”. Es la respuesta de la ira.

Y, afortunadamente, existe una tercera respuesta, que consiste en levantarte y dirigir la orquesta; en intentar cambiar las cosas con tu contribución diaria. Esta es la respuesta de la posibilidad.

NOTA: Esta entrada ha sido copia-pegada de aquí.
Gracias al autor.

De SCRUM a NADA

Es normal en blogs y páginas dedicadas a temas de agilidad, XP o Scrum hablar del cambio tan positivo que se produce en el equipo, en el cliente, en el avance del proyecto, en la calidad, ..., al empezar a utilizar dichas técnicas.

Se habla también de la mejora en el ambiente de trabajo, de la confianza que va impregnando el equipo, de la satisfacción por ver que el proyecto avanza, etc.

Pues bien, a mi me gustaría hablar hoy del caso contrario:
Un proyecto que empezó con SCRUM

• Comunicando al cliente como sería el desarrollo
• Diseñando la pila de producto y las pilas de Sprints, con distinto grado de detalle.
• Realizando reuniones diarias
  
• Entregando en fecha el resultado de los Sprints
• Se cerraron los dos primeros Sprints en fecha, con evidente sa
  
• En fin, un proyecto que no tenía pinta de terminar mal

Peeeeero, siempre hay un pero, era un proyecto:

• A precio cerrado (el cliente paga lo que dice en el contrato)
  
• Con requisitos abiertos (los requisitos sobre los que se ha hecho la estimación son cambiantes)
  
• Con un análisis previo tipo BDUF , que el jefe de proyecto (Él) pretende usar como contrato
  
• A Él le parecían "demasiadas reuniones", las de 15 min. por la mañana
• El responsable debe asignar las tareas a todos, dijo Él
• La estimación es cosa del analista y del Jefe de Proyecto
• No tengo información de como vamos, esto también lo dijo Él. A pesar de tener constancia de qué, cuando y como se hace cada tarea (gracias al excel de Navegapolis)
• En fin, un proyecto que no parece que vaya a terminar bien

Resultados y conclusiones

• SCRUM no es más que una tontería, por tanto se deja de usar
• Fuera reuniones mañaneras, son pérdidas de tiempo. Se pierde el enfoque a corto plazo
  
• Fuera reuniones de todo el equipo: Se hacen jerárquicamente y luego se van contando al resto (algún día debo hablar sobre el juego del teléfono)
  
• Los análisis y las planificaciones las hacen los gurús y se las cuentan al resto del equipo.
• Los gurús asignan tareas
• Como se eliminan los sprints, ahora es un continuo y se ha perdido el enfoque a medio plazo.
  
• Ahora el proyecto se sabe como va, a pesar de no saber qué hace quien ni para cuando estará
• Por último algo sin importancia: La moral del equipo no ha disminuido, ha DESAPARECIDO

Siguiendo con mi costumbre de estar equivocado (ya un clásico) diría que cada día se aproxima más al abismo, pero soy el único que lo piensa...

9 Pasos

Ya toca un poco de técnica ¿no?.

Leyendo y saltando por el ciber-despacio he llegado al blog de Sebastian y allí he descubierto unas simpáticas viñetas sobre como mejorar el diseño de las aplicaciones (ya dije que esta vez tocaba).

Se trata de unas técnicas de ingeniería complicadísimas como, por ejemplo,  no hacer métodos gigantes o anidar IF-THEN-ELSE hasta que no se entienda el código. En fin, cosas muy complicadas.

Son 9 aunque de momento sólo hay 6. Seguiremos atentos

Las resumo para quien le cueste trabajo el inglés:

1. No hacer métodos gigantes
2. No usar la palabra ELSE
3. Envolver las cadenas y tipos primitivos
4. Una sola operación en cada línea
5. No abreviar los nombres (en métodos o atributos)
6. Mantener las entidades pequeñas
7. ...
8. ...
9. ...

Por si alguien está interesado, es aquí

Es lunes, toca economía

Como ya dije, soy un lector empedernido y los domingos toca leer el periódico, empezando por las páginas anaranjadas, las de economía. Así que me he propuesto dedicar una entrada los lunes a algún tema económico que me haya llamado la atención.

Ayer me encontré con un artículo que hablaba sobre la situación en Italia y un concepto nuevo para mí: El síndrome de la cuarta semana

Se refiere a las dificultades para llegar a fin de mes, una vez que se ha acabado el cada vez más escaso salario y hay que hacer piruetas para llegar a fin de mes. Incluso he leído en alguna parte que este efecto se traslada ya a la tercera semana.

Puede que lo único que hayan hecho haya sido ponerle nombre a un fenómeno que se extiende como una mancha de aceite y en mayor o menor medida nos afecta a todos: Los salarios reales disminuyen mientras los precios (mucho más reales) aumentan, aunque los IPCs digan otra cosa.

Para saber más, artículo en El País

Ahorro

Ahora que estamos en plena crisis, por si alguien no lo sabe, todo el mundo en todas partes está intentando ahorrar costes.

En unos sitios lo consiguen (o lo intentan) reduciendo plantillas, cortando el acceso desde móviles a números no corporativos, quitando en definitiva todo lo que no sea absolutamente imprescindible para el negocio.

Pero una cuestión que parecen no tener en cuenta las mentes pensantes, al menos en negocios tecnológicos que son los que más conozco, es el coste y la pérdida de rendimiento (dinero en definitiva) que conlleva la reasignación de personas de una tecnología a otra.

Por mi experiencia, una persona necesita aproximadamente un año trabajando en un entorno determinado y, a ser posible, dentro de un equipo que le ayude, para ser productivo en una tecnología. Parecería lógico que este proceso inevitable cuando una persona empieza su carrera laboral se realizara una sola vez e intentar acortarlo todo lo posible, de forma que esa persona fuera rentable para la empresa en el menor plazo posible.

Sin embargo, es frecuente que programadores de Java se reciclen en .Net y luego en PHP y luego en COBOL y así sucesivamente.

A lo mejor habría que ver el efecto psicológico de estas prácticas y su impacto económico, porque la curva de aprendizaje de cada tecnología es más larga que la anterior y el nivel de conocimiento alcanzado es cada vez menor. De todos los factores que intervienen en el desarrollo de software, los más importantes son las personas y su talento. No lo olvidemos.

A lo mejor habría que revisar (también) como se distribuyen los costes en los proyectos, teniendo en cuenta la pérdida de eficiencia derivada de las reasignaciones a sucesivas tecnologías de los integrantes de los equipos, porque puede que esta sea una forma de reducir costes y, además, de mejorar beneficios.

Para saber más wikilearning

Una bonita herramienta

Esta herramienta desarrollada por una empresa japonesa se basa en principios ágiles, como Lean y Kanban.

Es una herramienta para la gestión de proyectos centrada en el equipo, con tres vistas principales: tiempo, tareas y equipo.

Puntos destacados

• Tablero Kanban: Visualiza el estado del proyecto de una forma bastante intuitiva, como si fueran post-it es una pared.
  
• Gráfico de burndown: Integrado en la pantalla principal, proporciona una vista rápida del avance del proyecto.
  
• Niko-niko calendar: Muestra el estado anímico de los miembros del equipo y tiene una especie de twitter integrado.
• Está desarrollado en Java y tiene una versión "community"
• Permite la múltiples proyectos (workspaces) y tiene la capacidad de exportarlos a HTML

Definitivamente me gusta, aunque debería probarla en algún proyecto de verdad para comprobar su utilidad.

Link: Trichord

Glosario de términos: burndown, niko-niko calendar

¡¡Hola Mundo!!

¿Como podría empezar un blog alguien que se dedica al desarrollo de software?

Después de preguntarmelo varias veces y aún a riesgo de no ser original (que creo que no),
me pareció que este era el comienzo adecuado.

Declaración de intenciones

La idea, muchas veces meditada, es que este espacio sirva para compartir mis conocimientos, mis inquietudes y mis experiencias de muchos años de desarrollo de software con la esperanza de ayudar a quien puedan serles de alguna utilidad.

Los temas que, en principio, trataré aquí serán

• Cuestiones técnicas, como bases de datos, UML, Frameworks, etc. En fin, cosas de informáticos.
• Gestión de equipos, proyectos y metodologías ágiles.
• Pensamientos sobre las más diversas cuestiones, según vayan surgiendo.
• Libros. Como lector constante que soy, comentaré aquí lo que vaya aprendiendo de mis nuevas lecturas y lo que recuerdo de las nota nuevas.
• Etc. Como practicante de la agilidad sé que es mejor adaptarse que intentar hacer un plan exacto y seguirlo, así que el futuro está abierto...

Los objetivos son ambiciosos, pero como dijo alguien "Las grandes obras son, en principio, imposibles.