A) Es el porque, el correcto?

Supongamos un proyecto de IT, cuya gantt es de 3 años de desarrollo en base a una tecnología X, con cierto nivel de desarrollo y muy prometedora. La tecnología principal a usar en el proyecto es publicitada por los grandes compañías de informática y apoyada por expertos como algo con un futuro prometedor. Ademas, el proyecto se apoya en las tradicionales herramientas, metodologías y áreas de desarrollo de software, así como en plataformas de Hardware, Bases de Datos, Diagramas de Procesos, Cluster o arreglos de discos y de servidores para la infraestructura de datos, redes, etc.  Asumamos también un gran equipo de desarrolladores para los periodos Pick de codificación que pudiesen llegar a una centena de programadores sin contar ademas los analistas,  Managers, etc.

Este tipo de mega proyectos IT que justifiquen tamañana inversión (Varios pares de US$ Millones) necesitan en su promesa final ante directorios o dueños para promover ventajas y beneficios suficientes que promuevan tamaña aventura. Podemos citar entre estos los siguientes:

• Reducir costos de administración y de operación de los sistemas core (reducir la planta de personal IT y contar con costos de mantencion y operación menores)
• Continuidad del negocio – el sistema actual ya no da para mas y requiere un alto nivel de procedimientos manuales con riesgo operacional alto (pero el sistema legacy aun funciona)
• Aprovechar tecnologías innovadores actuales para generar una diferenciación respecto a la competencia en la eficiencia y rapidez de ofrecer los servicios actuales y futuros.
• Contar con sistemas core altamente adaptables a normativas cambiantes y a mercados en evolución.

Lo mas probable es que sea una mezcla de los puntos anteriores la promesa del Gerente IT, CIO o como se llame en dicha empresa, hacia el directorio y/o dueños. Este punto lo dejo de manera explicita pues es el que finalmente junto a los plazos comprometidos iniciales indicaran finalmente si el proyecto es o no exitoso, o si por el contrario fue un fracaso.

Lo anterior respecto a la pregunta A) sin embargo es lo básico y los argumentos citados anteriormente no responden al porque, en un sentido profundo. Esto es, cual es la creencia y no la necesidad que impulsa tamaña aventura? Por supuesto dependerá de la misión de la empresa y de las creencias de sus directores. Quiero mencionar este punto en particular ya que debe ser el lineamiento base que fije las conductas responsables cuando las externalidades, problemáticas o desafíos nuevos se presenten en el andar del proyecto. Por sobre todo. Consecuencia. Para un liderazgo correcto.

B) Es el como, el Correcto?

Esta gran pregunta es la que mas dudas a despertado en el ámbito de la creación de tecnologías o productos como software o aplicativos. Considera el contexto. Las IT en lo que se refiere a su administración y gestión de proyectos es una disciplina basicamente juvenil (en el mejor de los casos). Las metodologías o formas para confección de infraestructura, como puentes, construcciones, etc. Tienen centenas y décadas de experiencia acumulada. Y en las ultimas décadas esa experiencia se ha normalizado en iniciativas y metodologías que han nacido bajo el amparo de este tipo de creaciones. Es así como las metodologías predictivas tales como PMI han irrumpido fuerte en el área de las IT, y sin duda han ayudado a poner orden en el caos original. Son sin duda la base para partir. Sin embargo nosotros no construimos puentes, construimos aplicativos, software algo básicamente intangible y representativo de conocimiento y procesos. En la ultima década un movimiento original en base a metodologías ágiles, para ponerles un nombre común han irrumpido fuerte en la forma de construir software y han presentado ventajas indiscutibles en el desarrollo de software.

Por otro lado la base de la información que soportara el sistema normalmente se encontrara en un modelo relacional clásico SQL. No obstante y tal vez por una formación académica de visión estrecha, en muchos casos he visto como por doctrina y ortodoxia teórica se terminan sistemas con modelos de datos de mas de 1500 tablas. Algo que a todas luces repercutirá en los costos de mantencion post salida al aire del sistema. La dificultad y errores a corregir y la dinámica de estas operaciones de manutención que se presentan cuando se administra tamaño nivel de tablas y entidades en las etapas de explotación del sistema (cuando se requieren pequeñas adaptaciones mínimas demandadas por el negocio) oculta finalmente el real TCO del proyecto. Los fundamentos que he escuchado en el tiempo que explican semejante nivel de entidades son los siguientes:

• “Hemos separado las entidades y normalizado el modelo a fin de dar la mayor flexibilidad posible de forma que soporte toda posible futura variación”.
• “El contrato indicaba que el modelo del sistema debía ser altamente flexible en el manejo de la información”
• “Menos entidades implicaría tener tablas que comparten información de mas de una entidad, y eso no corresponde a un modelo SQL normalizado”
• “Menos entidades implicaría repetir información en mas de una entidad y esto conlleva un mayor consumo de espacios en almacenamiento”

Todas estas explicaciones son validas para un sistema que no tenga mas de un centenar de tablas como mucho. Pero mas halla de esto lo que para un escenario era correcto para otro ya no necesariamente lo es. Analizemos los hechos:

De que me sirve tener 1500 tablas si desde el punto de vista de la flexibilidad tendre que tener absoluta claridad sobre que hace cada una de ellas. Tema no menor que impactara el area de documentacion. Pero mas halla que eso vea en la practica cuantas tablas o entidades es posible que un manager o programador senior del sistemas tenga en su cabeza. En lo personal creo que una excesiva normalizacion del modelo es inoperante y no eficaz cuando tenemos semejante nivel de entidades, puesto que lo que sale barato a nivel del modelo de datos. Se traspasa directamente al nivel de codificacion de aplicativos, a la revision de los mismos y a sufrir con un modelo enorme.

Por el contrario imagine que su modelo cuenta con un numero menor de entidades, algunas decenas como mucho, algunas normalizadas y otras no. Pero altamente entendibles. Entonces lo que hay que evaluar en este punto es: Que es mas adecuado?, pagar el costo de un altertable para modificar el modelo?, trabajar con un modelo semi-normalizado pero mas pequeño?,agregar una entidad mas cuando se requiera al modelo? o contar con un modelo enorme que contempla muchos escenarios futuros pero tal vez no todos y ciertamente mas costoso a la hora de generar nuevos aplicativos.

“NOSQL”: Sabe usted que base de datos SQL usa FaceBook o Google o enormes sistemas de administración de información de la era Web actual?. Se sorprendería saber que muchos ya no usan SQL. FaceBook  y Google usan tecnologías NOSQL con sistemas de repositorios de información no relacional. Pensados para volumnes de data enormes. La tecnología ”NOSQL” esta emergiendo a pasos agigantados y soluciones como MongoDB entre otras traerán aire fresco a la estructuras de datos de grandes proyectos.

C) Es el que, el Correcto?

Estamos usando las herramientas de software correctas?. Tal vez los evangelistas de aplicaciones y lenguajes no demoraran en contestar que si. Yo en lo personal he empezado a ver con desconfianza cualquier asomo de ortodoxia en la elección de herramientas. Las grandes empresa de tecnología no usan grandes y novedosas soluciones, si no mas bien simples soluciones con lenguajes con decadas de historia (Google en un buen ejemplo). Por otro lado las pequeñas pero innovadoras empresas de IT, están usando modernos lenguajes de tipo dinamico como Ruby (Las StarpUp tipo Web son muy buen ejemplo de esto). En lo personal le recomendaría no dejar de evaluar Lenguajes como Python (usado ampliamente en proyectos de ingeniería, un buen ejemplo de ello es ALMA) o modernas aproximaciones de desarrollo web usando FrameWorks como ROR o Symphony. Como esta seccion puede dar para mucho les dejo un resumen de “Ques” a considerar en distintos ámbitos de grandes proyectos IT:

• Micro Modelo de Incidencias / Por sobre complejos sistemas de tracking
• No agrupar incidencias por ser del mismo tipo. (Error fatal que he visto en grandes empresas)
• Testeo en el Código TDD. Vital!
• Testeo de Aceptación BDD. Mas Vital!
• Programación en Pares. Al estilo Extreme Programming (eXP). Dos cabezas piensan mejor y se equivocan menos.
• NoSQL y SQL. Cada dia me gusta mas NoSQL!
• MVC (Modelo Vista Controlador). Al menos!
• Proceso Iterativo rápido, Sprint y Scruum por sobre modelos predictivos como PMI. Si va a desarrollar software considere los 2 puntos de vista predictivos y no predictivos en la administración de proyectos.
• REST vs SOA. Cada dia me gusta menos SOA y mas REST como alternativa minimalista.
• Capacitación Continua acerca del Negocio, Basico!
• Axure (Story Board) y no UML. No escriba documentacion para Ingenieros!
• Replica de datos en linea Horizontal VS tablas satélites y Modelo Gigante. MongoDB y modelos NoSQL.
• No BPM como parte del Core. Procesos no son el negocio!
• Salida Parcial VS BingBang en lo posible. Escuchanos señor te regamos!
• Si al Opensource donde sea mejor. Asi no mas!
• Menos capas en las aplicaciones máximo MVC.
• Compilación del Cliente de los códigos fuentes entregados por el proveedor.No se entregan binarios. Aunque no lo crea lo sigo viendo en grandes empresas!
• Control de SVN por parte del Cliente no del proveedor. Idem que arriba, lo sigo viendo, y mas seguido contra mas grande el proyecto.
• Sistema de Base de Conocimientos. Elemental, pero el mas olvidado.
• Control de Avance lo hace el Cliente no el Proveedor. No es chiste!. Lo sigo viendo en grandes empresas aun.
• Gráficos de Flujos y procesos de negocios conocidos por todos. Lo sorprenderia con las historias que tengo al respecto.
• Gráficos de Maquinas y redes conocidos por todos.Idem al anterior.
• Mismos nombres para únicos problemas. Sentido comun.
• Control presupuestario consolidado por 1 persona y reportado a Gerencia General. De preferencia externo al proyecto.
• Modelos Gráficos por sobre verbales en el conocimiento común.
• No a los script regularizadores, automatización vs correcciones manuales. La solucion barata trae grandes problemas y oculta otros peores

Contando con una base de metodología Predictiva tipo PMI (minimizada), y trabajando el día a día con Metodologías No-Predictivas (SCRUM, Ágiles, póngale el nombre que quiera). Es mas probable un exito en el desarrollo de software.

En ultimas palabras para evitar todos estos problemas en grandes y no tan grandes proyectos, me he convencido que la única forma viable real y efectiva es priorizar la comunicación  de los equipos y personas, por sobre los procesos y las herramientas.Por que cuando se priorizan las metodologías y herramientas por sobre los equipos y personas,las personas quedan relegadas. Cree usted que en ese escenario saldrá algo bueno si en ultima instancia el proyecto lo construyen, dirigen y lideran las personas?. Y si las respuestas a las preguntas: Porque?, Como? y Que? son solamente formalidades y no creencias.

Bueno espero que este breve resumen les sirva.

Saludos Cordiales
Javier Urrutia Tobar

En mis últimos 14 años laborales me he dedicado siempre a temas relacionados con Software y Administración de Proyectos IT, pero en el 2010 una variante me llevo mas que nunca hacia el Hardware. Mas precisamente, ha  hacer Hardware. Entendiendo con esto el construir soluciones con Microcontroladores y adentrarse al mundo de la robótica. Este fue mi trabajo principal la mayor cantidad de meses del 2010. Tanto así que en conjunto con 3 amigos formamos una empresa cuyo fin es desarrollar soluciones robóticas en diversas áreas. Así en mis próximos Post me adentrare en contarles cosas interesantes, practicas y entretenidas al respecto. Por cierto seguiré escribiendo de Software y administración de proyectos.

Aquí después del salto una introducción a como un informático y un electrónico ven el mundo de la robótica, empezando por usar Microcontroladores de la era actual. Todo un mundo nuevo para un informático como yo (los avances desde las clases de la universidad en electrónica y control automatizado hasta ahora me sorprendieron), misma opinión que creo tendrá usted después de leer este y mis próximos artículos. Así pues…

A fines del primer trimestre del 2010 termine mis labores en mi empleador anterior (otra historia). Con una cantidad de dinero suficiente para un par de meses como independiente, busque en que trabajar de forma temporal mientras encontraba algún trabajo de calidad. En esas andaba cuando un buen amigo me contó de las dificultades que una empresa productiva tenia. Me menciono de como lidiaban con problemas que tal vez se podrían automatizar. Nos juntamos con ellos y después de varias reuniones unas PPTs bien hechas y mucha energía nos asociamos con esta empresa. Nosotros pondríamos el talento y ellos el capital. Hoy en día resultado de esta aventura tenemos 2 soluciones prototipos. Y aunque la sociedad se termino por problemas financieros mucho se aprendio en el camino.

Partes que se necesitan para construir y realizar una solución robótica o de control automático:

Para partir un Microcontrolador es la solución base. Si esta considerando usar algo que no sea un clásico PC para controlar o censar dispositivos externos vía puertos Seriales o USB.

Microcontroladores existen muchos. Aquí en Chile los mas usado son los de la línea PIC (Una clásica línea de Microcontroladores que se han actualizado continuamente) inicialmente se programaban a punta de Assembler, hoy en día se programan en lenguajes clásicos de distinto tipo. Cuando iniciamos la fase de investigación encontramos que los Microprocesadores mas usados en Chile eran clásicos que no estaban a la altura de nuestra expectativas, en términos de facilidad, potencia y agilidad ( y la verdad queríamos utilizar algo nuevo, moderno y ágil).

En nuestra búsqueda dimos con la empresa Parallax Inc. (USA). Parallax tiene entre sus productos clásicos una línea de Microcontrolador de la clase STAMP. El “Basic STAMP” es el mas clásico de todos, muy usado en áreas de educación y en temas productivos. Pero si el Basic STAMP era nuestra elección . Nuestro ambicioso proyecto requeriría muchos de estos Microcontroladores comunicándose y coordinándose entre si. Ese nivel de complejidad no era lo que buscábamos. Buscábamos un Microcontrolador capas de ser programado en un lenguaje amigable (no Assembler)  con buena documentación y Multitarea real, no a punta de Interrupciones (La forma clásica de simular paralelismo en procesamiento monoprocesador)

Nuestra elección: El Microcontrolador “Propeller” de Parallax.

El Propeller (Hélice) es un Microcontrolador que como muchos chips de este tipo, posee una sección de proceso, generación de reloj, contador de sistema, puertos de entrada/salida, memoria RAM y ROM… pero aquí termina toda similitud con los Microcontroladores conocidos y clásicos.

Cuando analizamos el Propeller versus otros Microcontroladores, vimos su potencia y su posible complejidad. Igual nos animamos y fue nuestra elección. Apostamos a ganarle a una posible complejidad en su uso VS mas potencia para nuestros emprendimientos, en los meses siguientes confirmaríamos esta buena decisión ya que no era tan complejo de usar como pensábamos, eso si, tuvimos que conocerlo de apoco.

Al igual que otros Microcontroladores el Propeller se programa en Assembler. Pero también en otros lenguajes. Nuestra elección fue usar el propio lenguaje de Parallax llamado SPIN. Sorprende saber que hoy en día se puede programar a nivel de Microcontroladores un chip en un lenguaje como SPIN. Que controla hilos paralelos reales, que puede generar bibliotecas de objetos y que tiene toda una comunidad de desarrollo importante. Pareciera que programáramos un PC mas que un Microcontrolador. La era de generar código para control automatizado a punta de Assembler y códigos especiales ya paso…

Como se puede ver en la ilustración (ejemplo de invocación en paralelo sobre el método DispCnt). El lenguaje es de fácil lectura. El editor y compilador es gratuito y rápido. Existen otras herramientas que probamos pero que no fueron de nuestro agrado (prometían fácil debug) al no ser agiles en su uso.

Nuestra estrategia de acercamiento al Propeller, antes de comenzar a construir nuestra solución fue adquirir y aprender a usar el Microcontrolador vía las tarjetas de prueba y desarrollo que vende la empresa conocidas como “Demo Board”. La Demo Board, incluye el chip en la placa y incluye resistencias y otros conectores y partes ya incrustados en la placa. Como no queríamos quedarnos en una aprendizaje meramente educacional,  también adquirimos la “Professional Development Board”. y El Kit de educación del Propeller. Este ultimo kit es por decirlo de una manera bruta un kit de partes sueltas. En las Demo Board y Profesional, estas piezas ya están armadas, pero se presentan también los conectores para probar y programar distintos sensores, entradas y salidas del Propeller. La diferencia entre la Demo y la Profesional, es solamente mas piezas pre instaladas para realizar distintos montajes de pruebas (usando cablecitos para simular pistas que en placas de producción ya están soldadas).

En mi próximo articulo andaremos en como programar el Chip Propeller paso a paso, generaremos bibliotecas de objetos y generaremos código SPIN complejo haciendo uso de Multitarea. En nuestro aprendizaje nos dimos cuenta que un Microcontrolador como este era necesario para nuestros objetivos. Pero cuando interactúan sensores de distinto tipo, con Routers 3G, conexión WIFI, Visión en 360 grados, lógica de visión artificial, movimiento de ruedas, un scanner 3D o una cámara de profundidad (como el Kinectic de Microsoft) . Todo esto para lograr un robot autónomo con capacidad de movilizarse. Necesitamos como coordinador, de todo este conjunto un computador que calcule cosas mas complejas; como rutas de navegación y desplazamiento, etc. Nosotros elegimos el FitPC2. Y con ello no solo tuvimos que programar SPIN y Propeller sino además conectar vía USB el Propeller al FitPC2, y programar en VB.NET 2010 para las pruebas de concepto y generar todo un protocolo SPIN/VB.NET 2010. De todo esto escribiere en mis próximos artículos. Para muestra una foto de nuestro prototipo en su fases iniciales (como a mediados del 2010).

Saludos Cordiales
Javier Urrutia Tobar.

Los juegos que jugamos…

Pareciera ser que al realizar nuestras acciones participamos de distintos juegos de forma consciente e inconsciente. La manera de jugar los distintos juegos que la vida nos impone, se forma en un contexto donde conocimiento, instituciones e individuo lidian entre si y desarrollan sus particulares interacciones. Estos dos mundos, el de la sociedad, organización o Proyecto, y el del individuo, persona y ser, conforman nuestro espacio de prácticas con el conocimiento que poseemos en el contexto del juego especifico en que participamos. Asi…

Si aplicamos esta idea a los proyectos de tecnologías de información, podríamos decir por ejemplo; que un desarrollador especializado posee un conocimiento práctico sobre cierto lenguaje o solución tecnológica. La organización o proyecto fija ciertas reglas o factores institucionales como por ejemplo la hora de entrada, la forma de cargar las horas de un proyecto y como documentar el trabajo de codificación. Y por otro lado el individuo tiene subjetividades sobre el cómo hacer su trabajo. Por ejemplo como distribuir su carga de trabajo, como priorizar entre sus pendientes de codificación y documentación, etc.

Hasta aquí todo bien, pero llegara el momento en que los factores institucionales, reglas de la organización o del proyecto dejan ver su naturaleza general y no particular, se harán visibles entonces los intereses propios de cada individuo y las practicas particulares acerca de la manera de hacer las cosas: 

Practicas y practicas…

Las formas de hacer las cosas, las distintas practicas que tenemos como organización y persona, no se pueden clasificar simplemente como buenas y malas. El siguiente cuadro muestra una agrupación más realistas de las mismas, distinguiendo practicas potenciadores, anómalas, disfuncionales e ineficientes, todas ellas tienen distintos grados de beneficio como oportunidades sociales o de equipo, y de igual forma existen practicas que se pueden categorizar como más cercanas a las subjetividades de cada individuo en contrataste con aquellas que se acercan más al grupo, equipo o sociedad.

Reconociendo algunas de nuestras prácticas:

1) LA ADOPCIÓN RESISTIDA
“Lo hago, pero a mi manera”

“Esta práctica típica se caracteriza por la resistencia que oponen ciertos actores a procesos de cambio cultural o institucional, cambios que ellos creen que podrían perjudicarlos en algún sentido. Aquí los actores reinterpretan el sentido del cambio, establecen estrategias para resistirlo y buscan maneras de adaptarlo a sus intereses.”

Siguiendo con nuestro desarrollador como ejemplo, la organización ha declarado que es responsabilidad de cada programador registrar via un portal web de la empresa, en que tareas y proyectos a consumido sus horas de trabajo de cada día de la semana (información para generar reportes semanales a gerencia). Pero en la interpretación de esta trabajador, la adopción resistida se refleja en que este, cargara sus horas el día viernes a última hora. Con ello desde su punto de vista “maximiza” y concentra sus horas de trabajo en codificar, y deja la “burocracia” para el ultimo día de la semana. Con ello tendrá que recordar muy bien que hizo cada día. En la realidad, las horas serán cargadas de forma más bien genérica, y en mas de alguna ocasión se olvidara y las cargara el día lunes siguiente, pero con el tiempo tampoco hará eso, la debilidad en la fiscalización y la asimetría de información se harán visibles dada la gran cantidad de tiempo y de recursos que requieren para revisar de forma individual la correcta carga de horas de todo el personal. Con ello, en una temporalidad larga se afectara al negocio, cuando este tome decisiones basadas en la información proporcionada de esta forma.

2) LA IMPROVISACION ADAPTATIVA
“Hay que hacerlo, y si no lo hago yo no lo hace nadie”

“Esta práctica se caracteriza por la presencia de algunos factores que asumen la función de parchar los vacíos o suplir las indefiniciones de ciertos cambios institucionales o culturales, sea por un sentido sacrificial o porque mantienen un fuerte compromiso con el sentido del cambio que se busca impulsar”.

En esta práctica y siguiendo con el ejemplo de nuestro desarrollador, podemos nombrar el caso en que un programador al encarar una situación de codificación, detecta que mientras todos sus demás colegas trabajan arduamente en avanzar codificando, nadie se ha detenido en evaluar si existirá alguna solución que se pueda comprar y adaptar para el requerimiento original de forma rápida, de tal forma que no haya que inventar la solución desde cero.

3) LA TRANSGRECIÓN PACTADA
“Ni a ti ni a mi nos conviene, arreglemonos entre nosotros”

“Se produce una transgresión pactada cuando, en contextos de cambio institucional (por ejemplo, una nueva ley), los actores se coordinan para contravenir la norma porque consideran que ésta perjudica sus intereses de corto plazo.”

Puede ser una de las prácticas negativas más antiguas. Se inspira en los supuestos efectos benéficos a corto plazo, pero destruye el espíritu original en que fue creada una norma o línea directriz al interior de una organización o proyecto. En nuestro caso podemos nombrar el evento en que un proyecto está atrasado y se pacta entre un grupo de desarrolladores y el Project manager una semana de trabajo intenso con más de 9 horas diarias de trabajo de codificación. En el corto plazo se observan los beneficios, pero en el largo plazo, la práctica se puede hacer fácilmente costumbre. Y de 9 horas, se puede paulatinamente pasar a 10 y más. En la temporalidad de largo plazo. El equipo agotado y destruido abandonara la organización. Situación parche como días libres adicionales para recuperar o compensar el trabajo adicional generaran más problemas administrativos en el largo plazo, generando cargas de días adicionales a las vacaciones, escondiendo los costos en instancias informales de días de bonificación “extras” empeorando aun más la situación.

4) LA ADAPTACION PROYECTIVA
“A la larga los cambios son para mejor”

“En esta práctica los actores aceptan e incorporan los cambios institucionales o culturales porque entran en sintonía con sus motivaciones y aspiraciones de largo plazo. Aquí tienden a primar juegos de identidad en los que los actores adoptan nuevos roles y atribuciones, y juegos de intercambio caracterizados por la exigencia recíproca en función de un beneficio mutuo.”

Como ejemplo de esta práctica, y en el contexto en que estamos desarrollando esta aproximación. Podemos imaginar una empresa de tecnología cuando se decide incorporar normas de documentación para apoyar el área de marketing de la empresa. De esta forma los programadores deben agregar imágenes y material grafico en su documentación normal para ser utilizada en la promoción de las soluciones informáticas que ellos desarrollan. Claramente una sana competencia por posicionar mejor sus propios trabajos, generando una “Adaptación Proyectiva”, al proyectar en la norma los interés propios de querer potenciar su propio trabajo, identidad y ego.

5) LA RENEGOCIACION CONSTANTE
“Y quienes son ellos para decirme lo que tengo que hacer?”

“Esta práctica se caracteriza por la dificultad de los actores para alcanzar consensos mínimos que permitan futuras acciones. Ocurre en contextos de alta indefinición de roles y de deslegitimación entre los actores, lo que obliga a estar permanentemente estableciendo acuerdos que a la primera complicación se desconocen.”

Un ejemplo clásico que se me viene a la mente, es cuando en una empresa de tecnología de carácter global, se deben resolver acuerdos de control de firewalls y normas de seguridad en cada sede de país, cuando existe una centralización de estas decisiones, pero a su vez existe infraestructura propia en cada país. Los encargados de cada país lidiaran con los requerimientos locales, y al mismo tiempo deberán cumplir las normas globales. Cuando no exista una declaración superior formal y compartida entre todas las partes. Se generara una “Renegociación Constante” entre las sedes y corporate, sobre casos particulares y generales respecto a cómo configurar políticas de seguridad en firewalls, accesos especiales, puertos hacia clientes, etc.

6) EL ACUERDO DE MINIMOS
“Por que voy a dar mas de mi si ellos no lo hacen?”

“En esta práctica existe un alto grado de dependencia entre los actores, quienes además actúan anticipando un abuso por parte del otro. En un contexto de desconfianza recíproca, las personas ponen lo mínimo de su parte en la práctica, para perder también lo menos posible.”

Un ejemplo clásico de esta práctica, se da en el escenario de proyectos incendiados o con serios problemas históricos de administración y coordinación, producto de indefiniciones iníciales y diseños incompletos. Así cuando un nuevo Project Manager incorporado para cerrar el proyecto, en reuniones con el cliente acuerda un listado de temas únicos y pendientes para dar por finalizado formalmente el proyecto. Se puede dar normalmente que en la confección de esta lista, ambas partes se sientan ya, a esa altura abusados, por un lado el cliente respecto a sus expectativas y por el otro lado la empresa de tecnología respecto a los costos totales. Ambas lados trataran de llegar a acuerdos mínimos que disminuyan sus posibles pérdidas.

7) LA NEGOCIACION HABILITANTE
“Si todos nos ponemos, todos ganamos”

“En esta práctica los actores están desafiados por cambios culturales, institucionales u organizacionales que los presionan a reflexionar sobre sus modos de coordinación y a entablar nuevas relaciones. En la negociación habilitante los actores logran arreglos beneficiosos en el largo plazo a partir del reconocimiento de que las demandas de los otros actores también son legítimas.”

Un ejemplo de esta práctica puede darse, cuando la gerencia de una empresa de tecnología y el equipo de representantes de desarrolladores deciden, implementar una política de menos horas en el trabajo, por accesos remotos y teletrabajo con el fin de lograr una mayor productividad y calidad de vida. Para los trabajadores que decidan esta modalidad una negociación de este tipo generara un compromiso alto por cumplir lo requerido, en post de la facilidad de estar mas cerca de su propia familia.

El mapa de practicas…

Podemos entonces notar ciertas factores comunes en todas las prácticas descritas, ciertos contextos que se repiten como se ilustra en la siguiente figura:

Después de revisar este conjunto de prácticas y como pueden ayudar o dificultar nuestros desarrollos, podemos clasificarlas en el siguiente cuadro:

Podemos notar como algunas prácticas son en general positivas o negativas, y como otras según el contexto pueden o no apoyar el avance de un proyecto. Diferenciando aquellas más o menos afectadas por subjetividades individuales.

Espero que estas nuevas distinciones, y este nuevo conocimiento cuyo descubrimiento a sido de gran significado para mi, sea tambien para ustedes de gran ayuda en su propia organización.

En mi próximo post, abordare el mismo tema y este estudio tan interesante con que me he topado, pero esta vez con una aproximación para ver cómo se pueden lograr los cambios en la organización cuando estas distinciones estan sobre la mesa. En particular mi vision de los desafios propios y las estrategias especificas para las empresas de tecnologias de la información en lo que se refiere a cambios de practicas.

Saludos Cordiales
Javier Urrutia Tobar

Todas las ilustraciones y las definiciones iniciales de cada una de las 7 practicas descritas, se encuentran y son originalmente descritas en el estudio “Desarrollo Humano en Chile” en su versión 2009 del fondo de Naciones Unidas para el desarrollo (PNUD). Puede obtener mayor información en el siguiente link .

En mi último post termine de exponer por ahora ideas y experiencias en relación a reuniones y organización personal. En este último ítem (organización personal) sigo investigando y aprendiendo. Últimamente a raíz de la lectura del libro “Procrastination”, el cual llego a mis manos buscando literatura relacionada el tema de la organización personal (tiempo y recursos). He dado con una distinción que aclara un poco mas algunas preguntas y dudas que tenía hace un tiempo, pero que no lograba responder o al menos distinguir en relación a optimizar nuestra tiempo y aumentar nuestra eficiencia en torno al logro de nuestros objetivos personales y profesionales.

La procrastinación es la acción de procrastinar (del latín procrastinare) es decir, de postergar actividades o situaciones que uno debe atender, por otras situaciones más irrelevantes y agradables. Este término proviene del latín pro- (adelante) y crastinus (relacionado con el mañana). Todos en menor o mayor grado tenemos episodios de procrastinación. Pero bajo ciertas circunstancias y tal vez profesiones, corremos un mayor riesgo de no atender esta distinción. Aunque es un tema en el que aún hace falta realizar mucho trabajo de investigación. He decidido tomar una actitud específica con respecto a este ladrón del tiempo.

Este post, contiene una serie de recomendaciones acerca de como combatir la Procrastinación y de cómo entender por qué algunos autores afirman que esta distinción tiene un lado positivo. Anqué en lo personal difiero de esa evaluación. Así pues…

Con el arribo de las tecnologías de la información, trabajar en un documento Word y mantener al mismo tiempo vía Messenger o chat una conversación con una o varias personas no es tan poco común. Por otro lado los BlackBerry y otros dispositivos móviles de lectura de emails no ayudan mucho a enfocarse cuando uno lo requiere.

Si a esto le sumamos la tradicional lectura de correos que van llegando vía Outlook a nuestro escritorio de trabajo en el PC. Y si además disfrutamos de navegar y descubrir nuevos temas tecnológicos o de aprendizaje. Tenemos un escenario con bastante potencial para encontrarnos bajo las garras de la Procrastinación.

Entonces parase ser que en el ámbito tecnológico profesional estamos mucho mas propensos a este trastorno. Es esto una coincidencia?. Según autores como John Maeda “Procrastinar es un factor primordial en el proceso creativo, porque cuando el coste de la procrastinación se incrementa, lo hace también la probabilidad de aparición de pensamientos radicalmente nuevos.“

Otro enfoque es el de autores como Paul Graham “Hay un número infinito de cosas que podrías estar haciendo. Pero independientemente de en qué estés trabajando, no estás trabajando en todo lo demás. De modo que la cuestión no es cómo no procrastinar, sino cómo procrastinar bien“

Como yo lo veo. El hecho de relacionar la Procrastinación con un tema de creatividad superior. Por decirlo de alguna manera, solo acrecienta la posibilidad de ser un mayor procrastinador. Ya que al justificar el éxito probabilistico por trabajos realizados en el último minuto. Genera una sensación falsa de mayor control del tiempo y de las propias capacidades. Avalando de forma positiva el hecho de la distracción con temas que son mas placenteros por sobre las responsabilidades reales.

Así solo se elude la realidad, puesto que como todos sabemos existen responsabilidades que son placenteras y otras que no. Y aunque elegimos nuestra carrera y otras cosas en la vida porque nos resultan placenteras. Esto no significa que no tengamos que lidiar con las del otro tipo. Y es en este punto donde ser víctima de la Procrastinación se vuelve mucho mas probable cuando se pretende reconocer el lado positivo por sobre la realidad. Así solo se logra retroalimentar un ciclo negativo que tarde o temprano desemboca en una sensación de estar sobrepasado y abrumado.

Por cierto que en el ámbito de las tecnologías de la información y otros contextos de descubrimientos tecnológicos, se está en un contexto de mayor creatividad. Pero también de mayor riesgo.

La historia nos demuestra que existieron grandes creativos que lograron su éxito a base de disciplina. Aunque estoy seguro que disfrutaban de su trabajo, también estoy convencido que debieron realizar muchas tareas respetivas hasta dar con lo que buscaban. Si en ese momento hubiesen evaluado y actuado en salir a jugar futbol por que era mas placentero que lo que estaban haciendo seguramente no hubiesen logrado sus objetivos.

Al final se puede reconocer que Procrastinador o no. Existen formas de mejorar nuestra actitud y técnicas para rendir mejor y conseguir realizar muchas mas actividades que queremos hacer. Y que solo unos pocos logran llevar a cabo en su totalidad. Estoy convencido que reconocer este hecho justifica dar la batalla en contra del ladrón del tiempo.

Aquí van mis mejores recomendaciones después de mucho buscar. Y algunos links relacionados y muy inspiradores:

1.- Agrupar tareas es mejor que un gran To Do List.

Está demostrado que para la mente es mas fácil ejecutar tareas por grupos que de forma independiente. Es simplemente una lógica económica de razonar y ejecutar. Usted puede rendir mas utilizando el hecho cierto que es más simple procesar por lotes que de forma individual todos sus pendientes.

2.- Evite la multitarea.

Aunque nuestro cerebro puede hacer muchas cosas a la vez, nuestra conciencia opera de forma distinta. Mantiene el enfoque en solo una cosa a la vez. Así, evite la multitarea organizando listas agrupadas de cosas por hacer antes de hacerlas. Ejecute su lista una a la vez según la prioridad que tengan.

3.- No evada la imperfección

Como buen Ingeniero, seguramente usted siempre desea que todo funcione bien y mejor a la primera. Si usted mantiene este discurso interno de forma permanente se aleja de lo humano, entra en conflicto y contradicción con el hecho cierto que hoy por hoy hay muchas más cosas que están en beta que antes. Sobre todo en temas de TI. Esto no significa que deba hacer las cosas como le salgan. Uno siempre puede definir criterios de calidad pero si siempre son perfectos usted está en problemas. Como bien dice el refrán lo perfecto es enemigo de lo bueno. Al cual por cierto ya agregaría que “Es mejor empezar para obtener algo imperfecto que no empezar nunca a la espera de realizarlo de forma perfecta“.

4.- “Querer” no es “Tener que”.

Así es, si usted está siempre con el discurso de tengo que… en términos de las tareas que debe cumplir. Entonces ese cumplir se transforma en obligación. Y aunque lo sea. El “Tengo que” resalta el lado negativo. Acuérdese que muchas veces la Procrastinación nace como un mecanismo de defensa que provoca rebelión y resentimiento a lo imperativo. Es mucho mejor buscar el lado positivo y la prioridad en el “Quiero que”, que en el “Tengo que”.

5.- No se Abruma.

En ocasiones uno puede sentirse abrumado por el tamaño de las tareas por realizar. En este sentido use el principio romano de la conquista. “Divide y Conquista”. Disminuir las grandes tareas a un número mayor de ítems mas pequeños le da otra perspectiva al desafío. Delegue lo que pueda de estas tareas más atómicas. No se olvide nunca de pre visualizar el éxito como ayuda al sentirse abrumado. Si la tarea por realizar es muy grande entonces fijese metas pequeñas para trabajar en ese tema, por ejemplo trabaje 10 minutos en el tema y luego descanse unos minutos. LO mas posible sera que despues de las 10 minutos siga trabajando por otros 10 mas y no se dara cuenta que ya empezo y bien.

6.- Apague sus programas de mensajería instantánea.

Enfóquese, no necesita todos esos dispositivos para que lo ubiquen si usted está en otra, enciéndalos cuando este de viaje. Para lo demás y lo urgente todos sus amigos saben cómo ubicarlo por teléfono.

7.- Póngale música.

Auto ayúdese con un poco de música motivante. Busque ese tipo de música que le ayuda a trabajar y rendir. Un tarareo mental mientras trabaja puede ayudarle, pero no pierda el enfoque, no se trata de poner el mejor tema. Solo ponga la radio y simplemente quite el silencio para distraerlo de las distracciones.

8.- Reconozca el ciclo de la Procrastinación y evítelo.

Piense como piensa cuando piensa en empezar. Si!, no es un trabalenguas, es solo una alegoría en el sentido de que usted debe saber de memoria el ciclo de la procrastinación para evitarlo correctamente. Cuando se reconozca en esta trampa mental entonces es más posible que salga de ella rápidamente y haga lo que tenga que hacer.

Este tema de la procrastinación da para mucho mas. Espero luego poder agregar más conocimiento sobre esta distinción.

Saludos Cordiales

Siempre en mi mente la idea de volver a escribir, pero con las prioridades en contra para ello. Decisión personal al fin, pero ahora nuevos aires y experiencias aprendidas, así como un tiempo adicional disponible me tienen aquí, escribiendo nuevamente y contento por ello.

En mi post anterior, escribí en base ha algunas experiencias y tips aprendidos, después de mas de 1 año, otras experiencias he acumulado, lecciones aprendidas si quiere llamarle, he aquí algunos de ellas, esta vez en un formato un poco mas eclíptico, pero no por ello menos significativo…

 1) Acerca de reuniones de negociación

Siempre tranquilo y sereno:

Como usted ya sabrá en muchas reuniones con nuestros clientes, algunas evaluaciones de nuestra contraparte a veces nos llenan de una implacable necesidad de responder con nuestra verdad y en no pocas ocasiones con la pasión que nuestra edad interna, espíritu o indignación si usted lo prefiere. En mi experiencia de ver a otros y de la propia, he aquí el mejor consejo que le puedo dar respecto a reuniones difíciles o donde afronte un ambiente hostil, ya sea por errores suyos, de su cliente o de terceros. Siempre mantenga la calma, nunca nada de pasión, siempre serenidad en su exposición y fundamentos. Algunas personas equivocadamente piensan que defender sus argumentos con pasión es valido. Lo cual puede ser verdad para un discurso de candidatura, pero le aseguro que en no pocas ocasiones sino en la mayoría para reuniones de proyectos esto solo generara una escalada de tensión inútil y perjudicial. Mis mejores maestros en el ámbito de reuniones inicialmente difíciles con clientes, me enseñaron que incluso se pueden decir cosas muy duras con la tranquilidad y serenidad de estar convencidos de tener la razón y los fundamentos. No confunda, no se trata de ser irónico o de siempre tranzar, sino de ofrecer la mano distendida, explicitando de lo que realmente se tiene convicción (Pero quite la pasión, le conviene a sus fundamentos, por cierto no sea extremadamente parco o aburrido, sea distendido y franco diplomáticamente). He visto como a una persona del lado del cliente se le a tratado de insolente por parte de un PM con la mayor serenidad y amistad que usted imagine. Y en la misma reunión salir con un proyecto adicional bajo el brazo. Maestro!!!

No negocie basado en posiciones:

Cuando usted negocia basado en posiciones, el resultado mas halla de terminar a su favor o en contra, generara un daño a su relación, ya sea por abuso de posición de la parte vencedora o por una concesión extrema de la parte perdedora.

La alternativa?: Negocie basado en principios y en méritos, como así?:

Construya su reunión de negociación de manera efectiva siguiendo los siguientes conceptos y considere que su negociación tiene 2 partes: La primera trata de lo esencial, es decir el problema en cuestión, la segunda y la mas importante pero la menos entendida, se basa en la forma implícita de negociación: Esto es , este consciente primero de negociar como negociara:

• Separe a las personas del problema.
• Concentrese en los intereses, no en las posiciones
• Genere una variedad de posibilidades antes de decidirse a actuar
• Insista en que el resultado se base en algún criterio objetivo

Así pues, iniciamos nuestra reunión difícil (inicialmente) programados para sacar nuestra pasión, e iniciar nuestro viaje en busca de la verdad de nuestros fundamentos, a parte de ello, que mas hacemos?. Revisemos el equipo, 2 por lado, usted 1 y  el otro 4, la cantidad de gente representando ambas partes puede ser ayuda o perjuicio, por cierto también la calidad y experiencia en años en la mesa. Trabaje para entrar a esa reunión parejo en cantidad al menos (y en Calidad de experiencia de ser posible).

Normalmente en una reunión para resolver dificultades (y esa debería ser la premisa) una de las partes expone sus puntos de vista y luego la otra parte el suyo, en algún momento después de ello se inicia un debate o conversación de cierre, buscando resolver la situación. Mas halla de que existan innumerables estrategias de negociación que pueden ayudar. Al menos recuerde estos tips:

• Inicie la reunión declarando que ustedes esta con la predisposición de resolver este tema de una forma justa, basada en principios y no en posiciones extremas.
• Declare que inicialmente que la situación no se trata de personas sino de eventos y realidades.
• Busque generar una línea de eventos que sea concluyente tanto en su exposición como en la de su contraparte, esto es clave, los argumentos utilizados deben generar una línea concluyente de eventos, es decir debe haber congruencia entre cada acción y reacción que se expone como premisa de generación de resultados y situaciones (explicaciones de lo que paso). Si esta línea no es concluyente se debe explicitar: "Lo siento Sergio pero los eventos que relatas no son concluyentes con respecto a la situación que expones y la petición que realizas, dado que xxxx, no implica que yyyyy."
• Por otra parte busque el interés en la conversación de trasfondo de su contraparte y explique el suyo. El cual por cierto debe ser el de una solución justa.
• En no pocas ocasiones el cliente puede generar la clásica escena del bueno y el malo, en donde un representante del cliente hace de bueno (el policía bueno, se acuerda) y otro representante del mismo hace de malo (que presiona y genera ruido y situaciones poco agradables). Deberá estar atento ante este ejercicio clásico. La mejor forma de desarmar esta vieja estrategia es explicitarla como por ejemplo de esta forma: "Estimado Sergio, veo que tu y Juan tienen una diferencia de opinión respecto a la forma de resolver este tema y tal vez con respecto alguno de los puntos de fondo, te propongo reunirnos otro día, una vez que ustedes resuelvan sus diferencias de enfoque".
• Tenga claro que tiene un alto nivel de posibilidades de éxito, en el amplio espectro de la palabra. Esto es de salir de la reunión bien parado y sin atropellar a nadie. Si es que se concentra mas que en su posición, en la forma de jugar el juego de su negociación, si usted logra persuadir a su contraparte sobre las reglas de negociación, esto es las reglas del juego. Entonces usted tiene una ventaja.
• No confunda la relación con el problema, otra variante mas de personas y problemas.Esto es, separe la relación de lo sustancial y concreto de la situación a resolver.
• Algunos expertos negociadores, recomiendan partir diciendo NO, de forma explicita ante ciertas solicitudes base de las negociaciones. No deseche esta opción, pero deberá ser explícitamente explicada en sus fundamentos y ser congruente con una situación justa.

Prepare con anticipación todas sus reuniones de Negociación:

Ahora bien, si cree que todas estas recomendaciones son suficientes para afrontar exitosamente una reunión de negociación, le aviso de su error. El cual por cierto se basa en que deberá siempre considerar  ir preparado a esa reunión. Esta preparación de reunión para negociación deberá considerar los siguientes puntos:

• Genere una lista de sus intereses reales: Aquello que le importa de verdad, sus deseos, necesidades, etc.
• Considere la lista de sus Opciones: Posibles acuerdos que se puedan alcanzar
• Verifique su lista de Legitimidad: Que criterios o precedentes utilizara para convencer o lograr declarar un acuerdo propuesto como justo
• Cual cree usted es la lista de intereses de su contraparte: Que cree usted que es lo que a la otra parte realmente le interesa y preocupa en el corto y largo plazo.
• Genere una lista de temas a y aspectos de Comunicación a declarar: Cuales son los mensajes que quiere transmitir, tiene un listado de estrategias para hacer efectiva la comunicación de sus mensajes.
• Verifique su checklist en el ámbito de las relaciones: Podría ser que si en su negociación, gana su punto de vista se afecte a futuro su relación de largo plazo? y cuales serian esas implicancias?. Trabajara a futuro con algún integrante de su contraparte?, etc.
• Revise su checklist en el ámbito de los compromisos: Tiene claridad acerca de los compromisos que puede esperar al termino de la negociación? Hay mas temas a tratar después que se llegue a un acuerdo entre ambas partes? Esta hablando con la persona que tiene la autoridad real para comprometerse según sus intereses?  

Ya en plena negociación considere estos otros tips:

• Busque los intereses ocultos tras las posiciones.
• Conozca su opción alternativa: Sabe usted cual será su Mejor opción si no llega a un acuerdo negociado?
• Tenga a su disposición todo su abanico de justicia e imparcialidad para sus criterios de negociación.
• Piense en procesos imparciales.

Por otro lado evite los clásicos errores en una negociación poco efectiva:

• No discuta posiciones.
• No achaque responsabilidades a personas (en el peor de los casos a actitudes no a personas).
• Tenga presente que algunos errores de ambas partes se deben a un proceso común de aprendizaje, que a veces generar eventos no concluyentes.
• No piense que una reunión bastara para solucionar el problema, pero una reunión deberá ser suficiente para declarar sus intenciones y su modelo de negociación.
• Por ultimo este dispuesto a ceder, sin comprometer su mejor alternativa de salida no negociada.

2) Acerca de su organización personal y productividad:

Bien, este puede ser el gran problema de muchos ejecutivos a la hora de enfrentar múltiples actividades y compromisos.

Como se organiza usted personalmente?, donde le enseñaron eso? como lo hace?, como se organiza para organizar a otros, o dicho de otra manera como se organiza para ejecutar múltiples proyectos o acciones? Existe una forma mejor que otra?

Durante un tiempo me di contra la pared con este tema buscando la mejor manera para mi. Debo reconocer que es un proceso de mejora continua. Pero algunos tips he encontrado a punto de desaciertos, descartes y gracias a dios buena literatura al respecto, de las cuales les dejo aquí un resumen de lecciones aprendidas (rezo para que así sea):

• Saque de su mente todo eso: Si, así como lo escucha, la mejor manera de lidiar con el stress que todas esas cosas por hacer le generan, es sacarlas de su mente.
• Lo único que necesita son listas y carpetas: Vea usted si son digitales o reales, da lo mismo. El proceso es lo que importa. Deberá tener entonces un repositorio externo a su mente, confiable y seguro, sobre el cual trabajar. Agenda, Palm, etc. Pero será su nuevo proceso de como usar esas bandejas de entradas, procesar esas cosas , proyectos y compromisos lo que deberá ser la diferencia.
• Considere el siguiente diagrama como pilar para este nuevo proceso de organización de las cosas por hacer:

Le gusto el diagrama?, no tiene nada de especial, tal vez lo único es que declara el método base, cosa poco común en ejecutivos organizados. Pero lo mas importante tal vez sea considerar el cajón que dice "Que es?":

Planificación Natural vs Planificación No natural:

A caso me va a decir que usted no puede hacer un sin numero de cosas por que no tiene un método para ello. Ridículo verdad?. Por que en la realidad existe un método natural de planificar sus actividades, puede que este consiente de ello o no, pero sigue en reglas simples las siguientes directrices:

• Define usted primero sus propósitos y principios
• Visualiza sus resultados
• Genera una variedad de nuevas ideas de como hacerlo
• Organiza su acción
• Identifica sus acciones siguientes.

Ahora la pregunta del millón: Cuando fue la ultima vez que al enfrentarse a una tarea o proyecto en su oficina o lugar de trabajo reviso estos puntos?. Por otro lado, esta consciente que en su casa cuando enfrenta una actividad es exactamente de esta forma como la resuelve. Curioso verdad?Volviendo al cajón del "Que es",  y tomando la Planificación natural, es como enlazamos y nos damos cuenta que preguntar "Por que?" y "Cual es el propósito de su tarea", nos da el valor y beneficio de definir el éxito que queremos, genera los criterios para la toma de decisiones, distribuye recursos, motiva, clarifica nuestro enfoque y aumenta nuestras opciones.

Tal como muestra nuestra ilustración anterior, las "cosas" por hacer requerirán un método y proceso para abordarlas, en este método o proceso consideraremos el concepto de planificación natural para buscar y pensar mas en profundidad cada cosa y su propósito, pero no será secuencial. Por el contrario nuestro método antes de procesar nuestra bandeja de entrada construirá nuestra lista de cosas por hacer primero.Nuestro proceso como muestra el diagrama generaran las siguientes listas:

• Una lista de Recopilación "Bandeja de Entrada" (La Primera, de aquí parte usted , antes de procesar su trabajo por hacer)
• Una lista de "Proyectos" (Cosas complejas por hacer)
• Acciones e información con fecha fija (Nuestra Agenda)
• Una lista de "A la espera", (Delegación a otras personas)
• Una lista de "Algún día/Tal vez" (Cosas pospuestas)

Les dejo aquí un par de títulos para ahondar mas en temas de negociación y organización personal, libros recomendables de leer si o si:

"Organízate con eficacia" de David Allen
"Si de Acuerdo" de Roger Fisher, William Ury y Bruce Patton.

Saludos Cordiales a todos
Y espero seguir escribiendo al menos 1 post  por semana.

Javier Urrutia T.

(Fingerprint:clstg-jut-10694774)]]> http://www.misbytes.com/wp/2008/04/14/de-proyectos-y-reuniones-con-clientes-algunos-consejos-prcticos-2da-parte/feed/ 1 http://www.misbytes.com/wp/2007/02/04/de-proyectos-y-reuniones-con-clientes-algunos-consejos-practicos-1era-parte/ http://www.misbytes.com/wp/2007/02/04/de-proyectos-y-reuniones-con-clientes-algunos-consejos-practicos-1era-parte/#comments Sun, 04 Feb 2007 22:42:52 +0000 Javier Urrutia http://www.misbytes.com/wp/2007/02/04/de-proyectos-y-reuniones-con-clientes-algunos-consejos-practicos-1era-parte/ Como Project Manager, o encargado de liderar algún ámbito en proyectos informáticos o de otros tipos. En mas de una ocasión tenemos que enfrentar reuniones con clientes. El como sacarle el máximo de provecho a estas instancias y el como lidiar con distintos tipos de ellas no siempre es tarea fácil.

En general en pocas instituciones de enseñanza, como universidades o institutos técnicos se capacita a ingenieros en el arte de llevar y concretar reuniones exitosas con clientes. Es mas, estoy convencido que muchos otros profesionales tales como "Periodistas", "Sicólogos", "Entrenadores", etc. Están mucho mejor preparados que los ingenieros (y en particular informáticos) en esta área practica del saber hacer. Las Reuniones son siempre instancias de relación con el cliente que son imprescindibles para el éxito de los proyectos si es que sabe llevarlas a buen termino (con objetivos y propósitos). Pero en otros casos pueden ser simplemente el inicio de muchos problemas, en particular cuando no son mayormente planificadas o registradas.

En este articulo lo invito a conocer algunos tips y herramientas que a punta de errores, desaciertos y teoría del descarte, he aprendido en relación a "Reuniones con Clientes". Todavía me falta bastante por aprender del tema, pero aquí hay algunos puntos de interés que comparto ahora con usted. Espero que en conjunto con sus comentarios. Podamos tener un set común de tips, creados en base a mucha gente como usted, en relación al "Saber hacer" una buena reunión con clientes. Así pues..

Veamos que ámbitos en relación a Reuniones de proyectos con clientes, debe considerar siempre, antes de que ella se realice:

Objetivo y Propósito :

Toda reunión de trabajo con clientes debe tener un Objetivo y Propósito, esto es, debe cumplir una meta previamente definida y dicha meta debe estar en concordancia con algún ámbito en pro del éxito del proyecto. Así pues, para definir el objetivo y propósito de una reunión de trabajo deberá clasificar estas reuniones en categorías que le permitan mantener siempre en mente el origen y destino de la reunión de trabajo. Según mi experiencia en el tema (reconozco ser solo un poco mas que principiante) existen al menos desde mi punto de vista las siguientes categorías:

1. Reuniones Comerciales
2. Reuniones de Control
3. Reuniones Políticas
4. Reuniones de Diseño

Las Reuniones Comerciales: Existen de muchos tipos pero la mayoría de la veces estas pueden tener por objetivo lograr la aceptación del cliente de algún acuerdo que revista un compromiso, un pago adicional, o un cargo a nivel de Horas Hombre no contempladas en el proyecto original. Para facilitar este tipo de reuniones el concepto de control de cambio debe ser explicado al inicio de los proyectos, acordado entre las partes porque es una realidad que siempre aparece en menor o mayor grado. En mi experiencia una forma sutil y practica de lograr una aceptación de controles de cambio es acordar cuando estos surgen, un pacto de caballeros (formalizándolo en minutas) que genere al final del proyecto una factura adicional. La razón de por que no cobrar un control de cambio cuando se genera, es meramente política. No es factible o resulta muy difícil para un jefe de proyecto del cliente tramitar un pago extra antes del cierre del proyecto (pongase en su caso). Pero si es mas fácil para un administrador de parte del cliente, justificar un pago adicional al presentar el producto final terminado. Usted puede acordar la forma de registrar este esfuerzo adicional e informar periódicamente a su contraparte como las HH adicionales se acumulan. La idea es llegar a un consenso al final del proyecto y generar la factura adicional. No se engañe, no podrá de esta forma facturar el 100% de sus HH adicionales consumidas, pero si podrá en un escenario difícil para los controles de cambio, lograr un alto porcentaje de recuperación de este esfuerzo adicional, y si aplica una tarifa adecuada podrá considerar exitoso su manejo de HH adicionales.

Las reuniones comerciales: En otras ocasiones se gatillan por crisis de distintas naturaleza en los proyectos. Tal vez sean estas las mas difíciles de tratar. Considere que los objetivos clásicos de una reunión de tipo comercial es traspasar y transparentar los costos que su empresa incurre, cuando acciones no consideradas (normalmente gatilladas por su cliente) se generan o dejan de generarse. No hay recetas para enfrentar este tipo de reuniones de crisis. Mi consejo es concentrar su esfuerzo en transmitir sus dificultades y la posición en que se encuentra dado los eventos e historia de lo ocurrido. Puede utilizar para ello , el hecho de transparentar sus costos y como dado los hechos se encuentra en una posición no sostenible. Genere un esfuerzo en transmitir su condición actual, y no entre en evaluaciones, transmita su condición en base a hechos. Y considere firmemente que tal vez el escenario mas posible sea un consenso en donde ambas partes ganen o pierdan un 50% de sus expectativas. Temas que puede usar para fundamentar sus costos adicionales pueden ir desde, poca disponibilidad de su cliente (imposibilidad de toma de decisiones), cambios en la especificación una vez iniciado los desarrollos, lucro cesante (Horas Hombre que los desarrolladores,analistas u otros pierden de usar, producto que no tienen que desarrollar dado la inexistencia o falta de especificaciones técnicas particulares), etc. En ocasiones su cliente podrá no comprender sus explicaciones, puede usted usar en este caso analogías de la vida diaria para transmitir mejor su posición, pero deberá elegirla muy bien y ponerse critico ante ella para ver sus puntos débiles y preparar un contra argumento de ser necesario.

Las Reuniones Comerciales: También pueden ser obviamente de preventa y venta, pero para efectos de este post, solo considerare reuniones de proyecto propiamente tal (ya iniciado).

Las Reuniones de Control: Tienen la finalidad de llevar la cuenta del avance del proyecto, lo mejor por cierto es utilizar la clásica lista de tareas pendientes, terminadas y por realizar. En base a la mítica Carta Gantt. Aquí unos Tips rápidos ente esta tan vilipendiada entidad de "La Carta Gantt", y otros temas varios de control y avance de proyectos:

• Una mala Carta Gantt es mejor que ninguna.
• La mejor Carta Gantt especifica las tareas en base a horas, y no en base a días, e incluye las recursos humanos asignados a cada tarea.
• Una Carta Gantt sin ruta critica no sirve de nada.
• Los controles de cambio, deben ser generados no solamente cuando algo cambia en términos de cosas nuevas, sino también cuando algo no puede hacerse en el plazo original (Lucro Cesante).
• Tome nota de todas sus reuniones, compartalas con su cliente y especifique que ante un par de días sin comentarios de ninguna de las partes, las notas y acuerdos quedaran a firme (Pasan a ser parte del contrato, en términos de acuerdos varios)
• Sea innovador al momento de registrar sus reuniones, use las herramientas que mas le acomoden, por ejemplo yo grabo el audio de las reuniones (a veces esto no siempre es posible).
• Las minutas o notas de reuniones que nunca debe dejar de registrar en primer lugar son TODAS!, pero un crimen seria no dejar registro de aquellas que guardan relación con controles de cambio, fechas de actividades importantes del proyecto, temas de facturación u otras tales como entrega de materiales, etc.
• La mente humana es frágil, registre, anote, escriba, grabe, vea usted el como, pero no deje de hacerlo.

Las Reuniones Políticas: Si sus reuniones no son comerciales netamente, ni tampoco de control o diseño de la solución que conforma su proyecto, entonces lo mas posible es que sea una reunión política (en el buen sentido de la palabra). Así pues puede ser tan sutil como una reunión de presentación de personas (quien es quien y que poder declarativo posee cada persona), hasta tan compleja como la toma de decisiones criticas que podrían generar cambios de gente, cliente o montos de facturación. Mi consejo en este tipo de reuniones, es nunca ir solo, siempre valla con alguien mas, de preferencia con mayor experiencia que usted. A veces una salida elegante es mejor que una continuidad financieramente desastrosa.

Las Reuniones de Diseño: Antes que nada usted debe responder la siguiente pregunta cuando valla a tener una reunión de diseño. Es el diseño en particular sobre el que usted trabajara muy subjetivo?. Por ejemplo: el diseño del arte de una solución, o la disposición de los campos grillas y otros elementos de la aplicación. Si la respuesta es si, usted esta ante los diseños mas peligrosos. Los diseños donde la opinión de su cliente son mas difíciles de contrarrestar con argumentos técnicos. El peor caso cuando de diseño se trata es por ejemplo la gráfica de su solución (el arte). En este escenario mi recomendación es deje todo el diseño posiblemente subjetivo en modalidad "Time Material" (Cobro por HH y no a precio fijo) y toda la parte técnica de la solución la cual si puede prever en costo, cóbrelas como precio fijo, ya que en general es como los clientes prefieren pagar. Sus diseñadores html, flash y otros similares se lo agradecerán. Si esto no es posible. Entonces deberá hacer su máximo esfuerzo en el control de cambios de esa área, y deberá definir "1" solo cliente en el ámbito de diseño subjetivo y no varios, y deberá preocuparse que esto se cumpla en la practica. No sirve si para este tipo de diseños, se le asigna un cliente especifico pero en la reuniones de presentación, control y diseño (pre-diseño) opinan a parte del cliente "1" otras 10 personas. Entendió verdad?

Las Reuniones de Diseño : Dejando del lado aquellas de tipo artístico o subjetivo, las reuniones de diseño son en general y mayormente reuniones de diseño técnico, en estas su equipo y usted deberán tener la mente lo mas abierta posible. Escuchar las expectativas de su cliente es algo imprescindible. No basta con cumplir al pie de la letra la propuesta entregada. Muchos clientes no entienden los detalles finos del producto final que resiviran. Mi consejo aquí, es trabajar con productos que permitan visualizar al cliente el rumbo y forma que tomara la solución final. Herramientas como Axure o similares le pueden ayudar de gran manera a eliminar dolores de cabeza en las ultimas etapas de un proyecto tecnológico. No escatime esfuerzos gráficos a la hora de mostrar y visualizar con su cliente la solución final, power points, animaciones, gráficos, esquemas, story boards, todas son validas y útiles. De lo que se trata aquí es que el cliente sepa la mas posible antes de recibir el producto que este será lo que el pensaba obtener y no otra cosa.

Las Minutas y otras Herramientas :

Reconozcamos que la idea de realizar minutas después de cada reunión de manera de generar un resumen de compromisos y acuerdos no resulta una idea mayormente atractiva. Como? entonces, poder generar un registro de las reuniones de manera mas eficiente. La respuesta consiste en generar la minuta "en" la reunión y no después de ella. Para esto existen herramientas que pueden facilitar tal trabajo. Si a esto agregamos el concepto de minuta efectiva, la cual consiste en contraposición a una clásica minuta en un resumen simple de acuerdos y compromisos, participantes y alguna información adicional importante, podemos generar un documento de forma bastante mas simple y útil. En particular yo uso un producto de Microsoft llamado "One Note" puede bajar un trial del producto si lo desea. Una de las características principales de este concepto de herramienta es que no esta orientado a una minuta tradicional, sino a la generación de notas de reuniones, mas simples y efectivas, de esta forma usted puede agregar elementos de distinta naturaleza para conformar una nota-minuta de reunión. Mi tipo preferido de estos elementos son los registros de audio de la reunión. Así por ejemplo, después de una reunión de trabajo genero el documento en formato Word (una característica de OneNote) y adjunto el registro de audio de la misma (Normalmente todo notebook trae hoy en día un micrófono que permite realizar efectivamente esta operación). Claro no siempre podrá realizar esto, deberá al menos consultarlo con su cliente en la primera reunión.

El Cliente :

Sabe usted quien es su cliente?. Primera pregunta básica que deberá realizar cuando inicie reuniones de proyecto. No es trivial la pregunta. Puede ocurrir que su cliente no sea quien parece ser. Y peor, puede ocurrir que su contraparte del lado del cliente no tengo el mas mínimo poder declarativo (poder para la toma de decisiones). Mi consejo aquí, es observe a la organización, fijese en otras reuniones con otros proveedores si puede, quien habla primero y quien después, quien es la persona que influencia a otras en las decisiones practicas y finales. Los actores que deberá reconocer son. Quien es su contraparte valida (la informal), quienes son influenciadores de toma de decisiones (deberán ser sus mejores amigos) y quien es realmente su cliente, cuales son sus preocupaciones mas relevantes. No solo de proyectos, estamos hablando aquí de generar empatías sociales para maximizar la comunicación efectiva al interior de cada reunión de proyecto.

La conversación de transfondo :

Concordara conmigo que en ciertas reuniones, usted pude iniciar una escucha mas halla que lo que las palabras explicitas dicen, esto es, conversaciones que por lo delicado de los temas no siempre se dan con franqueza. El concepto de diplomacia se me viene a la mente. No obstante ello, la conversación de transfondo va mucha mas halla, se trata de descubrir que cosa están en juego en la conversación, que tema no se esta explicitando, pero del cual gira mas del 50% de las otras conversaciones que están dando. Algunos ejemplos de conversaciones de transfondo son: Desconfianza, Temor a lo desconocido, Ego, etc. La importancia de reconocer el tipo de conversación de trasfondo que se esta dando en una reunión le permitirá entrar en la conversación con la ventaja de saber donde hacer énfasis en sus opiniones para enlazar de forma positiva en las preocupaciones de transfondo que hacen girar la reunión en torno a conversaciones que pudiesen no ser su objetivo, pero si el de su cliente.

El Lenguaje del Cuerpo :

Tal vez sea este uno de los puntos mas relevantes cuando usted inicia reuniones con nuevos clientes o nuevos actores, el concepto de Rapport nacido desde PNL puede ser de mucha ayuda para usted. Para entender mejor que significa el Rapport, considere la imagen clásica de una pareja "afín", que usted observa en un café. Como conversan?, como se miran y como actúan. Que observa? o como reconoce esa afinidad que ambas personas se expresan con el cuerpo?. Muy simple, ambas están realizando los mismos gestos y actitudes físicas, pero sin darse cuenta, están en un estado de Rapport o sincronismo físico y mental. Las técnicas de PNL ayudan a través de las técnicas de Rapport a generar afinidad entre personas desconocidas, cuando aquella que domina la técnica de Rapport empatiza primero a un nivel físico y luego a uno mental, asimilando gestos de la contraparte, posturas físicas, velocidad del habla, etc. Considere técnicas como esta o similares para generar una buena primera impresión. Ojo no se trata de imitar el comportamiento físico de su contraparte, se trata de sincronizar ritmos físico para que los mentales puedan confluir en consensos y simpatía. De lo que se trata finalmente es que tanto la contraparte como usted generen empatías mutuas, que faciliten la reunión.

Bueno espero que algo de lo que leyó aquí le ayude, en próximos post trabajare otros ámbitos de reuniones de proyecto. Lo invito a indicarme que temas relacionados he dejado de lado, por olvido o ignorancia. Usted puede comentar lo que desee en relación a este tema tan interesante para todos los que realizamos alguna labor de PM, como lo son las famosas reuniones de proyectos.

Saludos Cordiales
Javier Urrutia.

En nuestra vida laboral, hay momentos en donde nos cuestionamos acerca de nuestro rol dentro de la organización, ello se puede deber a diversas razones o circunstancias, en general a veces lo anterior se debe simplemente a la multiplicidad de tareas que se deben asumir buscando cumplir y asegurar que ciertas cosas ocurran, que los proyectos terminen a fecha, que el cliente quede contento, que los trabajadores a su cargo estén conformes y contentos con el ambiente laboral, etc.

En un punto del lidiar con las múltiples responsabilidades que enfrentamos en el rol y trabajo que cumplimos, surge una pregunta que puede ayudarle si la contempla detenidamente y con mente abierta.

Para que le pagan a usted?

En este articulo profundizare esta pregunta, que tal vez le parezca trivial, si ese es su caso bien por usted, pero si no es así, o se lo ha cuestionado en algún momento, o simplemente le da curiosidad tal pregunta, permítame mostrarle que pienso al respecto, a la vuelta de pagina…

Bien, digamos que en un principio la respuesta a la pregunta para que le pagan se la da la persona que lo contrato. No obstante muy pronto se dará cuenta que eso en el mejor de los casos es solo el principio, y a veces incluso el rol no especifica el trabajo, con suerte y mucha suerte solo definirá algo de su ámbito de responsabilidad.

Y entonces para que le pagan a usted realmente?

Yo personalmente me hecho esta pregunta un par de veces, en esas ocasiones el entrar en esa dinámica de preguntarse tal cuestión creo, a sido en general en ocasiones de mucha presión y trabajo. Pienso que no es en ningún caso algo negativo preguntarse tal cosa. Al final las respuestas que me generado después de mucho análisis y conversaciones con otros me han ayudado a retomar y mejorar las condiciones y acciones para quitarme algunos estados de animo no muy positivos. Pero plenamente validos.

Como Project Manager, hay un numero de temas y responsabilidades que asumo son generales para toda persona a cargo de equipos de desarrollo de software y de forma intuitiva digamos que lo principal es:

1. Trabajar para que sus proyectos sean exitosos
2. Trabajar para que sus clientes sean exitosos
3. Trabajar para que sus trabajadores sean exitosos

Tal vez esto 3 puntos básicos le ayuden a desarrollar mejor sus metas y propósitos, pero solo fueron los primeros puntos que yo y otros encontramos a la pregunta inicial.

No obstante no responden el para que le pagan, sino en que enfocarse del trabajar. No es lo mismo, finalmente después de mucho pensar llegue a que en mi opinión inicial:

A usted le pagan, para que tenga clientes!

Por cierto esos clientes son tanto externos como internos, siendo prioritarios los primeros para poder contar con los segundos. También considere que sin los segundos no podrá responder a sus clientes externos de forma correcta.

Tal vez mi aproximación inicial del, para que le pagan, no sea de su mayor agrado o sintonía. Pero considere fríamente que al final de los finales a usted le pagan, por que hay clientes que pagan a su empresa y que le paga finalmente a usted.

Dada esa premisa inicial como respuesta, en el sentido que a usted le pagan para que tenga clientes, seguí dándole vueltas al tema y pensé. Entonces para que no le pagan?

1. No le pagan para que usted sea feliz en su trabajo, aunque prefiero trabajar en labores que me dan un sentido de realización, en ciertas ocasiones (y espero pocas) deberá hacer cosas que no me agradan, tareas tediosas, asumir responsabilidades que no son propias de mi rol, pero que deberé tomar por el bien del proyecto, trabajar los fines de semana, etc. Cosas que en general no me hacen muy feliz.
2. No le pagan para que le agrade su cliente. Esta claro este punto verdad?. En ocasiones ya sea por la ignorancia propia del cliente (Comprensible) o simplemente por diferencias de personalidad, usted preferirá salir corriendo lo antes posible de esa reunión. No obstante, no le pagan para que le agrade su cliente cierto?
3. No le pagan para que sus trabajadores lo amen por su carismática personalidad o por su cercanía social y su gran compañerismo. Que decir del día que le toque despedir a alguien de su equipo, definitivamente eso no es agradable, no obstante el no hacerlo podría significar en un futuro posible el fracaso de un proyecto y por ende un aumento en el riesgo de los demás trabajadores y su fuente laboral.

Y no obstante todo ello, siempre estamos haciendo un esfuerzo para ser felices en nuestro trabajo, para entender mejor a nuestros clientes y para tener las mejores relaciones con nuestros trabajadores. O al menos reconozcamos que serian estos últimos puntos preferibles. Y por que?. Se lo ha preguntado alguna vez?. Por que pone usted esfuerzo en estos puntos si no le pagan para ello?

Permítame una simple hipótesis:

Usted hace cosas en su trabajo aunque no le paguen por ello, por que usted trabaja para algo mas que para que le paguen! . Puede parecer obvio pero considere todos estos temas que hemos conversado en este post.

Es mi hipótesis, que mayormente si usted en algún punto de su carrera se ha cuestionado el para que le pagan, es por que su trabajo le esta exigiendo algo mas, en esa área o ámbito para la cual a usted NO le pagan. Y como es esto?

Muy simple, usted esta en un proceso donde por su perfil, esta creciendo y eso puede resultar por el nivel del cambio requerido, algo incomodo, o lo están ayudando a crecer (y eso a veces molesta más). Otra opción ante tal estado de animo, es que usted renuncie a su empresa. Pero considere antes si el problema es suyo o de su empresa. Si la respuesta es la primera, entonces tiene sentido el que se cuestione, pero la acción a realizar no pasa por evadir temas, responsabilidades o tareas que no le agradan.

Escribo este post después de casi 2 meses sin escribir algo aquí. El por que de ello?. Bueno, durante este tiempo he tenido que enfrentar con mi equipo la salida al aire, primero como marcha blanca y luego como etapa de producción inicial, de un sistema informático complejo del cual soy responsable, no solo en el ámbito técnico, sino también en el ámbito político y personal. El hecho es que me ha exigido mucho y creo que en mas de algún momento del mismo, me he preguntado el por que hago lo que hago, cuando ello no es necesariamente lo que debería hacer. Cuestionarse su trabajo, sus acciones y su tiempo, no es para nada algo negativo, podría ser un buen punto de partida para darse cuenta que aun le queda mucho por aprender.

Finalmente quiero compartir con usted mi conclusión final acerca del reflexionar "Para que le Pagan". Definitivamente no solo es por dinero. No solo es por algo que debería gastarle hacer, aunque ello no siempre será así. Lo mas importante podría ser no "Para que le pagan" sino donde trabaja, con que tipo de personas, y cual es la historia que en su trabajar usted esta creando.

Y usted que opina?, como se ha sentido al terminar una etapa importante
de un gran proyecto?. Al final aprendió algo mas que de tecnología?
Me gustaría saber, en su caso, como fue….? y que mas aprendió…?

Saludos Cordiales
Después de un largo proyecto, que recién inicia su vida en producción.
(Por cierto, ahora tal vez puede escribir con algo mas de periodicidad…)

Javier Urrutia T.

En este post quiero hacer un breve análisis de lo que significa migrar sistemas informáticos, compartir con ustedes mi experiencia en el tema, y dar algunas recomendaciones básicas al respecto. Comentare también algunas buenas practicas y donde deberá hacer énfasis para minimizar los riesgos de proyectos de este tipo. Obviamente una buena metodología o recomendaciones no aseguran que todo salga bien, solo aseguran que usted realizo o se preocupo de todos los ítems que debería haber considerado.

Veamos entonces donde hacer el énfasis si usted es el responsable de una migración de sistemas informáticos. Lo primero será…

Considerar que este articulo se enfoca principalmente para aquellos proyectos de migración de sistemas core o principales, donde ya existen versiones y data de sistemas antiguos que desean ser remplazados.

Como una imagen vale mas que mil palabras considere la siguiente figura como aproximación general de una metodología de transición de sistemas informáticos empresariales (Puede hacer click para ampliar la imagen):

Como puede observar en la figura superior, el patrón de transición de sistemas deberá orientarse en general a la descontinuación y reemplazo de módulos, servicios o subsistemas por aquellos que en su totalidad considera el nuevo modelo. En este punto es correcta la afirmación de que una migración de sistemas puede ser evolutiva o incremental, en particular para sistemas complejos y mutí relacionados, como por ejemplo ERPs. Sin embargo existe una diferencia sobre a que nivel estamos hablando al considerar el tamaño mínimo de las piezas y partes que incrementalmente serán migradas.

Idealmente es aconsejable migrar evolutivamente primero servicios y luego aplicaciones o módulos. Sin embargo en situaciones donde los sistemas legacy no soportan interfaces del tipo webservice o similares esto es mas dificultoso. Pero siempre es aconsejable en este punto que los tamaños de cada pieza a migrar sean lo mas pequeño posible, sin entrar en riesgo operativo al realizar dicho reemplazo.

El por que es correcta la afirmación del párrafo anterior, radica en el riesgo potencial de mas líneas de código presentes en un modulo en comparación con aquellas presentes en un servicio. Sin embargo es imprescindible considerar en el escenario de migración de servicios o partes pequeñas, que dichos servicios o piezas pueden impactar en varios módulos al mismo tiempo. Por ejemplo el pack de servicios relacionados a cuentas corrientes, este pegara tanto en los sistemas de venta como en los sistemas de créditos de una solución empresarial.

Así pues deberá primeramente realizarse un estudio completo de todas las partes de los sistemas actuales, llegando a validar dichos impactos haciendo estudios de observación de los propios códigos y flujos de módulos y sub-partes de la solución.

En este punto quiero tocar un tema altamente significativo en el éxito de un proyecto de migración de sistemas empresariales. Este punto tiene relación en cuanto al governance de este tipo de proyectos. Es poco probable que un proyecto de estas características llega a tener éxito si no considera su empresa al menos una clasificación que separe la operación tecnológica de las soluciones informáticas de la gerencia de desarrollo de nuevos proyectos.

• Gerencia de operaciones tecnológicas: Departamento encargado de darle continuidad operativo a todos los sistemas vigentes o legacys de la empresa, esta gerencia solo se preocupa del "hoy", del soporte y del "ahora" de los sistemas computacionales, no del mañana o de los nuevos proyectos en general.
• Gerencia de desarrollo tecnológico: Departamento con personal independiente focalizado en el desarrollo de las nuevas soluciones tecnológicas. Esta gerencia no trabaja sin consultas a la gerencia de operaciones, pero en general evita quitarles tiempo al personal operativo de soluciones tecnológicas al interior de la empresa.Tiene una carpeta de proyectos o sub proyectos y el control de los mismos y sus costos asociados. La priorización de ellos esta definida a nivel estratégico de la empresa

Así pues considere la siguiente figura en relación a los actores y la cantidad de ellos, su importancia y su impacto en proyectos de migración de sistemas (Puede hacer click en la imagen para aumentar su tamaño):

Puede ver en la figura que actores e ítems debe considerar al momento de la planificación de la migración, énfasis en los componentes fundacionales de su sistema antiguo y aquellos actores que los soportan o utilizan, alternativas de negocio para estos cambios manteniendo los objetivos de negocios y en concordancia con la futura visión de negocio de la empresa.

Pero el punto mas importante a la hora de migrar su sistema informático a otro, será sin lugar a dudas en el ámbito operativo, la migración de datos. Este debería ser casi un capítulo aparte y llevar una planificación adicional dentro de la totalidad de la migración de sistemas.

En algunos casos de nada servirá migrar sistemas si no se pueden reutilizar parte o la totalidad de los datos antiguos, en otros casos esto no será de mayor importancia para empezar pero deberá sin duda planificar una migración incremental de la data histórica. De otra forma comparaciones a nivel de informes, cálculos en base a proyección de varios años de data, o otros temas relacionados con la data antigua no serán viables.

En general estas recomendaciones son de sentido común y de experiencia real. Pero existe otro set de recomendaciones o ítems a considerar poco vistas en las practicas de migración. Le comento aquí algunas de mis preferidas:

• Si usted esta migrando de sistemas informáticos del tipo cliente servidor de primera generación, esto es de sistemas cuyos clientes corre desde archivos ejecutables (*.exe) con bases de datos tipo SQL en un repositorio central. Hacia un modelo WebEnabled donde su cliente corre en un browser y la ejecución de procesos de interfaz se ejecuta en un servidor Web, que tiene por detrás otro servidor donde permanece una base de datos SQL como repositorio, considera las siguientes puntos:
  • El modelo de cliente servidor .exe puede realizar operación con conexiones abiertas entre pantalla y pantalla, es decir el tipo de conectividad a su repositorio esta mas cercano a un modelo sincrónico. Por el contrario un modelo WebEnabled debe ser un sistemas mas cercano a algo asíncrono en el sentido que cada pantalla se conecta al repositorio extrae datos y se desconecta. Por lo tanto en el intervalo posterior puden surgir situaciones que en el modelo antiguo no se contemplaban, como por ejemplo validaciones para asegurar que los registros a actualizar, sigan existiendo al iniciar el proceso de escritura.
  • En el modelo cliente servidor .exe, al mantener entre pantallas la conexión abierta usted no administra el concepto de sesión, en web enabled cada pantalla se conecta y desconecta, permaneciendo la mayor parte del tiempo desconectada de su repositorio, por lo que deberá implementar o utilizar un alguna estructura de manejo de sesiones vía GUID u otra similar para distinguir a ese cliente como el mismo que se desconecto anteriormente y darle continuidad a su sesión.
  • Es recomendable que si puede reutilizar su repositorio original mas algunas mejoras, lo haga versus la alternativa de un repositorio y cliente nuevo, esto le permitiría migrar en 2 fases, primero la capa 1 o pantallas, y luego el repositorio, si al definir su capa 1 se abstrae usando un modelo de servicios entre la capa 1 y su repositorio, la segunda fase. Esto es, la de migrar su repositorio a un repositorio nuevo, distinto o mejorado, será mas fácil ya que sus servicios le darán una mejor medición del impacto de los cambios, deberá por supuesto ajustar su capa 1 y servicios, pero ya los tendrá reconocidos y podrá con las mejoras en su repositorio mejorar también el rendimiento y funcionalidades de sus servicios o generar funcionalidades plus por sobre las originales de sus servicios, de manera de suavizar mas aun la migración.
• Pero si por el contrario su migración es mas dura, y planea cambiar de un modelo de .exe a otro totalmente distinto tipo ERP WebEnabled, entonces considere algunos tips como estos:
  • Planifiqué el governance del proyecto con 2 tareas fundamentales: migración de aplicaciones, módulos y funcionalidades. Y migración de datos.
  • Según el modelo de su ERP existen módulos que pueden ser implementados primero que otros y de menor impacto. No es lo mismo migrar el modulo de RRHH que el modulo de Inventario. El primero no se relaciona con la venta de productos, pero el segundo deberá tener implementados los módulos de Contabilidad, y otros similares que en un ERP son base para otros módulos.
  • Planifiqué la fecha de migración con el periodo de menores ventas: Vacaciones u otros donde el nivel de clientes o transacciones sea el mínimo. Ni se le ocurra planificar una migración en meses cercanos a navidad o fin de año. Recuerde que para muchos rubros ese periodo puede significar el hasta el 30% de las ventas del año, y sin sistemas eso es casi un crimen.
  • Administre las expectativas reales con sus clientes, que funcionara, que no y los problemas que tendrán. Muestre o haga ensayos donde se concientise el tipo de problemas que pueden surgir y cual será el Plan B, en esos casos.
  • Priorise los puntos de Ventas, Vendedores e Inventarios o Productivos, por sobre otros de menor importancia de continuidad operativa de ventas si va contra el tiempo.
  • Si el tiempo le acompaña y su planificación fue bien hecha, debería considerar un plan piloto, es decir pruebas en paralelo al sistema actual, pero solo para efectos de validación de comportamiento de sus nuevos sistemas.
  • Genere un ambiente de pruebas para sus usuarios, de manera de capactitarlos con un set de datos distintos al real.

Considere hacer énfasis en su migración en otros temas relevantes o mas genéricos como los que se detallan en el siguiente cuadro, si puede generar equipos coordinados que desarrollen estos temas doblemente mejor.

Cada uno de ellos es un mundo a parte y tiene importancia directa y relacionada con los demás, Por ejemplo su maestro de productos, su nuevo plan de cuentas contables, su plan de pruebas, las nuevas características de usabilidad que dispondrán en el nuevo sistemas, etc.

Finalmente considere que existen migraciones y migraciones, algunas pueden ser muy simples y otras como renovaciones de arquitecturas y sistemas totales muy complejas. Sepa bien en que nivel de migración esta parado. Y cuales son las características propias del nivel que enfrentara y sus riesgos. En el siguiente diagrama puede ver algunas relaciones al respecto. Puede hacer click para ampliarlo:

Finalmente mi mejor recomendación para una buena migración de sistemas, es la planificación detallada de cada fase, etapa, modulo, pantalla y funcionalidad que migre, invierta hasta el 50% del tiempo de su proyecto en esto si lo requiere, no será tiempo perdido. Trabaje con herramientas orientadas al usuario final, por ejemplo realice sesiones de storyboard usando herramientas como Axure o similares. Planifiqué, planifiqué, planifiqué!. No planifiqué en días, planifiqué en horas (como detalle máximo), use el Project como visión general y en detalle de su proyecto de migración, pero use mucho mas el Excel para el control del dia a dia de los trabajos (pero en Horas a Horas consumidas y por consumir) .

Ahora, finalmente considere que políticamente un plan de migración en general pude tener costos políticos para los responsables técnicos de llevarla a cabo, asegúrese entonces con contar con el apoyo necesario en esos niveles (estratégicos). No bastan palabras.

Me gustaría saber algo de su experiencia personal en el tema de migración de sistemas, ayudeme a ver si agregamos ítems a este pequeño resumen de donde hacer énfasis y que temas considerar a la hora de migrar sistemas empresariales, cual a sido su experiencia personal en migración de sistemas empresariales?.

Buena suerte! en su migración de sistemas
(Pero mas Planificación!).

Javier Urrutia

Se ha preguntado usted alguna vez, por que ciertos profesionales son mas exitosos laboralmente que otros, o por que pareciera que ciertas personalidades son mas adecuadas para ciertas profesiones, como por ejemplo los doctores?, en el caso de la medicina. Bien, resulta que en el ámbito del desarrollo de software también aplica. Y no solo con un tipo especifico de personalidades, sino con varias de ellas (por suerte). Mi intención con este articulo no es darle indicaciones acerca de como cambiar su personalidad para que sea en el ámbito del desarrollo de software laboralmente mas exitoso (o para imitar lo necesario para ello). Seria una tontera pensar que eso es posible. Aunque conozco casos de auto-engaños muy parecidos.

No, lo mío en este articulo es mostrarle cierto tema que podría redundar en aprovechar de mejor manera algo que, intuitivamente usted ya sabe, solo que aquí le vamos a poner un nombre (Primera virtud de un buen programador). Y por cierto no lo invente yo, otros antes ya se dieron cuenta. Le suena la palabra "Pragmático", etimológicamente Pragmático del latín pragmaticus" (hábil en los negocios), la cual está derivada del griego "prattein" que significa "hacer". La actividad pragmática es la actividad del artífice. Veamos de que se trata todo esto…

Quiero antes que nada dejar claro que este es mi punto de vista personal y particular (influenciado por personas con mayor experiencia que la mía, y de libros relacionados), respecto a cuales características son las que mayormente se valoran por las empresas que reclutan profesionales de la informática, ya sean programadores, desarrolladores, arquitectos de software o consultores tecnológicos. Ahora, creo que después de casi 10 años de experiencia laboral y estando en una posición donde muchas veces me ha tocado asumir la responsabilidad de contratar a alguien. Algo de mi punto de vista puede ser de valor para usted.

Esta claro que según el cargo, son distintas las necesidades de conocimiento que una empresa espera de una nueva contratación. Asi que en este post en particular solo me referiré a profesionales mas cercanos a la parte técnica de proyectos informáticos. Dejare para otra oportunidad y post, el caso especifico de administradores de proyectos, o Project Manager en soluciones informáticas.

Estas son según mi experiencia las características que mas buscan las empresas de software en sus programadores:

• Buscan al Programador Pragmático : Esto es un programador con cierto sentido de negocios en su mente, un programador que prefiera salir al aire con un producto no perfecto pero salir antes al mercado. Otro ejemplo: Un programador que prefiere comprar un par de componentes o una solución completa para integrarla con sus propios desarrollos de manera de optimizar plazos y costos. En otras palabras un programador que tenga presente que al cliente no le preocupa la tecnología fina, sino mas bien el resultado final.
• Buscan al Programador con buena SUI (Social User Interface): Espero no ser peyorativo al respecto, pero en general no son pocas las veces en que un buen programador tiene el complejo de genio. Esto es, una persona que es tan excepcional en su conocimiento técnico que su capacidad de inteligencia emocional y social es tan baja que prácticamente esta condenado a trabajar solo. Esto, en el mundo global de hoy no es aceptable. Se asombraría saber el gran porcentaje de Programadores que tienen algún grado de dificultad con su SUI y que por ello son rechazados en muchas empresas. Por ello es tanto a mas valorado en las empresas de hoy el contar con buena interfaz (SUI) como con una buena capacidad técnica. Algunos programadores creen que ante su genio, la empresas no podrán tener mas que lidiar con su idiosincrasias y particularidades personales. Lo que podría ser cierto en muy pocos casos, y le aseguro que ese tipo de trabajadores una vez que cumplen con las metas de una empresa son dejados de lado (entendió verdad?). En contraparte piense en un programador que no tiene muchas habilidades técnicas pero por el contrario tiene una personalidad de gran comunicador y vendedor. Ese tipo de trabajadores sin tanto o mas escasos que los genios técnicos, son de hecho genios sociales o comerciales, como usted quiera verlos.
• Buscan al programador con valores: Que valores?, bueno en general buscan valores globales, entre ellos y sin limitarse a estos buscan estos principios personales:
  • Ética Indiscutible: Es cierto en muchas empresas que el discurso hacia el cliente puede ser uno, y al interior de la empresa otro. Ahora comercialmente esto es parte de las reglas del juego en muchos casos, pero el tener claro cual es el limite en el sentido de los efectos negativos en el cliente y la propia empresa son vitales, y en ultima instancia se busca a personas con criterio y sentido común, y esto por supuesto aplica en la Ética Indiscutible. Piense en estas palabras, honestidad y transparencia.
  • Compromiso con el éxito de sus clientes: A veces hay que hacer sacrificios, generalmente al final de los proyectos es cuando mas se nota. Preocuparse por sus clientes primero, después del costo (pero sin ser criminal), si después de su sacrificio su empresa no lo reconoce, ese es otro problema, no sacrifique a su cliente por problemas con su empresa. Piense que ese cliente podría ser su cliente en otra empresa o en otro trabajo.
  • Flexibilidad y agilidad con su propósito: Tal vez uno de los puntos mas conflictivos, el que cambien los requerimientos no le hace gracia a ningún programador, pero deberá entender que estos llegara, algunos se filtraran y otros no, piense en los requerimientos no como algo inamovible, sino como evolutivos. Requerimientos Evolutivos vs Requerimientos estáticos.
  • Sentido de Equipo: Si no a trabajado nunca en equipo, difícilmente podré explicarle que significa, pero si le gusta el deporte y a jugado fútbol y su equipo a sido exitoso tal vez me entienda mejor. Use su intuición. La comunicación ante todo (ojo nadie dijo que era fácil, y una cosa es decirlo y otra hacerlo)
  • Respeto por el individuo y por la diversidad: Sin comentarios, en un mundo global no puede darse el lujo de discriminar.
  • Responsabilidad y Disciplina: Permítame detenerme en este punto, no quiero enfatizar el lado de la responsabilidad,creo que eso se explica solo por la misma palabra. Pero otra cosa es la disciplina, y desde mi punto de vista ésta esta directamente ligada al nivel de madures de cada persona.Tal vez sea este el punto que mas lentamente perfeccionará con el tiempo.
• Buscan al Programador Autopoietico en su sentido laboral: Esto es un programador capas de organizarse a si mismo, autónomo en su creación y crecimiento, con capacidad de auto-coaching. Nadie dice que encontrar esta capacidad en una persona es fácil, personalmente conozco muy pocos casos, y muchas empresas se conforman si en relación a esta capacidad sus posibles nuevas contrataciones son al menos capaces de organizar su trabajo de forma semi-autónoma y saben pedir ayuda a sus pares o superiores cuando lo requieren.
• Buscan al programador que aprenda rápido: Estoy convencido que a veces es mucho mejor contratar a una persona que técnicamente esta en la media, o incluso de bajo nivel, si es que su SUI es buena. Lo técnico se puede aprender, si lo puede aprender rápido, doblemente mejor compensara su debilidad técnica y en el tiempo la superara, para finalmente destacarse sobre sus pares. Alguien con mala SUI, tiene muchas mas dificultades de superación en ese ámbito y será una gran limitante.
• Buscan al programador diseñador: Si, una característica sutil de un buen programador, no es tanto que sea un excelente codificador, si no mas bien un gran arquitecto del código, una personalidad que a nivel de código ve mas desde arriba que desde el lado. Visión periférica global a la hora de considerar el código. No ve líneas de código, ve estructuras y relaciones entre las mismas.

Que los programadores son personas especiales, que duda cabe, también los médicos, artistas y de otras profesiones. Pero veamos las peculiaridades propias de esta profesión-arte:

Piense en que hace la mayor parte del día un programador?. Como yo lo veo hace todo el día prácticamente solo un par de cosas: Crea o relaciona detalles y procesos, busca errores y trata de evitarlos , siempre busca los impactos de condiciones de borde por muy poco probables que estas sean. En su experiencia histórica el no preocuparse o no darse cuenta de ellas le costara caro. Diseña e inventa soluciones, por lo que siempre piensa en problemas. Que podemos deducir de semejante actividad día tras día, en cuanto a su personalidad. Permítame especular al respecto, con mente abierta a mis palabras:

1. Buscara siempre ante cualquier situación, idea o concepto, las posibles fallas o errores del mismo. En otras palabras, ante cualquier situación buscara los peros de ella.
2. Es probable que cuando se le pida resolver un tema no técnico, aplique el mismo patrón que usa en su trabajo, por lo que es muy posible que no se concentre en el 80/20, esto es en el 20% de lo importante que significa en la practica el 80% de la solución.
3. Preferirá pensar y escuchar, al hablar o divagar. Aunque es muy posible que se presente la opción contraria, pero con una gran diferencia. Hablara para aprender él mismo el concepto que trata de entender.
4. De personalidad analítica y detallista, pero no se confunda no es una personalidad que busque problemas, busca resolverlos, pero por lo mismo su énfasis esta en los problemas y a veces no en las soluciones.

Seguramente con tales evaluaciones muchos de mis colegas pensaran distinto que yo (errores de concepto : ) . Pero la mayor parte de mi vida he codificado, programado, desarrollado soluciones, diseñado arquitecturas y comercializado software y créame que no estoy tan perdido.

Ahora puede parecer que son puntos de personalidades complejas y hasta tal vez negativas, pero creo que es todo lo contrario, puede ser un gran punto de partida para superar las partes negativas o limitantes de nuestra profesión. Si!, el conocer nuestras limitantes y como al aplicar los mismos patrones de comportamientos en situaciones que no son las propias de codificar puede ayudarnos no solo en los aspectos laborales, sino mucho mas que eso. Para finalmente permitirnos y darnos la autoridad personal para crecer y desarrollarnos en esos temas débiles de nuestro ser.

Y ante todo una empresa exitosa, busca programadores con cierto nivel de madures.
Y créame que en este punto una cosa es hablar de ella y otra tenerla.

Me gustaría saber que piensa usted al respecto?, si es programador, desarrollador o tiene algún relación en esta profesión que mitad es arte, lo invito a ayudarme a definir como somos, nosotros los programadores y cuales son limitantes que nuestra propia profesión nos induce a tener en nuestras personalidades. Y también lo invito a ayudarme a conversar e identificar como esos patrones son también virtudes de personalidad y carácter.

Javier Urrutia

Ahora usted se preguntara como podría una tecnología informática, jugar un rol preponderante en las profesiones ligadas al desarrollo de software?. Piense en cuando se programaba en arquitecturas monolíticas y llego cliente-servidor para cambiarlo todo, piense luego cuando llego la web para darle un sabor distinto al modelo cliente-servidor y cambiarlo en gran medida. Bueno JXTA es el primer esfuerzo serio, para desarrollar un Framework de desarrollo (preliminarmente en java, pero no limitado a este lenguaje) para agregar a sus aplicaciones capacidades de redes P2P. Imagine distribuyendo la responsabilidades de su aplicación y su data en una red P2P en base a un Framework potente, bien pensado y capas de lidiar con todas las problemáticas de redes P2P, desde los firewall con tecnologías FirewallFrendly, hasta todas las temáticas propias de la tecnología P2P, como mensajería, avisos, distribución, búsquedas, etc.

El tema no es trivial, tendrá que aprender muchos conceptos que cambian la estructura típica de programar y ver los flujos de información. Lo Invito a pensar en las aplicaciones y ventajas que podría tener para sus desarrollos el contar con ingresar al mundo de las redes P2P. Veamos de que se trata…

Veamos cuales son los objetivos de JXTA cuando se definió su creación:

• Resolver las necesidades de la mayor variedad posible de aplicaciones P2P
• Sin suposiciones sobre SO, hardware, lenguaje, o mecanismos de transporte
• Recomendaciones: caché para reducir tráfico de red y routers para los participantes no conectados directamente
• Sin servidor central
• Responsabilidad del servicio distribuida
• Explotar el ancho de banda en toda la red

Veamos ahora un listado simple de algunos conceptos y relaciones de P2P generales:

• Peer (Participante): Una entidad capaz de realizar alguna tarea útil y de comunicar los resultados a otra entidad en la red, ya sea directa o indirectamente.
  • Tres tipos:
    • Simples: servir a un usuario, normalmente en una red privada
    • Descubrimiento (rendezvous): para descubrir otros participantes, fuera de la red privada
    • Encaminamiento (router): permiten atravesar una red privada
• Grupos de participantes: formado para servir un objetivo común. Proporciona servicios a sus participantes miembros que no son accesibles a otros participantes en la red P2P.
  • Datos privados
  • Seguridad
  • Monitorización ente miembros
• Red de transporte:
  • Puntos finales: inicio o final de paquetes de datos
  • Conductos (pipes): canales unidireccionales asíncronos entre dos o más puntos finales
  • Mensajes: contenedores de datos transmitidos por un conducto de un punto final a otro. Se necesitan dos conductos para una comunicación bidireccional entre dos participantes
• Servicios: trabajo útil
  • Servicio de participante: funcionalidad ofrecida por un un participante a los demás.
  • Servicio de grupo de participantes: ofrecido por un grupo de participantes al resto. Acceso redundante al servicio.
  • Servicios esenciales: proporciona la base de P2P y se utiliza para construir servicios más complejos.
• Anuncio: una representación estructurada de una entidad, servicio o recurso disponible para un participante o grupo de ellos en una red P2P.
• Protocolo
  • Un modo estructurado de intercambiar información entre dos o más partes utilizando reglas previamente acordadas por todas las partes.
  • Organizan el intercambio de anuncios.
• Identificación de entidades
  • Participantes, grupos, conductos, contenido
  • Se necesita un sistema independiente de identificación de entidades

Si le parecen muchos, hay mas pero la potencia que contiene y podría contener su propia aplicación son realmente impresionantes. Permítame mostrarle el siguiente diagrama que le permitirá ver de mejor manera como JXTA lidia con los problemas de infraestructura propios de Internet para crear redes virtuales P2P.

Como puede observar, una de las gracias de JXTA es que esconde al programador toda la problemática de redes P2P en Internet, en el sentido de lidiar con firewalls, NAT, y permitir realmente implementar una red P2P con integrantes estén donde este, si es que tienen conectividad Internet.

Y si lo anterior le parece poco, pude en el siguiente diagrama darse cuenta, que JXTA también esta pensado para considerar como peerID o cliente, no solo computadores o notebooks, sino también dispositivos de los mas diversos desde teléfonos hasta PDAs y otros dispositivos que corran alguna de las versiones de Java. Pude hacer click en la siguiente figura para ampliarla y ver en detalle lo que le comento en este párrafo, y algunos de los conceptos interesantes como Rendzvous y J2ME.

Pero a grandes rasgos, cuales son los servicios que ofrece a nivel de Arquitectura de Software JXTA a programadores como Framework de redes P2P?. Puede ver en el siguiente diagrama una respuesta rápida esta pregunta (click para aumentar tamaño).

En los próximos post desarrollare en profundidad estos tres niveles de JXTA y ejemplos de codificación. La invitación es a considerar darle capacidades P2P a sus aplicaciones.

No limite P2P a ambientes de Internet como redes sociales. Considere P2P también a nivel empresarial, dentro de una organización donde su red Internet es la red privada de su empresa, y pude considerar a sus aplicaciones empresariales dando servicios en esta modalidad de manera de mantener conectados a todos los departamentos.

El paradigma es muy distinto y necesitara darse el tiempo y revisar donde y como aplicarlo en su organización o empresa. Pero creo que su intuición al igual que la mía, y de otros expertos que están clamando para que se considere a este JXTA como el primer Framework serio y Abierto para el nuevo salto tecnológico en el desarrollo de software.

La invitación esta hecha.
Ups! se me olvidaban los links, por si desean ver mas mientras desarrollo el tema, algunos de ellos fueron utilizados para presentar parte del material usado en este post.

La fundación JXTA
Introducción a JXTA en Sun (de Daniel Brookshier)
Peer to Peer JXTA 2.0 (de Jesús Vegas)

Javier Urrutia