— Ed Freeman, Filósofo y Profesor de Administración de Empresas Darden School (Universidad Virginia, EE.UU.)
(Source: dronte.es)
— Ed Freeman, Filósofo y Profesor de Administración de Empresas Darden School (Universidad Virginia, EE.UU.)
(Source: dronte.es)
Una nueva herramienta para la Gestión de Proyectos: Trello
Leyendo ayer (gracias Javi por el enlace) sobre las nuevas características que Stack Overflow ha añadido a Careers 2.0, su portal de empleo para perfiles tecnológicos de alto nivel, he descubierto una herramienta para la Gestión de Proyectos que me tiene enamorado: Trello.
Más concretamente, Trello es una herramienta de colaboración on-line (además gratuita) para la organización de cualquier tipo de proyecto que te puedas traer entre manos. Como dicen en su página, el uso está abierto a cualquier cosa: desde la organización de una boda a listas personales de cosas pendiente de hacer (To-do), pasando por la gestión de un proceso de selección. Este último caso es el que sirvió de inspiración a la gente de Stack Overflow para adoptar el concepto de Trello a la funcionalidad de seguimiento integrado de un proceso de selección.
![]()
Fuente: StackExchange Blog
Hace más o menos un año, estuve inmerso en un proyecto de consultoría tecnológica para uno de los principales bancos de España, donde estábamos revisando las aplicaciones de reclutamiento y selección de cada una de sus filiales para intentar dar forma a una aplicación global para dicha entidad financiera.
Una de sus principales demandas era una redefinición total de la interfaz gráfica para hacerla más usable e intuitiva a sus usuarios. De haber conocido a Trello en esas fechas, sin duda las líneas maestras de la nueva interfaz para la gestión de un proceso de selección deberían haber tenido muchas similitudes con ella. Con lo cual, me parece muy acertada la adopción de este concepto para Careers 2.0.
Pero volvamos a Trello como herramienta para la Gestión de Proyectos, aunque realmente se puede adaptar a cualquier proceso de negocio o actividad, siempre que tengas bien definido cual es el work-flow que quieres controlar.
La herramienta desarrollada por Fog Creek se basa, inspirada en la metodología Kanban, en una serie de “tablones” (cierto paralelismo podemos sacar aquí con la penúltima red social de moda, Pinterest) al que se van añadiendo “listas”, que serían las diferentes fases del proyecto. Dentro de cada una de esas “listas” se incluyen “tarjetas”, que serían el equivalente a las tareas de un proyecto. Evidentemente, cada “tarjeta” contiene la información sobre la tarea a realizar, y permite adjuntar documentos, vídeos, check-list, asignarle una fecha de entrega o la persona o personas responsables. Y siempre, en todo momento, puedes ver el estado de la actividad en el proyecto.
Todo esto se hace de manera muy sencilla, arrastrando (drag & drop) los elementos con el ratón en el “tablón” del proyecto podemos realizar las tareas más básicas: cambiar el orden de las “listas”, pasar una “tarjeta” a la siguiente fase, asignar un nuevo responsable a una “tarjeta”, etc. Realmente intuitivo, lo mejor es que veáis el vídeo para tener una idea más completa de las posibilidades que ofrece como herramienta de Gestión de Proyectos.
Además, nada de preocuparse de la compatibilidad con dispositivos. Trello funciona a la perfección en un smartphone, con lo que el manager de un proyecto puede gestionar con plena libertad de movimientos las tareas del proyecto en tiempo real.
Y por supuesto, todo ello en un entorno seguro. Con el tráfico bajo SSL y con una política de back-up muy estricta, cada hora hay una copia, con lo que las posibilidades de pérdidas sensibles de información y trabajo se reducen a algo perfectamente aceptable por el usuario.
Al ser una herramienta gratuita creo que le voy a dar una oportunidad, no me faltan ideas o proyectos a los que aplicarla. No prometo nada, pero probablemente haya un 2º post sobre Trello sometida a las particularidades de la vida real. Si alguien ya lo ha usado o conoce gente que lo utilice se agradece que deje un comentario contando sus experiencias.
PD: No, aunque lo parezca, este no es un post patrocinado, con 300 visitas al mes únicamente mis admirados (y espero que fieles) lectores son capaces de dedicarme un poco de su bien más preciado: el tiempo.
Vía: emergentfutures:
Has Human Resources Become Out of Date?
“Now fast-forward to today. Today’s high-performing organizations (Facebook,IBM, Apple, Amazon.com, UPS, JPM Chase) now move so fast that their product cycles move in months, not years. Their workforce is highly interconnected and shares information instantaneously. People are hired and rewarded for their deep expertise, not their ability to follow instructions. And they work on fast-changing projects and programs which evolve and change continuously.
Even more profoundly, today the managers are no longer really in charge. Customers are.”
Full Story: Forbes
— Patrick Rhone, Escritor y ensayista.
(Source: enoughbook.com)
— Jose Alcántara y Biaka Hajdu, Socios fundadores Cartograf.
(Source: cartograf.net)
—
Peter Bregman, fundador de Bregman Partners.
Vía: David Monreal
(Source: blogs.hbr.org)
Lo bueno (al menos lo vamos a intentar) se hace esperar, el mini-proyecto de la trilogía macedonia abre su andadura con el post de enfoque más técnico y por eso voy a intentar hacer divulgación y explicar de forma sencilla el concepto de “deuda técnica”.

Supe del término por primera vez este año en una reunión informal entre gente de Sistemas y Desarrollo y pese a su importancia creo que no se le presta la atención suficiente por parte de algunos gestores de proyectos y menos aún por los responsables comerciales, lo que ocasiona no pocos problemas, ya no solo a la hora de llevar a buen puerto un proyecto, sino de su mantenimiento a lo largo del ciclo de vida del producto.
La persona que acuño el término fue Ward Cunningham, y lo hizo para describir aquel código que se escribe de forma rápida, basado en obtener posibles beneficios a corto plazo, sin tener en cuenta los costes adicionales (intereses) que va a suponer en forma de mantenimiento extra por su baja calidad a lo largo del tiempo.
Muchos tratan de hacer símiles con la idea de la deuda financiera, y aunque creo que conviene mantener ambos conceptos por separado, es una buena aproximación para que le gente como yo, de formación no técnica, lo pueda entender.
Leyendo sobre el tema, me ha parecido muy interesante descubrir la raíz del concepto, ya que no es algo nuevo, sino un problema con más de 40 años de historia y que se le conoce como “crisis del software”. Algo que la OTAN (sí, la Organización del Tratado del Atlántico Norte, aquella de: “OTAN, de entrada no”) identificó en 1968 y que atañe a una serie de problemas que son comunes a la mayoría de los proyectos de software:
Es ese último punto de la “crisis del software” el que entra en relación directa con el concepto que estamos analizando. Y es que puede haber un punto, en el que el coste del pago de los intereses de la “deuda técnica” acabe con la rentabilidad del proyecto e inicie su inexorable camino a la bancarrota. Una bancarrota que supondría el esfuerzo de tener que empezar a reescribir el código del proyecto desde cero, con las nefastas consecuencias que ocasionaría a todos los implicados en el proyecto.
Entonces, ¿es siempre la “deuda técnica” un riesgo a evitar en nuestros proyectos? Pues depende, al igual que puede ser imprescindible para una empresa textil ampliar la línea de crédito financiero para abordar el lanzamiento de una nueva línea de ropa masculina, es probable que en alguna ocasión nos veamos en la tesitura detener que decidir si debemos asumir el coste que supone la “deuda técnica” en alguno de nuestros proyectos de software.
Pero no vamos a entrar más en detalle por ahora, ya que dentro de poco lo haremos en el capítulo II de la trilogía macedonia, donde veremos, desde la óptica de la gestión de proyectos, los efectos de la “deuda técnica” en los mismos y cómo gestionar los riesgos que puede implicar.
Hace unos días me envió un amigo (gracias Javi) uno de esos artículos que nada más leerlo sabes que te va a ser útil en algún momento. Me parecía demasiado bueno para hacer un rápido comentario y poco más, llevo tiempo intentando encontrar una forma digna de darle salida en mi blog y creo que lo tengo más o menos enfocado…voy a hacer una trilogía.
En los próximos días, si las musas no me son esquivas y más pronto que tarde, trataré de dar mi visión sobre la gestión de proyectos, el proceso de venta de productos de software y el concepto de deuda técnica, aunque no sean probablemente en ese orden.
¡Muy importante!, Altamente recomendable para seguir la trilogía es leer el artículo que da pie a la misma: “Cómo las funcionalidades no negociables matan a los productos de software”.
El futuro no es cosa de las tendencias, es cosa nuestra, de cada uno y de cada organización, de...
As a country’s GDP per capita increases, how do internet penetration rates...
Joi Ito of MIT Media Lab:
Ito: There are nine or so principles to work in a world like this:
1. Resilience instead of...
#yorkville #manhattan #nyc about 2 miles away from my home #nytvoyage #repost from @nycbaton (at Yorkville)
Each company on this list has done something over the past year that will strengthen its hold on a...

Infografía de Mary Ellen Tibby que retrata los factores predominantes de las personas exitosas y de aquellas que no lo...