.
Es una experiencia interesante cuando tu jefe te llama para proponerte un paracaídas: debes caer en el lío de un proyecto, comprender qué es lo que causa los retardos y enseguida tienes que ponerlo en sus rieles.
Siempre he dicho que corregir los proyectos no es cuestión de talento, ni de autoritarismo, sino de un profundo conocimiento de las limitaciones (sobre todo de las propias), y de una comprehensión real tanto de lo que está en juego como de la complejidad del problema.
Hemos abordado en muchas entradas del blog la dimensión de comunicación y la de planificación del tiempo. Sin embargo, cómo facilitar la transición entre jefes de proyecto? cómo facilitar la inclusión de nuevos participantes en el proyecto? cómo facilitar la reutilización de los nuevos conocimientos adquiridos durante el proyecto para proyectos similares?
Los proyectos son centros de interacción y de interpretación de esas interacciones. El conocimiento viene de tales interpretaciones, no del conocimiento de los hechos en sí mismos. Las metodologías para ejecución de proyectos se han concentrado en el control de la ejecución de los proyecto, y en la creación de indicadores para la gestión del rendimiento y de la calidad que ahora son estándar, tales como Earned Value (AV), Six-Sigma, entre otros. Infortunadamente, tales indicadores brindan una visión parcial de la porción “dura” (hard) del proyecto, y aunque todo sea claro, esto no te ayuda mucho cuando debes tomar las riendas en medio de una catástrofe.
Debemos asumir la transferencia de conocimiento como un reto, si queremos plantear soluciones reales. En este sentido, podemos considerar el conocimiento del proyecto como un elemento líquido. Debemos aislar el otro elemento crítico de la transmisión: vamos a sunponer que podremos encontrar inmediatamente todo el personal talentoso y preparado requerido.
La transmisión óptima de conocimiento es un problema tan importante, que si logramos resolverlo, muchas empresas tendrían una eficiencia casi infinita 
y los escenarios –dantescos en muchos casos– se convertirían en casos simples a manejar.
Vamos a suponer que trabajamos en una sociedad de consultoría. Esta sociedad enfrenta contínuamente este reto: como los consultores deben estar asignados en forma contínua a diferentes misiones, al tiempo que las demandas de los proyectos varían en el tiempo con los presupuestos y la disponibilidad de los actores del proyecto. Existe una alta probabilidad que los consultores asignados al proyecto cambian en el tiempo.
NOTA: Este es un escenario análogo a aquel de las empresas cuya tasa de rotación es elevada, ó en las startups que son normalmente super-dinámicas.
Qué es aquello que se requiere
Un proyecto en ejecución es un ser vivo. Una vez finalizado, el proyecto puede convertirse en un modelo para otros (ó en un contra-ejemplo 
).
Esto implica que las necesidades no son las mismas en las dos fases, y que los procesos de soporte no son tampoco equivalentes.
- Durante la vida del proyecto, se debe poseer la información suficiente para hacer el seguimiento del proyecto, de los cambios y de la ejecución de su presupuesto. Dada la alta tasa de rotación durante la vida del proyecto, es esencial poder hacer una puesta a punto rápida de los nuevos miembros.
- Al final del proyecto, se debe recuperar aquello que puede reutilizarse como ejemplo, pero también como contra-ejemplo.
La contínua navegación entre proyectos, tanto de negocios privados como
estatales, realizados en empresas diminutas y grandes, de aquellos que
involucran a pocas personas como de aquellos que tendrán un impacto
global, me indican que no es posible soñar con una solución única. Por eso propondré un modelo general, y no una receta de cocina.
A continuación listaré las dimensiones principales de aquello que constituye el conocimiento. En el futuro abordaremos tales dimensiones en detalle.
El proyecto en ejecución
- Información contextual: necesidad estratégica y operacional del proyecto, productos esperados, actores principales, personas de contacto (tanto de la sociedad cliente como de las prestadoras de servicios), una matriz RACI para establecer las necesidades de comunicación en cada fase y para cada tipo de reporte.
- Portal de Colaboración: contenedor de la comunicación, un lugar para compartir los ficheros/documentos, un lugar para los reportes de seguimiento (preferencialmente gráficos).
- Control de cambios: un sistema para el seguimiento
de cambios adaptado, rendidor y coherente. - Control de la configuración: En los proyectos IT, es necesario gestionar la configuración, porque esta es una información crítica para la mantenibilidad de la infrastructura tecnologica propiamente dicha.
El proyecto finalizado
Además de algunas informaciones extraídas de la fase de ejecución, deberían incluírse:
- Información contextual: Razones de finalizar el proyecto, nuevos proyectos relacionados
- Archivado: métricas del proyecto (general, de los participantes bajo su responsabilidad, gestión de calidad de productos entregados), generalización de soluciones (modelo para el tipo de proyecto, heurísticas para cálculo de esfuerzo/costo), portafolio de proveedores.
- Conocimiento generado: Captura de lecciones aprendidas, comparación estadística, puntos a mejorar
Hemos introducido en esta entrada del blog la necesidad de transmitir el conocimiento. Hemos visto que esto permite disminuír el riesgo relativo a la trazabilidad del proyecto. Trataremos los puntos en detalle desde la semana próxima.
.
Vender la Gestión de Procesos de Negocio (BPM) no es nada fácil. Es mucho más fácil vender una Arquitectura Orientada a los Servicios (SOA).
Es también posible vender a la dirigencia un enfoque basado en la Arquitectura de Empresa. Pero no con BPM.
Esos son hechos. Lo interesante es entender las razones de un escenario tan lejano de la lógica.
En las conversaciones que tenemos con los comerciales de mi empresa y los otros consultores senior, hemos podido ventilar ciertos elementos que complementan mi trabajo (tanto científico como pragmático) en el área durante los últimos 5 años y 10 meses.
La SOA es un aproximación técnica. Por lo tanto, los técnicos estarán dispuestos a acogerla. No es necesario entenderla claramente; los argumentos esgrimidos por los vendedores más importantes en los últimos años, sumado a la supremacía del discurso de la conectividad universal como objetivo último de toda arquitectura ágil y bien realizada, no dejan espacio para dudas.
Desafortunadamente, nadie hace las preguntas que nadie ha hecho. Y todos tan contentos, y nadie hace el ridículo.
.
Para qué la conectividad universal? para poder reutilizar de manera también universal (tanto para componentes locales como distantes, en forma transparente e independiente del protocolo) los componentes. De hecho, no los componentes como tales, sino las funcionalidades expuestas por el componente.
De manera tácita, la serpiente se muerde la cola: el argumento principal de los vendedores es la posibilidad de crear aplicaciones compuestas.
Veamos el gráfico de nuestra graciosamente engurgitada BEA:
BEA - Aplicaciones Compuestas
Las aplicaciones compuestas se realizan sobre la base de una plataforma evolutiva realizada con componentes desacoplados y deslocalizados. Esto quiere decir que las funcionalidades se basan en simples contratos funcionales, y los proveedores que satisfacen tales contratos se encuentran en cualquier lugar del espacio (locales, distantes, y hasta super-distantes).
Entonces, se necesitan componentes que se puedan conectar de forma universal. Esto garantiza su reutilización.
Premisas:
La tecnología T permite de obtener A y B. Lo que usted desea es sobre todo A. B permite de obtener A.
Análisis de Causalidad:
Usted necesita C (axioma), B garantiza C, B permite crear A, entonces A poseerá también la cualidad C. QED.
Esta pequeña demostración de la serpiente hambrienta nos deja pendiente solamente el aspecto que hemos denominado C. Lo acabo de emplear en los párrafos anteriores, pero es un vocablo tan repetido y tan buscado en la ingeniería de software, que olvidamos que está allí: la reutilización.
Procedo entonces a formular la pregunta que incomoda desde hace más de 4 años a todos mis colegas y competidores que laboran en los dominios de la arquitectura, concepción y programación: cuál es la tasa de reutilización obtenida? (seguido de: y cuál es la tasa de evolución en los últimos 5 años?).
Este punto ya lo he mencionado en el pasado, y la respuesta sigue siendo invariablemente una de estas dos: “indeterminada” (con cara de verguenza por la falta de franqueza), ó “menos de 1%“.
¿¿¿¿¿Para qué insistir e invertir tanto con una aproximación arquitectónica si el argumento de base no ha sido demostrado??????
(Esto es similar a la actual crisis bancaria: la aproximación se volvió una finalidad en sí misma, una meta-paradoja)
Si con humildad volvemos a los años 1993-1995, cuando se sentaron las bases metodológicas de la práctica de las tecnologías orientadas a objeto, veremos que el aspecto más crítico de la reutilización es la creación de un referencial. Un referencial es un inventario controlado (managed) que permite establecer un control de calidad sobre la evolución de la arquitectura de un sistema o aplicación.
Con humildad debemos también reconocer que la creación de un referencial nunca fué fácil. ¿Por qué debería serlo en una SOA? ¿qué ha cambiado? acaso tenemos nuevas técnicas o metodologías? tal vez, pero no son populares ó por lo menos no son prácticas.
Es decir, la reutilización es una solución y un problema en sí misma. Estamos tan enseguecidos en su búsqueda, que pocos se preocupan de los aspectos difíciles y los retos que esto significa. El (entonces) famoso “ingeniero de reutilización” que vendían tantas propuestas metodológicas a principios de los años 90 no es práctico y ha desaparecido en la bruma (desde 1995, para ser precisos). Los arquitectos han tomado una parte de ese rol, pero la reutilización se volvió un término inconveniente y ha sido escondida adecuadamente.
Yo recuerdo el “ingeniero de reutilización” porque me parecía magnífico evitar el despilfarre, pero me resultaba difícil materializarlo, y nunca lo ví en ningún proyecto. Quedó retenido en mi memoria porque le tomé cariño, como a cualquier otra curiosidad ó idea en apariencia genial pero realmente bastante lunanca: más exótica que útil.
Si entendemos esto, luego es fácil entender por que los servicios web crecen en forma horizontal en las organizaciones, pero el crecimento vertical (la evolución en la forma de servicios con versiones explícitas) no es fácil de lograr (¿Cuando fué la última vez que chequeó un proyecto con servicios web versionados?). Como causa y como consecuencia de esta aproximación, la forma de describir los componentes y sus funcionalidades mantiene el formato empleado hace 15 años (el de la API). Muchos autores hablan de la urbanización… eso esta muy bien, pero como no poseemos notaciones para explicar las funcionalidades de un componente, mucho menos para expresar aquella de decenas/cientos/miles de funcionalidades expuestas pour un número creciente de componentes. Los bloques funcionales a nivel macro, los paquetes UML a nivel medio y las interfaces UML a nivel micro son la práctica corriente.
En realidad, estamos limitados porque no hemos querido/podido evolucionar en este sentido. Por eso las aproximaciones de tipo Scrum/XP son tan eficaces: no perdamos el tiempo generando una documentación que no podemos generar.
La Arquitectura de Empresa es un enfoque de negocio: según la teoría, se deben entender los procesos de la empresa, con el objeto de entender cómo se crea valor en interno, pero también cómo se debe/puede interactuar con los actores del entorno de la empresa (proveedores, compradores, competencia, reguladores). En el mundo real, un esfuerzo de documentación de los procesos se justifica si se desea calcular el riesgo operacional dentro de una aproximación de compliance; en algunas ocasiones también para construír procesos ejecutables mediante aplicaciones compuestas.
No me extenderé más en esta parte de mi discusión. Lo cierto es que a muchos managers le encantan los dibujos hechos con herramientas tales que ARIS, Mega, System Architect. En realidad, dada la complejidad de tales modelos, la consecuencia es una no-adopción (cariño) por parte de las personas encargadas de mantener los modelos. In veritas, la mayoría termina re-adoptando Visio y lo emplean en forma tan ad hoc como la propia organización. Una vez finalizados, se imprimen y se guardan en una gaveta, hasta la próxima auditoría de compliance.
Muchos dirigentes creen que con haber contratado la creación de tales modelos, ellos ya pueden lavarse las manos. Concuerdo con ellos que esto es la due diligence, pero esto no equivale a una appropriate diligence. Como siempre, prefiero ser provocador.
¿Qué falta en el mundo de la arquitectura orientada a servicios para poder garantizar la reutilización? habilitar la governancia de tales funcionalidades.
¿Qué falta en la arquitectura de empresa para que los modelos no sean solamente elementos pasivos y olvidados? establecer una governancia de los modelos.
Qué es la governancia? Eso lo puede responder wikipedia. Para nosotros los profanos, una definición orientada a procesos podría ser:
- el conjunto de procesos y procedimientos que permite de establecer ciclos de vida claros para los elementos governados,
- complementado por la ejecución de tales procesos y procedimientos.
- implica a los actores que participan en el ciclo de vida de los elementos, y a los clientes de los servicios generados
Una governancia para nuestras dos queridas arquitecturas (orientada a servicios y de empresa) genera una dinámica, hace que los elementos normalmente destinados a “guardar polvo” se conviertan en factores de la estrategia empresarial, tanto en el IT como a nivel del negocio.
El BPM involucra los aspectos de governancia, racionaliza/determina el expectro de la SOA y hace el puente entre la Arquitectura de Empresa a nivel de negocio y a nivel de servicios provistos por la Infraestructura Tecnológica. Es por esto que no es lógico que miremos los extremos opuestos y olvidemos el lazo que los une, y que puede evitar tantos dolores de cabeza.
Lo gracioso es que se genera el famos efecto de miopía de mercado. Cuando finalmente tenemos el conocimiento y la tecnología para realizar una gestión de los procesos de negocio (BPM), ya nadie busca la solución. En consecuencia, nadie cree en la proposición y es difícil venderla.
El nuevo reto de los próximos 10 años nos está esperando hace rato. Estamos atrasados, señoras y señores.
En las últimas semanas he venido participando en varios proyectos en los cuales mis clientes son los IT Managers, y en sus discusiones he identificado un patrón muy interesante.
Casi simultáneamente, tuve una fuerte discusión con mi jefe, porque yo soy un iluso que creo que hay proyectos IT que se pueden acabar a tiempo… Oops!
No me gusta discutir, ni me gusta rogar: me encanta demostrar mediante la acción.
En estas últimas 6 semanas he podido dirigir y ejecutar (nunca he podido alejarme de mi costado técnico) proyectos para una capital en Suiza, otros 2 para Nesxxx, y arranco otro para un banco privado dentro
de poco, además de trabajar con los comerciales de la empresa para crear una nueva oferta para el mercado. En este blog hemos ilustrado cómo gestionar el tiempo (para entender como lo logramos), así que me dedicaré solamente a la dimensión de realización de proyectos:
- En el primer caso, es una iniciativa para todos los empleados de Lausana, con una plataforma para la gestión de tiempos: pude lograr terminar la primera fase en 31 días, con 30 días de avance sobre la fecha prevista. Además, hemos construído todas los aceleradores que nos permitirán de avanzar en forma ágil en el futuro, y el plan de comunicación ha creado una excelente acogida.
- En el segundo caso, un viejo proyecto de la más grande multinacional suiza, y que tiene un retardo crónico de 24 meses, será terminado en menos de 10 semanas. Esto ha permitido revivir la segunda fase del proyecto, los módulos de BI, a la cual ya se había renunciado debido a la imposibilidad de terminar los primeros 4 bloques arquitectónicos.
- Estamos construyendo una propuesta para la Arquitectura de Empresa (EA) y, particularmente, en la Gestión de Procesos de Negocio (BPM).
El caso de la discusión con mi jefe, muestra que es difícil cambiar las costumbres, así que ya no lucho contra ellas. Cuando estas en Europa Central, es difícil mostrar tus capacidades de líder: en tu tierra se habla español –idioma considerado como “del sur“–, se supone que la metodología no es tu fuerte, y que eres del tipo seguidor más que lider.
Yo no lo veo así: durante mis años jóvenes y viejos, he tenido grandes ejemplos de lo bueno y sobre todo de lo malo, y he construido mi base de conocimientos. No soy brillante, sino solamente consciente de la efemeridad de los momentos de intercambio: es ya todo un logro poder cruzar algunas personas excepcionales. Debemos aprovecharlos mientras duran.
Así que viendo la sorpresa creada con mi intervención, decidí compartir algunas perlas con mis colegas y con mi jefe, que ahora presento aquí:
Hipótesis de arranque: El peso específico proviene no de dónde vienes ni de lo que creen de tí, sino de lo serio de tu propuesta para gerenciar el proyecto. No dejes instalar un ambiente sumamente tecnocrático, incluso si tu proyecto es exclusivamente técnico. Los proyectos son dirigidos y ejecutados por individuos. Ellos son el corazón y la sustancia misma, la razón de ser de los proyectos, los artistas que realizarán la obra.
Primero, muestre interés y respeto por su cliente. Nunca se debe hacer un proyecto con alguien con quien no se tiene un contacto orgánico, excepto si la distancia lo justifica. Dele la mano, obsérvelo, establezca sus valores y su experiencia, examine lo que él espera del proyecto. Sea auténtico: tiene que gustarle aproximarse a las personas.
Segundo, deje sus vicios en casa. Yo era super-tímido, y no era capaz de hablar a mi madre, literalmente. Los años, la experiencia y sobre todo la necesidad me han mostrado que no es algo para reflexionar: su timidez puede interpretarse como antipatía, y si la cosa comienza así, puede hacer una cruz sobre su proyecto.
Tercero, establezca solidos canales de comunicación: las tarjetas corporativas y los primeros correos electrónicos son la clave. Nuevamente, hágalo en forma espontánea. Yo casi nunca lo hago en la primera reunión, sobre todo porque una persona importante faltará a esa reunión. Haga un comentario adecuado, y proceda a pasar su tarjeta, sin esperar las de los demás. Un clima de colaboración se puede establecer solamente si no parece tieso (stiff) y que sigue un guión.
Cuarto: hable de la importancia de la comunicación. Desde el principio muestre que conoce su dossier. Normalmente me invitan a última hora, pero ya he establecido una táctica para este tipo de casos: siéntese y observe. Luego responda.
Cuando conozca muy bien el caso del cliente, entonces es más fácil pero toca asumir otra táctica: siéntese y observe. Luego responda.
Alinearse con el cliente solamente es posible cuando usted ha entendido lo que él busca. Escuche lo que dice. No lo suponga. Busque que exprese lo que no dice voluntariamente.
La gente solamente va a comunicar si usted le da el espacio. No falta el jefe de proyecto que parece profeta… y se quedará en el desierto. Deje hablar a los comerciales, que para eso les pagan. No tema corregirlos (a los comerciales), y no tema detenerlos para que no invadan el espacio del cliente.
Quinto, el principio esencial: recuerde que en cada momento en que Ud. se presenta delante de un interlocutor, usted vende confianza. Sea consciente que en la comunicación hay varios actores, y que los demás esperan algo de Usted. No les haga perder el tiempo, porque perderá su confianza y hasta su paciencia. No diga muy poco porque lo verán como alguien vacío y falto de resultados concretos.
Sé que soy un jefe de proyecto muy estricto, pero no soy pedante. Dónde esta la diferencia? Creo que mi éxito viene de confiar en los colaboradores, en respetar su arte, y en pensar que son adultos e inteligentes. Entonces –y sobre todo para ver la reacción de los nuevos miembros– solicito explícitamente lo siguiente: No espero que lo intenten [resolver el problema] , espero positivamente que lo hagan [proponer soluciones y resolver el problema].
No es un juego: esto es un negocio, y usted es la/el responsable.
Sexto: láncese al agua antes que sus colaboradores, y nade en el problema con el cliente. Muestre el ejemplo, y sus ingenieros lo acompañarán, al menos los buenos. Entienda su cliente: no lo juzgue! esto es un formidable error de apreciación.
Sea siempre competente en los dominios en los cuales realiza proyectos, conozca sus asociados de negocios (las empresas que proveen la tecnología y los productos que Uds. llevan a sus clientes), no dependa en canales intermedios (porque los problemas siempre recaerán en Ud. durante la fase más crítica del proyecto). En ningún caso tenga miedo de doblarse las mangas de la camisa!
Séptimo: construya una plataforma de comunicación. Ella debe ser heterogénea, y jerárquica, agradable y práctica. No installe simplemente un bugzilla (porque muestra que espera muchos problemas), ni inunde de correos (otra fuente de e-mails == Ud. será percibido como un problema más, no como una solución).
Facilite el intercambio. No pierda tiempo y no lo haga perder a los demás. Presente su propuesta a su cliente rápidamente, y construya un prototipo a alta velocidad. No olvide adaptarlo a la imagen del cliente, a su proyecto.
Octavo, entienda que las expectativas de un proyecto IT casi nunca son técnicas. Aunque no lo crea, eso casi nunca sucede. El IT obtenido es una oportunidad, una solución. Es esa la razón del foso entre los actores del negocio y los actores IT en la misma empresa. En otras palabras: lo único que cuenta es cómo se soportan los servicios del negocio de su cliente con los productos obtenidos del proyecto que Ud. dirige. Durante mis años de experiencia con grandes grupos y pequeñas empresas, siempre he visto este fenómeno, lo que me llevó a hacer un doctorado en este dominio.
Creo que estas perlas contienen muchos elementos para hacer la diferencia entre el éxito y el fracaso de un proyecto IT. No se extrañe si mientras usted ejecuta su proyecto, la gente termina por adoptar algo que funcione rápidamente y no lo espere. Tal eventualidad puede pasar a pesar de que Ud. entregue su solución de acuerdo con el plan
Si hay deseo, hay una forma de lograrlo.
Mantenga la lucidez
Proponga soluciones, no explique los problemas
Sentado en el tren, y al enfrentar la mirada despectiva de este muchacho, me puse a pensar en todos aquellos que había conocido. Siempre había tenido un gran respeto por la India, pero esto ha cambiado fundamentalmente al interactuar con aquellos hindúes que han cruzado mi camino.
Las opiniones expresadas aquí no se pueden generalizar a toda la población de India. Sin embargo, escribo la entrada en la forma genérica en que se aplica el mito a todos los hindúes que trabajan en la informática.
Los conocí venidos de Madras, de Bangalore (donde estan dos de sus Institutos de Tecnología), etc. En aquellos años en que hice mi primer postgrado y mi master eran traídos a la Universidad por decenas, muchachas y muchachos para hacer pasantías que apoyarían nuestros trabajos de investigación. Conocí otros cuando volví para mi segundo postgrado, la mayoría aún como stagiaires y pocos como estudiantes de postgrado. Algunos años después, cuando hice mi doctorado, ya eran muchos menos.
Antes de eso, pensaba que eran grandes pensadores por su cultura milenaria, y que su fama debía estar sostenida por algo. Son la segunda diáspora científica del mundo según la IEEE, después de los colombianos, así que mis expectativas eran grandes. Además, tienen una industria informática que crece a una velocidad enorme.
Afortunadamente conocí también griegos, cameruneses, tunesinos, irlandeses, bielorusos, libaneses, marroquíes, checos, armenianos, ingleses, neo-zelandeses, gringos, rumanos, japoneses, franceses, ucranianos, chinos, afganos, israelitas, húngaros, senegaleses, italianos, sudafricanos, australianos, canadienses, argelinos, y gentes de muchos otros países. Trabajé con ellos en muchos proyectos, asociaciones, iniciativas. Conocer la verdadera riqueza de tanta gente me permitió soportar la caída del mito hindú.
Afortunadamente, siempre pude mantenerme dentro de mi núcleo de
hispanoamericanos y de brasileños. Eso me permitió no solamente soportar sino saber que hay esperanza. No hay mito del mismo tipo en América Latina, pero sí hay un potencial enorme. A veces existe una realidad concreta y sólida.
Definitivamente, nada que ver! los hindúes trabajan duro, sin muchas preguntas, y no son muy creativos. Cuando estan ahí, SABES que estan ahí…
Algunos son brillantes, pero apenas en la media estadística. Realmente siempre había creído que un país con 1000 millones de personas poseería un sistema tan competitivo que la gente de “la crema” es hiper-talentuosa, ó me los imaginaba como creadores y hormiguitas de trabajo como las que conocí en mi tierra latina. No es así. Sorprendente y decepcionante.
No puedo decir que haya conocido un solo genio. Excepto por los que se auto-proclaman genios: muchos hindúes, cuando pueden obtener un trabajo fuera de India, poco a poco adoptan una infortunada actitud bastante “inflada”, que no corresponde a lo que aportan. Así que ahora soy más prudente con su potencial. Y me molesta su mirada despectiva.
Creo que los informáticos hindúes se creen su mito; confunden realidad con fantasía. Y nosotros los lationamericanos no hacemos nada excepto lo mismo: no actuamos sino que nos maravillamos. Habría que preguntarse de qué.
Los hindúes hablan un inglés con un acento muy fuerte, pero como lo han aprendido como lengua de estudio y de trabajo, supongo que lo escriben bien. Hablar con ellos requiere concentración. Tienen una fuerte tendencia a no aprender la lengua local, ni alemán, ni francés, ni danés… simplemente los demás en su entorno deben adoptar el inglés. Punto.
No son muy buenos para la escucha, al menos como colegas. Eso sí, son muy verticales, lo que es comprensible dada la estructura social en India. Como jefe de proyecto no he tenido muchos problemas con ellos. Eso sí, son tercos… pero eso tiene que ver con el hecho de que –desde el momento en que los contrata una empresa europea ó gringa– ls han dicho que son desarrolladores excepcionales… ojalá emitieran tanta energía en su trabajo!
En resúmen: Son especiales. Y se creen su mito.
Mi punto es: POR QUE AMERICA LATINA NO HA OCUPADO EL LUGAR DE PROTAGONISMO QUE SIGUE OCUPADO POR UNA INDIA QUE NO CORRESPONDE AL MITO?
Los hispanoamericanos tenemos todo el potencial. He podido trabajar con empresas en España, además de todas aquellas que conocí en América Latina, particularmente dentro de la dinámica chilena y brasileña.
- Poseemos una capacidad de reacción e improvisación asombrosas.
- Poseemos el talento y el conocimiento técnico
- Poseemos la cantidad necesaria de gente formada para conformar una industria de grandes dimensiones
- Somos capaces de escuchar, y nos encanta servir.
- No trabajamos solamente por el salario.
Qué nos falta? aunque no soy un especialista, ni pretendo serlo, he podido caracterizar algunos elementos que han permitido a muchos tener éxito, y puedo citar los siguientes:
- El inglés oral
- Un inglés básico para escribir correo de negocios.
- Mostrarnos más cartesianos en el trabajo
- No prometer cuando sabemos que no vamos a lograrlo
- No dejarnos comprometer cuando sabemos que no vamos a lograrlo
- No aceptar las críticas relacionadas con nuestro origen, ó la situación actual de nuestros países
- Aceptar las críticas en cuanto al trabajo y saber negociar una solución
- No criticar al hermano latinoamericano, a pesar de su diferencia de opinión en la política
Aunque he visto amigos y colegas adaptarse bien a tantas situaciones en diferentes países, no poseemos el mismo nivel de respeto que los hindúes. La india es un país con muchos problemas y conflictos y guerras, pero nadie habla de ello. Sin embargo, a la mínima oportunidad, la gente estará criticando tu país latinoamericano, ó haciendo preguntas ociosas y mal informadas. Eso no nos permite ganarnos el respeto. Y depende de nosotros el acabar esta situación.
Considero que entiendo la razón de una buena parte del éxito de la informática hindú. Entre más conozco gente que ha vivido en India, entiendo el sistema económico, y ahora que el grupo Tata Group se ha vuelto tan prominente, y que hay tantos documentales de India acá en Europa, las cosas son más claras. No es fácil que un hindú te explique lo que pasa en su país; es difícil obtener una explicación clara y sin florituras.
Los hindúes son gente hiper-pragmática. Su cultura es complicada y su realidad también. Así que ellos se concentran en lo indispensable para vivir y para trabajar.
No son forzosamente antipáticos, sino que tienden a preocuparse exclusivamente por ellos mismos. No son grandes filósofos ni poseen el amor a la vida que tenemos nosotros.
No aprecian conocer nuevas gentes ni realidades, ni mucho menos lo esencial de otra cultura; al menos, no como nosotros lo hacemos.
SOBRE TODO: TRABAJAN BARATO. Las empresas hindúes pagan salarios bastante bajos. Además, su sistema económico no se hace mayores preguntas, mientras haya trabajo.
De otro lado, poco a poco la atractividad de la informática en India se deteriora, porque el nivel de vida ha subido en las pocas ciudades desarrolladas. Sin embargo, la situación de pobreza del 90% del país, y los conflictos en el norte, y las castas, y el esclavismo que aún existe, etc. permiten mantener un PIB bajo. En la medida en que los países de Europa oriental se integran a la UE y sus salarios suben, la India vuelve a ser competitiva por un momento.
Si la tendencia continúa, en unos 5 años sus salarios seran suficientemente altos para compararse con los nuestros en América Latina. Eso nos permitirá ser competitivos para atrapar nuestra parte del pastel.
Así que propongámonos tener éxito y mostrar lo que tenemos debajo de la camiseta. No podemos seguir siendo simplemente una tierra de promesa.
Las carabelas que se dirigían hacia las Indias se detuvieron en América. Demostremos que eso tenía una razón.
Sin sacrificio no hay victoria es el lema de la familia Witwicky en la película de transformes, bandera de la familia del protagonista cuyo abuelo había sido el primero en explorar el polo norte.
Esta frase despierta aquel soldado que cada uno de nosotros lleva dentro y que debe sacar a flote en cada situación en busca de la victoria. Es una frase con mucha fuerza que hace ensanchar el pecho y alistar la mente para acometer nuestra incesante lucha por nuestros objetivos.
Sin sacrificio no hay victoria nos recuerda que la mayoría de veces debemos dar mucho más de nosotros mismos para conseguir nuestros objetivos. Las grandes metas exigen que tengamos que invertir en ellas muchas horas de trabajo, leer e investigar hasta el cansancio, sacrificar ocio y diversión, sacrificar horas destinadas a la familia, hijos y mujer, etc.
La capacidad de sacrificio en pro de un objetivo puede marcar la diferencia entre lograrlo o no y esta capacidad no la tienen todas las personas. Se requiere mucha entrega y valor, mucha fuerza espiritual.
En contraprestación de este sacrificio podemos obtener la victoria. Victoria que puede estar representada en múltiples formas, la más importante de ellas, lograr nuestro objetivo o meta trazada.
Y aun cuando no logremos ese objetivo siempre seremos ganadores de habilidades, destreza y experiencia adquirida durante el tiempo invertido y cuanto más luchemos por nuestras metas, mayores probabilidades tendremos de obtenerlas.
Este lema puede servirnos de motor para no perder el interés por las cosas que queremos, para no tirar la toalla o desfallecer. Para ver en cada derrota un avance para la siguiente lucha y para comenzar a dar los primeros pasos en busca de aquello que siempre hemos deseado o aquellos planes que tenemos en el tintero y que no somos capaces de iniciar simplemente por falta de tenacidad.
Este lema sirve para ayudarnos a combatir las excusas de NO TENER TIEMPO, una respuesta muy común para no ir en búsqueda de nuestros anhelos. Para combatir la pereza o nuestra resignación a seguir como estamos. Para luchar contra el desaliento y las desavenencias de la vida o para darnos ánimos a nosotros mismos cuando las condiciones nos sean adversas.
Hemos venido discutiendo de la gestión del tiempo y de la medida del tiempo, pero ¿qué podemos hacer cuando no ha habido éxito en esta gestión en un proyecto?
Cuando me llaman para colaborar con la gestión de un proyecto, generalmente la razón es que hay un retardo sensible. Indagando un poco más, la mayor parte de los proyectos asociados ó cercanos tienen retrasos; es raro encontrar un proyecto solito atrasado en medio de un mar de proyectos bien manejados. Claro, los estudios internacionales muestran que 87% de los proyectos informáticos sobrepasan los presupuestos de tiempo y dinero, pero eso no ayuda, aunque puede consolar a algunos: su rendimiento es normal e incluso están en el promedio .
Lo que intento siempre es entender el equipo de proyecto y el contexto. Tengo un buen historial en retomar proyectos descarrilados, y esto requiere competencias particulares y estrategias diferentes a aquellas necesarias para lanzar nuevos proyectos. Otros hacen simplemente su trabajo, dada la presión que reciben, y atacan el problema urgente, pero no creo que funcione el seguir en la misma dirección: Si haces lo mismo, con la misma gente y en el mismo contexto, ciertamente obtendrás los mismos resultados.
Cada organización y cada jefe tiene una manera de abordar los proyectos, que se convierten con el tiempo en costumbres tácitamente aceptadas, y el proyecto retrasado puede ser la punta del Iceberg. Me aplico entonces a entender el histórico del proyecto y de los proyectos asociados: descarto los conflictos, problemas de configuración, la falta de presupuesto para comprar el PC de desarrollo, ó la “simple” falta de especificaciones claras. Casi todos estos hechos se pueden calificar de complejidad accidental, y siempre hay una justificación para todo.
Haciendo abstracción de los eventos, podemos ver las fases. Ahora podremos comparar lo prometido, lo exigido y lo realmente ejecutado en términos de tiempo, ya sea para varios proyectos ó para diferentes versiones de un mismo producto. En la gran mayoría de casos un patrón de repetición histórica emerge:
- la fase de prototipado cada vez dura el doble de lo presupuestado,
- conseguir entrar en producción siempre toma 5-6 meses más de lo previsto,
- nunca se considera que hay que configurar un ambiente para la etapa de tests de integración y de regresión (1-3 días por test, por ejemplo),
- etc.
Esta es la complejidad esencial.
Qué hacer? Primero: cambiar el modelo; en otras palabras, corregir la planificación inicial por aquella que es realmente la que se ejecuta (para uno ó para varios proyectos). Ahora tenemos un modelo real. Los modelos, como las herramientas, no son malos ó buenos sino mal ó bien utilizados.
Segundo paso: Ahora sí podemos ser sinceros; las exigencias por salir a producción no son realistas si partimos de un plan que no corresponde. Sé que esto es una fuente de temor, y que es mejor mentirse. NO! para detener este círculo vicioso debemos ser honestos con nosotros mismos.
Tercer paso: Manifiesta tu interés. Hay que presentar el plan en forma impersonal (en el corredor, alrededor de un café ó una cerveza, durante el almuerzo) a algunos de los que participan en el proyecto ó tienen influencia sobre él, preguntando en forma inocente qué les parece esta planificación corregida. Claro, no puedo hacerlo de la misma forma cuando trato un cliente Fortune 100, ó un banco privado que cuando trato con clientes en manufactura de precisión, ó con startups. Lo importante es no acusar a nadie, y presentarlo como una simple constatación que te sorprende/inquieta un poco. En un ambiente con unos 15 actores directos, escoge un grupo de unos 2-3 actores que luego se agranda en unas 3 iteraciones. No es un chisme ni un rumor de corredor, y hay que evitar las multitudes.
Cuarto paso: Escucha con atención. Aquellos que se quejan mucho, y hasta se ponen contentos de saber que alguien los entiende, son personas a retenir para las iteraciones posteriores. Ellos te van a dar elementos clave de por qué todo sucede, así como los nombres de las personas a contactar y a evitar (en su opinión).
Sin embargo, la mayor parte de la gente te va a dar un golpecito en el hombro, y te dirá “Bienvenido a XXX”, una sonrisa mientras huyen, y listo. Estas personas no te sirven en una primera etapa porque están resignados.
Los intercambios deben ser cortos, y las personas no se deben ver obligadas a responder. No pierda la naturalidad, e interésese al rol de la persona y a su punto de vista. La gente colabora mejor así. Mantenga el foco las preguntas para obtener lo que busca; no entre en discusiones ni en modo chisme. Hay informalidad pero con sinceridad y transparencia.
Es importante evitar las personas que proponen buscar una solución inmediata, sobre todo si tienen poder, ya que hay tendencia a caer en los mismo esquemas que causaron la crisis del proyecto. También evita aquellos que busquen convocar a una reunión ó un comité para ventilar el asunto. Uno de los principios de Murphy nos dice que si uno hace un número suficiente de reuniones sobre un asunto, se puede llegar al punto en que no se resuelve nada y todo continúa igual.
Quinto: redacta tus apuntes en limpo y reposa. Los múltiples intercambios informales son ricos. Debes escribir tus notas y comentarios tan rápido como sea posible durante/después de las entrevistas. Enseguida, es mejor dedicarse un tiempo a otra cosa, y apuntar todo aquello que recuerdas y que no apuntaste. Deja que el tiempo permita decantar los eventos para que solamente la esencia flote.
Sexto: analiza la información y crea conocimiento. Los múltiples intercambios informales son casi siempre asombrosamente contradictorios. Haz un inventario de los puntos críticos e intenta comprender las diferencias de percepción/sensibilidad, porque deberás validarlas en las siguientes iteraciones. No es obligatorio eliminar las contradicciones, ya que son naturales a los puntos de vista, y el tiempo es escaso.
Séptimo: Eureka! ya haz encontrado lo que buscabas. No puedo generalizar la solución porque los clientes, los tipos de industria y los proyectos son muy diferentes, pero en este punto la visión de los problemas de planificación debe ser clara, y solamente ha tomado un par de semanas. Si pasas por el conducto regular, lo mismo puede tomar meses y te tocará emplear los formatos de la empresa, etc. y perderás la libertad. Siguiendo esta estrategia has logrado romper los círculos de poder y hacer que las personas dejen de lado los intereses personales por un momento.
Generalmente la problemática viene del mismo hecho de no ser sincero: como la exigencia y/ó la planificación del proyecto no era realista, entonces hay una medida incorrecta del avance del proyecto. Esto hace que se implementen una serie de procedimientos y reuniones para corregir la situación, y rápidamente se instaura un clima de críticas y de presión para ir más rápido… solamente por el placer de hacerlo, porque el problema no esta allí. Ahora que tienes un modelo real y que conoces los puntos a corregir/optimisar/introducir, y la forma real en que se invierte el tiempo, ahora sí puedes remediar la situación. Un modelo/plan equivocado genera expectativas erradas que finalmente acaban por destruir la moral de las tropas.
Las personas al mando tienden a protegerse, y muchas veces se lavan las manos en la forma de la “due diligence“. Seamos claros: el control de calidad y la gestión de la calidad no son lo mismo.
Las organizaciones y las personas saben cómo resolver sus problemas, y tú debes conducirlos a encontrar estas soluciones. De hecho, manifestar un interés sincero es actuar como catalizador para que la gente se libere y hasta te proponga sus soluciones, sus frustraciones y lo que ellos realmente esperan de ese proyecto. Además, la gente adhiere mucho más fácilmente a las soluciones que ellos mismos propusieron, no? (excepto por los deshonestos).
Al final del día estarás de acuerdo con mi estimado Gerald Weinberg: All problems are people problems. La falta de comunicación es la razón principal de retardos y de conflictos que atrasan un proyecto.
Ahora que todo es claro, applica el círculo de Demming y para adelante! Plan-Do-Check-Act
Qué pasa si no podemos identificar las fases? entonces el proyecto nunca ha sido formalizado. Hay que comenzar de cero. Probablemente el cliente ó el ejecutivo que pidió el proyecto pensaba tener todo bajo control, y que no era necesario hacer nada más para iniciar. Las cosas no son así. La gestión de proyecto profesional es una gestión del riesgo y del análisis de opciones, y es irresponsable darle prioridad a las costumbres ó querer “hacer puntos” con el management lanzando algo que no tiene una base sólida.
Un paso muy importante antes de asumir una metodología de gestión de tiempo suele ser conocer en que invertimos el nuestro o en que lo gastamos. Esta práctica es muy poco utilizada y suele parecer completamente tediosa a muchas personas.
Para saber como invertimos nuestro tiempo es importante registrar de manera sistemática todo lo que hacemos durante el día. Esto suele ser llamado sistema de Time Tracking o registro de tiempo. En este post lo denominaré como registro de actividades (Yo prefiero llamarlo así porque este registro o seguimiento de tiempo no solo lo uso para tomar tiempos, sino historial de actividades y doy mucha importancia a las notas tomadas en cada tiempo.). Esto es, debemos de tener un log instantáneo de las actividades que estamos haciendo sean de trabajo o no.
Según algunos expertos en el tema esto debería hacerse por lo menos durante una semana continuada. Yo particularmente aconsejo hacer del registro de actividades una práctica habitual.
Ahora se preguntará que registro?, y yo digo, en lo posible TODO de manera cronometrada porque necesitas saber EN QUE DESPERDICIAS tu TIEMPO. Por ello debes registrar cuanto tiempo estás trabajando (y que haces), cuanto tiempo vas a comer, a fumarte un cigarrillo, al baño, cuanto tiempo duermes, juegas o compartes con tus hijos. (Este nivel de detalle es aconsejable solo por un tiempo, luego debes registrar el tiempo durante las horas laborales y periódicamente repetir el ejercicio).
Como hacerlo?. Pues la forma más básica es con un cronómetro y un papel haciendo anotaciones clasificadas de las actividades, por ejemplo, trabajo, ocio, comida, llamada, reunión, etc. y tomando una pequeña nota de lo que realizas y cuanto tiempo te lleva. Ahora bien, puedes usar un sistema de registro automático de tiempo si tu trabajo lo realizas en un ordenador, esto te permite semiautomatizar el inicio y fin de las tareas y la toma de notas y clasificación.
Que puedo ganar?. Al final del ejercicio (diario, semanal, mensual, etc) podrás sacar indicadores del tiempo que inviertes en las diferentes actividades que realizas y con ellas puedes determinar que actuaciones puedes tomar para optimizar el uso de tu tiempo. Por ejemplo, puedes deducir que el número de horas que dedicas al trabajo es excesiva y las de ocio mínimas y esto puede ser contraproducente y afectar el rendimiento, o lo contrario.
Para que más me puede servir?. El registro de actividades sirve para llevar una bitácora propia de cosas que haces y que en dos semanas ya ni te acuerdas (Sobretodo si usas un sistema semiautomático no intrusivo). Este registro le puedes usar para:
- Hacer informes de actividades.
- Ayudar a recordarte que ya has hecho algo.
- Para ayudar a controlar o gestionar tu todolist cuando no lo has actualizado a tiempo.
- Para determinar cuanto tiempo efectivo inviertes en una tarea en la que habías planificado un tiempo X.
- Para determinar el tiempo que inviertes en ti mismo y en tu formación personal.
- Para determinar el tiempo que has invertido en un proyecto de manera cuantitativa más exácta.
- Para validar el grado de exactitud con el que haces tus predicciones de cuanto tiempo puedes invertir en un trabajo y de esta manera mejorar esos estimativos.
- Para darte cuenta que muchas predicciones de tiempo hacen pasar por alto muchos detalles que debes tener en cuenta para analizar el tiempo que llevaría hacer algo.
- Para conocerte a ti mismo.
- etc, etc, etc.
Mi Experiencia Personal
Personalmente inicié el uso de un sistema de registro de actividades o de time tracking en un proyecto freelance que realicé, la motivación inicial fue la de intentar determinar si el número de horas que había presupuestado y el número de horas que iva a invertir se ajustaban o no. Ahora ya llevo más de tres años midiendo el tiempo que invierto en ejecutar mis tareas y registrando las actividades que realizo en cada momento.
Aunque al principio cuesta un poco adaptarse y ser disciplinado, con el tiempo se adquiere el hábito, ahora esta actividad ya forma parte de lo que hago por defecto.
Para ello uso Allnetic, una herramienta que me permite desglosar las actividades realizadas y me saca estadísticas de diferentes tipos. Allnetic permite registrar los tiempos agrupados por proyectos y tareas (anidadas). Tiene un sistema de generación de reportes de diferentes tipos y formatos de salida y es muy sencillo de utilizar.
Allnetic es una herramienta para pc y orientada sobretodo a personas que utilizan los ordenadores para realizar su trabajo, pero no exclusivamente.
Las Herramientas
Como dije anteriormente, a nivel personal y en los equipos de trabajo que he organizado he utilizado un software llamado Allnetic Working Time Tracker. Esta aplicación se lanza en background y detecta cuando se está utilizando o se deja de utilizar el ordenador y de esta manera permite iniciar o parar un registro de tiempo. En la barra de herramientas se pone un reloj como el mostrado en la figura que cuando está en color verde indica que está contando el tiempo. Desde ese mismo reloj, pasando el cursor por encima aparece una ventana donde podemos ver el tiempo registrado y tomar notas.
A continuación muestro una vista de la pantalla de aplicación donde vemos en el panel izquierdo los proyectos y las tareas y en el panel derecho los logs que hemos registrado y un filtro de fechas que podemos utilizar para filtrar los logs que queremos ver.
Y para finalizar les anexo una imagen de un informe html con descripciones de actividades donde se ve el tiempo total invertido en el rango de fechas indicadas, y una descripción detallada de cada actividad.
En otro post espero describir mejor el uso de esta valiosa herramienta.
Hace unos días escribí un post sobre Saiku, una plataforma, software o aplicación online para soporte a la gestión de proyectos con características colaborativas. Un producto español desarrollado por el grupo Teras.
He recibido más información sobre la aplicación y ésta se hace merecedora de una nueva entrada. Tengo en mis manos un conjunto de diapositivas que quiero compartir con ustedes.
He hecho una selección de las más relevantes y añadido algunos comentarios en las mismas para que nos vayamos haciendo una idea de la herramienta.
Menú General
Una vez el usuario acceda a la herramienta tiene a su disposición una barra de menú muy sencilla de manejar y entender. Como se muestra en la siguiente figura.
Desde esta barra el usuario accede a la página de control de proyectos (Dashboard), los mensajes intercambiados por los usuarios (Messages), la lista de tareas (To-Do’s), las páginas de publicación general (Pages), las páginas personales (People), el chat y acceder a cualquiera de los proyectos de manera directa (Projects), editar mi configuración (My Settings).
Página Principal de Proyectos
La siguiente imagen nos muestra la página principal de proyectos desde donde podemos controlar los mismos y recibir información sobre las principales actividades que en ellos suceden.
Como puede observarse en la figura, de una sola mirada podemos enterarnos de los últimos sucesos, alertas y eventos que ocurren en un proyecto y acceder a la información específica de un proyecto o la página de una persona.
La vista de cada proyecto es similar a la vista de resumen de proyectos pero filtra la información para el mismo.
Página Principal de Mensajes
La página de mensajes nos permite recibir y desde él escribir mensajes a los usuarios de la plataforma. Estos mensajes y sus respuestas quedan enlazados como hilos y al ser un servicio de internet quedan almacenados en el servidor en línea para ser leidos desde cualquier navegador sustituyendo de esta forma el correo electrónico como base de comunicación de los equipos de trabajo.
Los mensajes pueden ser comentados, enviados por email y/o SMS. Se puede anexar ficheros o grupos de ficheros en ficheros comprimidos.
Listas de Tareas
Saiku permitirá gestionar y planificar varias listas de tareas como se muestra en la siguiente figura.
Desde este sencillo panel, el usuario puede acceder a la información de la tarea, editar y organizar las listas, añadir items, planificar las tareas y ver las personas involucradas entre otros. Es un panel bastante sencillo para esta tarea que suele darnos dolores de cabeza cuando queremos gestionar proyectos. Igualmente podemos ver un resumen de las tareas activas y terminadas.
Páginas
Para finalizar voy a mostrar la vista de páginas (pages) una herramienta de comunicación, documentación y para compartir conocimiento, ideas, comentarios, etc alrededor de un proyecto.
Esta herramienta es supremamente útil dentro de un proyecto porque es una herramienta para soportar ciertos procesos de conocimiento que no pueden quedar almacenados en un mail, discutir ideas, propuestas, documentar problemas, y alojar el know how de un proyecto. Este servicio es una mezcla de un blog y un wiki permitiendo crear entradas que se almacenan cronológicamente y a su vez ofrece la posibilidad de edición insitu de los contenidos. Además se pueden añadir notas y ficheros a los mismos.
Conclusión
Adicional a estas pantallas tenia otras no menos importantes relacionadas con los participantes en los proyectos, vistas de edición, pero que no vienen al caso adentrar para resaltar las bondades de la aplicación.
Viendo estos pantallazos son más grandes mis deseos de que esta herramienta salga pronto al mercado para poder disfrutar de su servicio. Para mayor información pueden contactar con (Info(arroba)GrupoTeras.com).
En la reunión de emprendedores Madrid 2008 tuve el gusto de conocer a uno de los creadores de Saiku, una aplicación web para gestionar proyectos online orientada principalmente a mejorar el control de tareas e hitos de proyectos, la comunicación y colaboración entre los participantes del mismo.
Actualmente está en fase de desarrollo, pero por lo que muestra en un primer pantallazo y con lo que hemos tenido la oportunidad de comentar, esta aplicación tiene una pinta muy interesante.
Como puede observase en la imagen, Saiku ofrece una interfaz agradable e intuitiva y dentro de sus funcionalidades permitirá crear y hacer seguimiento a proyectos, planificar hitos, compartir ficheros y notas, etc. Según las conversaciones, el servicio será altamente interactivo y dinámico haciendo uso de tecnologías web2.0 (Ajax, drag&drop, ruby, rss, colaboración y participación, etc).
Saiku permitirá la interacción entre los participantes del equipo de trabajo (people) mediante mensajería y chat. Los usuarios podrán organizar su agenda de tareas y planificarlas para su ejecución y reflejar las actuaciones sobre las mismas a todo el equipo en línea. El sistema de mensajes interno de saiku permitirá enviar los mensajes via SMS, email o sms&Email permitiendo de esta forma optimizar los procesos de comunicación entre los miembros de los equipos de trabajo.
Adicionalmente Saiku dispondrá de una interfaz de publicación de contenidos tipo blog mediante la cual los integrantes podrán escribir notas, compartir conocimiento o comentar aspectos propios de un proyecto. Una característica importante de este módulo es que permite la edición insitu, es decir, que desde la misma página de contenido puedo editar el mismo y actualizar los cambios mejorando aún más la usabilidad de la aplicación y el rendimiento de los equipos de trabajo.
A continuación anexo algunos screenshot que me ha enviado el equipo de desarrollo.
A mediano plazo, el equipo de desarrollo planea desarrollar un API (OpenSource), integrar Saiku con iphone, blackberry y hacer uso de APIs de facebook, gmail y otros para ampliar su alcance.
Las personas que estén interesadas en apuntarse al programa de pruebas pueden hacerlo aquí. Yo particularmente estoy ansioso de evaluar esta herramienta pues he revisado varias herramientas online y aún busco una que complemente todo en uno con un grado de homogeneidad entre planificación, organización, documentación y colaboración.
Más información sobre Saiku y el equipo de desarrollo lo pueden encontrar en su blog. Próximamente estaré escribiendo más sobre esta aplicación.
Este post es el cuarto de la serie “Mejora el uso de tu tiempo”, en los anteriores hemos visto la importancia de la planificación, de fijar objetivos y de la segmentación de las tareas para atacar mejor los problemas. Hoy nos ocuparemos del una labor sumamente importante, la asignación de prioridades a las tareas que tenemos en nuestras lista(s) de tareas.
En la labor de planificar, no basta con tener una dos o tres listas. Es importante que asignemos a las tareas un peso o prioridad que nos indicará cual es el orden en el que debemos realizar las tareas.
La priorización de las tareas depende del proyecto, el tiempo de desarrollo, el impacto o importancia de una tarea y de sus habilidades y fortalezas. Esto hace que esta tarea en si misma ya sea compleja.
Al priorizar una tarea se le asigna un peso generalmente numérico (Ejm. de 1 a 10) , un color (verde, azul, etc), una letra (Ejm. A – F task list template, Mindtools) u otro mecanismo que nos permita deducir el orden en que las tareas que deben ser ejecutadas.
Para determinar la prioridad de una tarea debe evaluar entre otras cosas:
- La importancia proyecto o rentabilidad.
- Objetivos a corto plazo que se están buscando.
- Restricciones de tiempo o hitos.
- Complejidad o dependencia de otras tareas.
Al priorizar las tareas y agendarlas para su ejecución es importante tratar de seguir al máximo la agenda prevista y atacar los problemas de acuerdo a las prioridades, de esta forma al final del día podremos tener la satisfacción de ver como de nuestra lista de tareas desaparecen tareas realizadas.
Mi Experiencia propia
Yo personalmente uso la priorización de tareas para determinar el orden de ejecución de las mismas. Para ello, intento al máximo asignar una prioridad tan pronto creo una tarea. Si esta tarea es subdividida en otras, éstas a su vez tienen una prioridad interna.
Cuando tengo varias tareas de la misma prioridad, determino el orden de ejecución por el riesgo o el impacto que la tarea tiene sobre el resto o sobre los hitos, su relación con otras tareas o personas, o dependiendo de si esa tarea va a tomar más o menor tiempo, e intento sacar las de menor tiempo antes.
Al final del día y durante el mismo suelo revisar las prioridades asignadas y realizar una replanificación si es el caso.
Suelo mantener una lista única de tareas (planificada previamente ) por realizar al día, trabajo sobre ella y esto facilita esta labor de asignación de prioridades. Esta lista a su vez depende de otras listas donde se debe priorizar con antelación y entre varias listas debo seleccionar las más relevantes para poner en mi lista diaria.
Herramientas
Como comenté en post anteriores, las herramientas que uso son hitask (Cada día menos) y todolist, éstas me han resultado suficientes por ahora para organizar las tareas.
El hitask ofrece un mecanismo de priorización de tareas basado en colores como se muestra en la figura de edición de tarea. Esta clasificación permite agrupar las tareas más importantes que podemos usar para realizar la planificación. Las tareas de color Rojo son las de mayor prioridad, las blancas las de menor prioridad.
Para ver la lista organizada por prioridades en el panel superior encuentra una opción color, hitask mostrará agrupada la lista de tareas del mismo color desde el rojo al blanco. Ver imagen anterior.
Con el todolist, la tarea de priorizar es bastante sencilla, en esta aplicación se asigna un valor de 1 a 10, siendo de mayor prioridad la de 10. Simultáneamente, todolist asigna un color de prioridad que nos ofrece una gran ayuda visual.
Todolist además nos permite asignar un valor llamado riesgo de la tarea, este valor también puede ser usado para determinar el orden de ejecución de tareas de igual prioridad. Por otro lado al igual que hitask, me permite cambiar el orden de las tareas (subirlas o bajarlas) para organizar en que orden las quiero realizar. Esto se muestra en la siguiente figura.
Con ayuda de las barras superiores podemos organizar la lista de tareas por prioridades. Las tareas se pueden ir tachando en la medida que se van evacuando y puede volver a organizarlas fácilmente y de una manera muy rápida e intuitiva.
Otra Bibliografía
Valora mi trabajo
Si me conoce mi trabajo porque has trabajado conmigo, o conoces mi trabajo, puedes valorlo en Webspotters.com
