La milla extra

Existe un término en inglés "The extra mile" o la milla extra, que suele utilizarse para referirse a ir más allá de la obligación, de lo acordado o esperado.

Creo en general, que las empresas que contratan servicios de IT a otras compañías esperan siempre esta milla extra y en algunos casos hasta lo pueden llegar a reclamar: "no hicieron más que lo que estaba acordado, no aportaron ningún valor nuevo" podría ser una queja al respecto.

Como empleados de una compañía, creo que la milla extra es lo que habla de nuestro compromiso con la firma, del seniority que tenemos para leer lo que se espera y cómo podemos mejorarlo. Está claro que todos debemos cumplir con nuestro trabajo (eso es lo de mínima), pero generalmente sólo progresan dentro de una compañía los que aportan esta milla extra.

No siempre la milla extra requiere esfuerzo adicional. Para esto voy a poner un ejemplo:

La semana pasada estábamos con mi mujer en unas vacaciones cortas. Buceando la tarde anterior, mi mujer había tenido un percance en una uña. Esta vez su kit de viaje no incluyó una lima, por lo que fuimos a la recepción para pedir una. La respuesta fue que no tenían. El tema quedó ahí para nosotros. El hotel estaba en una zona alejada y no teníamos acceso a negocios fuera del complejo.

Después de cenar, cuando volvimos a la habitación, sobre la cama había una lima nueva en un sobre con el nombre del hotel. Obviamente nuestra sorpresa fue muy grata.

Cuando agradecí por el gesto la mañana siguiente, me comentaron que todas las tardes suelen ir a una farmacia para hacer compras diversas. En este caso, agregaron una lima que posee un costo insignificante y que además, nunca nos cobraron.

Creo que como empleados y como proveedores de nuestros clientes siempre debemos estar buscando esta milla extra, para mejorar cada día un poco más.

Llamados telefónicos vs Mails

Los que ya tenemos varios años de experiencia en el desarrollo de software estamos muy acostumbrados a dejar constancia de nuestros actos, pedidos o notificaciones a través de los mails que enviamos y que resguardamos para hacer frente a reclamos cuando el proyecto se encuentre en situación crítica: ¿por qué nos atrasamos? ¿quién es el responsable?

Sin embargo, podemos correr el riesgo de sobreutilizar este mecanismo, contando con que el enviar el mail, y pasar la responsabilidad del próximo acto (la pelota está del otro lado de la red) es suficiente.

No digo que no debamos guardar esos mails, todo lo contrario. Pero creo que muchas veces podemos enviar el mail y luego hacer un seguimiento telefónico, o viceversa: avisarle a la otra persona que le estaremos enviando un mail para asegurar que las dos partes entendimos lo que se acordó por teléfono.

Tengamos en cuenta que todos atienden el teléfono ni bien suena (si están sentados en su escritorio) pero no todos leen y contestan sus mails con suficiente regularidad. No podemos contentarnos con decir: "yo lo avisé". Recordemos que uno de los principios del manifiesto ágil: "Colaboración con el cliente por sobre negociación de contratos" No alcanza con no "quedar pegados", tenemos que ser agentes de cambio, actuar y forzar a que las cosas ocurran. Entonces, la próxima vez, mandemos el mail, pero hagamos seguimiento por teléfono.

Prácticas Empresariales - MUG Argentina

A continuación, les paso el link de la capacitación que dicté sobre Prácticas Empresariales en el MUG

La fuerza de los lazos débiles

Leyendo The Tipping Point me encontré con un concepto interesante.
Se trata de la fuerza de los lazos débiles. Según otro libro publicado en 1974 (Getting a Job), más de la mitad de las personas habían conseguido su trabajo a través de contactos personales, aunque curiosamente, la mayoría no fue gracias a amigos, sino de contactos con los que uno se relaciona raramente.

¿Cuál era la razón? Los lazos débiles para encontrar trabajo, nueva información, nuevas ideas, son más importantes. Nuestros amigos, en general, viven nuestra misma realidad. ¿Cuánto de lo que ellos sepan no lo sabemos ya nosotros?

Son nuestros contactos los que nos van a permitir acceder a otras realidades.

Entonces: ¿cómo difundir las metodologías ágiles? No empezar por nuestros amigos/compañeros de trabajo, ellos ya nos conocen, saben cómo insistimos con el tema, lo pesados que podemos ponernos, eventualmente incluso, ya las deberían estar usando, según nuestro poder de convicción. Hagámoslo a través de nuestros contactos. Ellos tienen otra realidad, todavía pueden estar sufriendo con metodologías antiguas!

Introducción a OpenUP - MUG Argentina

A continuación, les paso el link de la capacitación que dicté en el MUG sobre OpenUP.

Si encuentro una forma más fácil de publicar el documento (o me la recomienda alguien) la cambio.

Notas del PMDay

Ayer participé del PMDay 2008. Si bien por cuestiones de agenda (lease, trabajos, incendios, etc) no pude asistir a todas las charlas, pude participar de las de Linda Vella y la de Diego Quiroga.

Algunas notas:
La charla de Linda no me gustó. Demasiado orientada a vender los cursos de PMP. Por ejemplo, mostró un slide donde intentaba evidenciar cómo variaba lo que cobra un PM según su certificación. El slide (lamento no haber sacado una foto) mostraba los ingresos anuales sin PMP, uno con el PMP certificado, pero con 1 año de experiencia (casi el mismo ingreso) y cómo un PMP certificado iba incrementando sus ingresos a medida que ganaba experiencia. Mi lectura del slide: vale más la experiencia que la certificación.
Además, no me gustó la forma en la que se hizo traducción simultánea. Si bien sé que es caro alquilar auriculares para los asistentes, el tener que interrumir la charla cada 20 palabras y esperar la traducción, cortaba todo posible ritmo.
Por otro lado, la charla prometía aportar valor obtenido de un estudio de 3 años. O me quedé dormido (cosa que sé que no ocurrió) o los resultados no se mostraron o no aportaron nada.

La otra charla fue de Diego Quiroga de Globant.
Diego tuvo el coraje de hablar de metodologías ágiles en una charla de PMI. O no se dieron cuenta, o se quieren subir a la ola (convengamos que en Argentina, el 70% de los participantes de cursos de PM son gente de sistemas, y que las prácticas del PMI suenan mas a Metodología en Cascada que a las ágiles).

Me quedo con algunas ideas que transmitió y que comparto de la experiencia que tengo trabajando en proyectos remotos:

• La confianza que se posee al arrancar el proyecto es fundamental. Hay que invertir recursos para no perderla. Las comunicaciones son contadas y detalles superfluos pueden ser tomados como evidencia de tendencias.
• No hay que perder el contexto. El estar en otras latitudes puede ir quitándonos ese feeling que se puede tener del proyecto y de las compañías involucradas que se posee naturalmente cuando los equipos trabajan en el mismo edificio.

Justificación Económica del Modelo Ágil

Mas allá de la justificación tradicional que tienen las metodologías ágiles, existe una justificación económica, que si bien es dificil de medir con exactitud, no debe ser obviada.

El modelo en cascada tradicional entrega valor al usuario recién a partir de la publicación de la versión 1.0 o su equivalente. Esto ocurre cuando el producto está terminado, fue testeado en su completitud y fue aceptado por el usuario. Para llegar a este punto, han transcurrido seguramente varios meses. De hecho, debe haber finalizado el proyecto, o encontrarse en una instancia de transición o algo similar.

En el modelo ágil, se realiza una entrega temprana, pudiendo validar las expectativas del usuario, pero sobre todo, pudiendo transformar el producto de software en una pieza que, si bien incompleta, ya puede ser utilizada, y por lo tanto, comenzar a entregar valor. Obviamente, es de vital importancia detectar no sólo las dependencias con otras funcionalidades (no tiene sentido entregar un auto sin motor, pero con el sistema de cierre centralizado funcionando) sino también, qué es lo que en forma parcial ya puede comenzar a entregar valor.

Sucesivas entregas iran incrementando el valor del software entregado. A diferencia del modelo en cascada, deberemos esperar a que se cumpla un nuevo proyecto, por ejemplo, versión 2.0 para recibir la nueva versión. Posiblemente, esta última versión resuelva funcionalidades de nuevos requerimientos, no necesariamente estará incrementando valor. En el modelo ágil, con entregas cortas, el valor se irá incrementando con cada entrega, aumentando así, la superficie de valor agregado.

La Ventana Rota y la calidad del software

Hace tiempo se hizo famosa la teoría de la ventana rota. Básicamente, lo que dice es que si hay una ventana rota y no es reemplazada, la gente que pase caminando por ahí va a pensar que a nadie le importa y que no es responsabilidad de nadie. Rápidamente aparecerán más ventanas rotas, expandiendo la sensación de anarquía, enviando la señal de que nada de lo que pase tendrá importancia, de que colapsó el sistema. En una ciudad, problemas menores como graffitis, basura en las calles, etc. son equivalencias de la ventana rota, invitaciones a crímenes mayores.
Una forma de prevención, es resolver estos problemas cuando todavía son menores.

¿Qué relación tiene todo esto con el desarrollo de software?
La percepción de la calidad. ¿Cuántas veces por poner foco exclusivamente en los errores mayores no nos fijamos en detalles que hacen a la calidad que perciben los usuarios?

Algunos ejemplos:
• Tab Order (cómo va pasando el control entre los campos de una pantalla al presionar la tecla tab)
• Palabras con errores de tipeo o faltas ortográficas
• Campos sobre los que no controlamos el formato de ingreso
• Mensajes de error sin tratar, por ejemplo: mostrando la excepción que arrojó la base de datos sin explicar qué es lo que significa

¿Cuál es el resultado de todo esto?
Estamos dando la impresión de que estos temas (posiblemente otros más) no son importantes para nosotros, no nos preocupan, no nos interesan.
¿Cuál es la solución?
En primera instancia resolverlos. Si bien los errores deben ser tratados con prioridad, dejar errores que no tienen costo de reparación muestran que el control ha colapsado.
En segunda instancia, si no damos a basto con las correcciones por estar con bugs críticos, mostrarle al usuario a través de un issue tracker que los tenemos identificados, que los consideramos como errores que deben ser corregidos, y que están en nuestro roadmap.

¿Cómo vender un proyecto ágil?

Esta es una pregunta recurrente que surge en casi todas las charlas de metodologías ágiles.
Sabemos que realizar una propuesta o definir un alcance cerrado es un riesgo.
Según el Standish Group, la mayoría de los problemas del desarrollo de software no son técnicos, sino que están entre otros, en los requerimientos.

¿Relevamos mal? ¿Deberíamos dedicar más recursos? ¿Lograr mayor compromiso del usuario por lo acordado?
No necesariamente. Muchas veces el relevamiento es adecuado, el usuario lo entiende y lo acepta.
¿Qué pasa entonces? La realidad que sustenta el alcance cambia: cambian las necesidades, la tecnología, la legislación, etc.
¿Es esto evitable? No, y tampoco debemos esperar que no ocurra. Justamente lo contrario: la capacidad de adecuarnos, de ser ágiles para cambiar el rumbo, es la principal ventaja de las metodologías ágiles. Por eso lo de "abrazar el cambio"

Vuelvo a la pregunta inicial: ¿cómo convencemos a nuestros clientes, los usuarios, de trabajar en el marco de un proyecto ágil en lugar de uno con alcance cerrado?
Recuerdo la respuesta de Tobias Mayer en la primer capacitación de SCRUM que se dictó en Latinoamérica. Fue más o menos algo así: "Este es un problema comercial, no del proyecto" Scrum resuelve la problemática de los proyectos, no los comerciales.
La respuesta de Tobias es cierta. Pero no nos deja satisfechos. Es que estamos, en general, en una instancia previa. Antes de convencer a nuestro cliente, debemos convencer a nuestros comerciales, a nuestra dirección.

¿Cómo podemos hacerlo?

• lo primero: buscar entregas cortas que puedan ser puestas en producción rápidamente.
• acordar un alcance macro (por un tiempo macro) del alcance del sistema a ser revisado en cada iteración.
• identificar qué es imprescindible: Siempre hay dos o tres cosas que tienen que estar sí o sí. Que dan forma al desarrollo que estamos planeando. Una vez que las identificamos, resolverlas en las primeras instancias.
• concientizar a los usuarios que un alto porcentaje de software desarrollado nunca llega a usarse.
• dar libertad al usuario para suspender el proyecto al final de cada iteración, sea porque se alcanzó la funcionalidad más importante, o porque se perdió el objetivo del sistema. Esto es parte de ser ágil.

Tablero de Control o Collar de ahorque

Y la pregunta es siempre la misma: ¿para qué sirven los planes de proyecto?

No quiero caer en el error que si somos ágiles, es peso del que podemos prescindir. Nada más errado. Ser ágil no quiere decir ser desordenado.

Todo proyecto debería tener un plan acordado entre las partes, principalmente, el cliente (se interno o externo) y nosotros. Es el punto en el que nos pusimos de acuerdo sobre cómo vamos a ejecutar y controlar el avance del proyecto.

Ahora: ¿el proyecto tiene que atarse al plan o el plan atarse al proyecto?

¿Es un tablero de comandos? Podemos imaginar el de un auto, donde indica temperatura del motor, nivel de combustible, aceite, etc
¿Es un collar de ahorque? ¿Dentro del plan todo, fuera del plan nada?

Como siempre, no hay una respuesta única. Si la hubiese, no existiría la pregunta….

Peter Drucker decía que un plan es un conjunto de buenas intenciones más que un compromiso. Creo que esto podría reformularse de la siguiente forma: "un plan sirve para saber que hay que actuar en cuanto deja de cumplirse"

Ya sabemos que escribir un plan para no seguirlo y olvidarlo no es ágil: es estúpido, simplemente, una pérdida de tiempo.

¿Y al revés? ¿Cómo detectamos cuando queremos forzar la realidad: el alcance, el desarrollo, al cliente a restringirse a ese plan que le hicimos firmar con sangre?

Algunos indicadores:

• Cuando empezamos a discutir sobre lo que se quiso decir en el plan. Indicador: estamos queriendo volcar el plan para nuestro lado y así ganar la discusión.
• Cuando no vemos alternativas al plan. No es que es la mejor opción. No estamos encontrando alternativas. Como diría un scrum master: Es el arte de lo posible. Siempre hay soluciones alternativas. El plan no deben ser orejeras que nos impidan ver otras posibilidad, incluso si se encuentra fuera del plan.
• Cuando en las reuniones siempre hay alguien que lo pueda recitar de memoria: los talibanes del plan. Esto no ayuda. Nuevamente, el plan es una guia, pero nunca… nunca la realidad

Ok, el plan dejó de cumplirse… y ahora?
¡Ahora a escribir un nuevo plan!