Chess - antoniomartel.com

Archivos de Autor: antoniomartel

El mundo avanza que es una barbaridad

Es una expresión muy castiza pero no por ello deja de ser cierta. En el mundo de la tecnología las cosas suceden más y más rápido cada vez. A los profesionales TI nos cuesta Dios y ayuda saber qué se está cociendo en cada uno de los nichos tecnológicos.

En el desarrollo de software, por ejemplo, si trabajabas hace unos cuantos años para un banco o hacías un programa de contabilidad, trabajabas en un único lenguaje. En tu primer día de trabajo te dejaban un libro muy gordo que se llamaba «La Biblia de (pon aquí tu lenguaje favorito)«. Todo estaba ahí, la lista de instrucciones, sus parámetros y ejemplos de su uso. Tenían incluso un anexo con la lista de todos los errores posibles. Nada podía salir mal. Después de tres años trabajando te conocías la lista completa de errores y no había instrucción que tuviera secretos para ti.

Lamentablemente alguien empezó a poner los servidores cada vez más lejos del usuario: Primero el servidor de base de datos, escondido al fondo de la oficina por lo que tuvimos que aprender SQL. Luego llegó Internet y junto al servidor de base de datos se puso un servidor de aplicaciones. Hubo que aprender a usar un Tomcat y a programar en Java, PHP o .NET.

Cuando al fondo de la oficina no quedaba hueco para tanto servidor se les buscó un sitio en un centro de datos en las afueras, donde había un montón de servidores de empresas diferentes. Pero no fue suficiente, unos años después Google se llevó los servidores y sus datos aún más lejos, a Arkansas o Arizona, o a ambos sitios a la vez, nadie sabe muy bien. Llegó la computación en la nube y ahora comienza a ser imprescindible programar en NoSQL, MongoDB o Cassandra, pero también con Android y para el iPhone, y …

Ya no basta con tener un título universitario. En menos tiempo del que pestañeamos ya hay dos frameworks nuevos. Tampoco basta con acumular pequeños cursos subvencionados, mal traducidos y con temarios que son un ‘refrito’ de la misma información repetida de curso en curso. Coleccionar diplomas como estampitas te puede dar una falsa sensación de seguridad pero en realidad no te está ayudando gran cosa a mantenerte actualizado.

Afortunadamente, al igual que la tecnología nos obliga a mantenernos al día, también nos ayuda a hacerlo con cursos de gran calidad como los que puedes encontrar en Miríada XedX o Coursera. Muchos de estos cursos son impartidos en inglés ¿no lo dominas? Quizás tu formación debería empezar por ahí. Échale un ojo a webs como busuu.com donde podrás enviar tus textos en inglés para que los corrijan nativos de ese idioma. Mientras, tú puedes corregir los de otros alumnos en español. Te recomiendo también memrise.com que te ayudará a aprender nuevo vocabulario y a recordarte el ya aprendido si hace tiempo que no lo repasas o si cometiste un error cuando te lo preguntaba.

Si te interesa saber más sobre la certificación, estimaciones, ventajas y desventajas de Scrum o cómo gestionar proyectos de forma ágil quizás te interese mi libro: Gestión práctica de proyectos con Scrum.

Si en cambio quieres poner a prueba tus conocimientos de Scrum haciendo un test en español antes de tomar el examen de scrum.org aquí tienes el Test no oficial de Scrum (aplicación realizada con Ruby on Rails y desplegada en Heroku).

El ingeniero y el puente

En el siglo V antes de Cristo cierto ingeniero romano fue designado para dirigir la construcción de un puente sobre el río Leza. El puente era importante para la zona, permitiría el paso de personas y mercancías ahorrando tiempo en recorrer largas distancias buscando un paso llano por el que cruzar el río.

El ingeniero acogió su nombramiento con entusiasmo y se lanzó a planificar y estimar todo lo que sería necesario para su construcción. Calculó con exactitud cuantos albañiles, grúas, poleas, andamios y cimbras necesitaría y pudo ver claramente que contando con 50 trabajadores podría terminar un puente como aquel en 4,7 años de trabajo.

Con los 600.000 sestercios que recibió para ejecutar este encargo se apresuró a comprar todo el material que había calculado y ordenó depositarlo a pie de obra. Reclutó los 50 albañiles que había estimado y los envió a orillas del río para empezar los trabajos cuanto antes. No había tiempo que perder, cuanto antes se comience, antes se podrá acabar.

Pronto los trabajadores le dijeron que no eran necesarias tantas poleas y grúas pero que los picos y sierras eran claramente muy pocos para el trabajo que había que hacer. No puedo hacer nada, dijo el ingeniero, ya se ha gastado la mayor parte del presupuesto y no queda gran cosa para comprar nuevo material. Tendrán que adaptarse a lo que hay.

La construcción continuó su curso haciéndose pronto evidente que todo no marchaba según lo previsto. El capataz explicó al ingeniero que la cantera de donde se traía la piedra estaba demasiado lejos y que la calzada estaba llena de baches y socavones desde la riada del pasado invierno. Se tardaba mucho en traer la piedra en carretas hasta el puente. Tendrán que hacer un esfuerzo extra, dijo el ingeniero, no hay tiempo ahora para arreglar la calzada.

El capataz también hizo saber al ingeniero que era necesario construir arcos entre los pilares del puente para reducir los materiales utilizados y, sobre todo, para mejorar la resistencia del puente. No hay tiempo ahora para florituras, dijo el ingeniero, vamos retrasados. Pondremos algo más de mortero en los pilares, con eso será suficiente.

Las noticias sobre la marcha del puente llegaban a oídos del Prefecto que desesperaba por la lentitud de las obras por lo que mandó llamar al ingeniero. El Prefecto necesitaba justificarse ante Roma y exigía que el puente estuviese acabado para las próximas fiestas saturnales. El ingeniero explicó que para conseguir tal cosa necesitaría al menos otros 50 trabajadores adicionales. Ante la presión, el Prefecto accedió y se comprometió a enviar los nuevos trabajadores en el plazo de 1 mes.

De vuelta en el puente, el ingeniero reunió a todos los trabajadores y les pidió un esfuerzo adicional para cumplir los compromisos. Los trabajadores no entendían cómo podían trabajar el doble de rápido si no tenían suficiente piedra para continuar y en cualquier caso siempre debían esperar a que el mortero secase.

Ni siquiera con los nuevos trabajadores pudo terminarse el puente a tiempo. No había herramientas para todos, la piedra seguía llegando con lentitud a la obra y los desmoronamientos eran habituales por las prisas en la construcción.

En la antigua Roma, los constructores de un puente debían colocarse debajo mientras la primera legión lo cruzaba. Es un buen aliciente para construir puentes firmes y sólidos ¿no crees?

Si te interesa saber más sobre gestión ágil de proyectos, estimaciones, ventajas y desventajas de Scrum quizás te interese mi libro: Gestión práctica de proyectos con Scrum.

Si en cambio quieres poner a prueba tus conocimientos de Scrum haciendo un test en español antes de tomar el examen de scrum.org aquí tienes el Test no oficial de Scrum (aplicación realizada con Ruby on Rails y desplegada en Heroku).

Propósitos para el 2014

Se suele decir que para lograr alcanzar nuestras metas debemos definir una serie de pasos objetivos y medibles que nos lleven a nuestro fin. Luego comprobar periódicamente cómo de cerca o de lejos estamos de cumplir nuestros objetivos. Yo no he hecho nada de esto en mis propósitos de este año. Mis metas para 2014 no pueden ser más subjetivas pero me quedaré más que contento si pudiese solo alcanzar la mitad de ellas.

Les dejo en esta imagen un enlace al prezi con mis propósitos en la gestión de proyectos para este nuevo año que comienza. Aquí va:

Propósitos para el 2013 en la gestión de proyectos

Repaso a 2013

Finaliza el año 2013 y con él se cierran casi diez meses de publicaciones semanales en el blog. Han sido unas 45 entradas en las que he escrito sobre muchas cosas diferentes. La temática ha ido adaptándose a mi propia evolución, a mis intereses y por supuesto, también a los temas que percibía como más interesantes por los lectores.

Les dejo aquí un resumen los posts que han tenido más repercusión, empezando por los más leídos:

Los más comentados o con más likes:
Algunas entradas se escribieron durante el primer mes de existencia de este blog por lo que creo que no recibieron la suficiente audiencia. Ahí van:
Este es mi resumen del 2013 en este blog de dirección de proyectos. Sólo me queda desearles que tengan un gran 2014. Espero verles por aquí en este nuevo año.

5 errores gestionando proyectos

Gestionando proyectos se comenten errores continuamente, yo por lo menos he cometido unos cuantos. Publico aquí sólo cinco de ellos, los más importantes o los más confesables según se mire. He metido la pata de muchas otras formas pero había que ponerle algún límite a esta entrada en el blog. Ahí van:

Primero el problema, después la solución

Ese es el orden, primero se identifica un problema y luego se le aplica una solución, no al revés: Es habitual oir hablar de una solución muy guay que luego aplicamos entusiasmados al proyecto. Haya problema previo que solucionar o no. ¿De qué sirve implantar en el trabajo diario el nuevo y sofisticado software para hacer Test Driven Development si realmente estás teniendo un problema mucho más básico con ese proyecto que te trae de cabeza?

Contar los pasos en lugar de mirar el camino

Todos sabemos que en los proyectos se suelen disparar las horas empleadas y que rara vez se cumplen los cálculos hechos en las estimaciones. Nuestra primera reacción suele ser la de supervisar cada hora registrada y hacer complejas gráficas que nos muestren lo bien o mal que vamos con respecto a la estimación pero ¿nos ayuda ésto a terminar antes el proyecto?

Si nos contratasen para llevar una carga desde el punto A hasta el punto B e hiciésemos una estimación según la cual haremos ese trabajo dando 10.000 pasos ¿en qué nos va a ayudar saber que ya hemos dado 5.000? ¿Sabemos dónde estamos o si hemos estado dando vueltas en círculo? ¿No será mejor levantar la vista, mirar cuánto hemos recorrido ya, si el camino realmente lleva a B o si hay algún modo más fácil de llegar allí?

Requisitos fantasma

En ocasiones le pedimos a los miembros del equipo de trabajo que cambien lo que ya han hecho porque ‘así no lo va a aceptar el cliente‘ o porque nosotros pensamos que el producto debe funcionar de otra manera. Nuestro compañero ya hizo una propuesta que ha costado tiempo y esfuerzo. Es mejor que la vea el cliente y dé su opinión. Él decidirá si está bien o está mal. Invertir tiempo en correcciones o mejoras no solicitadas sólo nos va a retrasar la entrega (con esto no quiero decir que no se revise lo que se ha hecho o que no se compruebe si tiene la calidad suficiente antes de mostrarlo al cliente)

Contagiar las prisas

Como jefe de proyecto suelo trabajar en varios a la vez, lo que suele implicar a varios clientes, cada uno con sus necesidades, múltiples fechas de entrega, tensión y mucho estrés. Intento no contagiar este estrés a los miembros del equipo de trabajo y aportar la tranquilidad que pueda. Por supuesto, todos los miembros del equipo deben conocer las fechas de entrega y el trabajo comprometido en cada una de ellas. Añadir prisas al trabajo diario sólo suele traer problemas en la calidad del producto final o cosas que quedan a medio resolver.

¿Puedes hacerlo más fácil?

Uno de los principales errores que se comete en un proyecto es el de comenzar cuanto antes cada tarea sin pararse a planificar los pasos a dar en esa tarea, si realmente es necesaria y, sobre todo, si puede simplificarse de algún modo. Me refiero no solo a implementarla del modo más fácil posible sino a simplificar la tarea en sí. Para ese complejo sistema de interconexión entre múltiples ordenadores ¿no existe ya algún estándar predefinido? Para ese analizador sintáctico ¿es necesario que sepa resolver ecuaciones de tercer grado? No hay tiempo mejor invertido que el utilizado para reducir la complejidad del trabajo a hacer.

Estos son los errores de los que me he dado cuenta hasta ahora. A algunos ya les he aplicado alguna solución, en otros todavía tengo que encontrarla. Seguro que me quedan aún errores nuevos por cometer. En los siguientes enlaces pueden encontrar algunas de las lecciones aprendidas de estos errores: