Inocente renuncia

Uno de los mayores temores en este ambiente de alta competencia y escases de recursos calificados es la rotación. Activar el circuito de pedir un reemplazo, comunicarlo al cliente (si es necesario) y planificar el cambio cuando alguien renuncia es una tarea para nada grata de un project manager.

Hoy, 28 de Diciembre, me encontré con la siguiente situación. Un miembro de un equipo de dos personas (X e Y) me contacto a las 11 de la mañana por MSN y tuvimos la siguiente conversación:

X: te enteraste lo de Y?
MArtin: ???
MArtin: que paso?
X: uh, no, si no te contó el, no te puedo decir :S
X: pensé que ya sabias
MArtin: .... ok...
MArtin: buh, ahora me quedo con la duda de lo que podría ser
MArtin: te voy a matar!
X: ya te va a pedir hablar....
MArtin: y si...
MArtin: buh
X: no le digas que te comente nada por que me mata
MArtin: y si, igual hiciste mal!
X: si, ya se, es que pensé que ya había hablado con vos primero...
MArtin: ahora tengo miedo de ir a su oficina
X: banca a que te pida el hablar sino me haces quedar mal.
MArtin: si, voy a hacer

Instintivamente me imagine que Y iba a renunciar, que le había comentado a su compañero de equipo X y que pronto me iba a comentar a mi. Me enoje bastante con X por contarme eso, me hizo sufrir una situación por adelantado. Ya comencé a pensar como iba a buscar el reemplazo, sobre como iba a comunicarle la situación al cliente y manejar la situación.

Luego almorcé, me cayó mal la comida (broma) y a eso de las 16hs, me contacta Y porque quería hablar conmigo. Temiendo lo peor, me acerco a donde se encuentra el equipo y le toco la espalda a Y. Lo invito a que me acompañe a una sala de reuniones y me dice que quiere que X esté presente también. Eso me pareció muy raro, y me dio cierto alivio, pero no le di mucha importancia en ese momento.

En la sala, Y me empezó a comentar, muy nervioso, que había recibido una propuesta que no podía rechazar, que era para un rol que el estaba buscando y que lo estaban apurando (como siempre pasa). Quería que le comente los pasos a seguir y que invito a X a la sala para que el también sepa.

Paso justo lo que me había imaginado, hasta que luego se miraron ambos y se rieron, y me dijeron en coro: "Feliz día de los inocentes!". Yo me quede sin palabras.

Realmente fue una broma excelente, bien planificada y ejecutada. Tenia muchos baches (o "plot holes" como se le dice en el cine) pero ni les preste atención porque no estaba al tanto de lo especial del día. No fue una broma grata, pero la festeje por ser una buena idea.

Gracias X e Y! A trabajar todos los feriados de ahora en mas! :)

Historias de Overtime

Todos los que trabajamos en la industria del desarrollo de software, tuvimos que trabajar alguna hora extra (o muchas de ellas). Todos vemos el overtime como un fenómeno común. Todos sabemos que es malo, pero lo aceptamos igual. Las justificaciones son muchas, por ejemplo, decir que la ingeniería de software es muy nueva y los procesos no están muy ajustados como para poder calcular bien la carga de trabajo antes de comprometerse en una fecha. Otra justificación puede ser presión para que salga el producto a tiempo. Hay muchas mas, pero la idea de este articulo no es buscar excusas, ni mucho menos intentar dar algún tipo de solución, sino comentar un caso famoso de overtime en la industria del desarrollo de videojuegos, que dio mucho que hablar y cambio las cosas, por lo menos en esa empresa (luego de ciertas acciones legales)

En el 2004, la esposa de un empleado de Electronic Arts publico en internet un articulo titulado: "EA The Human Story" comentando sobre las practicas de la empresa con respecto a las horas extras, ya que no dejaban a los empleados compensarlas y no se las pagaban. Este articulo fue precedido por un montón de juicios y también por un cambio de actitud de la empresa. Les recomiendo que lean el articulo. Les dejo un párrafo clave de el mismo:

The stress is taking its toll. After a certain number of hours spent working the eyes start to lose focus; after a certain number of weeks with only one day off fatigue starts to accrue and accumulate exponentially. There is a reason why there are two days in a weekend -- bad things happen to one's physical, emotional, and mental health if these days are cut short. The team is rapidly beginning to introduce as many flaws as they are removing.

Sin lugar a dudas, casos como estos sobran. Es responsabilidad de los Project Managers pelear contra los clientes y las empresas para reducir el overtime al máximo. No es fácil, pero cada granito de arena de todos nosotros sirve.

El día que vino Tommy H.

Recuerdo muy gratamente el dia que vino Tommy H. a mi primer trabajo. Tommy H. (no el de la marca de ropa :) ) fue un cliente del proyecto mas grande de mi carrera hasta ahora. El equipo era muy grande y duro casi dos años. Además fue mi primer proyecto como Project Manager. En la mitad de ese periodo, vino el vice presidente de ingeniería del Cliente Tommy H.a visitarnos y conocer como trabajabamos.

El cliente se había reestructurado, así que Tommy era el nuevo sponsor del proyecto, y quería saber de que se trataba todo. Del éxito de nuestra presentación estaba ocultamente atada la continuidad o cancelacion del mismo, cuestión de la cual me di cuenta mucho después.

Tommy tenia que ir a la sede de Francia de la empresa y paso dos días por Buenos Aires para conocernos. Con el equipo preparamos una presentación del proyecto la cual termine la noche anterior de la reunión. La presentación salio muy bien, no me puse muy nervioso y hable lo suficientemente fluido en la primer visita de un cliente en mi vida profesional. Luego fuimos todos a almorzar y el proyecto siguió mucho tiempo mas. El equipo estuvo presente y cada uno dio su aporte, el cual fue muy importante.

Lo importante a destacar fue que el proceso de trabajo ya estaba aceitado y probado por mucho tiempo. A Tommy le contamos como trabajabamos, y eso fue lo que lo sorprendió. Un proceso solido es mucho mas importante que una linda presentación. Hay que trabajar diariamente en eso.

Cambios forzados en equipos de desarrollo de software

Cuando hay que cambiar a una persona en un proyecto en los casos que esta persona mantiene en contacto con el cliente, hay que informárselo. Esto no habría que hacerlo en un proyecto de costo fijo si esta persona no se comunica con el cliente activamente, por ejemplo. Estoy hablando de realizar un cambio porque supongo que el proyecto está en curso y la necesidad de esa persona sigue, y no es común que se quiera dejar de obtener ganancias por esa posición.


La razón del cambio puede ser por:

• Necesidad de reasignarla a otro proyecto debido a que se obtendría un mayor margen.
• Necesidad de reasignarla a otro proyecto debido a que sus habilidades serian mas aprovechadas en el nuevo proyecto.
• Pedido de cambio de la persona, por aburrimiento u otras razones.
• Pedido de cambio del líder técnico o project manager por considerar a la persona no apta por temas de motivación, falencias técnicas o similares.
• Renuncia por diversas razones.
• Despido por diversas razones.

Existen muchas otras razones, las que enumere son las más comunes. Una vez me paso que la novia de un ingeniero había conseguido una asignación de 6 meses en Estados Unidos y la empresa de la novia también le pagaban la estadía y el pasaje a él y no dudo en renunciar. Sin embargo, el objetivo de este artículo no es citar razones, sino contarles qué hay que informar en estos casos.

Lo ideal es tener un candidato para reemplazar a esta persona. Si se sabe esto con la suficiente anticipación, se puede esperar unos días para encontrar un posible reemplazo. Si uno se entera sobre la hora, hay que informarlo cuanto antes. En este caso lo mejor es llamar al cliente, contarles que cierta persona no está más, que ya se está trabajando en buscar un candidato, y decirle que en tal día (sugiero no más de 3 días) se le va a actualizar sobre la situación.

Si uno tiene un candidato para presentar, lo ideal es mandar un mail con el curriculum vitae de esta persona, ofreciendo hablar sobre el tema ni bien el cliente pueda. Lo mejor que puede pasar, lo más fácil de digerir para el cliente es decir es que esta persona consiguió una beca de investigación en una universidad del exterior. Si es renuncia, lo mejor que se puede decir es que se fue a una empresa que le ofrecía un desafío tecnológico mayor, que en esta empresa no existía tal cosa. Recuerdo una vez que el cliente luego de informar que alguien renunciaba ofreció contratarlo por su cuenta, freelance, y le conto a la persona lo que pagaba por mes por él, un mamarracho. Lo peor es decir que se va por mas plata. Hay que manejar el tema con cuidado, porque si se disfraza la verdad (recomiendo no hacerlo) y la persona tiene una buena relación con el cliente, este le va a ir a preguntar enseguida.

Si uno manda un mail con un candidato, lo ideal es comenzar contando que uno lamenta informar que cierta persona se va, si no se tiene el día exacto comentarle al cliente cuando uno lo va a tener. Luego hay que comentar la razón. Después se tiene que presentar al candidato (adjuntando el curriculum vitae, informando el costo por hora) y dar las razones por la cual uno piensa que es el correcto. Posteriormente hay que avisar que se planeo una transferencia de conocimientos para que la transición no impacte en los planes (esto hay que hacerlo en serio con el líder técnico, hay que comentarle al cliente que se comunique con esta persona para mas detalles). También hay que ofrecerle que conozca a esta nueva persona en una charla telefónica. Prefiero no sugerir que lo entreviste para evitar que lo reboten, ya que es difícil tener más de un candidato en estas situaciones. Hay clientes que quieren entrevistar a la gente si o si, y no se puede hacer nada para evitarlo. Finalmente hay que ofrecer disculpas de nuevo y comentarle que puede contactarse con uno cuando quiera para charlar sobre el tema. Les deseo la mejor suerte si tienen que pasar por esto.

Cualidades del Software

Hoy me preguntaron sobre cualidades del software y recordé lo que me habían enseñado en la facultad, como es un tema interesante, quiero escribir algo en el blog sobre ellas.

Las cualidades del software podrían definirse como las características propias e innatas del producto de software a construir. Idealmente, Las cualidades de un sistema deben estar por encima y por delante de la funcionalidad del sistema. Lamentablemente, la funcionalidad no sólo ocupa el primer lugar en las prioridades de los desarrolladores sino que muchas veces es el único.

Las cualidades podrían clasificarse como externas (visibles a los usuarios), internas (visibles solo a los desarrolladores), del producto, del proceso, observables y no observables en tiempo de ejecución.

Robustez: es un concepto difícil de definir, pero haremos nuestro intento: robustez = distancia al caos. Mientras menor es la distancia al caos, mayor solidez/robustez posee ese sistema. También puedo medir la robustez de un sistema en base a la tranquilidad al: 1) usar, 2) modificar una pieza de software.

Corrección: un sistema es correcto si hace lo que el cliente necesita. Dicho de otra forma, un sistema es correcto si su resuelve el problema real que causó su desarrollo. Adaptación total a una especificación no necesariamente implica corrección ya que dicha especificación puede no ser un fiel reflejo de la realidad del problema a resolver. Dicho de otra forma: pasa todo el tiempo que el cliente te pide y/o espera algo distinto de lo que necesita (de hecho lo que dice, lo que espera y lo que necesita pueden ser los tres súper distintos entre sí).

Eficiencia: tenemos dos dimensiones posibles para medir la eficiencia (tiempo/recursos) de un sistema: Recursos necesarios para la construcción (tiempo de desarrollador) o Recursos necesarios para la ejecución (tiempo de usuario + hardware). “Tiene mejor eficiencia el sistema que necesita menos recursos para realizar una tarea determinada”, por lo tanto deberíamos considerar ambas dimensiones a la hora de medir esta cualidad.

Claridad: Se refiere a la posibilidad de entender el funcionamiento de un sistema, subsistema o una porción de código cualquiera, su objetivo y la forma de solucionar el problema; en particular por gente que no es la que lo construyó. La claridad de un módulo afecta claramente a la posibilidades de modificarlo (flexibilidad).

Flexibilidad: es la capacidad que tiene un sistema para reflejar cambios percibidos en el dominio (sea por mejor comprensión del mismo o porque de verdad cambió) de una manera simple y sencilla. Conceptos relacionados son:
Extensibilidad: un sistema es extensible cuando pueden incorporarse nuevas características al mismo sin mayor impacto sobre las características actuales.
Mantenibilidad: un sistema o desarrollo es más mantenible cuanto menor esfuerzo requiere para que el sistema siga funcionando en condiciones distintas a las originales e incluso en las originales. Entre estas tareas podríamos enumerar:

1. Pequeños cambios de funcionalidad o parametrización (aquí se relaciona con la flexibilidad)
2. Debugging
3. Posibilidad de corregir las incongruencias producidas por los propios errores del software
4. Posibilidad de hacer cualquier tipo de cambio sobre el sistema mientras este sigue funcionando.

Consistencia: el sistema debe comportarse siempre de la misma manera ante un mismo evento y las tareas similares deben poder realizarse siguiendo pasos similares.

Simplicidad: el sistema debe ser simple tanto en la interfaz como en la implementación. Es más importante la simplicidad en la interfaz que en la implementación.

Completitud: Un sistema es completo cuando contempla todas las posibles situaciones a darse en la práctica.

Encapsulamiento o Modularidad: poder agrupar unidades funcionales me permite que el sistema sea cohesivo, reduciendo la complejidad del sistema y aumentando en cierta forma su flexibilidad.

Escalabilidad: la facilidad con la que un sistema pensado originalmente para una carga determinada puede ser adaptado para soportar una carga mayor. Las aplicaciones Web nos dan una buena muestra de cuándo la escalabilidad puede ser importante para no afectar 1) la imagen del usuario que da vida a nuestro sistema, 2) la imagen corporativa del negocio que manejamos.

Abstracción: un sistema debería contener buenas abstracciones de la realidad. Recordemos que el sistema no es la realidad, sino un modelo. En base a nuestras abstracciones podemos definir:

1. Reusabilidad: la posibilidad de utilizar un sistema construido anteriormente para resolver un problema nuevo.
2. Genericidad: Un sistema o subsistema es genérico cuando se puede aplicar a un conjunto de situaciones similares.

En general reusabilidad y genericidad están relacionadas, un sistema muy específico difícilmente puede ser reutilizado.

Utilidad: no está de más recordar que el sistema debe ser útil al usuario.

Seguridad: Un sistema seguro debe impedir que agentes (personas u otros sistemas) no autorizados realicen acciones sobre el sistema.

Hagan click para ver la siguiente imagen mas grande con una subdivisión de estas y otras cualidades:


Fuentes:

• UTN - Técnicas Avanzadas de Programación
• Facultad de Ciencias Exactas, Ingeniería y Agrimensura (FCEIA) de la Universidad Nacional de Rosario
  

Evaluando el rendimiento de la gente en distintos tipos de proyectos

Como Project Manager, cuando uno necesita evaluar el rendimiento del equipo, conviene estar en un proyecto donde se está en el día a día, donde se trabaja con el equipo para lograr un objetivo y uno tiene responsabilidades sobre las tareas. Al estar bastante tiempo asignado y compartiendo el avance del proyecto uno puede evaluar el desempeño de cada miembro del equipo.

Esto seria en proyectos de costo fijo, en proyectos "time & materials" y en proyectos "staff augmentation" donde además de los desarrolladores, testers, diseñadores (y cualquier otro rol que se les ocurra) el cliente también te tenga contratado a cierto porcentaje para administrar al equipo, sus tareas y tiempos.

El problema surge cuando uno esta asignado como "focal point" en proyectos donde el cliente solo contrata tiempo de gente técnica y el se encarga de la administración de sus tareas y el tiempo. Uno tiene que estar asignado en cierto pequeño porcentaje para resolver cualquier tipo de problemas que el cliente tenga con el equipo y/o viceversa. También por temas financieros, de viajes o para hacer seguimiento del contratamiento o entrevistas de nuevos candidatos para formar parte del equipo.

En estos casos uno tiene que tener una idea de lo que la gente esta haciendo, y si tiene que evaluar su desempeño, uno cuenta con los comentarios que pueda dar el cliente. Si hay alguna persona técnica que el cliente asigna como líder y oculta al resto del equipo de alguna forma, hay que referirse a esa persona para evaluar al resto del equipo y al cliente para evaluar a esa persona. Esto es mucho mas complejo de lo que parece, se los aseguro, pueden surgir cientos de inconvenientes.

La idea es tomarse el tiempo necesario durante toda la duración del proyecto para hablar con el equipo, el cliente, contrastar opiniones, confrontarlas. Esto ayuda a tener un panorama amplio preparar la evaluación con una buena base y estar seguro del resultado.

Proyecto sin responsabilidad sobre tareas: Es bueno sentarse cerca de la gente

Actualmente estoy ejecutando proyectos del tipo "Staff Augmentation" donde uno no tiene responsabilidades sobre las tareas, ya que el cliente asigna directamente estas al equipo, pero uno actúa como contacto del cliente y como contacto del equipo con la empresa.

El tema es que el objetivo principal en esos proyectos es que la gente rinda bien, que el cliente este contento, que la gente no este aburrida y se vaya y también de hacer crecer el equipo. Sin contar temas de facturación y otros temas administrativos.

Como uno no esta en el día a día de las tareas, es bueno pasar a charlar una vez por día para ver si están bien, si tienen algún problema o si detectaron alguna oportunidad. Es muy importante inculcarles la idea de que estén atentos de las necesidades del cliente.

Una mejor practica es tratar de sentarse con estos equipos, ir alternando entre ellos si se tiene mas que uno. Estar cerca ayuda a que comuniquen muchas mas cosas (algunas útiles, otras no realmente), y esto sirve para conocerlos mas y las necesidades del cliente, por ende, ejecutar mas efectivamente este tipo de proyectos. Se que hace unos días dude sobre esto, pero era otro tipo de proyecto, donde tenia responsabilidades sobre las tareas, estaba en el día a día involucrado con el trabajo que todos tenían que hacer.

Descuido al olvidar pedir la aprobación formal en un proyecto

Hace poco les conté sobre un proyecto Time and Materials con limite de tiempo (y dinero, por eso "Capped") y garantía que por suerte termino bien (Leer acá!).

Lo que me falto en ese proyecto fue pedir la aprobación formal. El tema fue que como fue Time and Materials no me preocupe por eso, como si lo hubiese hecho en un proyecto de costo fijo.

Luego de casi tres semanas de haber entregado el proyecto me llega un mail de que pudieron terminar de instalar todo y su cliente les dio el ok, entonces que me daban la aprobación formal y comenzaba la garantía ese día. No se imaginan mi cara al recibir ese mail. Quería literalmente desaparecer de este planeta.

Yo pensé que con el ok de la entrega ya estaba, pero descuide ese importante aspecto. Estoy seguro que con la presión adecuada hubiese conseguido la aprobación mucho antes.

No hay que descuidar obtener la aprobación formal en todo proyecto que tenga garantía, sin importar el tipo de contratación.

¿Es bueno que un Project Manager se siente cerca de su equipo?

Hoy cuando estaba volviendo a mi casa repase mi historia de proyectos, y estuve pensando si mi ubicación afectaba de alguna forma (positiva o negativa) al resto del equipo y al éxito del proyecto.
Primero les cuento que pienso que un Project Manager es parte de un equipo (donde tiene responsabilidades sobre las tareas) y lo lógico es que es bueno que se siente con el equipo, pero una experiencia reciente me hizo pensar que tal vez la distancia sea buena en ciertas ocasiones.

Igual no tuve malas experiencias sentándome cerca de la gente, y voy a seguir buscándolo, pero en esta ultima experiencia no pude por temas de espacio físico e igual todo salio bien.

El equipo se conformaba con gente de mi misma edad mas o menos y todos los días nos reuníamos a charlar del proyecto. Además a mi me cuesta mucho quedarme sentado, entonces pasaba a saludarlos y ver como andaban varias veces por día, muy amistosamente obviamente. Por suerte el equipo andaba muy bien solo y no necesitaba mucho apoyo de mi parte. El tema es que hubo ciertos momentos críticos, donde pienso que si hubiese estado cerca hubiese molestado mas que ayudado. Hay ciertas ocasiones donde hay que dejar al equipo trabajar. Estando lejos podía contenerme, pero cerca tal vez los hubiese acosado mas con preguntas. De lejos pude contener mis nervios y dejarlos tranquilos.

Lo que veo ahora es que el equipo es muy unido, siguen almorzando juntos, esta muy bueno eso, pero me da un poco de lastima haber quedado fuera de eso. Igual tal vez es bueno que el Project Manager mantenga cierta distancia. Realmente no estoy seguro de eso ¿Que les parece?

Proyecto de costo fijo: Enojo de un cliente al darse cuenta que la garantía estaba vencida

Hace un tiempo viví una situación tristemente graciosa. Tome una cuenta de un PM que se iba de la empresa para hacer un nuevo proyecto y encargarme de la garantía que corría de un proyecto anterior.

Durante la ejecución del nuevo proyecto, el cliente reporto unos errores del proyecto anterior. Por suerte fue de otro sector del cliente, no fue nadie con quien estuviese en contacto actualmente. Antes de analizar estos errores, me referí al contrato para ver cuando vencía la garantía y descubrí que ya estaba vencida. ¡Informe sobre esto y el cliente se enojo porque no le había avisado!

Fue la primera vez que me paso, realmente no creo que sea una practica usual ir manteniendo al tanto al cliente del estado de las garantía de un proyecto ya terminado. En un mundo ideal seria lo mas correcto, pero la realidad es que uno quiere ejecutar lo mínimo que se pueda de garantias, porque es plata que se pierde. Yo configuro un recordatorio y aviso cuando termina, no antes.

En realidad uno cobra un 5% adicional aproximadamente cuando ejecuta proyectos de costo fijo con garantias, pero si no gastas esa plata mucho mejor. Además tenes que buscar a la gente que estuvo en el proyecto, pedirle a sus actuales PMs que te pidan tiempo, coordinar con el cliente, asegurarte que los ambientes de trabajo se mantengan, y rezar que sigan en la empresa, sino es mucho mas difícil, creanme.

Finalmente el cliente acudió a su contacto de ventas, que me hizo que estime los errores, si no llevaban tanto (ya lo había visto y llevaban bastante tiempo), los haríamos gratis para quedar bien con el cliente, pero finalmente nos llego la orden de operaciones de no ejecutar garantias vencidas, así que el cliente lo hizo internamente, no quiso contratarnos de nuevo por ese trabajo, estimo que se les libero alguien internamente.

Por suerte el otro proyecto que ejecute salio muy bien y en pocos días termina la garantía, espero que no encuentren nada!

¿Ustedes avisan a los clientes el estado de la garantía?

Reuniones con notebooks y blackberrys

Imagínense lo siguiente, una sala, una mesa en el centro y muchas sillas al rededor de la mesa. Ahora imagínense gente sentada, reunidas en la sala con un propósito en común. También, imagínense que el horario es de 9 a 18, y la sala se encuentra en una empresa.

Creo que establecí exitosamente el contexto de la situación. Estoy hablando de una reunión de trabajo, útiles o inútiles, todos las vivimos (o sufrimos).

Les voy a comentar un detalle que me pareció muy curioso, que estoy viviendo ultimamente en las reuniones de project managers en mi trabajo. Hay varios que llevan sus notebooks, y durante la reunión la usan. Para mi no esta bueno eso, lo ideal es prestar atención al que esta hablando en la reunión. Supongo que los que la llevan y usan estarán muy ocupados, tendrán muchas cosas que hacer, pero no es el lugar indicado. Igual, lo peor es la gente que atiende el teléfono, eso me parece malisimo

Lo que yo hago (no soy perfecto, lo admito! :P), es llevar mi Blackberry y dejarla en silencioso. Si advierto que se prende la lucecita de que llego un mail o hay un llamado entrante y si justo en ese momento la atención de la reunión no esta puesta sobre mi, disimuladamente me fijo que es, leo por arriba el mail, veo quien esta llamando, pero nunca atiendo. Nunca me pondría a responder un mail.

Todo esto es un resumen de los tiempos modernos en los que vivimos, todo muy portable, todo tiene que ser ya, hay que hacer muchas cosas a la vez. Necesitamos ser mas civilizados en ciertas situaciones.

Proyectos a Costo Fijo: Vendiendo un Producto, no un Servicio

Hay un cliente que no esta conforme con los resultados de un proyecto Time and Materials, entonces se esta charlando para ver si se puede cambiar a la modalidad de costo fijo, para futuros proyectos.

La idea en estos proyectos es vender un producto, con su garantía, y asumir los riesgos que esto pueda implicar. Obviamente esto se comienza con las especificaciones cerradas del producto a desarrollar. Si en el medio del desarrollo al cliente no le gusta lo que pidió, todo cambio se cobra aparte. Además dependiendo del tiempo se arma el equipo. Igual es importante dejar claro que esto no es para nada lineal. Nueve mujeres no pueden tener un bebe en un mes, se necesita una mujer y nueve meses.

Estamos estimando un proyecto para este cliente, y le mandamos un costo. Luego de esto, el cliente nos pregunto por las estimaciones. Luego de deliberarlo, decidimos mandarle la estimación de desarrollo, separada en tareas. El objetivo del cliente era ver si habíamos sobreestimado cosas y si habíamos contemplado todo lo necesario. Luego de esto, el cliente pidió un plan completo con todas las horas de cada rol que va a intervenir en el proyecto y también pidió a una persona especifica para que lo lidere técnicamente.

El tema en dar esa información, es que va un poco en contra de la idea de un proyecto de costo fijo. Uno cuando compra un televisor, se lo lleva con la garantía. No le pregunta al vendedor cuanto costo cada circuito, ni cuanto tiempo se tardo o cuantos operarios lo instalaron. La cosa es que el cliente necesitaba estos tiempos para venderle el proyecto a su cliente, porque no podía ir y decirle, sale X plata y listo. Mi cliente podía ir a otra empresa proveedora de software y preguntarle cuanto le costaba que le hagan lo mismo.

Lo que intuíamos es que el cliente con esa información iba a calcular el precio hora que le cobrábamos, compararlo con la anterior contratación y quejarse. Obviamente el precio hora de un proyecto de costo fijo es distinto a un proyecto donde se cobra por hora. Dependiendo del riesgo y de lo que se va a hacer, también así como del periodo de garantía, se arma un precio. Nada es gratis.

Otro factor es el equipo, nosotros elegimos quien, los seniorities, y cuanta gente. Total el riesgo es nuestro de entregar lo que se pidió en X fecha y con el nivel de calidad acordado.

Al final parece que le vamos a revelar la información de las horas al cliente, todo por lograr vender el proyecto. Épocas dificiles.

Modalidad de Proyecto: "Capped" Time and Materials con Garantia: Salgan corriendo!

Estoy ejecutando un proyecto Time and Materials con limite de tiempo (y dinero, por eso "Capped") y garantía: realmente es complicado.

Al principio no pensé que habría problemas, pero ahora que esta finalizando, los estoy viendo con mis propios ojos. Cuando mis colegas se enteraron que estaba ejecutando un proyecto de tales características, me dieron su pésame, me dijeron que era el peor tipo posible.

Yo pensaba inicialmente, que puede pasar? Vamos haciendo los features durante los distintos sprints (Utilizamos Scrum), y en el ultimo cerramos los bugs y listo.

El tema es que el primer problema fue que nos pasaron los requerimientos el primer día del primer sprint, o sea bastante tarde. Se armo el equipo teniendo en cuenta un proyecto similar anterior con el mismo cliente. Al final el tiempo de diseño era mucho y el de desarrollo poco, pero por suerte no afecto mucho esto.

Mientras iban pasando los sprints, veíamos que no íbamos a poder a completar todo el backlog. Ahí me empezó a agarrar miedo, sinceramente. El cliente tenia la idea de que se podía hacer todo en el tiempo dispuesto. Ahora estamos en el ultimo sprint, y por suerte muchas features se sacaron de scope, y estamos cerrando bugs. El tema es que lo que puede pasar es que l cliente quiera que completemos features en estos últimos días y luego los bugs se vean por garantía. Mi objetivo es no ejecutar garantía, obviamente, para no perjudicar el margen del proyecto. Estoy en una situación medio tensa con el cliente porque tengo que convencerlo de cerrar lo que esta, corregir los bugs, para poder tener algo listo para producción, y que luego nos contrate por mas tiempo para terminar el resto de los features.

Por suerte tenemos charlas diarias con el cliente, y ellos ven que tenemos una velocidad de desarrollo decente, y que progresamos. Mi objetivo es hacerle entender que tenemos que cerrar todo estos días y que entienda que no quiero ejecutar garantía. Lo bueno es que parece que esta entendiéndolo, porque están ajustados con el tiempo para lanzar el producto, o sino no me entenderían y tratarían de que hagamos features y dejemos bugs para la garantía.

Creo que teniendo en cuenta las cosas que podían pasar, la estoy sacando fácil, pero todavía no canto victoria hasta que termine el ultimo sprint. No, mejor, cuando termine el periodo de garantía.

The Design Of Everyday Things

The Design Of Everyday Things, de David Norman es básicamente un libro de usabilidad. Realmente hice mal, porque leí la continuación de este libro, Emotional Design, antes de leer este, pero igual disfrute ambos un monton.

El objetivo de este libro es apoyar el diseño centrado en el usuario, una filosofía basada en las necesidades e intereses del usuario, enfatizando que se hagan productos utilizables y entendibles.

El diseño de cada producto debe:

• Facilitar al usuario la determinación de que acciones son posibles en cada momento.
• Hacer visible las cosas, incluyendo el modelo conceptual del sistema, las acciones alternativas y el resultado de las acciones.
• Hacer fácil evaluar el estado actual del sistema
• Seguir un mapeo natural entre intenciones y las acciones requeridas, entre acciones y el efecto resultante, y entre la información visible y la interpretación del estado del sistema.

En otras palabras, lo que quiere enseñar el liibro es que los diseñadores se aseguren que el usuario pueda darse cuenta que hacer y que el usuario pueda darse cuenta que esta pasando. Algo básico que no pasa. El libro esta lleno de ejemplos muy interesantes e ilustrativos, vale la pena leerlo si interesa el tema.

ASAP significa As Soon As Possible :)

Este es un relato que pretende ilustrar como sugiero trabajar con el sector de soporte, servicios e infraestructura de una empresa.

Estos sectores, reciben gran cantidad de pedidos y las prioridades no están bien definidas, ya que la persona que sube el pedido se la establece, y no tiene una visión sobre la criticidad del resto de los pedidos del resto del personal de la empresa. Hace escasos días, un líder técnico pidió que se instale cierto software sobre las máquinas de todos los miembros del equipo. Me paso la dirección del pedido en el sitio web donde se realizan para que lo apruebe. Yo seleccione monitorear el pedido, o sea, que me llegue por mail cualquier cambio de estado del pedido.

El día siguiente, vi que el líder técnico había escrito la siguiente nota en el pedido:

ASAP significa As Soon As Possible :)

Al no gustarme dicho comentario, le comente mi punto de vista de como trabajar con esta gente. Yo no me puedo quedar mucho tiempo sentado, entonces luego de subir un pedido, en la herramienta, voy a hablar con la gente directamente para ver en cuanto podría hacerse y darle algún que otro detalle mas. Ni me acerco al sector de soporte sin subir el pedido siguiendo la política, porque ellos ahí tienen derecho a ignorarme.

Si veo que pasa el tiempo y no me responden, me acerco de nuevo al sector a preguntar el estado, a ver si tienen otras prioridades o problemas con la misma tarea. La mayoría de la gente pregunta directamente en la herramienta el estado, pero yo prefiero levantarme e ir a hablar con ellos, prefiero el contacto directo, establecer una buena relación a base de demostrar interés (el cual es real) en su trabajo, así puedo entenderlos mejor y lograr mejores resultados.

Un comentario como el de arriba no sirve para nada, eso demuestra que el líder técnico tiene que mejorar sus "Soft Skills", manejar estos temas de una forma mas amigable. Hay que ponerse en los zapatos de la gente de soporte, tratar de pensar como ellos, y no tratarlos como a uno no le gustarla que lo traten, es algo que hay que practicarlo en todos los ámbitos de la vida.

Dificultades para llevar a cabo proyectos de costo fijo en empresas grandes

El staffing dentro de una empresa de ~1000 personas no es fácil. Sus objetivos son minimizar la cantidad de gente que esta sin asignación, y lograr una asignación correcta de toda esa gente, para que el cliente este contento, la persona este contento y el equipo este contento. Además hay que maximizar la facturación por cada persona.

No es nada fácil, menos en esta época de crisis donde la facturación es una necesidad muy critica.

Se me presento un problema. Me asignaron a un proyecto de costo fijo, para realizar un sitio web de consultas técnicas con una tecnología muy especifica. El proyecto comienza en un mes, pero ya hay que ir armando el equipo. Ya habíamos tenido hace unos meses un proyecto para el mismo cliente y en la misma tecnología, así que lo ideal era conseguir al mismo equipo. Comencé a trabajar en pos de eso y resulta que la diseñadora gráfica no estaba disponible, estaba asignada a otro proyecto.

Debido a la rareza de esta tecnología, no contar con esa persona crea un gran riesgo, el cual se duplica en un proyecto de costo fijo, debido a sus características. Necesitariamos entrenar a otra persona en esa tecnología, asignarla un tiempo antes (perder plata) para pagar la curva de aprendizaje, obtener ayuda de la otra persona (perjudicando al otro proyecto). Lo único positivo que veo es que la empresa va a contar con otra persona con conocimientos de esas tecnologías, lo cual es muy bueno, pero como PM, tengo que enfocarme en mi proyecto y ese cambio me afecta. Cuando tenga otras responsabilidades, cuando vea al bosque en conjunto en vez de a un solo árbol, todo sera distinto, pero en este momento tengo objetivos claros: lograr que el proyecto sea un éxito, que el cliente nos de mas proyectos y que logremos un buen margen.

Un tema que me preocupa en una empresa grande es la visibilidad y la correcta toma de decisiones con tanta gente dando vueltas. Por ejemplo, en este caso, no hay una persona que pueda claramente tomar la decisión de si conviene desasignar a la diseñadora del proyecto actual y pasarla a este proyecto o dejarla ahí. Es una decisión muy difícil, teniendo en cuenta que son sectores distintos, cada proyecto tiene distintas cadenas de mando y la persona donde confluyen es el COO de la compañía, que no va a ponerse a ver un tema que desde su óptica parecería ser tan mínimo. Problemas de las empresas grandes.

Reconocimiento muy especial de un cliente

Un cliente esta muy contento con una persona de un equipo donde trabajo, y lo quiso reconocer, para eso le pidió que elija tres juegos para cualquier plataforma (nuestro trabaja en una empresa donde se desarrollan videojuegos). La persona del equipo los eligió y el cliente se los mando.

Hasta acá no hay mucho que destacar, aunque estas cosas no pasan muy a menudo, pasan de vez en cuando. Hoy cuando llego el paquete de Fedex, todos estábamos al rededor de nuestro compañero para ver sus nuevos juegos para su PSP, y además de los tres juegos, había una carta.

Ese fue el detalle de color del día, dentro de la carta, había una tarjeta de agradecimiento escrita a mano. Realmente eso dibujo una sonrisa muy grande en mi por mucho tiempo, y mucho mas en la persona reconocida. Fue un detalle excelente. Les dejo las fotos, p[rimero de la postal de afuera y los tres juegos (hacer clic para ampliar si son curiosos):

Luego de la postal:

Donde se puede leer lo siguiente:

Roman,
Just can't thank you enough!
Thank you for your outstanding contribution to NAWP.
Keep up the great work (and have fun with the games)!
Dave, Lukas, and the rest of the NAWP team.

Estas son las pequeñeces que me hacen amar mi trabajo.

Vida BlackBerry

Hace unos meses me entregaron una BlackBerry en la empresa. Realmente lo busque y fue algo positivo, ese aparatito en mis manos era como un reconocimiento, una nueva carga responsabilidades y mas posibilidades para crecer dentro de la empresa, algo que uno siempre busca, ser un mejor profesional, poder dar respuestas mas rápido, dar tranquilidad, consejos y mostrar el camino. Luego uno reflexiona y se da cuenta que no tuve opción en aceptar al querido aparatito. Ni pensé en no aceptarlo, pero es una de las tantas cosas que uno tiene que aceptar en ciertas situaciones. Decir no esta mal visto, mientras los ofrecimientos sean razonables, pero me estoy distrayendo y escapando del objetivo de este articulo, que es describir mi vida con una BlackBerry, estando todo el día online recibiendo el mail del trabajo.

Obviamente que a la noche la apago, cuando me voy a dormir!! Eso es crucial. Cuando me despierto la prendo, la paso a modo silencioso y la guardo en el bolsillo de la mochila, así empieza a descargar los mails. Luego me baño, me cambio, desayuno y salgo a trabajar. Tengo 10 cuadras hasta la estación de tren, entonces ahí es cuando comienzo a ver los mails. Generalmente no tengo que responder nada, porque ya estoy acercándome al trabajo y ahí tendré la oportunidad de responder desde la computadora, que obviamente es mas cómodo. Pero el hecho es que ya estoy al tanto de las cosas que pasaron, y puedo ir cocinando las respuestas en mi cabeza hasta que llegue el momento de escribirlas.

Durante mi día laboral, dejo la BlackBerry en un modo que programe yo, que solo suena si recibo una llamada y vibra si recibo un SMS, no pasa nada cuando recibo un mail. Si entro en una reunión lo silencio totalmente. Luego cuando almuerzo dejo el modo que programe, y lo tengo en mi bolsillo, si recibo una llamada o un SMS acudo a el, los mails no interrumpen mi existencia.\

Cuando salgo del trabajo, cambio al modo ruidoso, en el cual el aparato vibra y suena pase lo que pase. Cuando viajo en tren generalmente leo libros, pero me fijo si me llega un mail del trabajo. Afortunadamente no estoy quedandome fuera de horario en este momento en la oficina, pero hay gente que si y también tengo clientes en usos horarios menores que escriben a esas horas normalmente. No me molesta leer los mails o responder algo cuando estoy volviendo del trabajo.

Ahora viene la parte difícil, la parte donde dudo si soy un adicto a la BlackBerry o no: No la apago o la tengo conmigo hasta que me voy a dormir, y leo los mails hasta ese momento, pero raramente respondo. Eso es malo, porque hay veces que surgen problemas que me ponen nervioso, que me complican dormir a la noche, muchas veces que están fuera de mi control y que no puedo resolver hasta el próximo día laboral. Soy muy exigente conmigo mismo y eso me afecta. Hay veces que ayuda leer el mail antes, ya que tengo tiempo para reflexionar sobre ciertas cuestiones y dar una mejor respuesta al otro día. Todavía mi carga y responsabilidad no es tan grande como para que me afecte tanto, pero cuando lo sea, tal vez llegare a apagar por lo menos los mails laborales cuando llego a casa. Me imagino que cuando tenga una familia lo voy a tener que hacer. Los fines de semana leo los mails también, pero ni respondo.

Tengo que ver si sigo con las mismas costumbres o las cambio. Realmente no me afecto en lo personal todavía, y espero poder apagar la BlackBerry cuando lo haga, sin dudarlo. Este es el primer articulo de este tema, volveré a comentar mi 'estado' cuando cambie mi utilizaron dependiendo de cambios en mi vida profesional o personal.

Consejos para encarar una entrevista laboral

Hace poco llegue a un blog donde un autor recopilo gran información sobre entrevistas laborales, un manual para controlarlas y convencer al seleccionador experto (ese es el titulo de la entrada del blog).

Desde enumerar los objetivos de cada parte en la entrevista a explicar que es una entrevista de trabajo hasta dar consejos, pasos previos, desde como vestirse a como encarar la entrevista, que hacer el día anterior, como comunicarse, expresarse, que preguntar y que no preguntar.

Realmente es mucha información. No les voy a mentir, no llegue a leer todo, y tampoco estoy de acuerdo con todo lo que leí, pero si les interesa el tema les recomiendo que lo lean.

Disfrutenla acá.

Trabajando en la industria de los Videojuegos!!!

Es innegable que el primer contacto con una computadora de muchos haya sido con algún videojuego. Creo que para cualquiera nacido en los 70's o 80's esto es cierto. Tal vez para las ultimas generaciones el primer contacto es internet, quien sabe. Lo que importa, es que en mi caso fueron los videojuegos, en una 'poderosa' Commodore 64.

Desde chico me gustaron los videojuegos y actualmente sigo disfrutando de los videojuegos como forma de entretenimiento (Mi ultimo amor, el Fallout 3). Creo que mi pasión por las computadoras comienzo por los videojuegos. Creo que fue uno de los factores por los cuales comencé a estudiar ingeniería en informática.

Ahora la vida me encuentra trabajando en la industria de los videojuegos, hace escasos meses. Realmente nunca lo imagine, o si lo imagine, pero no pensé que iba a poder, acá en la Argentina, ni siquiera tan pronto, con la empresa numero uno del mundo como cliente.

Realmente no realizo tareas técnicas ni muy relacionadas a juegos, mas que alguna administración de tareas de alto nivel, pero espero que pronto en la empresa empecemos a obtener proyectos mas completos, donde pueda involucrarme mas. Realmente me encantaría.

Godzilla: ¿Es un riesgo en un proyecto?

Siguiendo el tema de los riesgos que comencé hace unos días, luego de plasmar los riesgos en digital, se lo pase al líder técnico para que lo revise con el resto del equipo, para ver si estaban de acuerdo y para ver se les ocurrían otros.

Luego de leerlos, me escribió un mail comentándome lo siguiente: "Yo agregaría que como riesgo, que el proyecto se caiga (por cuenta del cliente, o sea que cancelen el juego)."

¿Que piensan ustedes sobre ese riesgo?

Realmente creo que no va en una lista de administración de riesgos que es visible para el cliente y para la alta dirección en la empresa.

Creo que la administración de riesgos se debe hacer sobre riesgos que pueden transformarse en problemas y que pueden mitigarse, no sobre riesgos que están fuera de nuestras manos, temas de fuerza mayor.

La cancelación de un producto en desarrollo por parte del cliente (en este caso un juego online para el mercado asiático) , no puede ser controlada por nosotros. Para dar más detalles, nosotros somos una pequeña parte de un equipo gigante y multidisciplinario que trabaja hace largos meses en el juego. A nosotros nos contratan para hacer una tarea específica, no podemos causar la cancelación del juego, ni si nos propusiésemos a hacerlo.

Ese riesgo es tan inmanejable a nosotros como alguno de los siguientes:

- Que Asia se quede sin internet.

- Que prohíban en China los juegos online.

- Que ataque Godzilla!


Sin embargo, si yo fuese el PM de todo el juego, ese riesgo tendría que considerarlo. Todo depende donde uno se encuentra parado.

Contratos, reconocimiento de ingresos y otras yerbas

El otro día, un cliente se quejo por el proceso legal de los contratos que existía entre mi empresa y la suya. El tema es que cada vez que hay que el cliente contrata a alguien o hace un gasto por algún viaje o compra de algún equipo, hay que armar un contrato, que tiene que pasar al área de legales de su empresa, luego tiene que mandármelo, lo tengo que hacer firmar por el COO, escanear y mandárselo de nuevo para que el lo firme y luego ambos nos guardamos ese documento por fines contractuales y legales.

Es un proceso engorroso pero necesario, la manera de evitarlo seria tener una excelente plantificación, y crear un solo contrato para un largo periodo. El tema es que debido a temas de presupuesto, el cliente no puede comprometerse de esa manera, entonces me va pidiendo que agrande al equipo de a una persona por mes, inicialmente por unos meses y luego si le sirve esta persona se extiende el contrato. Luego me pide un viaje, luego otra persona mas y cada uno de estos pasos requiere ejecutar el proceso descripto anteriormente.

Mi única acción en este caso fue reportar esto al área de preventas y al ejecutivo de la cuenta, para que lo tengan al tanto, pero esto fue algo definido por el área de legales de ambas empresas, y no se puede cambiar de una mañana para la otra. Luego le avise al cliente (nunca olvidarse de responder en estos casos) que íbamos a investigar si podíamos agilizar el tema, pero por el momento había que respetar el proceso.

El otro día el CFO de la empresa nos indico que la empresa tiene que tener evidencia persuasiva de todos los contratos, para cumplir normas internacionales y algún día entrar en la bolsa. Nos envío el link de este articulo, donde cito lo siguiente:

There are four criteria that must be met to recognize revenue:

• Persuasive evidence that an agreement exists
• Delivery has occurred or services have been rendered
• The seller’s price is fixed and determinable
• Collectability is reasonably assured

¡Martin Vs. los Riesgos!

Hace tres o cuatro semanas, mi jefe me pidió que actualice los riesgos de los proyectos que tengo a cargo. Al utilizar la palabra actualizar, fue mas que generoso, ya que debería haberme dicho que identifique algún riesgo, ya que los que estaban no eran para nada validos, debido a que ya habían surgido o se habían mitigado.

Realmente cuesta administrar riesgos. A mi personalmente me cuesta pensar en riesgos. Sera porque nunca lo aprendí correctamente, ni tuve buen coaching para aprender ese arte. Otra razón debe ser porque leí que esto le pasa a mucha gente (creo que en este libro), y por eso me sentí aliviado y no me peso tanto la culpa al olvidar y encajonar esta tarea hasta hoy. Tal vez por esa misma razón mi jefe me asigno la tarea tan amablemente y no me persiguió para que la haga rápidamente.

Resulta que hoy a la mañana, como si algunas neuronas dormidas hayan hecho contacto de repente, se me ocurrieron cuatro riesgos de una! Para darle mas color al relato, estaba viajando al trabajo, eran las 835am, en la cómoda combi que me lleva desde plaza constitución hasta la oficina, tratando de no pensar en una chica que me había roto el corazón hace escasos días, medio dormido, mientras rodeábamos por la avenida Paseo Colon la plaza que se encuentra atrás de la casa rosada, con un sol muy placentero iluminándome y dándome calor gentilmente. Lo que quiero sacar a relucir es que las ideas pueden aparecer en cualquier lado y es algo mágico realmente, si uno se pone a pensar sobre el tema. Los cuatro riesgos que se me ocurrieron, los había incluso reportado anteriormente, pero no como riesgos. Eran cuestiones del proyecto, muy visibles, pero no estaban correctamente registrados.

Consejo: Cuando tengan que administrar riesgos, no piensen que tienen que administrar riesgos, piensen en los problemas y situaciones del día a día de los proyectos, y algún día se les ocurrirá como expresarlos como riesgos.

Emotional Design - Why We Love Or Hate Everyday Things

Emotional Design, de David Norman, explora el diseño de las cosas (desde artefactos domésticos hasta autos o paginas webs), pero no desde la usabilidad, desde el lado emocional.

El objetivo principal de este libro es sacar a relucir que los diseñadores no le prestan la suficiente atención a las emociones que sentimos al utilizar las cosas que se diseñan. Pensando un poco mas el aspecto emocional de los objetos, se podrían crear objetos mucho mas exitosos, ya que la usabilidad en si misma, sin apelar a las emociones de futuros usuarios, no vende un producto.

El autor argumenta que el atractivo emocional de los objetos se puede encontrar a tres niveles. El nivel visceral, que es el que uno siente cuando uno ve el objeto, es el atractivo inicial que uno siente. Luego esta el nivel de comportamiento, donde esta en juego nuestra experiencia (buena o mala) con el objeto, y finalmente el nivel reflectivo, donde entra en juego lo que el producto evoca en uno mismo, la satisfacción a largo plazo.

Finalmente opina sobre el futuro, los robots, y las emociones que deberían tener, ya que sin emociones, no serian tan efectivos ni útiles para los humanos. Realmente un libro muy interesante, te hace pensar sobre aspectos de los objetos que tienen mucho sentido, pero uno nunca le presto atención anteriormente.

Comunicación Efectiva: Factores a tener en cuenta para que el receptor entienda un mensaje

Les dejo unos factores que influyen en el exito de una comunicacion, muy interesantes. En todo mensaje hay un emisor, un receptor, un medio por el cual se transmite el mensaje y un contenido. Muchas veces todos los factores para que la comunicación sea exitosa no se dan, y el mensaje no llega, o llega distorsionado. A veces el problema comienza con el primer actor: el emisor del mensaje. Hay muchos factores que pueden causar que el emisor no sea comprendido correctamente. Todos ellos influyen en la forma en que el emisor emite un mensaje y en que éste llega a nosotros:

Cultura: la forma de expresar nuestros pensamientos se ve influida por nuestra cultura. Nuestro lenguage, nuestros gestos, nuestro lenguaje corporal responden a una cultura. A veces esta es una causa por la cual no entendemos a alguien: no entendemos el contexto de lo que está diciendo. En Argentina decimos “Esto es un penal en el minuto 90″, y esa frase la comprenden (casi) todos. Es parte de nuestra cultura. ¿Qué pasaría su usáramos esa frase en un proyecto multicultural? Respuesta: el emisor no sería comprendido por razones culturales.

Intereses: ¿Qué intereses tiene el emisor al dar un mensaje? ¿Quizás no revelar mucha información o no revelar información necesaria? Preguntémonos esto cuando estamos escuchando el mensaje.

Propósito: ¿Cuál es el propósito del mensaje? ¿Informar? ¿Tranquilizar? ¿Tergiversar?

Edad: este factor tiene que ver principalmente con la cultura.

Personalidad: ¿El emisor es una persona analítica, generosa en los detalles técnicos? ¿Es una persona hábil en la comunicación? ¿No hábil?

Supuestos: “La interface batch en XML con la tabla de clientes no funcionó anoche”. Si el emisor está asumiendo que todos conocen estos términos y no es así, aclararlo.

Credibilidad: cuando dudamos de la veracidad de alguna información, es una buena idea preguntar cuáles son las fuentes de información de dichos hechos.

Retroalimentación: si el emisor toma envión y habla sin parar sin solicitar feedback, muchas cosas pueden salir mal. Se puede equivocar en algo básico al principio que puede influir para mal en todo el mensaje. A veces hay que interrumpir y dar feedback inmediatamente.

Tono: el emisor puede hablar demasiado bajo, demasiado alto. Puede hablar con acento extranjero.

Prioridades: puede ser que la prioridad del emisor sea el tiempo, que sea que todos comprendan (entonces suprimirá los detalles). Puede ser que quiera que solamente la audiencia técnica comprenda.

Todos estos factores influyen en que el emisor sea comprendido. Debemos tener en cuenta cada uno de ellos al ser emisor, y como receptor también, para hacérselo notar a quien está emitiendo el mensaje.

Fuente: Blog Mejores Proyectos

Death by Meeting: A Leadership Fable

El titulo completo de este libro de Patrick Lencioni es "Death by Meeting: A Leadership Fable...About Solving the Most Painful Problem in Business". Es una fabula de liderazgo, es decir, es una novela de negocios donde enseña varios conceptos de reuniones contados como una historia. Realmente es muy entretenido, rápido de leer e interesante, como la otra novela que leí del mismo autor: The Five Temptations of a CEO: A Leadership Fable.

El tema de este libro son las reuniones. El autor tiene razón: las reuniones pueden ser muy aburridas e inútiles. Esto no debería pasar. En las reuniones se debaten temas muy importantes y deberían ser mas entretenidas que una película, porque uno participa y el futuro de uno depende de lo que se decida en estas reuniones.

La historia en este libro trata de una persona que vende su empresa, y un directivo de la empresa compradora va a una reunión de la empresa comprada. Estas reuniones son muy tediosas para todos los directivos de la empresa, y para el presidente inclusive. Este directivo cuestiona al presidente debido a esta pésima reunión que presencio. Un nuevo asistente del presidente se embarca en la tarea de corregir las reuniones de esta empresa.

Lo que termina proponiendo son cuatro tipos de reuniones para los directivos de la empresa:

1. Reunión diaria de 15 minutos, para ver en que anda cada uno (No se si esto se lo habrá copiado de las reuniones diarias de las metodologías de desarrollo ágiles).
2. Reunión semanal de 2 horas para discutir temas tácticos, sobre temas a corto plazo de la empresa.
3. Reunión semanal estrategica, para tratar uno o dos temas (no mas) sobre temas de mediano o largo plazo para la empresa, sin duración definida.
4. Reuniones cuatrimestrales de un fin de semana, fuera de la empresa, para hacer una revisión sobre decisiones estrategicas tomadas durante el periodo, discutir sobre el equipo gerencial, el personal importante de la empresa y el estado de la industria.

Es muy interesante como va contando el progreso de implementación de estas reuniones, como se lo va tomando el equipo de ejecutivos de la empresa y sobre todo la presión que siente el presidente para cambiar las cosas, mejorar las reuniones para mejorar en definitiva la empresa.