Categoría: opinion

Satisfacción del cliente más allá del entregable

Hace un tiempo comenté que estaba muy contento con mi experiencia como Producto Owner. Dicha experiencia positiva no se debió solamente a que recibí un producto acorde a mis expectativas, sino que también resultó fundamental la forma en que se desarrollo el proyecto. Yo suelo referirme a esto como «experiencia de cliente» y es lo que muchas veces hace la diferencia entre un proveedor de servicios de software y otro. Esta «experiencia de cliente» tiene que ver con cuán fácil le resulta al cliente trabajar con el proveedor y dado que me es difícil dar una definición concreta comparto algunas cuestiones que para mi son importantes para tener una buena experiencia de cliente:

  • El proveedor me da visibilidad contínua del estado del proyecto y los siguientes pasos
  • Cuando tengo inquietudes el proveedor me responde en tiempos razonables para mi negocio
  • El proveedor siempre está bien predispuesto a incorporar el feedback que le doy
  • El proveedor entiende las necesidades de mi negocio y sabe adaptarse a los cambios que este requiere

Todas estas cosas se cumplieron durante el desarrollo de SEAL y por ello mi experiencia como Product Owner fue muy positiva.

Creo que en parte, el haber cumplido con los puntos mencionados tuvo que ver en gran medida con metodologia de trabajo utilizada. Usamos un proceso tipo Scrum con las siguientes particularidades:

  • Iteraciones semanales
  • Una reunión de Demo/Planning semanal, de 1 hora, en la que primero repasábamos el trabajo realizado en la iteración pasada y luego planificábamos la iteración siguiente.
  • Luego de cada reunión de Demo/Planning el equipo enviaba dos mails:
  • Una retrospectiva cada X cantidad de iteraciones para mejorar dinámica de trabajo
  • Todo el tiempo el producto estaba disponible en un ambiente de prueba donde podía entrar a ver/probar funcionalidades
  • Ante cada situación que pudiera implicar un retraso o un desvio de expectativas el equipo me informaba para que tuviera la chance de repriorizar
  • Usamos una herramienta de gestión para administrar el backlog de proyecto
  • Utilizamos burndown charts para tener una visión del estado actual de la iteración y proyectar evolución

Sinceramente me he sentido muy cómodo trabajando de esta forma y por ello espero volver a trabajar así en futuros proyectos.

Implementado un pipeline de continuous delivery en .Net

La semana pasado estuve trabajando en el tema de referencia. Como suele ocurrir cuando se trabaja con tecnología Microsoft, el stack de herramientas a utilizar es bastante distinto del utilizado al trabajar con tecnologias no-Microsoft.

Como build server hicimos un primer intento de usar TFS, pues el proyecto ya lo venia utilizando como repositorio de código y herramienta de gestión. Pero luego de dos problemas, desistimos y decidimos apostar a lo seguro: Team City. ¡Ja!, seguro que más de uno pensó que iba a decir Jenkins. No, hace un año aproximadamente analicé ambas herramientas y llegué a la conclusión que para ambientes Microsoft era más apropiado utilizar Team City.

Como herramienta de build usamos MSBuild.

Para realizar los pasajes entre ambientes, dado que nuestra aplicación es web, optamos por la propuesta de Microsoft: MSDeploy.

Continuará…

User Stories vs. Casos de uso

Es común que en una primera aproximación tienda a verse las user stories como análogas a los casos de uso del Proceso Unificado, en el sentido que ambos artefactos describen en cierto modo una funcionalidad del sistema. Personalmente creo que esta analogia no es apropiada, ya que mientras un caso de uso es efectivamente una especificación de un requerimiento, la user story podría a lo sumo el título de dicho requerimiento.

Es más, en un punto podríamos decir que las user stories son en su espíritu contrarias a los casos de uso: mientras que los casos de uso pretenden contemplar los detalles del requerimiento para que el programador pueda realizar una implementación completa y correcta del requerimiento, las user stories son intencionalmente vagas pues lo que buscan es promover el diálogo entre quien debe implementar la funcionalidad y quien la ha requerido.

Agile no funciona con equipos grandes

Simplemente porque no existen equipos grandes. Seamos realista, 50 personas trabajando en un en una sala no son un equipo, son simplemente un amontonamiento de gente. Un equipo es mucho más que un amontonamiento de gente, basta con mirar los equipos deportivos, donde la mayoría no supera los 10 integrantes.

¿Esto implica que no pueden hacerse proyectos grandes? De ninguna manera, si un proyecto por la cuestión que sea require de 50 programadores, entonces simplemente habrá que particionar el proyecto de manera que puede ser desarrollado por 10 equipo de 5 integrantes cada uno.

Continuous Delivery en ascenso

En los últimos 2 meses me he visto involucrado en 3 iniciativas de Continuous Delivery y hoy comienzo un nuevo proyecto para ayudar a una empresa a implementar esta práctica.

En la mayoría de estos últimos casos en los que he participado, partimos de un contexto donde ya estaba implementada la práctica de integración contínua, lo cual facilita en gran parte las cuestiones técnicas. Al mismo tiempo me he encontrado que uno de los principales desafios al intentar implementar la práctica de Continuous Delivery se encuentra a nivel organizacional, ya que require de la participación de otros sectores más allá de equipo de desarrollo.

La herramienta que suelo recomendar es Jenkins con el agregado del plugin Build Pipeline, aunque tengo en mi backlog de experimentos hace un spike usando Travis para aplicaciones hosteados en Heroku.

Sobre las certificaciones profesionales

Por estos dias hay en foro-agiles un interesante hilo de discusión sobre este tema lo cual sumado a algunas consultas que recibí de alumnos en el último tiempo me ha motivido a dedicar estas líneas al tema.

Recuerdo allá por el año 2000, cuando pretendía comenzar a trabajar formalmente en la industria del software, haber pasado por varias entrevistas en las que los entrevistadores me preguntaban por certificaciones. Recuerdo que en aquel momento estaban de moda algunas certificaciones relacionadas a bases de datos (Oracle y DB2)  y a lenguajes de programación (principalmente Java y Visual Basic). Yo no tenia ninguna.

Hoy por hoy, más allá de las certificaciones de índole técnica (Java, .NET, etc, etc) también estan muy de moda las certificaciones sobre temas más «soft» como Project Management, Scrum, etc, etc. Certificaciones que tampoco tengo, ¡ups!

Creo que una forma interesante de analizar este tema es viéndolo desde la óptica de los distintos interesados: por un lado el profesional certificado y por otro quien lo contrata.

Comencemos por la persona que contrata un profesional certificado. En estos casos se espera que la persona certificada tenga ciertos conocimientos/habilidades/experiencia, pero ¿que es en realidad lo que le garantiza la certificación? Bueno, podriamos decir que nada o bien podriamos decir que depende de la certificación. En una simplificación extrema me animo a decir que hay dos tipos de certificaciones:

  • Las del tipo «esta persona tiene conocimientos/habilidades/experiencia» en la temática X
  • Las del tipo «esta persona realizó un curso/actividad» sobre la temática X y dicho curso cumple con ciertos criterios definidos por la autoridad certificante

Puede que simple vista parezcan lo mismo pero no lo son, vuelvan a leerlo detenidamente e intenten encontrar ejemplos.

Desde el punto de vista del profesional certificado estan los beneficios de contar con una certificación los cuales yo resumiría en: engrosar un CV y abrir algunas puertas ya que algunas empresas (para algunos puestos) sólo contratan gente certificada. Entre los beneficios también deberia mencionar la incorporación de conocimiento, pero lamentablemente esto no siempre ocurre.

Personalmente nunca me he certificado en parte porque con mi título de ingeniero siempre ha bastado (aunque en cierto modo un título también es una especie de certificación). Y cuando me ha tocado estar en la posición de contratar gente (generalmente programadores), nunca le dí mayor importancia a las certificaciones. Creo que la mejor carta de presentación son evidencias concretas, y personalmente que una persona haya respondido bien un examen sobre un lenguaje de programación, no me dice si esa persona programa bien. Entonces ustedes se preguntaran ¿que miro para contratar un programador? Miro como programa, le pido que programe algo o le pido que me comparta algo de código que haya escrito, algún TP de la facultad, algún trabajo que haya realizado o algún proyecto open source que haya participado. Lamentablemente son poco los casos en los que me han facilitado código, pero los casos en los que lo han hecho, resultaron ser excelentes programadores.

Bueno, estas son mis ideas, para cerrar dejo una reflexión de Tom De Marco en Peopleware ¿contratarias un malabarista sin ver como hace malabares? La respuesta parece obvia, pero sin embargo hay gente que contrata programadores sin ver como programan.

Impresiones de Venezuela

Debo decir que mi reciente viaje a Venezuela estuvo muy por encima de mis expectativas, a pesar de que ni pisé la playa. En primer lugar el trato de la gente fue impecable, tanto en las conferencias como en día a día. Aprendí muchas cosas de la cultura venezolana: historia, costumbres, vocabulario, etc, etc. Asi fué como me enteré de cuestiones tales como:

  • Que el deporte más popular tradicionalmente ha sido beisbol y que en el último tiempo en futbol ha ganado mucha popularidad poniendose en segundo lugar.
  • Que toman la cerveza bien fría y por eso siempre viene en botellas chicas, pues al tomar en botellas grandes, a la hora de tomar la segunda mitad, ya está “caliente”
  • Que es muy común que las reuniones (de cualquier tipo) comiencen tarde
  • Que el tránsito es un caos. El transporte público es bastante triste y el combustible es muy barato entonces todo el mundo tiene carro (auto).
  • Que la super abundancia de petroleo, es un arma de doble filo, pues es una fuente increible de ingresos, pero al mismo tiempo ha evitado que se desarrollen otras actividades

Tuve la suerte de que algunos amigos venezolanos me llevaran a conocer diversos lugares (algunos turísticos y otros no tanto, gracias Ofelia, Pablo, Eli y Gustavo).

Tuve el privilegio de asistir al clásico del beisbol venezolano: Leones del Caracas VS Navegantes del Magallanes (gracias Carlos, Omar y Yobana)

Como no podia ser otra forma también tuve algunas charlas sobre política, las que me permitieron saber un poquito más del modelo socialista que el actual gobierno intenta implantar y de la situación actual del pais. Y si bien detecté varios puntos en común con la situación argentina, también noté algunas diferencias importantes.  Pero más allá de estas diferencias, creo que tenemos muchas similitudes, tal vez la más notoria sea que somos paises con una gran riqueza de recursos (petroleo, minerales, alimentos, etc, etc) y una gran desigualdad social. Ojala algún día todos podamos sacar provecho de estos recursos y lograr así una mayor justicia social.

¿Hacia donde vamos?¿dominación cultural?

Advertencia: una vez más me tomo una licencia para desviarme de la temática habitual de este espacio. Las líneas a continuación no van a aportarle al lector conocimiento alguno aunque puede que le despierten alguna inquietud.

Estaba yo sentado en el parque de casa tomando mate. El sol comenzaba a ponerse cuando sonó el timbre. Me levanté y me dirigí hacia el portón. Al abrirlo me encontré con dos niñas que disfrazadas de brujas dijeron al unísono: «¿golosina o travesura?»

Algunas prácticas para organizar el trabajo

Hoy quiero compartir algunas prácticas para organizar el trabajo que cobran mayor relevancia cuando uno trabaja de forma independiente.

Establece horarios

Puede que al sentirte más dueño de tus tiempos terminés trabajando en cualquier horario, lo cual luego te lleva a comer en cualquier horario, lo cual te lleva a dormir en cualquier horario, lo cual te lleva directamente a un mal estado de salud.

Estaceble tu horario de trabajo dentro del horario comercial o a lo sumo sólo un par de horas defasado. Al mismo tiempo no te acostumbres a contestar mails de los clientes fuera de tu horario y si lo haces, escribelos, pero no los envies, no es bueno que los clientes se acostumbren a que les respondas en cualquier horario.

Evita el cambio de contexto

Cada cambio de contexto, requiere cierta adecuación lo cual disminuye tu productividad al tiempo que «va limando tu cabeza». Esto lo vivo todos los jueves y me afecta al extremo. Un jueves típico, comienzo el día programando C#, luego doy clases en FIUBA con Smalltalk y finalmente cierro el día dando clases en UNQ con Ruby, al llegar a casa tengo menos cerebro que una lechuga.

Si trabajas en consultoría y debes visitar a tus clientes, intenta aprovechar al máximo cada visita. Yo generalmente intento particionar mi dia en 2 slots: mañana y tarde. Cuando agendo una sesión de trabajo con un cliente busco, dentro de lo posible, que ocupe todo el slot.

Planifica con anticipación suficiente

El planificar tus actividades con anticipación te permitirá acomodarlas mejor en tu agenda y prepararte apropiadamente para llevarlas acabo. Personalmente intento programar todas mis actividades con al menos una semana de anticipación y siempre intento a más tardar el viernes al mediodia tener definida mi agenda de la semana siguiente.

Crónicas del nuevo rumbo

Ya pasaron un par de semanas desde que inicié este nuevo camino y la verdad es que la cosa viene bastante bien. Por un lado tengo algo de trabajo de desarrollo, como para no dejar de «ensuciarme» las manos y por otro lado tengo algunos trabajos de consultoría/capacitación.

Los trabajos de desarrollo me han llevado hacia Ruby y más particularmente a Rails.

Las cuestiones de consultoría están relacionadas a un tema que vengo trabajando hace bastante tiempo: Continuous Integratión. Este breve video resumen el tipo de trabajos que estoy encarando.

Para despedirme les comparto algunos consejos de organización personal que estoy intentando aplicar:

  • Fracciona tu tiempo en slots fijos (al estilo pomodoro) dedicando un slot completo a cada tema. De esta manera evitarás andar saltando constatemente de un tema a otro.
  • Si vas a trabajar en casa, arma tu oficina hogareña, busca un lugar donde puedas concentrarte sin sufrir
    interrupciones
  • Establece horarios de trabajo y respetalos, sino terminarás trabajando a cualquier hora dia y muchas más horas de la deseadas