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!