Dejar de empezar para empezar a terminar, o como un arquitecto IT puede organizarse

Empezar a terminar

El trabajo de un arquitecto IT en una empresa requiere muchas veces de enfrentarse a tareas de diferente índole, tamaño o prioridad. Estas, llegando a "la mesa de entrada" del departamento de arquitectura se convierte de manera muy fácil en un continuo inicio de nuevas actividades, y cuando nos queremos dar cuenta tenemos en nuestro backlog decenas de tareas sin terminar, lo que nos termina convirtiendo en un cuello de botella, y nos transforma en una pelota de stress y nervios.

Pensando en como resolver este tema y comenzar a destrabar tareas y ser mas eficientes, es necesario manejar de mejor manera el flujo de actividades que pasa por arquitectura. 

Una alternativa podría ser buscar la forma de que nos lleguen menos tarea, revisando si debiéramos hacer todo lo que hacemos, y definiendo claramente los procesos y límites del área. Muchas veces esto no es posible o, aún haciéndolo, seguimos en la misma situación. En estos casos, debemos dejar de empezar una tarea tras otra, y enfocarnos en comenzar a terminarlas.  De esta manera seremos mas eficientes, aumentaremos la calidad de lo que producimos, minimizaremos el riesgo de nuestras actividades y reduciremos el nivel de stress al que estamos sometidos. 

Gerald M Weinberg, en su libro Quality Software Management - System Thinking estima que el cambio de contexto entre tres tareas nos consume un 40% de nuestro tiempo de trabajo. Esto quiere decir que si tengo un proyecto A, B y C y tenemos 40 hs netas productivas por semana (eso con suerte, muchos tenemos la agenda abarrotada de reuniones y nos quedan menos de 20 hs productivas por semana), estaremos gastando 16 hs en el cambio de contexto entre las tareas, tratando de volver al nivel de conocimiento que teníamos antes de dejarla por iniciar otra actividad. Y solo nos están quedando 8 hs semanales para invertirle a cada proyecto.

Supongamos por un rato que podemos priorizar los proyectos A, B y C del párrafo anterior, y que decidimos arbitrariamente que vamos a hacer una tarea por vez, eliminando el cambio de contexto. En este escenario, tendríamos las 40 hs por semana para cada proyecto, lo que nos permitiría terminar el mas prioritario en menos tiempo. Siguiendo con este ejemplo, y para que nos quede claro el impacto que tiene el multitasking, supongamos que cada uno de los proyectos A, B y C se pueden hacer en 4 hs cada uno, y que el orden en que están nombrados indican su prioridad. Haciéndolo de la forma en que trabajamos habitualmente, los tres en paralelo, la línea de tiempo sería:

Para hacer el ejemplo mas simple, tengamos en cuenta que el cambio de contexto nos lleva una hora (es menos, y depende mucho de las tareas). En este caso, terminaríamos el proyecto A en la hora 19, la tarea B en la 21 y la tarea C en la 23. Pero el proyecto A era el mas prioritario, y solo lo entregamos dos horas antes del C!. Creo que podemos hacerlo mejor.

El siguiente cuadro muestra la línea de tiempo de ejecutar los proyectos anteriores uno a la vez:

Como se ve, se elimina el cambio de contexto, lo que nos produce una mejora enorme en nuestra productividad. El proyecto A lo terminamos en la hora 4 (versus la hora 19 de nuestra forma de trabajo habitual), el B en la hora 8 (versus hora 21), y el C en la hora 12 (versus hora 23).

Se que el ejemplo es bien simple, y que en el día a día trabajamos con tareas y proyectos mas complejos, con interdependencias, y con muchas distracciones que nos distancian de este mundo ideal planteado. Pero ver las cosas de esta manera nos permite acercarnos a una primer aproximación de como mejorar la forma en que hacemos las cosas.

Una buena forma de poner en práctica esta forma de trabajo es seguir los principios de Kanban en nuestro día a día. Lo bueno es que no requiere cambiar de procesos ni estructura. Podemos seguir organizados y trabajando con el mismo proceso, pero debemos hacerlo diferente.

Kanban

Kanban es una derivación de dos palabras japonesas: Kan - visual, y ban - tarjeta, lo que significaría algo como "tarjeta visual" o "visualización a través de tarjetas". Es un enfoque de trabajo basado en principios básicos, que busca asegurar un flujo continuo de actividades, y que las que se realicen primero sean realmente las mas importantes. Esto lo asegura siguiendo 5 principios simples:

1. Visualizar el flujo de trabajo, lo que asegura comprender el flujo y como funciona.
2. Limitar la cantidad de tarea en curso. Esto asegura que terminemos las tareas mas prioritarias, antes de comenzar con la siguiente tarea, limitando la cantidad de tareas en paralelo, reduciendo el context switch, lo que reduce los errores, el riesgo y los dolores de cabeza.
3. Gestionar el flujo, midiendo de manera simple, supervisando la ejecución y mejorando donde sea necesario.
4. Explicitar las políticas de proceso. Al visualizar como se trabaja, se hacen explícitos vicios ocultos o problemas no detectados, lo que es un disparador para la mejora.
5. Mejorar en forma continua y colaborativa. El proceso debe cambiar y evolucionar de manera continua, y evolucionar en forma constante.

Sobre como usarlo para arquitectura, ya lo dejo para otro post.

Leer mas

Se cierre de una etapa

Recién hoy, un día antes de emprender un nuevo proyecto laboral, es que caigo realmente en el cambio que estoy realizando.

Estoy dejando atrás casi 3800 días, casi 126 meses, casi 11 años. Viéndolo en números parece ser algo frío que no dice nada, pero estoy dejando atrás muchas experiencias, mucha gente querida, mucho aprendizaje. Mucho.

En todo este tiempo cambiaron muchas cosas. Cambió mi vida:

• Cuando entre a Personal no estaba casado. En unos días cumplo 5 años de casado.
• Cuando entre a Personal no era ingeniero. Me recibí de ingeniero, hice una especialización y una maestría.
• Cuando entre a Personal vivía con mis padres. Hoy vivo con mi esposa, en nuestra casa.
• Cuando entré a Personal era un gilun bárbaro. Ahora lo soy un poco menos, o eso espero.

Conocí también mucha gente, muy valiosa:

• Gente de la cual aprendí a ser mejor persona
• Gente de la cual aprendí a tener paciencia
• Gente de la cual aprendí a valorar
• Gente de la cual aprendí a escuchar
• Gente de la cual aprendí a negociar
• Gente de la cual aprendí a templar mi espíritu
• Gente de la cual aprendí
• Gente a la cual espero haberle dejado al menos un poco de lo que me llevo de ellos.

Hoy cierro una etapa, muy buena, realmente muy buena. Mañana abro otra. Espero sea la mitad de buena que los días en mi trabajo anterior.

Leer mas

Que implica hablar de arquitectura IT en una empresa grande

Hace unas semanas tuve el placer de dar participar de Arqconf 2014, la primer conferencia de arquitectura de Argentina, organizada por un grupo de nerds en el cual me incluyo.
En mi presentación hablé sobre que significaba la arquitectura en una empresa grande. En este post voy a transcribir una parte de la presentación, sobre cuales son las cosas que impactan el pensar en arquitectura en una empresa grande.
No voy a hablar sobre la teoría económica que define que es una Pequeña, mediana o gran empresa por variables duras y aburridas que para lo que estoy intentando transmitir no viene al caso.
Voy a contar que es una gran empresa desde el punto de vista de IT (y mi punto de vista), y mas puntualmente desde un área de arquitectura de IT dentro de una gran empresa.

Para graficar y ayudarme a transmitir la idea, armé el siguiente gráfico, que tiene 4 áreas o ejes diferentes. 

Yendo en el sentido de las agujas del reloj, estos son:

• •Mercado: Todas las soluciones que hacemos desde IT la hacemos para alguien. Estas cuestiones se refieren a quien o quienes están apuntadas las soluciones IT que desarrollamos y mantenemos.

• •Tecnología: agrupa todos los conceptos relacionados a las tecnologías disponibles para crear soluciones IT, o sea con que herramientas técnicas contamos para poder pensar las soluciones que creamos.

• •Negocio: Trabajamos para crear soluciones que soporten un negocio, cualquiera que sea. Este grupo categoriza las cuestiones relacionadas al negocio, que tenemos que tener en cuenta desde IT.

• •Política: Las empresas funcionan en un entorno político interno y externo que nos golpea directamente a la hora de pensar en arquitectura en una gran empresa. 

Cualquier empresa no funciona sola, sino que también se ve impactada por cuestiones externas. Por ese motivo cada cuadro representando a cada una de las categorías tiene un cuadro en su interior. ] El cuadro mas interno tiene en cuenta los aspectos internos de la empresa, mientras que el externo las cuestiones fuera de la empresa.

Veamos cuales son las cosas que nos impactan en el desarrollo de soluciones IT en una gran empresa:

Mercado

Estamos hablando de empresas que tienen decenas de miles de empleados. Y no solo eso, sino que en empresas altamente dependientes de las tecnologías, como las empresas de servicios, la gran mayoría de esos empleados son usuarios periódicos de los sistemas que desarrollamos. 

Para no dejarla tan simple, estos miles de usuarios internos no piensan todos iguales, tienen diferentes grados de preparación y realizan diferentes tareas, por lo que existe mucha diversidad cultural.

Esto se acrecienta cuando vemos afuera de la organización. En empresas de servicios o ya cada vez mas en todos los rubros, cuando hablamos de gran empresa estamos hablando de compañías con millones de clientes, en algunos casos siendo estos usuarios activos y constantes de las soluciones IT que mantenemos. 

Piensen en una empresa de telefonía, cada vez que ustedes llaman por teléfono, cada bit que consumen de internet, eso repercute en alguna solución IT de la empresa que les provee este servicio. 

Es mucho! Y, obviamente, como estamos hablando de personas, y de millones, hay diferencias culturales importantes, que debemos tener en cuenta.

Tecnología

En general se da que las grandes empresas fueron creciendo a partir de soluciones mas simples, integrándose con otras compañías o desprendiéndose de otras unidades de negocio, lo que lleva a que el ecosistema IT este formado por una diversidad de aplicaciones “legadas” enorme (varios cientos de soluciones IT) que integradas brindan el servicio a los usuarios. Sería muy simple si estas soluciones estuvieran desarrolladas en la misma tecnología. Lamentablemente no es así, por lo que en las grandes empresas se pueden ver casi todas las tecnologías disponibles, a modo de un museo tecnológico en vivo.

A la hora de pensar soluciones nuevas, es necesario tener en cuenta no solo la diversidad tecnológica, sino también cuales son los perfiles disponibles en la empresa y afuera de la misma (no sea cosa que la tecnología que decidamos sea la mejor, pero que para poder implementarla debamos contratar a un grupo de 4 locos que inventaron la tecnología que queremos implementar, a los cuales no les interesa trabajar con nosotros).

También hay que tener en cuenta las tendencias de la industria, para poder validar que la solución que planteamos tenga vida en el tiempo (tengamos en cuenta que las grandes empresas les gusta juntar aplicaciones, es su hobbie).

Negocio

Hacemos soluciones IT para soportar un negocio. Las áreas internas nos piden soportar nuevos productos, nuevos mercados y mas clientes, para poder hacer frente a la competencia y seguir las tendencias del mercado. Es muy importante tener esto en cuenta e intentar adelantarnos.

Es necesario conocer la industria para la que trabajamos, las tendencias en la misma, y entender como las mismas nos impactan en las soluciones IT que creamos y gestionamos. 

Una de las misiones principales de un equipo de arquitectura en una gran empresa es adelantarse a los requerimientos internos, interpretando de antemano lo que pueda pasar y pensando las soluciones para poder soportar los requerimientos venideros. Es algo parecido a futurología o magia negra a veces, pero es también algo muy desafiante y divertido al mismo tiempo.

Política

Las empresas en cierto aspecto son entidades muy políticas, y cuanto mas grande es la empresa, mayor es su política interna. Es inevitable, por eso debemos tenerla en cuenta, comprender las restricciones que puedan existir, y lidiar con ellas.

Las empresas no funcionan solas, sino que se deben regir por las normativas del país o países donde funcionen, y la economía de los mismos. También debemos comprender como estas cuestiones impactan en el mundo IT.

Concluyendo...

Las empresas grandes son entidades muy complejas desde lo estructural, lo que lleva muchas veces a que la interrelación, comunicación y trabajo en conjunto para crear soluciones sea algo muy complicado. Así, en ese contexto, como dicta la ley de Conway, “Las organizaciones que diseñan sistemas están limitadas a producir diseños que son copias de las estructuras de comunicación de estas organizaciones.”. Yo iria un poco mas allá, y diría que las soluciones IT diseñadas por una empresa es fiel reflejo no solo de sus estructuras de comunicación, sino también de su historia, sus restricciones y políticas. 

Una de nuestras principales misiones como arquitectos es lidiar con estas cuestiones, para:

• Convertirnos en el nexo entre diferentes áreas y mejorar la comunicación, luchando contra la ley de Conway

• Conocer las restricciones, pero no vencernos ante ellas

• Conocer la historia y razones que llevaron a la situación actual, pero para poder cambiar el rumbo

• Conocer la política de la compañía, para usarla en favor de crear mejores soluciones.

Leer mas

Implementando agile en una empresa tradicional

Acabo de leer una nota de InfoQ acerca de la necesidad de entrenar y acompañar a los gerentes de IT (y sumaría de las áreas clientes) en metodologías ágiles para asegurar que se implemente de manera exitosa las políticas y prácticas propuestas.

Leer esta nota me hizo pensar en la tarea que estamos encarando en la empresa para cambiar la forma de trabajo en IT, buscar mayor agilidad, previsión y calidad en lo que producimos.

Desde fin del año pasado estoy empujando la implantación de metodologías ágiles en la empresa. Es un cambio cultural enorme y un desafío profesional que me propuse encarar con todas mis energías.

En un principio eramos unos pocos locos los que iniciamos con la idea de agilizar la forma en que producimos software, basándonos en metodologías ágiles (luego la base sería SCRUM), los principios de Lean y la filosofía de DevOps. Ese grupo de 3 o 4 locos con un conocimiento previo casi nulo comenzamos a estudiar y leer mucho, para luego sentar las bases de la nueva forma de trabajo que íbamos a proponer, y comenzamos la cruzada de sumar adeptos para formalizarlo.

Una vez que formamos una masa crítica de gente convencida de que era necesario cambiar, era necesario hacer que el efecto contagio escalara a toda la organización. Comenzamos de la manera tradicional, presentando al top management lo que proponíamos como cambio. Luego de una presentación de unas horas compraron el cambio (volveré a este punto en un rato), con lo que teníamos luz verde para seguir escalando a toda la empresa (una empresa con miles de empleados, con una base de personas que trabajan en IT del 5%). Las tareas que nos propusimos (y realizamos) fueron:

1. Medir la temperatura de las ganas de cambio. Esto lo hicimos mediante presentaciones, charlas y talleres con el equipo IT. La conclusión de esta actividad fue que todos queríamos cambiar, que no podíamos seguir trabajando como lo estábamos haciendo. Eso era muy bueno. Pero también nos dimos cuenta que si bien todos querían el cambio, nadie quería empujar ese cambio, y esperaban que alguien lo hiciera. Decidimos ser nosotros el motor de ese cambio.
2. Selección de herramientas que soportaran la metodología. Uno de los problemas detectados en las herramientas que soportaban la metodología actual era la falta de una herramienta que permitiera una trazabilidad end to end desde el requerimiento a la implementación, y el hecho de que dicha herramienta (o el proceso implementado) tenía mucha burocracia y una automatización casi nula. Luego de mucho analizar, decidimos implementar varias herramientas de Atlassian, sumadas a otras para resolver problemáticas puntuales (Grunt, Selenium, Bower, Artifactory)
3. Organizar y dictar talleres sobre la nueva metodología, para establecer las bases teórico-prácticas. Preparamos y dictamos talleres sobre:
1. SCRUM
2. Gestión de requerimientos y planificación ágil (inception, user stories y user story mapping)
3. Pair Programming, TDD y BDD como prácticas básicas para asegurar calidad y compartir conocimientos.
4. Demo de la suite de herramientas que soportarán la metodología
5. Talleres de acompañamiento prácticos para comenzar a trabajar con agile en un proyecto real.
4. Proponer nuevas maneras de contratación para servicios de desarrollo y testing, de forma tal que se amoldaran a las filosofías agile.
5. Contar con una consultora especializada en metodologías ágiles para ayudarnos a dar los primeros pasos, y brindar capacitaciones formales sobre agile.
6. Sumar al área de recursos humanos al cambio cultural, para brindar soporte y acompañarnos con el gran cambio que significa salir de una metodología tradicional e ir a agile.

Este último punto es crucial, ya que es muy necesario ver este tipo de cambios como una modificación de la cultura organizacional, y no como un mero cambio de la forma en que trabaja IT. Hicimos y estamos haciendo un excelente trabajo en conjunto. Una de las tareas que realizó el equipo de gestión de cambio fue un assessment de las personas principalmente impactadas por el cambio, para entender que acciones se debían realizar. En las conclusiones de ese análisis surgió un punto que lamentablemente no me sorprendió, y que tiene mucha relación con como comencé este post. El principal punto de atención no era el miedo (que existía), ni la aversión al cambio (inexistente por suerte). Sino que veían que los gerentes no compartían la visión que comunicábamos y compartíamos con ellos.

Atentos a este warning, disparamos acciones adicionales:

1. Sumar a los talleres al top management.
2. Sumar al top management a las capacitaciones formales.

Es necesario que todos estén convencidos y sumados a la filosofía propuesta por agile, para lograr que sea un éxito. Ya que no es solo un cambio en la forma en que programamos, gestionamos requerimientos o analizamos. Es un cambio cultural y organizacional que abarca, también:

• Como contratamos y gestionamos proveedores
• Como planificamos un proyecto y medimos su avance
• Como definimos y manejamos el budget
• Como tratamos con nuestros clientes (internos y externos).

Podríamos haber hecho las cosas diferentes, seguro, pero estoy convencido que dimos y estamos dando todos los pasos necesarios para lograr trabajar de una manera mas eficiente, que nos permita crear software de calidad, y ser felices trabajando sin luchar contra las burocracias de una gran empresa.

Leer mas

Miedos de estudiar ingeniería en un adolescente

La semana pasada tuve la oportunidad de participar en una actividad que organiza Junior Achievement junto a varias empresas, una de ellas Telecom. Esta actividad, llamada "Socios por un día" busca que adolescentes finalizando la secundaria compartan un día de trabajo con un profesional de la carrera que eligieron. Yo estuve acompañado durante ese día por una chica de un colegio de Flores, a la que pude mostrarle diferentes aspectos del trabajo en IT en la empresa:

• Una reunión con el top management de IT
• Ver como trabajan los analistas, desarrolladores y personas de soporte IT
• Ser parte de una actividad de entrenamiento / cambio cultural que estamos realizando

Ella se fue muy contenta, y yo también. Creo que la convencimos de seguir nuestro camino. Durante el tiempo que compartimos, me fue contando los miedos que le daba la carrera. Me pareció bueno compartir las dudas, y las respuestas que le di, ya que dichas inquietudes deben ser compartidas por varios.

Me da miedo que la carrera sea difícil

Todas las carreras son difíciles, tal vez las ingenierías un poco mas aun, pero ninguna va a ser fácil. Lo que si me imagino que debe ser realmente muy difícil, es estudiar una carrera que no te apasione ni que te haga feliz, solo porque desde afuera pareciera mas simple.

Uno debe buscar seguir una carrera que lo haga feliz. Si se logra eso, todo se hace mas simple.

Me da miedo que no me guste y tenga que abandonar

Uno no sabe como va a terminar una historia antes de empezarla. Así como no sabes como termina un libro antes de leerlo o una película antes de comenzar a verla, no sabes que puede pasar con tu vida personal o profesional. Es algo que se va dando de a poco, con las decisiones que tomas todos los días.

Lo que uno tiene que tener en mente es un objetivo de vida, y hacer que las decisiones que uno vaya tomando te lleven a cumplirlo (o cambiarlo!).

No esta mal cambiar el rumbo mientras se esta andando, si ese cambio te hace ir a algo que te divertirá y gustará mas.

Me gustaría una carrera donde no tenga que exponerme ante gente todo el tiempo

Una de las mejores cosas que tiene trabajar en sistemas es que uno puede virtualmente hacer lo que mas le guste, todo depende de las decisiones que vayas tomando. Podes trabajar en cualquier industria (desde farmacéutica hasta servicios, pasando por empresas de producción) y en diferentes roles, en un abanico que va desde roles con mucha relación interpersonal a roles con mas introspección y trabajo individual. Todos los roles son importantes y necesarios, por lo que podes hacer lo que mas te haga feliz.

Una cosa que es necesario tener en cuenta desde antes de empezar, es que ocupar un puesto gerencial no es el único final de la carrera. Uno puede ser un excelente especialista en alguna o muchas cosas durante toda su carrera, y eso esta buenísimo!

Me gustaría una carrera que me permita trabajar en el exterior

Hoy en día IT es una de las carreras con mayor salida laboral en el exterior. Lo que si, tene en cuenta que hacen falta muchos ingenieros y especialistas IT en Argentina, así que evalúa quedarte!

Me da cosa tener que saber inglés para estudiar sistemas

Si bien no es obligatorio saber inglés para estudiar sistemas o trabajar en IT, es un punto importante. Hoy en día aún mucho conocimiento de la industria se genera y comunica en ese idioma. 

Si no te gusta aprender idiomas, te vas a dar cuenta, con el correr de la carrera, que te va empezando a gustar, mas teniendo en cuenta que queres viajar al exterior!

¿Como empiezo a trabajar en sistemas?

Existen muchísimas posibilidades para empezar a trabajar en sistemas, y esa es la primer decisión que tendrás que tomar en tu carrera.

Podes comenzar trabajando para una consultora de sistemas, como analista, desarrollador o tester trainee, para luego ir avanzando en otras tareas o aspectos. Este es un buen camino para empezar, ya que en general estas empresas ponen foco en capacitar a chicos que recién entran, y asignarles tareas en proyectos grandes en poco tiempo (no voy a hablar de las cuestiones éticas que tiene esta práctica). Te permitirá tener experiencia en un corto plazo.

Podes buscar entrar a una empresa que tenga un área de sistemas y un programa de pasantías. Esto lo podes buscar fácilmente en la facultad. En general son trabajos part-time, lo que te dará tiempo para ir ganando experiencia de a poco, sin dejar de darle dedicación al estudio.

Otra alternativa es, en paralelo con la carrera, hacer un curso corto de programación o sobre alguna tecnología. Esto te permitirá tener trabajos free-lance desde tu casa. No vas a conocer el mundo empresarial de esa manera (cosa que no esta para nada mal, puede ser muy bueno mantenerse alejado de las empresas), pero vas a ganar experiencia en la auto-organización, la negociación  y a defenderte, hecho no menor.

Lo que si, si trabajas, busca la forma de que no perjudique la carrera. Vas a encontrar la tentación de dejar de estudiar porque vas a ganar plata y te va a gustar, pero es pan para hoy y hambre para mañana. Termina la carrera.

¿Cuanto tiempo tengo que estudiar para poder comenzar a trabajar?

En la práctica, podrías trabajar en sistemas sin haber estudiado un día en una universidad. Volve a la pregunta anterior para ver las opciones que tenes.

Mi recomendación  es que al menos estés un año en la carrera antes de comenzar a trabajar. El cambio de la secundaria a la facultad ya es lo suficientemente grande como para romperte todos los esquemas de tu cabeza. Amoldate a la facu, a estudiar de otra manera y, en muchos casos, a viajar todos los días mucho mas que las pocas cuadras que debías recorrer a tu colegio.

Y así, una vez que estés en ritmo con el estudio universitario, ahi si, inicia la carrera del cambio constante buscando trabajo.

Me inquieta no saber como contar a mis conocidos que hago

No creo que ningun trabajo o actividad sea facil de explicar para alguien que conoce poco o nada de la misma u ocupa su vida en tareas diferentes. El problema con IT va un poco mas allá, ya que actualmente todos tienen un sistema al alcance de la mano, ya sea en su mano (un celular) o una PC desde la cual accede a internet.

Por eso, acostumbrate a que, cuando digas que estudias sistemas, te pidan que le configures la impresora, que le arregles el celular o le quites un virus a su PC.

Y lo mas importante, acostumbrate a que. cuando intentes por todos los medios de explicar que es lo que haces, te mires como si estuvieras hablando en chino mandarín. Es asi, es lo mas duro de ser de IT.

Leer mas

Mal entendiendo el manifiesto agil

Hace ya muchos años, en febrero de 2001, 17 referentes de lo que en ese momento se llamaban las metodologías "lightweight" (livianas) se reunieron en un resort (lugar extraño, pero no voy a meterme en ese tema) para acordar los lineamientos de la nueva rama metodológica de IT.

Una de las cosas que hicieron, fue sacar la mote de livianas a la metodología, y llamarlas ágiles. Para mi, ese fue un primer paso para eliminar uno de los primeros malentendidos de dichas metodologías. Llamarlas livianas hacen pensar que son mas fáciles de implementar, o que sirven para proyectos de juguete y no en serio, como las metodologías tradicionales. Por otro lado, llamarlas ágiles demuestra el principal objetivo de esta forma de trabajar: enfocarse en el aprendizaje y adaptación continua, de manera colaborativa con el ambiente.

Luego de horas de charla (y me imagino que también comida y alguna que otra cerveza) definieron 4 guías generales, acompañados de 12 principios, que formaron las bases del crecimiento futuro de las metodologías.

Actualmente, muchos años después, las grandes compañías se atreven a pensar en sumar estas metodologías "novedosas" a sus proyectos. Esto es una buena noticia, pero muchas veces se malentienden los lineamientos o los principios ágiles, lo que lleva al fracaso al corto plazo (en el mejor de los casos), o al largo plazo (lo que se relaciona con mucho tiempo y dinero perdido).

En mi opinión, parte de esos malentendidos se da por la naturaleza humana de buscar siempre el camino mas simple, y no adentrarse demasiado en lo que produce ese camino o en entender completamente lo que se hace. Como dice Douglas McGregor, en su teoría X, el ser humano es vago por naturaleza. No estoy completamente de acuerdo con esto, pero creo que muchas personas (en la lectura del manifiesto ágil se da claramente), paran de investigar o ahondar mas un tema cuando descubren alguna teoría que sirve para fundamentar su pensamiento.

Para explicar mi opinión, primero transcribiré los lineamientos del manifiesto ágil:

1. Individuos e interacciones sobre procesos y herramientas
2. Software funcionando sobre documentación extensiva
3. Colaboración con el cliente sobre negociación contractual
4. Respuesta ante el cambio sobre seguir un plan 

Luego de los cuales se encuentra la siguiente frase: "Esto es, aunque valoramos los elementos de la derecha, valoramos más los de la izquierda.". En ningún lado dice que debemos desechar los elementos de la derecha, y solo aplicar los de la izquierda. Pero muchos lo entienden de esa manera, solo porque la parte izquierda puede verse, desde el punto de vista de muchos, como lo único que debe hacerse en un proyecto IT. Y eso no es ágil. Eso es un fracaso.

¿Porque se da esto? Porque los que afirman que son agilistas ya que no documentan, no siguen procesos y no tienen un plan, no siguieron leyendo mas profundamente sobre el manifiesto ágil. 

Debajo de los párrafos anteriormente transcritos, se encuentra un link hacia la explicación de la historia del manifiesto (about the manifest). Seguramente esta página tiene muchas menos lecturas que la principal (tal vez sea un problema para muchos que dichos párrafos sean escritos solo en ingles), y eso explica el fracaso de muchos proyectos mal llamados ágiles. 

Voy a transcribir un párrafo de dicho texto:

"The Agile movement is not anti-methodology, in fact, many of us want to restore credibility to the word methodology. We want to restore a balance. We embrace modeling, but not in order to file some diagram in a dusty corporate repository. We embrace documentation, but not hundreds of pages of never-maintained and rarely-used tomes. We plan, but recognize the limits of planning in a turbulent environment.". Y lo voy a traducir por si ese es el problema:

"El movimiento ágil no es anti-metodología. De hecho, muchos de nosotros quieren devolverle credibilidad a la palabra metodología. Queremos volver a tener un equilibrio. Nosotros adherimos al modelado, pero no al hecho de almacenar algún diagrama en un repositorio corporativo. Adherimos a la documentación, pero no a cientos de páginas nunca mantenidas y raramente utilizadas. Planificamos, pero reconocemos los límites de planificar en ambientes cambiantes.".

Creo que si este párrafo estuviera junto a los lineamientos base, los rechazos a las metodologías ágiles serían mucho menores.

Las metodologías ágiles no se tratan de no tener procesos ni herramientas, sino de tener los que ayuden a los individuos y sus interacciones a ser mas fluidas, eficientes y eficaces. O sea, que ayuden a hacer lo correcto en el menor tiempo posible.

Las metodologías ágiles no se tratan de no tener documentación, sino de documentar lo relevante para comprender el código, que el mismo sea mantenible a futuro y que este siempre actualizada, para ser útil.

Las metodologías ágiles no se tratan de no tener un contrato con el cliente. Se debe tener la visión del cliente para poder tener un proyecto exitoso desde el principio, pero dicha visión no debe usarse como el mantra del proyecto, que nunca puede ser modificado. El alcance, los requerimientos y las necesidades van a cambiar durante el proyecto, debemos aceptarlo y no rechazarlo mediante un contrato y control de cambios.

Por último, usando metodologías ágiles, se planifica, y de una manera mucho mas eficiente que las metodologías tradicionales. Se planifica de a poco, haciendo que cada paso sea seguro. Preguntale sino a un project manager tradicional, cuando va a terminar. Si es sincero, te va a decir que no sabe. Lo mismo pasará con un Product Owner o un Scrum master, por ejemplo, pero luego de tres iteraciones se irá animando a brindar alguna visibilidad mas certera. 

Y seguro, en el segundo caso el plan será mas cierto y fácil de seguir.

Leer mas

Por que leer Lean Startup, de Eric Ries

Hace unos días termine de leer el libro "Lean Startup" de Eric Ries. Es un libro que busca transmitir una filosofía de management no tradicional, basada en los aprendizajes de metodologías de origen japones como Lean y Just In Time.
No es un libro para que lean solo aquellos que quieran comenzar su propia empresa - o startup, sino que lo primero que hace es hacer entender que todos somos emprendedores, ya sea iniciando nuestro propio emprendimiento independiente, o trabajando en una gran empresa multinacional.
Es un libro realmente muy interesante, que no se queda solo con la teoría, sino que muestra como llevarlas a la práctica y nos deja algunos casos donde su implantación fue un éxito.
En los próximos párrafos, voy a transmitir algunos de los conceptos que, segun mi opinión, son los mas importantes, y por los cuales recomiendo invertir el tiempo en leerlos del propio autor.
En primer lugar, los 5 principios de Lean Startup:

1. Los emprendedores están en todos lados. O sea, no importa que trabajemos por nuestra cuenta o en una multinacional, todos los que trabajamos para crear nuevos productos y servicios somos emprendedores.
2. El entrepreneurship es management. El "emprendedorismo" es una nueva disciplina, que debe existir en toda compañía.
3. Aprendizaje validado. Las startups existen para aprender como generar un negocio sustentable. Esto se logra realizando experimentos, midiendo y aprendiendo.
4. Build-Measure-Learn (Hacer-Medir-Aprender). Este es el ciclo de aprendizaje continuo que se debe llevar adelante, para realmente esforzarse en el producto indicado.
5. Contabilidad de la innovación. No nos debemos olvidar de demostrar el progreso, priorizar y gestionar nuestros esfuerzos en la innovación.

Un punto que me pareció muy importante - y que es parte del core del libro, viene del principio 4 y 3. Lo mas importante es aprender, no importa si lo que produzcamos tiene éxito o no en el mercado al que apuntamos. Debemos "perdonar el error la primera vez, y asegurarnos de que no vuelva a suceder". Esto se logra realizando un MVP - Minimun Viable Product, creado en base a hipótesis iniciales, el cual nos permita - mediante mediciones de valor- validar dichas hipotesis, y nos brinde información para seguir en el camino planteado, o cambiar la ruta hacia un nuevo obejtivo, manteniendo la visión mientras sea necesario. Esta forma de trabajar asegura que vamos a usar nuestra capacidad - muchas veces escasa - en desarrollar el producto que realmente se requiere.

Nombre en el párrafo anterior que, para crear un MVP - el cual debe servir para validar lo que queremos, y tiene que ser lo mas simple posible-, es necesario tener hipótesis que el mismo siga. Estas hipótesis marcan como el producto se supone que creará valor, y como irá creciendo una vez establecido. Debemos tener claro estos dos puntos, y establecer una manera clara de medir la innovación y el aprendizaje generado mediante métricas base asociadas a cada hipótesis o assumption, que permita demostrar claramente y de manera no ambigua como se crea valor, y como se va creciendo. Si las métricas están bien definidas (y no son vanity metrics-enfocadas en un aspecto parcial del problema), nos va a permitir establecer cuando perseverar, o cuando cambiar el rumbo.

Debemos definir bien las métricas asociadas a nuestras hipotesis, teniendo en cuenta la regla de las tres A, para que las mismas sean:

• Accionables. O sea, que deben demostrar claramente una causa y efecto.
• Accesibles. Los datos deben ser accedidos por todos los involucrados en el producto, de la manera mas simple posible.
• Auditables. Se debe poder tracear la información que generó las métricas, para defender cuando decimos que el proyecto va bien, o va mal y debemos cambiar el rumbo.

Volviendo a que el MVP sea lo mas simple posible. Es importante asegurarnos que vayamos avanzando en el desarrollo deproducto de a pasos cortos (small batches), que produzcan iteraciones de creación-medición-aprendizaje. Por eso, debemos ir planificando mejoras pequeñas, pero medibles y que nos permitan aprender y definir los siguientes pasos.

Algunas otras prácticas o herramientas que me parecieron interesantes:

• Enfocarnos en tener un MVP simple, y validarlo con usuarios finales, en un ambiente real, aunque cuidado. Lo mas adecuado es realizar estas validaciones midiéndolas por poblaciones de usuarios (cohortes), lo que nos permitirá tener una visión mas acabada de nuestra situación.
• Tener al aprendizaje sobre nuestro producto como primer objetivo, y dejar para una segunda instancia la optimización. Para un ingeniero o diseñador este punto es muy difícil, pero es vital mantenerlo en práctica.
• Realizar pruebas de diferentes versiones de productos a diferentes poblaciones, comparando las métricas entre los diferentes grupos de clientes. Pueden ser mediante tests A/B, pruebas green-blue servers, etc.
• Técnicas como continuous integration y continuous deployment permiten acelerar el ciclo de creación-medición-aprendizaje, mediante la automatización, que lleva a la eliminación de desperdicios (tiempos muertos), y el foco en esforzarse para crear valor en lugar de realizar tareas repetitivas.
• KANBAN nos permite tener siempre visible la capacidad de nuestros equipos, y el flujo de actividades, haciendo mas simple encontrar puntos de mejora y aumentar la productividad general.
• Debemos generar una organización adaptativa, que evolucione constantemente y no se quede congelada. Una herramienta para lograr esto, es ejecutar el ciclo de "5 porque" (five whys) cuando nos encontramos con un problema, para llegar a la raiz del mismo. Muchas veces, un problema que parece técnico - solución simple y superficial, en realidad esta dada por un problema sistémico y asociado a personas.

Esto fue solo un resumen de lo que a mi me parece mas importante del libro, pero es muy recomendable meterse a lleno, leerlo e implementar sus prácticas (Algo que voy a hacer, y luego comentar mis aprendizajes).

Leer mas

Frases desmotivantes que se mal usan para motivar

Hoy tuvimos un almuerzo muy interesante con el equipo, despiertos y con ganas de filosofar.

Entre tantos temas, surgió uno muy interesante: ¿que frases escuchamos, nos contaron o se ocurren que puede decir un lider, queriendo motivar, pero que logra totalmente lo contrario? A continuación, el compendio resultante, que se va a traducir en un "cubo de des-motivación":

1. "Recorda: sos prescindible". Esta frase es terrible. Logra desmotivar hasta la persona mas motivada de un equipo. No tiene costado positivo alguno.
2. "Es bueno tener actualizado tu perfil de linkedin". Tal vez esta frase haya sido utilizada con un lado positivo, el de enfrentar una posible futura crisis estando preparados, sin que nos agarre desprevenidos. Pero muchos (me incluyo) lo pueden tomar para el otro lado: Somos prescindibles
3. "Si se puede mejorar, aun no lo terminaste". Horrible mensaje. Buscar la perfección a todo costo nunca puede llevar a nada bueno. Desgasta el equipo y no se logra ningún objetivo. 
4. "Quedate trabajando... nadie te espera". Puff, malísima desde la primera a la última letra. No imagino una persona que pueda verse líder dando mensajes de este estilo.
5. "No se puede ser el mejor en todo, y menos en lo que haces". No solo te insultan y te tratan de inútil, sino que dicen que lo que haces no tiene sentido. Aunque hay que ser sincero, saca presión ;).
6. "¿Lindas las vacaciones? Ahora a trabajar, te faltan 350 días para las próximas". Esto puede ser un muy mal chiste de bienvenida de vacaciones, pero puede generar un pico de presión (y depresión) post-vacaciones que origina un espiral de malos augurios.

Actualización 3/1/14: Algunos agregados que me fueron pasando:

7. "No dejes para mañana lo que podes hacer hoy, posiblemente mañana no haga falta, o no estes para hacerlo". Esta pega bajo, muy bajo.

8. "Descansa en las vacaciones, te espera un año bien cargadito". Esta no solo no motiva, sino que te caga las vacaciones.

Seguramente existirán muchas mas, muy malas, tal vez sin mala intensión, pero muy hirientes y contraproducentes.

Seamos cautos con la comunicación, es lo mas importante.

PD: Gracias al equipo por los aportes!

Leer mas

De que hablamos cuando hablamos de DevOps

Como todo nuevo término de la industria IT, DevOps tiene muchas implicancias y significados, dependiendo de los intereses, historia y conocimientos de quienes lo definan, y a quienes lo comuniquen.

Muchos pueden pensar a DevOps como una serie de herramientas para cambiar la forma de gestionar la operación de los sistemas y su relación con las áreas de desarrollo, mientras otros pueden definirlo como una serie de prácticas para extender las prácticas de desarrollo ágiles (SCRUM, KANBAN) hacia las áreas de operaciones. Otros, los escépticos, pueden decir que son un montón de gente loca intentando cambiar el mundo, y que obviamente fracasaran porque lo que funciona en este mundo es la previsibilidad, monitoreo y gestión de prácticas tradicionales como ITIL, y que lo propuesto por DevOps lo único que traerá es mas caos. Por último, están quienes creen que es un nuevo área de la organización IT que viene a salvarnos de todos nuestros problemas (estos últimos para mi son los mas errados).

Para mi, no es ninguna de todas las definiciones anteriores, y al mismo tiempo todas. Me gusta definir a DevOps basándome en un paper de Mandi Walls (Building a DevOps Culture), como un  movimiento cultural combinado con una serie de prácticas de desarrollo de software soportadas por herramientas que juntas habilitan a un desarrollo mas rápido (o a fallar mas rápido mas seguido). Por lo que es muy importante tener en cuenta que implementar un cambio a un nivel que mejore nuestra capacidad de entregar software de calidad mas seguido no es algo que pueda ser realizado de un día para el otro, y requiere su tiempo de maduración y soporte de la organización completa (o al menos aquellas áreas impactadas).

DevOps no es algo nuevo (Patrick Debois acuñó el término en 2009, mientras organizaba la primer DevOps conference en Bélgica), sino que es un muy buen blend entre prácticas maduras con enfoques novedosos para enfrentar desafíos comunes en la entrega y operación de soluciones de software. Mezcla la visión de desarrollo (no solo los desarrolladores, sino también testers y QA) y operaciones (incluyendo no solo a los operadores, sino también a administradores de sistemas, DBA), poniendo foco en la colaboración y feedback constante para soportar la mejora contínua de la forma de trabajo.

Según cuenta Michael Hüttermann en su libro DevOps for Developers, DevOps abarca numerosas actividades y aspectos:

• Cultura: Las personas son mas importantes que los procesos y herramientas. Hay que tener siempre en cuenta que el software es hecho por personas y para personas. Debemos buscar la forma de ser felices haciéndolo, y hacer felices a los que obtienen el resultado de nuestro trabajo.
• Automatización: Es esencial obtener feedback rápido y minimizar los errores en tareas repetitivas.
• Medición: Se debe encontrar una forma única de medir, acompañado por incentivos de calidad y compartidos (o al menos alineados).
• Compartir: Es imprescindible crear una cultura en la que las personas compartan ideas, procesos y herramientas.

Hablamos entonces de cambiar la cultura de dos áreas históricamente enfrentadas (desarrolladores vs operadores) para que se vean como un único equipo (con objetivos alineados), compartiendo información y apoyados en la medición continua y automatización de tareas que no aportan valor para mejorar el día a día de su trabajo, y paso a paso, como diría el Tolo Gallego.

¿Como podemos entonces emprender este cambio cultural para poder trabajar mejor? Debemos enfocarnos en generar una nueva cultura, con base en los siguientes pilares:

• Comunicación abierta, donde nadie tenga miedo a participar y decir su opinión, y donde la decisiones sean tomadas de manera global, con responsabilidad compartida entre todos. Basta de ocultar información para sacarse de encima problemas.
• Incentivos alineados, tal como lo comenta Michael Hütterman y tal como lo nombré en párrafos anteriores.
• Responsabilidad alineada. Debe quedar en claro que la responsabilidad de un área no termina cuando culminó su porción de tarea y la pasó la pelota al siguiente pipe en el pipeline de desarrollo. La responsabilidad de todos los involucrados termina cuando se alcanzó el nivel de aceptación acordado entre TODOS.
• Respeto. Todos deben respetarse. Puede ser que no se quieran (ya eso va de la mano de los sentimientos de cada uno), pero es vital que cada uno reconozca el valor del otro en el pipeline completo.
• Confianza. Esto si es realmente desafiante. Los desarrolladores deben confiar en que lo que los encargados de operaciones les indican sobre el funcionamiento en producción, y estos últimos deben confiar en que lo que desarrollo produce es lo mejor dadas las circunstancias, y trabajar en conjunto para llegar a los objetivos planteados en conjunto.

Tenemos que tener en cuenta que algo es seguro: No es posible refactorizar una persona o resetearla tal como lo podemos hacer con las aplicaciones o los servidores. Se trata de un cambio interno de las personas, y debemos encontrar la forma de trabajar con los pre-conceptos, experiencias pasadas y prejuicios, para transformar la energía negativa actual en el combustible del cambio.

Leer mas

Creando infografías

Por cuestiones que no vienen al caso, tuve que pensar en como comunicar gráficamente muchos datos, métricas e indicadores, para que un auditorio no técnico comprenda claramente lo que se quería comunicar.

Esa tarea era algo desconocido para mi, ya que me gusta ver y analizar infografías, pero nunca puse a pensar como comunicar muchos datos de manera simple. Fué un gran desafío para mi.

En primer lugar pensé cuales eran las variables que quería mostrar (las cuales eran muchas), y luego vino la parte mas creativa, pensar como acomodar la información y luego la parte mas práctica, como llevarlo a una imagen.

Con respecto a como acomodar la información, caí en la cuenta de que lo que quería mostrar era la relación entre elementos (nodos), e indicar de alguna manera gráfica el peso que tenía esa relación entre los mismos. Además, debía indicar algunas otras métricas relacionadas a cada nodo. Por lo que decidí acomodar los nodos y sus relaciones como grafos, y que las relaciones mostraran con el grosor el peso que tenían. Para llegar a esto no fue que me dormi y al levantarme se me había ocurrido, sino que sumé mi lectura asidua de infografías a la búsqueda activa en http://vi.sualize.us. Es muy bueno para buscar inspiración (creo fervientemente que la creatividad no es mas que acomodar de otra manera ideas existentes).

Para terminar, la parte práctica la llevé a cabo con la herramienta de diseño open source Inkscape (descargable de http://inkscape.org). Después de probar varias alternativas open source al Photoshop y Corel Draw, me quedé con esta, por la cantidad de posibilidades que brinda, y la versatilidad de uso que tiene. Realmente es muy buena. La única contra, es que solo permite exportar a png, pero no es algo que me moleste demasiado.

En conclusión, tuve un día en que me puse el gorro de diseñador gráfico y realmente la pase bastante bien.

Leer mas