viernes, diciembre 31, 2010

Falsos Profetas

Hace un tiempo me dieron un valioso consejo. En Argentina somos orgullosos y a veces los vocablos no son compatibles con lo que el cliente interpreta y quedamos muy poco serios cuando los gurúes, maestro o un genio los gurúes, los masters o los genios terminan siendo falsos profetas. Ya nos ha pasado y el cliente se nos río en la cara.

Cuando se habla con contactos de afuera, conviene llamarlos lideres técnicos, pero no mas que eso.

Un gurú en Silicon Valley es un Phd que invento algo o está a cargo de una amplía área de conocimiento con proyectos de volumen y experiencia world class.

Estamos inducidos a usar estas denominaciones, pero suena mucho mas profesional un mensaje si se expresa con terminología corriente.

jueves, diciembre 30, 2010

Unit Tests en Etapas de Bugfixing

Continuando el artículo de Unit Tests que escribí unos años atrás, les dejo una lista muy simple de pasos para trabajar con Unit Tests cuando se corrigen bugs. Estos pasos deberían ser siempre los mismos:
  1. Crear el test que comprueba el error. Este test TIENE que fallar.
  2. Una vez demostrado que el error falla y SOLO entonces, se modifica el código para corregirlo.
  3. Luego de corregirlo se ejecuta el test nuevamente y se verifica de que el problema este arreglado.
  4. Este test se lo deja y se corre con la integración continua para verificar con cada build que el bug no volvió a aparecer.

miércoles, diciembre 29, 2010

Soft Skills

Las habilidades blandas (o Soft Skills) forman parte de las herramientas que tenemos para salir ilesos de un día laboral. Como el trabajo de PM requiere mucho contacto con personas, estas son mas que útiles. ¿Cuales son? Se las dejo a continuación:

Manejo de conflictos: la habilidad de resolver diferentes puntos de vista en forma constructiva. Sentar a dos personas con visiones opuestas y lograr que todos lleguen a un acuerdo.

Empatía: la capacidad de percibir y comprender los sentimientos y actitudes de otros. La empatía se explica muchas veces con la frase “Saber ponerse en los zapatos del otro”.

Resolución de problemas: la habilidad de identificar los componentes clave de un problema, formular una o varias soluciones y actuar en consecuencia. Conducir bien tu automóvil en una avenida con mucho tráfico es tener esta habilidad, lo mismo dar un buen pase en un partido de fútbol cuando estás rodeado de adversarios (”…identificar el problema, pensar en soluciones y actuar…”).

Responsabilidad por otros: la habilidad por tomar responsabilidades por las acciones de otras personas. Saber confiar. Comprender qué es delegar una tarea y simplemente confiar en el otro.

Inteligencia emocional: la habilidad para entender emociones propias y de otros, y comprender por qué una cierta emoción impulsa a actuar de una cierta manera a un individuo. Yo siempre explico esta habilidad blanda como la capacidad de ver un episodio de una novela latinoamericana en la TV y poder explicar qué pasó y por qué cada personaje actuó como actuó o dijo lo que dijo (admiro esta habilidad en las mujeres, ya que son mejores que nosotros en esto).

Fuente: IAAP

martes, diciembre 28, 2010

Being Geek: The Software Developer's Career Handbook

Finalmente terminé de leer Being Geek: The Software Developer's Career Handbook, de Michael Lopp. Este libro es el segundo del autor (el primero es Managing Humans) y realmente lo disfrute, aunque confieso que el primero me gusto más, ya que desde ese momento comencé a seguir el blog del autor y el libro esta armado con muchos de los artículos que el va escribiendo.

Sin embargo, este libro no tiene desperdicio. Desde el trailer que publiqué hace poco (ver!), surgieron tres artículos de revelaciones que quería compartir:
El libro es una guía de carrera para todos los que trabajamos en el área de informática. Tiene muchas historias y sugerencias para manejar tu carrera, desde como detectar que uno esta mal en el trabajo actual, hasta que tipos de trabajos le vienen mejor a uno para cada momento de la vida. Tiene el contenido justo de humor e informalidad que lo hacen muy ameno para leer. Altamente recomendado!

lunes, diciembre 27, 2010

Scrum: Comprometiendo Nuevas Tareas a un Sprint en Curso

En Scrum es posible que tengan que comprometerse nuevas tareas al Sprint. Esto puede pasar cuando alguien del equipo termina sus tareas y no quedan otras tareas asignadas a otros miembros del equipo que esta persona se puede hacer. También pueden quedar tareas bloqueadas, pendiente de definición del cliente, aunque idealmente las tareas que se comprometen a un Sprint cumplen todas las precondiciones para poder completarse dentro del Sprint.

En este caso, lo que hay que hacer es ir al Backlog y tomar la historia de mayor prioridad que pueda tomar esta persona que quedo libre. Un criterio incorrecto que solía tomar era comprometer la tarea solo si podía llegar a cerrarse dentro del Sprint, esto es cumplir con el "Done Criteria" definido. Utilizando este criterio, no siempre se atacaban las tareas de mayor prioridad para el negocio, que es lo que el cliente prefirió hacer, aunque no se lleguen a terminar las tareas en el Sprint.

En cualquier situación, el gráfico de Burndown va a deformarse uno de esos días, ya que se le agregan horas de trabajo al Sprint, y si las tareas bloqueadas no se sacan del Sprint, nunca se va a llegar a cero. Sin embargo, es recomendable dejarlas para que se vea que se estuvo bloqueado.

Supongo que en mi cabeza hizo mas fuerza el concepto de un Sprint como algo cerrado, tratando de cumplir con el "Done Criteria" de todas las tareas, pero el cliente prefería que se avance con las tareas de mayor prioridad para el negocio, que es mas que comprensible. Lo importante en estos casos ambiguos, es charlarlo con el cliente y tomar una decisión conjunta del criterio a tomar.

sábado, diciembre 25, 2010

Scrum: Como informar inconvenientes que afecten la velocidad del equipo

Cuando un equipo no puede desarrollar sus tareas normalmente, por ejemplo por experimentar errores aleatorios en el ambiente de trabajo, lo natural es sobrestimar las tareas de desarrollo para poder llegar a terminar las tareas. Menciono que es natural, porque sale instintivamente debido a que la mayoría de la gente estuvo en un proyecto con un proceso de desarrollo en cascada, y sobrestimar era la forma con que se trataba este problema.

En Scrum, en una reunión de planeamiento del sprint, cuando todas las historias ya tienen story points y hay que crear tareas y estimarlas en horas, la idea es tener en cuenta que se está trabajando en un ambiente ideal. Si se sufren problemas de ambiente de trabajo, hay dos formas de informar esto.

La primera es bajar la capacidad de los miembros del equipo afectados. Bajando la capacidad en un cierto porcentaje, se tienen menos horas por sprint para asignar tareas. Esto hay que informarlo insistentemente al cliente o a quien pueda ayudar a resolver este problema, ya que claramente queda evidenciado que el equipo puede dar más, pero debido a estos problemas se pueden asignar menos tareas, y entonces la velocidad del equipo se aleja de la ideal.

La segunda es no disminuir la capacidad, pero hacer un tracking de estos errores, teniendo una historia llamada "tareas no planeadas", y cargando tareas con un cierto tiempo para informar estos errores. Esto tal vez tenga mayor visibilidad para el cliente, pero insume mayor tiempo al equipo.

Resumiendo, la idea es dejar atrás el viejo paradigma de sobrestimar y mediante alguno de estos dos métodos, reflejar la realidad del trabajo del equipo para que se tomen acciones y se puedan resolver temas que afectan la velocidad.

lunes, noviembre 29, 2010

Alejandonos del estanque (Trabajando remoto)

Cuando pensamos sobre la comunicación en un gran grupo de personas, podemos pensar en un estanque. Un pequeño y a veces redondo charco de agua medio verdolaga. Se pueden ver los costados del estanque, y casi siempre hay un árbol al costado. Metafóricamente, toda la gente de nuestra organización esta en algún lugar de este estanque. La posición depende de a quien conocemos y de nuestro lugar en el organigrama. Cuando algo pasa en la empresa, cuando algo valioso se dice, una gota cae en la laguna y crea una onda. La onda es información viajando de una persona al resto. Cuanto mas grande la gota, mayor es la onda y mas lejos viaja.

Hay un flujo constante de información en una empresa. Hay gotas constantes que caen el estanque, creando ondas de diferente tamaño, viajando en todas las direcciones y chocandose entre ellas, transformándose en ondas mutantes. Estas ondas mutantes son los rumores, el chusmerio y toda la información bizarra que cruza tu camino durante el transcurso del día.

Si uno esta en el estanque, uno obtiene datos, aunque no estén direccionados a uno. Es inevitable. Es lo que hacemos como seres humanos curiosos. Recibimos información, la digerimos, alteramos y enviamos, transformada a nuestra longitud de onda personal.

Un empleado remoto no esta en el estanque y aunque esta en contacto por email, chat, lee las wikis, etc, hay información que nunca le llega, porque esta nunca deja el estante.

Es posible trabajar remotamente, la persona tiene que tener la personalidad adecuada, el trabajo tiene que ser el correcto y la cultura de la empresa y del equipo lo tiene que sostener.

Como mi ultima serie de artículos, esta genialidad también la saque del libro Being Geek de Michael Loop. Ahora quiero poner mi granito de arena. A mi me cuesta mucho trabajar remotamente. No me gusta. Lo positivo que saco de no viajar se ve terriblemente opacado por lo mal que me siento estando solo y sin poder cruzarme con nadie. Lo hago muy pocas veces, hace como seis meses fue la ultima vez. Mi trabajo consiste en comunicarme con gente. La mayoría de estas comunicaciones las hago informalmente. Me la paso levantandome a charlar y aclarar cosas. Por mail esto se puede hacer, por chat también, pero se pierde mucho dinamismo. Quiero conocer a algún PM que prefiera trabajar remoto, no creo que exista. Trabajé en varios proyectos con equipos remotos, y funciono mucho mejor cuando conocí, por lo menos por un par de horas, a esa gente. Les recomiendo que viajen y conozcan a sus equipos remotos, unos minutos de conversión, una mirada, ver como mueve las manos, como se expresa,todo eso es valiosísimo.

domingo, noviembre 28, 2010

Trabajo en equipo

Quiero compartir con ustedes unas palabras sobre el trabajo en equipo que me gustaron mucho del libro Being Geek de Michael Loop. El autor enuncia que el trabajo en equipo, grupos de gente realmente trabajando junta, es algo mágico. A veces a uno le cuesta llevarse bien con un hermano o pariente cercano que uno conoce de toda la vida, entonces el hecho de sentar un grupo de gente en un lugar determinado y que puedan construir un producto sin matarse entre ellos es un milagro.

Realmente no es un milagro, son años de practica, desde jardín de infantes donde te enseñan lo básico, a decir por favor, a decir gracias, y a no comerte el pegamento.

En mi experiencia, tuve la suerte de formar parte de grandes equipos. Todos son distintos, pero cuando se forma un equipo y funciona, el día a día del equipo es la satisfacción profesional mas grande que uno puede tener. Lo básico para armar un equipo es mostrarse colaborativo con todos y apuntar hacia el objetivo. Todos tienen que tener en claro lo que hay que hacer y todos tienen que tener un mismo nivel de compromiso. Hay que olvidarse del puesto que uno pueda tener y dar todo para llegar al éxito. Se necesita esfuerzo para aceptar a cada uno como es, apreciando la diversidad de personalidades. Hay que estar juntos en los momentos difícil, y reconocerlos y festejar cuando las cosas salen bien.

sábado, noviembre 27, 2010

Como evitar perder candidatos con la propuesta aceptada

Recuerdo que al poco tiempo de haber comenzado a trabajar en un proyecto, teníamos todo listo, ya estábamos comenzando con la primera iteración, pero faltaba una persona que ocupase un puesto clave. En ese momento no había nadie disponible en la empresa ni nadie que se libere en esos meses, entonces se decidió buscar en el mercado. Por suerte se consiguió a alguien rápido. El líder técnico del proyecto y yo hablamos con el, para ver si seria un buen candidato, y le comentamos de que se trataba el proyecto. Realmente era un proyecto muy atractivo y creo que le logramos transmitir la idea al candidato. Obviamente también había sido aprobado por el área técnica correspondiente de la empresa, así que procedimos a contratarlo.

Hasta ahí estaba todo perfecto. En dos semanas íbamos a tener a esta persona que tanto necesitábamos. ¿Que podía salir mal? Esta persona ya había aceptado la propuesta, se había hecho todos los examenes preocupacionales, estaba todo listo. Pero paso lo peor que podía pasar. El viernes anterior al lunes de la fecha de comienzo de esta persona, a las 17hs recibo una llamada del sector de recruiting de la empresa. Me avisaron que esta persona no iba a presentarse el lunes. No recuerdo si era por alguna contraoferta de ultimo momento u otra oportunidad que se le presento. No importa. Lo que importa es que ya no iba a contar con esa persona que tanto necesitaba en el proyecto. Tenia que empezar todo de cero, y era desalentador, porque no se puede conseguir a alguien de un día para otro. Mi proyecto iba a tener que esperar por lo mínimo tres semanas. Me arruinaron el fin de semana.

¿Como resolví la situación? No importa, todo se resuelve. La pregunta valida a hacer en este caso es: ¿Podría haber hecho algo para evitar perder a esa persona? La respuesta es si, aunque no es común tomar acciones para que esto no pase, yo nunca lo había hecho antes. El capitulo Wanted del libro Being Geek de Michael Loop habla sobre esto y me abrió la cabeza. Es increíble cuando uno aprende algo nuevo que nunca se le paso por la cabeza, pero tiene todo el sentido del mundo.

Cada posición abierta surge de una necesidad de la empresa, para cierto proyecto o área. Digamos que existe una necesidad. Otra realidad es que la gente pierde la cabeza en las transiciones laborales, es difícil pensar claramente, ya que uno hace una apuesta grande sin conocer realmente lo que le depara el futuro. La idea es tentar a esa persona para que tome la decisión de cambiar. Si alguien nos parece apropiado para este puesto, hay que decírselo y repetírselo, comentarle que el puesto es perfecto para esa persona. Recordándoselo, uno se vuelve una constante dentro del caos mental del cambio de trabajo. Eso tranquiliza a la persona y aumenta exponencialmente las posibilidades de que el lunes acordado aparezca en tu proyecto. La clave es dedicarle tiempo a esa persona que no entro a la empresa todavía. Llamarlo, escribirle, contarle el estado del proyecto, porque lo necesitamos, contarle que va a hacer. Incluso en el libro sugiere organizar una salida con el equipo actual con esta nueva persona.

Todavía no probé esto, pero la próxima vez que tenga una propuesta aceptada de alguien que necesito voy a seguir los consejos del autor, su razonamiento es simplemente lógico. No prestarle atención a alguien que necesitas y esta por entrar a tu equipo por dos semanas no es sensato.

miércoles, octubre 27, 2010

Being Geek - El Trailer!

Estoy comenzando a leer "Being Geek: The Software Developer's Career Handbook" de Michael Lopp (autor de Managing Humans, un excelente libro). Este libro tiene un trailer que es muy divertido, véanlo y van a querer tener el libro en sus manos, es muy divertido, se los dejo!

Being Geek: The Software Developer's Career Handbook from lonelysandwich on Vimeo.

lunes, octubre 25, 2010

The Goal: A Process Of Ongoing Improvement

"The Goal: A Process Of Ongoing Improvement" es el segundo libro de Eliyahu M. Goldratt que tengo el placer de leer. El primero fue Critical Chain, de 1997. The Goal es de 1993, y como Critical Chain, esta escrito en forma de novela. Esto es muy atractivo porque lo hace un libro muy ameno y accesible, no es para nada pesado.

The Goal cuenta la historia de un administrador de una fabrica en serios problemas. Ante la amenaza de cierre de la empresa, se ve obligado a revertir la situación. Para lograr esto recurre a un viejo profesor que ahora trabaja como un consultor. Con la ayuda de esta persona y los directivos de la planta, resuelve la situación dejando atrás principios que ni dudaba en dejar de aplicar antes.

En este libro introduce la teoría de las restricciones (o theory of constraints, TOC). Una empresa para lograr su objetivo, que es hacer dinero, tiene que identificar la restricción principal (o cuello de botella) y subordinar el resto de la organización en torno a la restricción. Luego de resolver esta restricción, se busca la siguiente y se hacen los cambios necesarios, este es un proceso de mejoramiento continuo.

Lo interesante de este libro es como el autor va contando como los personajes van descubriendo cosas obvias y cambiando su manera de pensar a medida que tienen éxito con sus planes. Es muy interesante y lo recomiendo!

domingo, septiembre 26, 2010

Software Project Survival Guide

Software Project Survival Guide de Steve McConnell, tiene en la tapa el siguiente subtitulo: "How to be sure your first important project isn't your last". Este libro salio en 1997 y creo que es el libro que mas tiempo me llevo leer en mi vida. Tendría que haberlo dejado de leer, pero no puedo hacer eso con libros.

Basta de emociones, este libro cuenta paso a paso como administrar un proyecto exitoso, describiendo todos los procesos, todas las etapas del mismo. El proceso de desarrollo por iteraciones que propone es muy rígido, con mucha documentación, poco practico en estos días, pero mucho mejor que el proceso de desarrollo en cascada que se utilizaba antes de la edición del libro. Muchas de las practicas siguen siendo buenas y son recomendables, y vale la pena recordarlas.

El problema es que el autor no encontró una forma amena de redactar este libro, no lo pude disfrutar. Podría atribuirse que es un escritor de libros técnicos, como Code Complete, aunque eso seria un insulto a los escritores técnicos, hay muchos que son mas entretenidos. Además de eso, no estoy de acuerdo con su rigidez en su visión de la administración de proyectos, pero seguro que para la época estaba bien.

jueves, septiembre 23, 2010

1$:1$

Continuando con mi articulo de 1:1 de hace unas semanas, les traigo una visión distinta sobre este tipo de reuniones. Alguien con mucha experiencia piensa que hay que evitar a toda costa charlar a solas con la gente, para evitar la oportunidad de que reclamen un aumento salarial.

Esto tiene cierto sentido, y realmente pasa, lo vivo día a día, pero manejar estos pedidos es parte del trabajo del project manager. Si la empresa tiene un proceso salarial definido, el trabajo consta en guiar a la gente en ese proceso. Si no, hay que manejar estos pedidos escalándolos y haciendo seguimiento de los mismos.

Hay muchas formas de encarar el trabajo, yo prefiero hablar todo y evitar las sorpresas, pero todos los puntos de vista son validos y suman.

sábado, septiembre 18, 2010

Mi nombre en los créditos de un juego!

Por mi participación en el desarrollo del juego Need For Speed World, de Electronic Arts, salio mi nombre en los créditos, todo un hito para mi carrera profesional!

Mi nombre aparece bajo el rol de Development Director, dentro del "External Development Team", que se pueden ver en la sección creditos de la de página web del juego.

Un articulo para alimentar mi ego :)

viernes, septiembre 17, 2010

Asunciones no cumplidas en Proyectos de Costo Fijo

En el contrato de un proyecto de costo fijo sano se listan diversas asunciones. Muchas de estas son técnicas, otras operativas. Por ejemplo, una asunción técnica puede ser la lista de navegadores web donde tiene que funcionar la aplicación. Una operativa podría ser que el cliente esta a cargo del traspaso de la aplicación a los ambientes de producción. Cuando una asunción no se cumple por el lado del cliente y afecta al equipo, eso es un cambio. En un proyecto con un adecuado control de cambios se elevan estas situaciones, y esto lleva a replanificar los costos y la duración del proyecto si es necesario.

Por ejemplo, hace unos días me paso que el cliente hizo un cambio en el código y nos hizo perder toda la mañana, hasta que llego y lo arreglo. Esto son muchas horas de trabajo en un equipo numeroso. En el contrato existe una asunción que indica que el cliente no puede hacer ningún cambio en el código a utilizar durante la iteración actual. Debido a eso, calcule el tiempo perdido en dinero y arme un documento de cambios, y para explicárselo al cliente, se me ocurrió la siguiente analogía:

Let me explain how this broken assumption thing works with an analogy: Let's say we have to host a concert. I'm the leader of the team who does the setup of the speakers in the arena. Kiana is the person who contracted me, she's the band's manager. The concert is on Saturday, that cannot be moved, the whole audience has tickets and the band has a gig in another town the next day, so the concert needs to happen that day. Let's say that we left the arena at 6pm the Thursday before the concert, and we're slated to continue working at 5am on Friday, as there's a lot of work left. When we get in on Friday's morning to the Arena, we look for the cables to connect the speakers but we can't find them! One of Kiana's guys locked them in a storeroom and we do not have the key. I cannot reach Kiana, and we have to wait until her people get in the Arena to resume our duties, as we cannot test the speakers without power. We have to stay later than planned to finish our jobs, and I have to compensate that to the guys somehow, either with money or by giving them time off in the future, which costs me money as well.
Espero que este ejemplo les de ideas para manejar este tipo de situaciones.

sábado, agosto 28, 2010

1:1

Un 1:1 (One on One) es una reunión entre dos personas. Para mi es la reunión mas útil que existe y me avergüenza que haya empezado con esta practica hace tan poco. Estas reuniones las hago cada dos semanas con todas los miembros de los equipos donde trabajo. Están calendarizadas y hago lo posible para que sean a la hora dada. Muy pocas veces las pase de días. Y nunca dejé que se retasen más de un día.

Las comencé a hacer luego de leer el libro Managing Humans - Biting and Humorous Tales of a Software Engineering Manager que dice lo siguiente de este tipo de reuniones:

My first piece of advice to all new managers is “Schedule one-on-ones, keep them on the same day and time, and never cancel them.” With this mind, some of the trickiest transitions for me during the day are when these one-onones show up. I’m deep in some problem, writing a specification, answering a critical e-mail, and this person walks in my office and they want to talk about I don’t know what . . . I’m working in the zone here, people. In the brief second
I try to figure out some way to reschedule this meeting, I remind myself of a simple rule, “You will always learn something in your one-on-one.” When is your manager giving you a chance to tell him what’s in your brain? I’m worried if your answer isn’t “at a one-on-one,” but I’m not panicking, yet. Maybe your manager is one of these organic types who likes to jump you in the hallway and gather relevant bits. Terrific. Does he do it consistently or when he needs something? The former is great; the latter is a problem waiting to happen. What is a manager learning in a one-on-one? Much of what you’re talking about in a one-on-one your manager already knows. You’re concerned about the reorg, right? Well, everyone is and he’s already talked to four other people about their concerns. You think the field engineers are a bunch of twits? So does he. A good manager has his finger on the pulse of their organization and the one-on-one usually echoes much of that pulse, so why is he carving out 30 minutes for every person on his team? He wants to learn. Whether it’s a one-on-one or a random hallway conversation, your manager should always be in active information acquisition. He should love it when you stop him in the hallway and tell him, “I hate your favorite feature.” See, the thing was, he’s been losing sleep over that feature for the past three days and he can’t figure out why. Your random hatred just shoved his thinking in another direction. Managers who don’t have a plan to regularly talk to everyone on their team are deluded. They believe they are going to learn what is going on in their group through some magical organizational osmosis and they won’t. Ideas will not be discovered, talent will be ignored, and the team will slowly begin to believe what they think does not matter, and the team is the company.

Realmente tiene toda la razón. En la primera 1:1, la idea es conocer a la persona, ver su historia profesional y también personal. Su historia en la empresa es muy importante también Para el resto, la agenda de esas reuniones seria la siguiente:

  • ¿Como andas personalmente?
  • ¿Como andas en la empresa?
  • ¿Como andas en el proyecto actual?
  • ¿Como te llevas con el equipo? ¿Algún problema con alguien?
  • ¿Que feedback tenes? ¿Que cosas están buenas y que cosas se pueden mejorar?
  • ¿Algún comentario? ¿Algo mas?
Algo muy fascinante que me hicieron ver estas reuniones es que rápido pasa el tiempo. Dos semanas no es nada de tiempo.

Para cerrar este articulo, les dejo el cuerpo del mail de la invitación que mando en los 1:1s:


[Nombre],
Te mando este invite para organizar nuestra reunión 1:1. Esta es una reunión que hago con todas las personas con la que trabajo, cada dos semanas, para hacer un seguimiento personal de cada uno. La idea es que no dure más de media hora, aunque puede durar un poco más la primera vez. La idea es ver como andas vos, como andas en el proyecto y como andas en la empresa. Esto no quiere decir que no puedas acercarte a mí el resto del tiempo cuando tenes una duda! Estoy siempre disponible para vos, cualquier cosa llamame, escribime un mail, contáctame por el chat o tackleame en los pasillos. Esta reunión es para tener un rato fijo para charlar cada tanto.
Gracias!

lunes, julio 19, 2010

Como arruinar un proyecto ágil

Les dejo un completo mapa mental o conceptual de como arruinar un proyecto Ágil, muy bien ordenado en los distintos aspectos de esta metodología, con todas las acciones que podemos tomar o dejar de tomar para arruinarla:

(Hagan click sobre la imagen para agrandarla)

Autor: Hedwig Baars

martes, junio 15, 2010

There's No Such Thing As "Business" Ethics

Acabo de terminar de leer "There's No Such Thing As "Business" Ethics: There's Only One Rule For Making Decisions" de John Maxwell, el tercer libro que leo del autor (luego de The 21 Indispensable Qualities of a Leader y Developing The Leader Within You).

Podría clasificarse como un libro de liderazgo y crecimiento personal, abarcando el concepto de la ética, concepto que parece muy complicado, pero el autor lo lleva a algo muy simple. Lo que enuncia el autor es que no existe la ética en los negocios, ni en las relaciones, ni en lo que sea, existe la ética y punto. Existe una única regla a aplicarse en todo tipo de situaciones: ante toda decisión preguntarse como le gustaría a uno que lo traten en esa situación. Es simple pero tiene sentido.

El libro luego esta lleno de ejemplos de aplicaciones de la ética, situaciones y enseñanzas. Realmente es muy entretenido, corto y al punto.

Les dejo cinco simples consejos para exceder esa regla:

1. Treat people better than they treat you.

2. Walk the second mile (do more than just going the extra mile).

3. Help people who can't help you.

4. Do right when it is natural to do wrong.

5. Keep your promises even when it hurts.


domingo, mayo 16, 2010

Managing Humans - Biting and Humorous Tales of a Software Engineering Manager

"Managing Humans - Biting and Humorous Tales of a Software Engineering Manager" de Michael Lopp es un interesante libro de management. Mas que eso es un compendio de historias del autor, cubriendo un sinfín de situaciones, desde como preparar tu renuncia, a como manejarte con gente rara, geeks. Tiene muchos relatos interesantes de la larga carrera del autor. Su visión y experiencia y la forma en que simplifica diversas situaciones es admirable.

El autor dice muchas verdades del negocio. Sabe lo valiosa que es la gente en esto, y da tips para mantener a los miembros valiosos de los equipos interesados.

Lo que me pareció muy sorprendente en un libro de este tipo, es que el autor no se preocupa por la correctitud del lenguaje. Su objetivo es hacernos dar cuenta de ciertas cosas, y para eso utiliza hasta insultos. Realmente refrescante y bienvenido. No todos los días un libro te deja con la boca abierta, mucho menos un libro de management.

Para ver un ejemplo del libro, lean el articulo que escribí sobre los tipos de managers. Luego de leer el ejemplo, les recomiendo que consigan el libro.

martes, mayo 11, 2010

Tipos de Managers

Uno de los capítulos más interesantes del libro "Managing Humans - Biting and Humorous Tales of a Software Engineering Manager" de Michael Lopp es el titulado "Inwards, Outwards and Holistics" donde esos tres tipos de managers. Cada uno de esos tipos tiene distintos trabajos, motivaciones y objetivos. Les dejo la descripción del libro de cada uno de ellos, y al final mi punto de vista personal, disfrútenla:

Inwards: These types of managers are responsible for a small team of folks working on a single product or technology. An inward manager’s vision is focused on their team and their product. While they’re aware there are other things going on in the organization, they don’t tend to be involved cross-functionally unless their team has dependency on an external team. Inwards are often junior managers, but that isn’t always the case. Some very experienced managers have settled into a comfortable groove as inwards because they want to stay near the team and near the code.

Holistics: Traditionally, holistics make up the middle layer of management. Whereas the inward’s vision is pointed down at the individual team, the holistic is staring across the organization. They are likely managers of managers; responsible for multiple products and multiple teams. The holistic’s main job is to figure out what the hell is going on everywhere in the organization. They’re doing this because, as we’ll see in a moment, they’re actually running your company. This is why they’re never in their office; they’re running around gathering information. This constant information acquisition gives the impression that they are spread thin and, well, they are. There’s a ton of information moving around your averagesized company, and staying tapped into that flood is a full-time job. Wait, don’t these holistics have product to ship? No, they have multiple products, but they’ve hired rock star inwards to get the products built to specification and on time so they can focus on figuring out what to build nextaand who they’re going to need to build it.

Outwards: These are the senior managers. VPs, CEOs. The biggest misconception regarding outwards is what they care about. You’d think their number one priority would be the care and feeding of the company. Wrong. The well-being of the company is the responsibility of the holistics. The holistics are the ones who are spending all the time sniffing around the hallways, gathering internal competitive intelligence, and building empires out of talented inwards. The outward’s vision is focused on the outside world. They care about the public perception of the company, the company’s relationship with its customers, the financial community, the world. That’s why they’re never at headquarters, they’re off telling other people what a great job all those holistics and inwards are doing. I’m not suggesting that outwards don’t care about the daily professional shenanigans within the company; they do, but they’ve also hired a group of rock star holistics to run their company. The rub is this: while it’s not their job to run the company on a daily basis, they are accountable for it. Tough gig.
Personalmente, a mi me encanta centrarme en el proyecto que estoy dirigiendo. Mi responsabilidad en este momento de mi carrera es de un manager Inward, pero me encanta recorrer los pasillos, enterarme de todo y charlar con mucha gente. Leer esta parte del libro me hizo dar cuenta que no esta mal lo que hago, que estoy encaminándome a cierto puesto mas holístico, lo cual me encantaría en cierto momento. Me asustaría ser un outwards, por el foco de su trabajo, creo que no es lo mío.

Les recomiendo ya que se suscriban al Blog del autor, es excelente: http://www.randsinrepose.com/

viernes, abril 30, 2010

Un día típico en la oficina

Les voy a contar como se desarrolla un día típico en la oficina para mií. Tengo ciertos rituales que sigo diariamente al pie de la letra.
Ni bien llego a la oficina, corro a prender a Taladrito (mi laptop, apodada así por la calcomanía de un simpático muñequito sosteniendo un taladro, en alusión al Club Atletico Banfield, club del cual soy ferviente hincha). Mientras se prende Taladrito, voy a llenar mi taza (de Banfield, obviamente) con agua. Por suerte tengo un dispenser a 10 metros, y lo visito muy seguido durante el día (por ende, también el baño).
Luego de tomar un poco de agua, me logueo en Taladrito y mientras carga todo voy a buscar un cortado de la maquina de café.
Al iniciar, mi máquina carga el Outlook y el Firefox. Creé un archivo BAT que se ejecuta al inicio con el siguiente comando:
...\firefox.exe "igoogle.com" "gmail.com "facebook.com" "clubabanfield.com.ar" "soydebanfield.com.ar" "ole.com.ar" "canchallena.com.ar" "lanacion.com.ar"
Vuelvo bien rápido de la máquina de café, evitando a todo el mundo, y chequeo en el Outlook la bandeja de entrada y la agenda para ver si hay algo urgente (Igual ya vi todos los mails en la Blackberry cuando caminaba desde mi casa a la estación de tren), y si no hay nada que requiera de mi atención en ese momento, paso unos minutos recorriendo todos esos sitios que el archivo BAT amablemente me abrió en el Firefoxi y en igoogle.com tengo mis feeds RSS que logran que las solapas sean bastantes más de las que fueron abiertas automáticamente.
Luego de eso, comienzo a revisar los mails, tomar acción sobre ellos, revisar mis stickies, y cumplir con mis obligaciones.
Luego de una hora aproximadamante, emprendo mi primer paseo por la oficina, para saludar y ver como anda todos los miembros de los equipos que formo, y también mucha gente de distintas áreas con las que interactúo por razones laborales y extra-laborales también.
Finalmente, se acerca la hora de la primera reunión diaria de algún proyecto. Antes de esto trato de comerme una fruta (generalmente un pomelo) que me traigo de casa.
Mi día laboral se corta por el almuerzo, pero durante la tarde también emprendo varios paseos por la oficina, me gusta despejarme una vez por hora, al menos que este muy complicado o inmerso en alguna tarea.
Luego de cada paseo, lo primero que hago es chequear mail, ver agenda y stickies, para ver con que puedo seguir.
Cierro este articulo con una foto de Taladrito, espero lo hayan disfrutado!

martes, abril 20, 2010

Fue un Honor!

El titulo de este articulo es el comienzo de la ultima frase que me escribió en un mail un cliente. La frase completa es:
It was an honor working with you.
Núnca me habían dicho algo así. Me sorprendió, fue realmente emotivo. Es muy común decir que fue un gusto, o un placer trabajar con cierta persona. Y muchas veces lo decimos de compromiso. Pero nadie puede usar la palabra honor sin sentirlo de alguna forma, por lo menos yo no lo haría.

Conociendo la procedencia del cliente tiene mas sentido esta frase. Es de una empresa en Singapur, pero la persona es de origen Chino. Los orientales tienen un código de honor mas "desarrollado" que los occidentales.

La cuestión es que las oficinas de Singapur de esta empresa cerraban y era una de mis útimas comunicaciones con esta persona y me escribió esta frase, la cual respondí con lo mismo, ya que verdaderamente lo sentía.

Me encanta trabajar con gente, estas pequeñas sorpresas dibujan una gran sonrisa en mi alma.

lunes, marzo 29, 2010

How to Win Friends and Influence People

"How to Win Friends and Influence People" de Dale Carnegie es esta catalogado como un libro de autoayuda. Es uno de los mas exitosos de la historia, ya que vendió mas de 15 millones de copias desde que fue publicado en 1936, y sigue siendo bastante popular, sino no hubiese llegado a mi lista de libros a leer.

En el prefacio, el autor cuenta que entre lo que la gente mas quiere aprender es como manejarse con otra gente. Y que en esa época no había cursos ni libros sobre el tema. Entonces se dispuso a escribir este libro, luego de dar varios cursos exitosos sobre el tema.

Aunque parezca trivial, me resulto muy refrescante leer este libro. Hay varios conceptos y formas de tratar ciertas situaciones que son muy piolas, y que parecen obvias, pero nunca se me hubiesen ocurrido antes de leer este libro. Creo que saque varios consejos que espero implementar en mi vida diaria, en el trabajo y con mi familia también. Se los recomiendo, es lectura muy ligera y entretenida, con muchos ejemplos que dan profundidad a los conceptos presentados en el libro.

Les dejo el titulo de los capítulos del libro:

Reglas para tratar con el prójimo

  • No critique no condene ni se queje
  • Demuestre aprecio honrado y sincero
  • Despierte en los demás un deseo vehemente

Seis maneras de agradar a la gente

  • Interésese sinceramente por los demás
  • Sonría.
  • Recuerde que para toda persona, su nombre es el sonido más dulce e importante en cualquier idioma
  • Sea un buen oyente. Anime a los demás a que hablen de sí mismos
  • siempre de lo que interese a los demás
  • Haga que la otra persona se sienta importante y hágalo sinceramente.

Logre que los demás piensen como usted

  • La única forma de salir ganando en una discusión es evitándola
  • Demuestre respeto por las opiniones ajenas. Jamás diga a una persona que está equivocada
  • Si usted está equivocado, admítalo rápida y enfáticamente
  • Empiece en forma amigable
  • Consiga que la otra persona diga "Sí, sí", inmediatamente
  • Permita que la otra persona sea quien hable más
  • Permita que la otra persona sienta que la idea es de ella
  • Trate honradamente de ver las cosas desde el punto de vista de la otra persona
  • Muestre simpatía por las ideas y deseos de la otra persona
  • Apele a los motivos más nobles
  • Dramatice sus ideas
  • Lance, con tacto, un reto amable

Sea un lider

  • Empiece con elogio y aprecio sincero
  • Llame la atención sobre los errores de los demás indirectamente
  • de sus propios errores antes de criticar los de los demás
  • preguntas en vez de dar órdenes
  • Permita que la otra persona salve su propio prestigio
  • Elogie el más pequeño progreso y, además, cada progreso. Sea "caluroso en su aprobación y generoso en sus elogios
  • Atribuya a la otra persona una buena reputación para que se interese en mantenerla
  • Aliente a la otra persona. Haga que los errores parezcan fáciles de corregir
  • Procure que la otra persona se sienta satisfecha de hacer lo que usted sugiere
Finalmente les dejo un enlace a un pequeño resumen por si les interesa.

domingo, febrero 28, 2010

The Inmates Are Running The Asylum

"The Inmates Are Running The Asylum: Why High-Tech Products Drive Us Crazy and How to Restore the Sanity" de Alan Cooper es un libro enfocado a mostrarnos problemas que trae la poca atención que se le da al diseño de un producto en la actualidad. El objetivo del libro es cambiar la visión corporativa, dejar que la gente técnica maneje el desarrollo de los productos, y agregar profesionales que se encarguen de la calidad de los mismos. No es un manual de como diseñar un producto usable y atractivo a la gente, sino está más enfocado a ser un caso de negocio para convencer a ejecutivos de implementar estas buenas prácticas.

La idea es simple, vivimos atestados de productos difíciles de usar, y amamos los productos que no nos hacen sentir como idiotas. Nos convertimos en leales seguidores de ciertas empresas que satisfacen nuestras necesidades y además nos hacen sentir bien. Esto se traduce en ventas y éxito, que es lo que toda empresa busca. Ace les dejo un pequeño resumen del libro:

Imagine, at a terrifyingly aggressive rate, everything you regularly use is being equipped with computer technology. Think about your phone, cameras, cars - everything - being automated and programmed by people who in their rush to accept the many benefits of the silicon chip, have abdicated their responsibility to make these products easy to use.
The Inmates are Running the Asylum argues that, despite appearances, business executives are simply not the ones in control of the high-tech industry. They have inadvertently put programmers and engineers in charge, leading to products and processes that waste money, squander customer loyalty, and erode competitive advantage. Business executives have let the inmates run the asylum!
In his book The Inmates Are Running the Asylum Alan Cooper calls for revolution - we need technology to work in the same way average people think - we need to restore the sanity. He offers a provocative, insightful and entertaining explanation of how talented people continuously design bad software-based products. More importantly, he uses his own work with companies big and small to show how to harness those talents to create products that will both thrill their users and grow the bottom line.

El libro es muy entretenido, y me abrió la cabeza con ciertas reflexiones del autor. Valió la pena

miércoles, enero 27, 2010

Etiqueta en el correo electrónico

Es increíble en esta época ver la baja calidad de los emails que tenemos que leer en nuestro ejercicio profesional, internamente en una empresa y con clientes también. Es extremadamente importante prestarle mucha atención a los emails que se escriben, sea quien sea el receptor. Ya había escrito sobre etiqueta en correos electrónicos varias veces (acá y acá también), pero estos días me llego una interesante presentación sobre el tema y quiero mostrarles los puntos mas importantes de ella. Disfruten y sigan estos valiosos consejos:

Just like the fine art of dinning, email has prescribed practices and norms. In a nutshell, Email etiquette is a set of unspoken rules which control acceptable behaviour. Failing to use proper etiquette, in this case email etiquette, can harm your relationship with others and leave an ever lasting bad impression.

When should we email?:
Timing is everything, You want your message to reach your audience at a time when they are going to be most receptive.
Don’t email during a meeting/diner/driving/holiday/weekend. If you’re dealing with your backlog emails on the weekend, save them as a draft and send them Monday morning. Don’t send someone an email at a time you wouldn’t call them on the phone

Do not send an email when talking is an option:
Email is an easy means of communication, but should never be chosen if talking is an available option. When possible one should always choose face to face conversation
over an, as it is much more personal, and the chances of the message being misunderstood are much lower.

Never, ever use the ‘To’ field to send a group email:
Use the bcc field to protect the privacy of your recipients. When you send a message to your mailing list, you are essentially providing every reader of the message with the email addresses of all your friends and relations.

Always assume positive intent:
Email lack tone and emotion. Always assume that the email has a positive tone unless you are certain otherwise. It really helps to include a greeting and closing to convey positive intent.

Be concise, Don’t write emails that are too long:
We are all busy. We all suffer from information overload. Keep it short and to the point. A long email is hard to read and can be discouraging for the reader. If you cant avoid a long email, write an elevator summary. Place all important facts and information at the top of the email.

Do re-read your email before you send it:
Not just for typos, check if the tone is appropiate.

Never write an angry or contentious email:
When you are angry, or wish to address a contentious issue, email can be the worst option … and will most likely come back to haunt you! Under such circumstances, a face-to-face or phone conversation is always best

Email that can Land you in jail:
We operate under the illusion that email communication is private. It’s not! A careless email can torpedo your career, or sink the whole company! Think Enron, Think Arthur Andersen, Think Worldcom.

Avoiding the Traps:
There are many industry examples of companies that use sophisticated software to mine email databases for “hot words”. Hot words: “worried”, “can’t sleep”, “confidential”, “confused”, “trouble”. Don’t use such words in your emails.

Only two things to remember:
  • Write email you would like to receive.
  • Think before your write. Think before you send.