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.

Agile Project Management with Scrum

"Agile Project Management with Scrum" de Ken Schwaber, es un libro que presenta Scrum mediante practicas de administración de proyectos mas tradicionales. No es un libro que explique Scrum desde cero, recomienda que se tenga algún conocimiento antes de abordarlo, pero igual da una pequeña introducción al principio.

Lo que mas me gusto de este libro es que esta contado por experiencias que tuvo Ken para aplicar Scrum en distintas organizaciones, todas relacionadas a una practica de administración de proyecto. Por ejemplo recuerdo que estaba implementando Scrum en una organización muy tradicional donde no podían faltar los diagramas Gantt en los reportes de estado, entonces cuenta como pasar de un backlog a un diagrama Gantt fácilmente.

Otro dato que da también interesante es como vender un proyecto Scrum a clientes que trabajan generalmente con proyectos de costo fijo, da una serie de tácticas y ventajas a enunciar, aunque el autor recalca que no siempre es posible ni siempre es la mejor solución. Scrum es una herramienta mas, un proceso mas, y aunque lo defiende a muerte, sabe que no se puede aplicar en cualquier ocasión.

Lo mas difícil de Scrum, a mi parecer, es como escalarlo para equipos muy grandes, como hacer distintos equipos Scrum, (un Scrum de Scrums) y que eso salga bien, cuando hay muchas interacciones entre equipos, personas compartidas. Realmente explica muy bien varios casos donde fue aplicado de forma diferente.

Sin embargo, la enseñanza principal que me dejo el libro es que Scrum es altamente adaptable, al ambiente, la organización, la gente. Hay que saber utilizarlo, respetando sus reglas, pero cambiando lo necesario en cada proyecto para llegar al éxito.

Los proyectos de costo fijo y la rotación no van de la mano

En los proyectos de costo fijo la retención de la gente es primordial. La razón de mi afirmación es muy simple: en un proyecto de costo fijo uno acuerda la funcionalidad y el precio de antemano. Esta estimación que uno realiza la hace teniendo a personas en mente, aunque inicialmente pueden ser perfiles, con distinto seniority y skills, que luego se traducen en nombres. Cuando se tiene al equipo listo, un contrato firmado, una fecha cerrada, uno comienza a trabajar con el equipo. Si alguien del equipo se va por alguna razón y es reemplazada, existe un gran costo para que la nueva persona llegue a comprender todo lo que la otra persona sabia hasta el momento de irse. Este costo se basa en todo el tiempo que tienen que utilizar otras personas del proyecto para enseñarle a la nueva persona, y todo el tiempo hasta que esta persona es productiva (La famosa ley de Brooks).

No hay forma de ganar plata con un reemplazo, no veo ninguna. Tal vez si se va un júnior, asignar a alguien de mayor seniority para que aprenda mas rápido. O en vez de asignar a una persona, asignar a dos. Se gasta mas eligiendo ambas.

Una empresa que se dedica a trabajar con proyectos de costo fijo tiene que cuidar mucho a la gente, escucharla, hacer lo posible para que estén bien, para minimizar la rotación. Tampoco se puede esperar que no exista la rotación, para eso se debe asignar un tiempo buffer extra en la estimación.

En una empresa donde se realizan proyectos en la modalidad time and materials, o Staff augmentation la rotación no juega un rol muy importante, ya que los clientes pagan una cierto persona por hora, y si esa persona se va, tiene que pagar las horas de aprendizaje de la nueva persona, aunque al cliente no le guste.

Para cerrar este articulo, una imagen muy graciosa que describe la rotación que estamos viviendo hoy en día:

"Talk time" con el cliente

Hace poco entro un nuevo Product Owner en el cliente (ya que el anterior se fue de la empresa) y se hizo cargo de dos productos que están siendo desarrollados por dos equipos que lidero.

Realmente voy a extrañar al anterior Product Owner, porque se notaba que sabia de lo que estaba hablando, y era muy claro en las conferencias, mails y walk throghs del producto.

Cuando presentaron al nuevo Product Owner en una conferencia me asuste un poco porque hablaba muy rápido ingles, y no se le entendía mucho (Es una persona de India). Luego por suerte le comencé a entender.

El otro día charlando por IM (algo que no hacia con el anterior Product Owner), empecé a preguntarle de como se sentía en la empresa, empezamos a hablar de nuestros trabajos anteriores y como se tenia que ir, acordamos calendarizar 'talk time' para este lunes, para conocernos mejor. Esto va a estar muy bueno para tener un contacto mas fuerte con el cliente, para enterarme mejor de sus prioridades, su forma de trabajo y de esa manera poder ayudarlos mejor. Ultimamente me estaba sintiendo medio flojo, ya que en las conferencias se trataban temas que para ellos eran obvios y nosotros no habíamos considerado, por falta de comunicación y de conocimiento de nuestra parte de lo que ellos necesitan.

Sin escribir mas, espero con ansias charlar con el Product Owner el lunes para mejorar el nivel de servicio que le damos en los proyectos que estamos llevando a cabo para ellos.

The 21 Indispensable Qualities of a Leader: Becoming the Person Others Will Want to Follow

Este es el segundo libro de liderazgo que leo de John Maxwell, y realmente lo disfrute mucho. El primero lo comente en un articulo anterior (ver articulo).

Este libro esta organizado en 21 capítulos donde cuenta 21 cualidades que para el autor son indispensables para ser un buen líder. Este libro es muy ameno, se lee muy rápido ya que es altamente entretenido debido a que en el medio de la expoliación de las cualidades, hay infinidad de historias y relatos reales que se basan en lo que esta explicando.

Leer este libro reforzó mi convicción en lo que quiero seguir, me ayudo a remarcar y reflexionar en puntos débiles de mi persona, actitudes en las que debería mejorar. Es un libro tan fácil de leer que pienso que lo voy a leer una vez por año para ver como ando con respecto a lo que recomienda el Sr. Maxwell.

Mail de despedida de mi primer trabajo

Les dejo parte del mail de despedida de mi primer trabajo. Como muchos sabrán, es una costumbre mandar un mail a todos para despedirse formalmente, y para que se entere gente que no es muy cercano a uno. Ahora que lo pienso, no le veo mucho sentido, pero igual es algo que se hace comúnmente.

Como muchos saben, hoy es mi último día.

En esta relación de tres años y dos días (exactamente), destaco todo lo que aprendí y en quien me convertí, ya que al bajar las alfombradas escaleras de Tucumán, a las 1030am de ese 28 de abril del 2005, no sabía quién era, ni que quería hacer en el mundo del software. Durante estos tres años definí un rumbo, un perfil, como profesional, gracias a los proyectos, los clientes y la gente con la que tuve el honor de trabajar.

Seguidamente destaco a la gente, mis compañeros, el ambiente, la cultura y las costumbres de las cuales me va a costar mucho desprenderme. Fue una experiencia invaluable trabajar estos años acá con ustedes, con algunos más tiempo, con otros menos.

Un abrazo grande a todos!!!

Como verán, no es muy emotivo, ni jugado, ni muy involucrado. Realmente raro para mi, ya que los que me conocen bien saben que soy una persona muy emocional, pero todo se debe al momento que estaba viviendo en esa época.

Notas de lanzamiento de un proyecto (Release notes) - Página wiki de Trac

En este articulo les voy a comentar como armaba las notas de lanzamiento o release notes de un proyecto en una página del wiki de Trac (Trac un software de administración de proyectos web que recomendé anteriormente).

Antes, un poco de teoría de las notas de lanzamiento, conocidas como Release notes o changelog en ingles. Cada vez que uno saca una nueva versión de un producto de software, ya sea esta una aplicación de escritorio o una aplicación web hay que sacar notas de lanzamiento, para informarle al cliente o al receptor del producto en que se diferencia la versión entregada con las anteriores (también se hace cuando se entrega la primera versión del producto, el que no haya una versión anterior no quita de que haya que escribir las notas de lanzamiento).

En un proyecto en el cual teníamos que desarrollar una aplicación web que soportaba la creación de una librería de software, el desarrollo de esta aplicación era incremental. Cada versión que sacábamos editábamos una pagina wiki en Trac, incluyendo lo siguiente:

Nombre del producto - Versión x.x - Fecha de lanzamiento: x/x/x

• Nuevas funcionalidades: Estas son las mejoras o nuevas funcionalidades acordadas para esta versión.
  
• Defectos corregidos: Estos son defectos que fueron encontrados en versiones anteriores y fueron arreglados para esta versión.
  
• Problemas existentes ('known issues'): Estos en especial conviene consensuarlos anteriormente con el cliente, para que no se lleve sorpresas. Es posible que se decida retrasar el lanzamiento de la versión para que se resuelva algún problema existente. Estos también podrían denominarse defectos no corregidos, pero esa nomenclatura es mas dañina.
  

Alguna (o mas de una) de las secciones anteriores puede estar vacía. Además de tener esta pagina wiki dábamos la opción de descargar un archivo DOC con la misma información, el cual era guardado en el repositorio.

Lo mas importante de esto es que cada una de las funcionalidades nuevas, los defectos y los problemas existentes esta cargado en la lista de tareas (o tickets) del trac, y automáticamente son referenciados de esta pagina. Para referenciar un ticket, basta solo con escribir #xx, siendo xx el numero del ticket, y el enlace se creara automáticamente. Esto es muy importante para que cualquier persona pueda ir rápidamente a ver de que se trata cada ítem de las notas.

Agile Software Development

Este libro escrito por Alistair Cockburn se trata (como su titulo indica claramente) sobre las metodologías o los procesos de desarrollo de software ágil.

No trata sobre ninguna metodología en particular (aunque usa como ejemplo XP). El objetivo del autor es contar todas las ideas de fondo del movimiento ágil, el porque de seguir este tipo de metodologías.

Se pasa mucho tiempo describiendo la dinámica de equipo de trabajos, la forma en que fluye la información entre la gente, las necesidades de los clientes, como debería sentarse la gente. Este libro no trata de enseñarte ninguna metodología, lo que hace es venderte las metodologías ágiles teniendo en cuenta que problemas resuelven y como se manejan en diversas ocasiones, y el autor lo hace muy convincentemente.

Lo que explica de maravilla es como cada metodología sirve para cada situación, no nos trata de vender que con una metodología ágil liviana se pueden hacer sistemas donde hay posibilidad de que alguien pierda la vida.

El autor cierra el libro comentando la historia de cuando el y otras eminencias mas se unieron para escribir el manifiesto del desarrollo de software ágil, contando lo difícil que fue ponerse de acuerdo en ese momento entre tanta gente y rescatando el aporte de cada uno en esa reunión. Muy recomendable!

Estudio del Multitasking: Hay solución a sus problemas?

Muchos de nosotros estamos asignados a varias tareas y a múltiples proyectos, y esto crece mediante vamos aumentando nuestra experiencia y capacidad. Se toma como algo natural en el crecimiento profesional, pero todo no es color de rosa en el multitasking, que se define como el arte de hacer mas de una cosa a la vez.

“To do two things at once is to do neither.” Publilius Syros -Roman Philosopher – 100AD

Les recomiendo que visiten el siguiente sitio de Mike Sanders, que explora ese concepto en profundidad. Les transcribo lo que me pareció mas importante de su estudio:

Mike estableció unas métricas y se midió durante un año y este fue el resultado:

• Task Loading - There were now twice as many tasks in my queue each week.

• Completed Tasks - I was completing half as many each week.

• Overtime - I was working double the overtime hours each week; many times over 20.

• Health - My health was poorer; I had gained over 30 lbs, did not exercise, and did not sleep regularly.

• Happiness - Had become relatively unhappy; I had less fun time at home, generally disliked my job, and I was not very happy.

• Relationships - Relationships had become strained at work and at home. They had worsened.

También midió los efectos nocivos del multitasking:

1. Lost task switching time results from the physiological time gap we experience each time we switch tasks This could cumulatively be ~5% of your work day.

2. Poor task engagement results from the productivity lag of cognitive and memory ramp-up after a task switch, This could cumulatively be ~20% of your work day.

3. Faulty task prioritization occurs from accidental or careless decisions to work on the wrong task. This could cumulatively be ~50% of your work day.

4. Task performance errors happen when mistakes are made from incorrect task assumptions or facts. This could cumulatively be ~25% of your work day.

Se concluye que el multitasking es malo. Espero que nadie lo dude. Mike propone la practica de Powertasking para solucionar los problemas del multitasking. Acá están los pasos a seguir:

• Determine your life priority. Answer the question "What do you want" (WDYW)?

• Framed by the answer to WDYW, List and Prioritize all your tasks, both personal and business.

• Create task queues (or triggers) when you engage them to help re-engage your tasks at a later time.

• De-engage tasks properly.

• Delete tasks when you can.

• Delegate tasks when you can.

• Transfer tasks when you can.

• Shave tasks when you can.

• Breathe once in a while, look up, take a walk! People actually stop breathing at their terminals over time!

• Get feedback on your progress in real time and then apply it.

En resumen, la idea principal es hacer una cosa a la vez, y hacerla bien. Entrar completamente y luego salir de esa tarea de la misma forma. Como tenes prioridades bien definidas, sabes cómo seguir! Lean atentamente el sitio de Mike Sanders, no tiene desperdicio.

Código del cliente en proyecto de costo fijo: anulación de la garantía!

Hace poco me enfrente a una situación poco usual en un proyecto de desarrollo de software realizado bajo un contrato en la modalidad de costo fijo.

Resulta que el cliente quería acortar los tiempos de entrega entregando parte de la funcionalidad acordada previamente en el contrato del proyecto. Además, una de las razones dadas era que ellos tenían mayor conocimiento del negocio en esa funcionalidad, ya que trabajaban diariamente con el equipo de negocios que requería la aplicación.

A simple vista no le preste mucha atención a esto. Nuestro mayor miedo fue que el código que nos iban a entregar iba a ser desastroso, que íbamos a tardar mas en integrarlo que en hacer la funcionalidad nosotros mismos.

Luego de unos días, uno de los gerentes nos hizo saber otro problema. Nuestro contrato establece una garantía de un año para cualquier defecto que se encuentre luego del cierre del proyecto. Si ellos tocan el código de alguna forma, se anula la garantía. Yo no tuve esto en cuenta (Mal PM Martin, mal PM!). Es como cuando uno compra una computadora, que tiene el precinto de seguridad, si uno la abre, se pierde la garantía. Esto era algo bastante obvio que no se tuvo en cuenta.

Al final, se le acepto el código al cliente (es difícil decirle no a un cliente) debido a que estaban muy apurados y era una situación muy difícil para ellos.

Por suerte el código entregado fue integrado sin mayores problemas, ahora estamos esperando a ver los errores que nos puedan llegar a reportar!

Midiendo la calidad del código: WTFs por minuto

Software y Poesía

Les dejo esta comparación entre desarrolladores de software y poetas que hace Alistar Cockburn en el libro "Agile Software Development". Muy interesante!

What if software development were not software development? Then what would it be, and what would the experience be like? I suggest that it is like a community writing epic poetry together. I make this comparison not because I think you have experience in community poetry writing, but because I think you don't. Your imagination will supply you with the sorts of contradictions I am interested in evoking.

Imagine 50 people getting together to write a 20,000-line epic poem on cost and time. What would you expect to find? Lots of arguments, for one thing. People trying to be creative, trying to do their best, without enough talent, time, or resources.

Who are the players in this drama? First, the people who ordered the poem. What do they want? They want something they can use to amuse themselves or impress their friends, not too expensive, and soon.

Next we have the key poem designers.

As you might imagine, this began as a one-person project. But our mythical poet found herself promising much more than she could deliver in the given time frame. So she asked a few friends to help. They designated her the lead poet and poem designer. She blocked out the theme and the poem's sequencing.

Her friends started to help, but then they ran into problems with synchronizing and communicating their work. It also turned out that they couldn't get it all done in time. So they added a couple of clerical people, more friends, and in desperation, even neighbors. The friends and neighbors were not real poets, of course. So our lead designers blocked out sections of the poem that would not require too much talent.

What do you think happened?

There was good news: One person was good at descriptive passages, another was good at the gory bits, and another was good at passages about people. No one was good at emotion except the lead poet, who by now was pulling her hair out because she didn’t have time to write poetry, she was so busy coordinating, checking, and delegating.

Actually, a couple of people couldn't leave well enough alone. Two of them wrote pages and pages and pages of material describing minor protagonists, and our lead poet could not get them to cut it down to size. Another few kept rewriting and revising their work, never satisfied with the result. She wanted them to move on to other passages, but they just wouldn't stop fiddling with their first sections.

As time progressed, the group got desperate and added more people. The trouble was that they were running out of money and couldn't really afford all these people. Communications were horrible, no one had the current copy of the poem, and no one knew the actual state of the poem.

Let's give this story a happy ending...

As luck would have it, they engaged a wonderfully efficient administrator who arranged for a plan of the overall poem, an inventory of each person's skills, a time-frame and communication schedule for each part, standards for versioning and merging pieces of the poem, plus secretarial and other technical services.

They delivered the poem to satisfied clients, well over budget, of course. And the lead poet had to go on vacation to restore her senses. She swore she would never do this again (but we know better). Groups have surely have gotten together to write a long poem together. And I am sure that they ran into most of the issues that software developers run into: temperamental geniuses and average workers, hard requirements, and communication pressures. Humans working together, building something they don't quite understand. Done well, the result is breathtaking; done poorly, dross.

Hug a Developer Today

Impresionante video sobre las penurias de los desarrolladores de software. No se lo pierdan

Developing The Leader Within You

Este es el primer libro de liderazgo que leo, y realmente es muy entretenido e interesante. John Maxwell escribió muchos libros de este estilo (estimo que entre tantos debe haber bastante superposición de temas). El tema principal del libro es desarrollarse uno como persona para enfrentar un puesto de liderazgo o mejorar y dar lo mejor de uno en todo lo que hace.

Personalmente, lo que más rescaté es la forma en que me hizo dar cuenta de la importancia de dar el ejemplo, entre muchas otras cosas. Creo que este libro me marco y me dejo pensando sobre muchas cosas de mi personalidad sobre las que tengo que trabajar para hacer las cosas mejor, y eso lo veo como algo muy valioso.

So Long, and Thanks for All the Fish!

En este articulo doy por cerrada una etapa de alta dedicación al Blog. Luego de cuatro meses con por lo menos un articulo por día, decidí tomarme esto con mayor tranquilidad, sin la obsesiva necesidad de escribir tanto.

Voy a seguir escribiendo artículos, voy a seguir leyendo libros, y obviamente voy a seguir trabajando en el apasionante mundo de la ingeniería de software.

Esto recien es el comienzo!

Facts and Fallacies of Software Engineering

Facts and Fallacies of Software Engineering es un reciente (2002) libro de Robert Glass donde enuncia 55 hechos y 10 falacias de la ingeniería de software, cuidadosamente indicando las fuentes de cada uno de ellos y antes presentando una discusión y controversias sobre el tema.

Es un libro muy valioso, porque realmente te abre la cabeza. Hay pocas verdades que pueden llegar a sorprender a cualquier persona que esta en el mundo del software hacer rato, es mas, hay verdades que pueden herir a mas de uno. Yo no estuve muy de acuerdo con varias de ellas. Lo mejor fue que muchas me sorprendieron gratamente, entre ellas verdades sobre el mantenimiento de las cuales escribí ayer.

El objetivo de este libro es hacer pensar a la gente, presentar estos hechos para que se pueda discutir y actuar sobre ellos para progresar. Lo considero esencial para cualquier practicante de la ingeniería del software.

Les dejo los hechos resumidos en una oración que obtuve del Blog Coding Horror:

People

1. The most important factor in software work is the quality of the programmers.
2. The best programmers are up to 28 times better than the worst programmers.
3. Adding people to a late project makes it later.
4. The working environment has a profound impact on productivity and quality.

Tools and Techniques

5. Hype (about tools and technology) is a plague on the house of software.
6. New tools and techniques cause an initial loss of productivity / quality.
7. Software developers talk a lot about tools, but seldom use them.

Estimation

8. One of the two most common causes of runaway projects is poor estimation.
9. Software estimation usually occurs at the wrong time.
10. Software estimation is usually done by the wrong people.
11. Software estimates are rarely corrected as the project proceeds.
12. It is not surprising that software estimates are bad. But we live and die by them anyway!
13. There is a disconnect between software management and their programmers.
14. The answer to a feasability study is almost always "yes".

Reuse

15. Reuse-in-the-small is a solved problem.
16. Reuse-in-the-large remains a mostly unsolved problem.
17. Reuse-in-the-large works best in families of related systems.
18. Reuseable components are three times as hard to build and should be tried out in three different settings.
19. Modification of reused code is particularly error-prone.
20. Design pattern reuse is one solution to the problems of code reuse.

Requirements

23. One of the two most common causes of runaway projects is unstable requirements.
24. Requirements errors are the most expensive to fix during production.
25. Missing requirements are the hardest requirements errors to correct.

Design

26. Explicit requirements 'explode' as implicit requirements for a solution evolve.
27. There is seldom one best design solution to a software problem.
28. Design is a complex, iterative process. Initial design solutions are usually wrong and certainly not optimal.

Coding

29. Designer 'primitives' rarely match programmer 'primitives'.
30. COBOL is a very bad language, but all the others are so much worse.

Error removal

31. Error removal is the most time-consuming phase of the lifecycle.

Testing

32. Software is usually tested at best to the 55 to 60 percent coverage level.
33. 100 percent test coverage is still far from enough.
34. Test tools are essential, but rarely used.
35. Test automation rarely is. Most testing activities cannot be automated.
36. Programmer-created, built-in debug code is an important supplement to testing tools.

Reviews and Inspections

37. Rigorous inspections can remove up to 90 percent of errors before the first test case is run.
38. Rigorous inspections should not replace testing.
39. Post-delivery reviews, postmortems, and retrospectives are important and seldom performed.
40. Reviews are both technical and sociological, and both factors must be accommodated.

Maintenance

41. Maintenance typically consumes 40 to 80 percent of software costs. It is probably the most important software lifecycle phase.
42. Enhancements represent roughly 60 percent of maintenance costs.
43. Maintenance is a solution-- not a problem.
44. Understanding the existing product is the most difficult maintenance task.
45. Better methods lead to more maintenance, not less.

Quality

46. Quality is a collection of attributes.
47. Quality is not user satisfaction, meeting requirements, achieving cost and schedule, or reliability.

Reliability

48. There are errors that most programmers tend to make.
49. Errors tend to cluster.
50. There is no single best approach to software error removal.
51. Residual errors will always persist. The goal should be to minimize or eliminate severe errors.

Efficiency

52. Efficiency stems more from good design than good coding.
53. High-order language code can be about 90 percent as efficient as comparable assembler code.
54. There are tradeoffs between optimizing for time and optimizing for space.

Research

55. Many researchers advocate rather than investigate.

Para cerrar el artículo de hoy les dejo las 10 falacias:

1. You can't manage what you can't measure.
2. You can manage quality into a software product.
3. Programming can and should be egoless.
4. Tools and techniques: one size fits all.
5. Software needs more methodologies.
6. To estimate cost and schedule, first estimate lines of code.
7. Random test input is a good way to optimize testing.
8. "Given enough eyeballs, all bugs are shallow".
9. The way to preduct future maintenance costs and to make product replacement decisions is to look at past cost data.
10. You teach people how to program by showing them how to write programs.

No hay que desmerecer a los proyectos de mantenimiento

Estoy leyendo un libro titulado "Facts and Fallacies of Software Engineering" de Robert Glass y encontré unos hechos o "facts" sobre el mantenimiento en la ingeniería de software que me parecieron interesantes y compartí con el equipo del proyecto en cual trabajo (Que se trata sobre mantenimiento de varias aplicaciones) y tambien quiero compartir aca.

En este libro el autor presenta hechos y falacias, luego discute, luego cuenta las controversias alrededor del mismo y finalmente cita las fuentes.

Maintenance typically consumes 40 to 80 percent (average, 60 percent) of software costs. Therefore, it is probably the most important life cycle phase of software.

Corolario: Old hardware becomes obsolete; old software goes into production every night.

Enhancement is responsible for roughly 60 percent of software maintenance costs. Error correction is roughly 17 percent. Therefore, software maintenance is largely about adding new capability to old software, not fixing it.

The 60/60 rule: 60 percent of software's dollar is spent on maintenance, and 60 percent of that maintenance is enhancement. Enhancing old software is, therefore, a big deal.

Maintenance is a solution, not a problem.

Far too many people see software maintenance as a problem, something to be diminished and perhaps even "obliterated." In saying that, they are really expressing their ignorance. The only way that software maintenance could be a problem would be if nearly all of it were about fixing errors. And we have already seen that it's not. Far from it, in fact. Maintenance, instead, is software's unique solution to the problem "we built this thing, but now we wish we had built something a little different."

In examining the tasks of software development versus software maintenance, most of the tasks are the same-except for the additional maintenance task of "understanding the existing product." This task consumes roughly 30 percent of the total maintenance time and is the dominant maintenance activity. Thus it is possible to claim that maintenance is a more difficult task than development.

Maintenance life cycle:

• Defining and understanding the change-15 percent
• Reviewing the documentation for the product-5 percent
• Tracing logic-25 percent
• Implementing the change-20 percent
• Testing and debugging-30 percent
• Updating the documentation-5 percent

Better software engineering development leads to more maintenance, not less.

Systems built using "modern development methods" were more reliable than those built using older ways. They required repair less often. But those systems required more time tomaintain them. How could that be?

These systems took longer to maintain than the others because more modifications were being made to them. And more modifications were being made because it was easier to enhance these better-built systems. Most organizations have a long backlog of enhancements to be made to their software products (Software 1988). The better-built systems were simply making their way through those enhancement queues faster than their more poorly built brethren.

Referencias: Facts and fallacies of software engineering, Robert Glass, 2002

Historial de versiones en una página Wiki de Trac

En este articulo voy a dejarles el simple código para armar una tabla con el historial de versiones en una página del wiki de Trac (Trac un software de administración de proyectos web que recomendé anteriormente).

Historial de versiones en una página de Trac

Siempre es recomendable mantener información de versiones en los wikis para ver rápidamente quien agrego que cosa, aunque también esta información esta accesible viendo la historia de este wiki (ya que Trac trabaja con control de versiones sobre los wikis).

Les dejo el código para que ingresen sobre todas sus paginas wikis en Trac. Para agregar una nueva linea, simplemente hay que copiar la ultima y cambiarle los datos.

===== Revision History =====
||Version||Date ||Author||Notes||
||1.0 ||2006.08.17||John||First draft||
||1.1 ||2006.08.31||Jane||Added this and that||

-----

Matemática... ¿Estás ahí?

Realmente me cuestan las matemáticas. No es algo que oculte. Debido a que me cuestan, siento rechazo por ellas. Es común sentir miedo o emociones negativas a algo que desconoce o que le cuesta. Igual siempre le vi un atractivo a ellas y este libro me ayudo a encontrarles un lado muy interesante.

En este libro, Adrián Paenza, quien es licenciado, doctor en matemática, y periodista, pretende contarle al lector sobre diferentes temas atrapantes de la matemática, dando a conocer distintos problemas de cierto interés y contándole al lector sobre diferentes propiedades y teorías pertenecientes a la matemática que podrían ser calificadas como divertidas; y declara que pensar puede ser algo entretenido. Como se señala en el resumen del libro, entre estos conceptos, problemas y demás relacionados con la matemática, Paenza le habla al lector de temas tan diversos como de los diferentes tipos de infinitos, de los números primos, la división por cero, las apuestas y las probabilidades, etcétera.

Hay tres libros en la serie. Hasta ahora leí los primeros dos, tengo que comenzar a leer el ultimo. Por suerte todos los libros están disponibles para bajarse gratuita y legalmente para uso personal. Les dejo los links:

Matemática... ¿Estás ahí?
Matemática... ¿Estás ahí?: Episodio 2
Matemática... ¿Estás ahí?: Episodio 3,14

When you ASSUME you make an ASS out of U and ME

Olvidándonos de la frase que titula a este articulo, todos los días hacemos asunciones, ya que son una parte natural y lógica del proceso de toma de decisiones. El problema se encuentra en:

1. Hacer asunciones en vez de tomar decisiones precipitadas: Cuando no puedo investigar algún tema tengo que tomar una asunción. Si puedo encontrar información fácilmente, demuestra que no hice mis deberes y tome una decisión precipitada.
   
2. Comunicar las asunciones al equipo: El equipo va a poder detectar errores!
3. Realizar seguimiento de las asunciones: El equipo va monitorear las asunciones que les comunicaste y va a saber cuando consultarte para revisar una decisión que tomaste cuando surge un problema
   

Para mas sobre este tema, les recomiendo que lean: Real World Decisions III: Making assumptions and jumping to conclusions

The Five Temptations of a CEO: A Leadership Fable

Este libro de Patrick Lencioni esta escrito en forma de fabula. Cuenta como un CEO de una empresa que tiene la reunión anual con los accionistas de la empresa al día siguiente se encuentra con unos extraños personajes en el tren, que le comentan las cinco tentaciones en las que puede caer un CEO. Realmente es un libro muy entretenido que te deja reflexionando sobre la forma en que uno actúa ante ciertas situaciones en la vida laboral (sea o no sea uno un CEO). Les dejo las cinco tentaciones de una crítica al libro, aunque igual les recomiendo que lo consigan y lo lean ya que van a poder entender cada una de ellas mucho mejor.

1. Soft-pedaling your drive to achieve results, tending instead to avoid making decisions that might damage your ego or reputation;

2. Wanting to be liked by peers and direct reports (It is lonely at the top, isn't it?), therefore shying away from holding them accountable;

3. Hesitating to take decisive action, (and/or hold direct reports accountable), until more information is in hand. In a world of imperfect and ever-shifting information, the CEO can project vague and hesitant direction to his/her reports, at the risk of paralysis;

4. Restricting "productive ideological conflict" among the management team during decision-making, a temptation motivated by a desire for harmony and/or a fear of conflict; and,

5. Overtly or unconsciously portraying himself/herself as invulnerable, discouraging direct reports from challenging his/her ideas, in turn preventing the foundation of trust that can steady an organization through hard times.

Gracias Ivo por la recomendación!

Las leyes de Murphy generales y para IT (Murphy's Laws of Information Technology)

Las famosas e infames leyes de Murphy son conocidas por todo el mundo. Se aplican a todas las disciplinas humanas, pero estoy seguro que al software le afecta mas de lo común, debido a la juventud de esta actividad. Les dejo las principales leyes de Murphy:

• Nothing is as easy as it looks.
• Everything takes longer than you think.
• Anything that can go wrong will go wrong.
• If there is a possibility of several things going wrong, the one that will cause the most damage will be the one to go wrong. Corollary: If there is a worse time for something to go wrong, it will happen then.
• You never run out of things that can go wrong.
• If anything simply cannot go wrong, it will anyway.
• If you perceive that there are four possible ways in which a procedure can go wrong, and circumvent these, then a fifth way, unprepared for, will promptly develop.
• If everything seems to be going well, you have obviously overlooked something.
• It is impossible to make anything foolproof because fools are so ingenious.
• Whenever you set out to do something, something else must be done first.
• Every solution breeds new problems.

Dejando atrás las leyes generales, entremos en las leyes de Murhpy aplicadas a IT, que son las originales extrapoladas a este campo.

Sobre Hardware:

• Law of Inconvenient Malfunction: A device will fail at the least opportune possible moment.
• Law of Cable Compatibility: If you choose a cable and a connector at random, the probability that they are compatible is equal to zero.
• Law of Hardware Compatibility: The probability of a given peripheral being compatible with a PC is inversely proportional to the immediate need for that peripheral.
• Law of Bad Sectors: The probability that an untested diskette will have bad sectors is directly proportional to the importance of the data written onto the diskette.
• First Law of Selective Gravitation: When an object is dropped, it will fall in such a way as to cause the greatest possible damage to itself and/or other objects on which it lands.
• Second Law of Selective Gravitation: The tendency for an object to be dropped is directly proportional to its value.
• Law of Reality Change: Unalterable hardware specifications will change as necessary to maximize frustration for personnel affected by said specifications.
• Law of Noise: Noise bursts occur so as to cause the most, and/or most serious, errors in data communications, regardless of the actual amount of noise present.
• Law of Expectation: Consumer expectations always outpace advances in hardware technology.
• Law of the Titanic: If a device cannot malfunction, it will.

Sobre programación:

• Law of Debugging: The difficulty of debugging software is directly proportional to the number of people who will ultimately use it.
• Law of Neurosis: The chances of software being neurotic (developing bugs spontaneously without apparent reason) is directly proportional to the confusion such neurosis can cause.
• Law of Available Space: If there are n bytes in a crucial software program, the available space for its convenient storage or loading is equal to n-1 bytes.
• First Law of Bad Sectors: The probability of software being mutilated by bad sectors is directly proportional to the value and/or importance of the programs.
• Second Law of Bad Sectors: When a program is mutilated by bad sectors, the damage will occur at the point(s) that result in the most frequent and/or severe errors when the program is run.
• Law of Noise: When a downloaded program is corrupted by noise, the corruption will occur at the point(s) that result in the most frequent and/or severe errors when the program is run.
• Law of Software Compatibility: If two programs are chosen at random, the probability that they are compatible is equal to zero.
• Law of Option Preferences: When two people share a computer, their software option preferences will differ in every possible way.
• Law of Expectation: Consumer expectations always outpace advances in software technology.
• Law of the Titanic: Bug-free software isn't.

Ver Referencia.