La necesaria mirada hacia adentro de la propia organización

by https://www.flickr.com/photos/144152028@N08/33772074972

Mañana se cumple exactamente un mes desde que dejé mi antiguo trabajo. Por esas cosas del destino ahora estoy en una empresa que ya conocí, sacando cuentas he vuelto después de 5 años.
No puedo negar que ahora me siento bastante más cómodo, la dinámica de trabajar por proyectos versus trabajar en torno a un producto que está posicionado en el mercado hace más de 20 años es muy diferente. Proporcionalmente hablamos de una empresa con un área de desarrollo mucho más pequeña, por ende mucho más especializada, contra una empresa que es derechamente de desarrollo, donde el área encargada es bastante más grande, y consecuentemente más heterogénea. Pero no quiero referirme a eso, sino a una reflexión que tuve antes de cambiarme de trabajo.

Desde el punto de vista de la empresa, ahora se fue uno (en rigor hace un mes), un recurso menos, un elemento reemplazable, con más o menos dificultad, pero siempre reemplazable. La pregunta a hacerse desde dentro es ¿porqué? ¿qué pasa en MI organización, que la gente piensa en irse a otra empresa?
El que tan indispensables somos depende de las estrategias de cada empresa. Si cada desarrollador es "dueño y señor" de los desarrollos que se le encomiendan, y si no existe un equipo de más de un solo hombre (o mujer) encargado, entonces se vuelve más complicado reemplazar a alguien que se va. Pero ¿porqué se va la gente?

¿Mejores condiciones? ¿salarios más atractivos? ¿mejores proyectos? ¿mayor proyección profesional?
A mi parecer, y un poco lo que personalmente me motivó, es una mezcla de factores, donde claramente el salario fue el 1er elemento a considerar, pero no el único.
Cuando día tras día la rutina de ir a trabajar se empieza a volver tortuosa por la percepción de una falta generalizada de voluntad por hacer cosas, y cuando empiezas a darte cuenta de una inusual venta de humo, de la que alguien (probablemente uno) tendrá que hacerse cargo, con requerimientos imposibles y en plazos irreales, entonces hay algo que dispara todas las alertas en tu interior. Si a eso sumas que la organización difícilmente ajustaría las condiciones y el equipo conforme a estos nuevos "desafíos", o simplemente ves que  te estás condenando profesionalmente a "seguir picando piedras", las señales no pueden ser más claras.

Entonces desde dentro probablemente van a ver todo bonito y tu partida será injustificada. Aquí es donde es importante no perder la objetividad.
¿Qué está pasando en MI organización? Si tu administración es desde el desconocimiento, entonces puedes esperar que muchos se vayan y no vas a entender porqué. La mirada hacia adentro debe ser crítica y siempre objetiva. No es pecado ni mal visto bajar del Olimpo a ver que pasa en la Tierra.

Las tropas no se mueven si no hay un liderazgo claro, pero tampoco dejan los puestos de batalla por nada.

Nota: Este artículo probablemente se lea como una contradicción (en algún grado) a este otro artículo . Si y no. Como mencionaba más arriba, las condiciones (entorno) pueden ser  muy buenas y atractivas, incluso mejores que las de cualquier otra empresa, y seguramente es eso lo que va a ver un jefe. Pero la informática es dinámica, y no se alimenta sólo de juguetes, vestimenta informal, pizza, café, golosinas y bebidas energéticas. El problema esencial es cuando el líder no se da cuenta (o no quiere darse cuenta) que las tropas están inquietas, ya sea por ese constante picar piedra o simplemente por la incertidumbre frente al futuro; y frente a eso por muy buenas que sean las condiciones del entorno la gente se va a ir.

Eventos y autogestión: Ojalá no se equivoquen

Este sábado 6 de enero recién pasado tocamos junto a mi banda Sin Cielo, en un evento autogestionado denominado Construye telaraña. Finalmente el evento salió adelante, sin embargo hubo muchas cosas que; al menos a mi; me dejaron con la sensación que no se hicieron bien.

Cuando recibimos la invitación nuestras primeras dudas fueron:

• Fecha y lugar del evento
• Bandas participantes, y estilo de las mismas.
• Backline disponible; vale decir que equipos iban a estar disponibles para que utilizaran las bandas que iban a tocar en el evento.

Lo único de lo que había claridad era la fecha y lugar, el Galpón de la Juana, en la comuna de Conchalí. Una vez allá nos dimos cuenta que no se trataba de un recinto, sino más bien un área abierta, techada, aledaña a una multicancha y a una calle.
Durante la semana se iban a definir las bandas participantes, que a priori incluían a algunas bandas de rock, e intérpretes de "trova". Y sobre los equipos disponibles, en un principio nada, irían consiguiendo  los equipos entre las mismas bandas participantes. Ya en ese momento nuestras expectativas del evento empezaban a ser bajas, sobretodo por el tema del equipamiento, tanto así que una semana antes incluso dudamos de nuestra participación.

No es que seamos Rock Stars, pero incluso habiendo sido invitados a participar lo mínimo que esperas es contar con lo básico; léase al menos 2 micrófonos para la voz,  2 amplificadores para guitarra, 1 amplificador de bajo, una batería. Al confirmar el backline disponible, la organización señaló que faltaba un amplificador de guitarra, pero que "Aún hay tiempo para conseguir otro" (a un día del evento).
En alguna parte de las conversaciones se les preguntó porqué no arrendaban lo que faltaba, solicitando el apoyo monetario de quienes participaran, a lo que respondieron que era  "un evento autogestionado, y preferían conseguir los equipos con quienes participaran".

Sobre el tema de conseguir y facilitar equipos, es complicado, ya que en mi caso particular, dispongo de algunos equipos, sin embargo sin conocer a nadie salvo al gente de mi banda, no puedo llegar y confiar, menos cuando no hay una voluntad manifiesta de hacerse responsable en caso que llegaran a dañar un equipo.
Imagino que parte de esta particular filosofía de "autogestión" era ver esos temas sobre la marcha.

Otra consulta que hicimos fue el orden en que se presentarían las bandas e intérpretes participantes, básicamente si tienes 10 participantes, y el evento empieza a las 5 ó 6 de la tarde, para poder sacar un cálculo de cuanto tiempo dispone cada banda para tocar, y a que hora te vas a presentar en el evento. En principio no hubo respuesta, y finalmente dijeron que 1ero tocarían quienes no requerían de amplificación (show acústico, presuntamente los intérpretes de "trova") y luego las bandas.
Respecto a la hora de llegada nos citaron a las 2 de la tarde "para poder ayudar a armar". Llegamos tipo 3 de la tarde, y nos encontramos con otros chicos que si llegaron a las 2PM, quienes nos comentaron que "no dejaron que los ayudaran".

Supuestamente al llegar temprano también podríamos a hacer una buena prueba de sonido. La verdad es que si no dispones del equipamiento necesario difícilmente podrás hacer una buena prueba de sonido...
Nota al margen: No hubo prueba de sonido...

El evento comenzó a eso de las 4 de la tarde, casi a  las 5. Nos dimos cuenta que faltaba un amplificador de guitarra, o mejor dicho sólo disponían de un amplificador mediano, el otro amplificador disponible era un amplificador "de habitación" (10 watts con suerte). 

Y aquí es donde terminaron de revelarse los problemas de la organización.

Cómo no existía un orden a priori para las bandas e intérpretes, la presentación se hizo "en la medida que aparecían". Los "trovadores" estaban todos atrasados y hubo momentos muertos en el evento. Después de un rato de incertidumbre le planteamos a uno de los organizadores si podíamos hacer nuestra prueba de sonido, ya que dado que les faltaba un amplificador de guitarra tendrían que ver como microfoneaban el mini amplificador, un problema que iban a tener ya que al menos otra banda  más entre las participantes (aparte de nosotros) tenía 2 guitarras en su formación.

Cuento corto, nuestra prueba de sonido se convirtió en nuestra presentación, ya que la gente prendió cuando empezamos a tocar. No tocamos nuestro playlist completo y nos bajamos con una sensación de haber estado en un "ensayo con público".

Lo malo:
(tristemente lo más fácil de apreciar en las circunstancias de este evento)

• Mala organización (perdonable si fue el 1er evento que organizabas).
• No se contaba con el equipamiento mínimo (perdonable si hubieran tenido la disposición de conseguirlo, vs esperar del cielo la buena voluntad de alguien).
• El único micrófono dispuesto para la voz falló durante todo el evento (imperdonable).
• No había orden dispuesto para los participantes (imperdonable). Si no hubiéramos tocado en el momento que lo hicimos, seguramente hubieran tenido que cortar las presentaciones de otros para poder dar tiempo a todos. ¿Mala organización? OK admisible, pero tampoco puedes ser tan al lote.
• Seguridad ciudadana llegó a terminar el evento (imperdonable).

Lo bueno:
(ya que no todo puede ser malo)   

• Sacaron adelante el evento, a pesar de todo.
• El apoyo del público. OK, bandas  apoyando a otras bandas, más los familiares, más amigos cercanos, más los borrachines locales, más los perritos, pero apoyo al fin y al cabo.
• El ambiente generado. El hecho de poder interactuar con otros músicos y bandas y poder abrir la posibilidad de organizar cosas en conjunto es, por si solo, valorable.
• La oportunidad de darse a conocer. Nosotros, como Sin Cielo, no somos una banda conocida. Supongo que será el caso de varios de quienes participaron de este evento. Hubo gente que no nos había escuchado nunca, que estuvo presente, nos puso atención y disfrutó de nuestra música.

Puntos notables:

• La niña de pelo rosado que cantó con su guitarra, a la que los borrachines que le cambiaron el coro de su canción.
• Los borrachines que aplaudieron, cantaron y gritaron con todas las bandas.
• Los perritos que se acercaron a acompañarnos.
• Cerveza polaca a CLP$500.
• El campeón que llegó con su amplificador, tocó una canción de Los Bunkers, terminó, tomó su amplificador y se fue.
• Las salvadoras sopaipillas.

Pero no se equivoquen, en este contexto la buena autogestión no es sólo sacar adelante un proyecto (evento musical), y conseguir los equipos sin pagar ni un peso a terceros.
Es (entre  un millón de cosas más) poder transmitir un mínimo de seriedad a los participantes, lo que se traduce en confianza hacia la organización, y el deseo de participar en otros eventos del mismo comité.

Nosotros salimos con sentimientos encontrados de este evento. Lo que es claro que frente a cualquier invitación a tocar y presentarnos como banda, las preguntas base van a seguir siendo las mismas:

• Fecha y lugar del evento
• Bandas participantes
• Backline disponible

Desarrollo ágil y metodologías

Ya había comentado mis observaciones relativas a las metodologías de desarrollo. Bueno, aquí hay alguien con bastante más experiencia y reputación, y un poco más extremista que yo, quien también tiene apreciaciones similares:

One Hacker Way - Eric Meijer

Y obviamente acompañado del interesante artículo Erik Meijer: “Software is eating the world”

Metodologías de desarrollo ¿Ser o no ser?, he ahí la cuestión

Este mes comencé una "nueva aventura/desafío laboral" en otra empresa. Viniendo de una modalidad de trabajo bastante salvaje, llegar a una empresa donde el uso de metodologías de desarrollo es intenso ha sido un cambio no menor. La experiencia ha sido bastante diferente a lo acostumbrado.

En mis trabajos anteriores si bien nos preocupábamos de una u otra manera de llevar un control de versiones, y llevar algún registro de actividades, todo el desarrollo se realizó de manera "salvaje". Salvaje en el sentido que más que el control sobre las actividades a realizar, lo que importa, y casi lo único que importa, es cumplir con las entregas finales de código (y no es que con metodologías más estrictas esto sea menos importante). Dicho en fácil, estuve desarrollando "a lo brutito" mucho mucho tiempo. El objetivo era cumplir si o si.

Metodologías

En esta empresa, muy ligado al alto nivel de los profesionales del equipo con el que debo trabajar, así como también la envergadura del proyecto en curso, la planificación y las metodologías son vitales:

• Se realiza una planificación para la semana. Un conjunto de tareas que debiera estar resuelto en un plazo dado. La fecha tope normalmente no debiera exceder  de una semana de trabajo (5 días).
• Cada mañana se realiza una "breve" (a veces no tan breve) reunión, a priori no más de 3 minutos por persona. Todos de pie debemos contar que hicimos en la jornada anterior, y cuál es nuestra planificación para el día de hoy. Se deben levantar las alertas necesarias  sobre aquello que pueda dificultar el desarrollo.
• Cada viernes, idealmente en la mañana, se realiza una sesión de demo en la que se presenta al equipo algún resultado visible de las actividades realizadas en la semana.
• Las actividades se ordenan en un tablero Kanban en el cual cada tarea se va moviendo de columna conforme al estado de la misma. Las columnas son:
• Por hacer
• En desarrollo
• Detenido
• Resuelto
• Cerrado
• Cada bloque de código tiene que contar con su correspondiente set de prueba. El Test Driven Development (TDD) amerita un artículo aparte (próximamente en este mismo canal).

Uno de los focos principales es la autogestión del equipo, por lo que cada integrante hace sus propias estimaciones de tiempo.
Y el nivel de control sobre el equipo de desarrollo es claro, siempre sabes que están haciendo todos.

Lo positivo

• El equipo tiene una visión general de todo lo que está pasando. Se lo involucra en las actividades de la empresa, lo que SIEMPRE es bueno.
• Se logra un nivel de orden para las actividades de cada integrante del equipo.
• Se puede dimensionar el costo en tiempo para el desarrollo de un proyecto.
• Se van afinando, progresivamente, los procesos de desarrollo.

Lo no tan bueno (desde la humilde perspectiva del autor)

Mi gran reparo respecto a la aplicación de estas metodologías apunta hacia el tiempo.
Hacer una reunión diaria, de pie, en un equipo de más de 5 personas puede tomar por lo bajo 30 minutos. Similarmente hacer una sesión de sesiones de demo, podría extenderse al orden de una hora.

En relación al registro de actividades y atenerse a las directrices que se definan incluso para los comentarios al subir código a un repositorio de versiones tampoco es  una tarea directa.

Y sobre los sets de pruebas, estos deben considerarse como un desarrollo anexo, que se suma al tiempo normal de desarrollo. Suele suceder que la detección y corrección de errores (bugs) puede resultar muy rápida, sin embargo la construcción de los set de pruebas muchas veces puede demorar bastante, y muchas veces no tienes como dimensionarlo de manera adecuada.

Tengo cierta claridad sobre la duración de los períodos reales de productividad diaria, habitualmente no más de 5 o 6 horas en una jornada de 8 horas, sin embargo contar con un hora menos para resolver mis tareas planificadas (y me refiero exclusivamente a mi experiencia) pesa.

En un trabajo anterior mi jefe decidió involucrarme en reuniones con cliente, a veces 2 horas al día. Paralelamente yo tenía asignadas ciertas actividades de desarrollo, con fechas de entrega planificadas. Esos días por fuerza tuve que recuperar las horas que literalmente perdí por estar metido en reuniones.

¿Ser o no ser? (o ¿cuándo usar metodologías?)

La respuesta debiera ser siempre. Debiera ser...
Desde mi aún inexperto punto de vista, como en muchos otros casos, la respuesta será un gran depende. Las ventajas son bastante claras sobre no usar metodologías. Sin embargo, su uso estará definido desde la misma filosofía de la empresa hasta el tipo de proyectos que se está desarrollando.

• Tratar de imponer el uso de metodologías en una empresa que ha sobrevivido en estado salvaje puede tener un costo más alto que el beneficio en el corto y mediano plazo tras incorporarlas. Hay empresas que simplemente no valoran hacer las cosas bien, basta con hacerlas (tristemente las hay...).
• En proyectos "pequeños" desarrollados por ejercitos de un solo hombre es discutible (y sólo discutible) si vale la pena incluir el desgaste natural asociado a incorporar metodologías.

Personalmente creo que la decisión pasa por la apreciación que tenga cada lider de desarrollo respecto al recurso tiempo, y de que manera puede hacer mejor gestión de este.
Pero sí, hay mucha ganancia en usar metodologías, sólo hay que encontrar la combinación correcta, en la medida que civilice un poco los procesos de desarrollo

¿Qué tan frágil es tu organización?

Hace aproximadamente un mes atrás conversaba con mi ahora ex-jefe sobre que tan frágil es una organización. Básicamente porque mi rol en la empresa tenía cada vez más responsabilidades, y en caso de irme reemplazarme no sería tan sencillo. Hoy estoy trabajando en otra empresa, y créanme que la últimas semanas en mi antiguo trabajo fueron intensas.

Un artículo atrás hablaba del costo de la especialización, y la importancia de poder desempeñarse como un profesional versátil (busquen por fullstack developer para más referencias al respecto).
Si bien es cierto un fullstack developer resulta muy valioso para la organización, es también un riesgo, tan grande como su valor como profesional, puesto que inevitablemente habrá muchas tareas que le serán confiadas. Muchas veces, por no decir la mayoría, este tipo de profesional será el único quien se puede hacer cargo de muchas de las ya mencionadas tareas, o bien será el único que las puede resolver de manera rápida y eficiente.

Cuando se dió esta conversación con mi antiguo jefe, me señaló que si yo me iba, le sería muy difícil encontrar a alguien que pudiera cubrir mi posición. Similarmente si se iba otro compañero que se ha involucrado más en actividades de gestión que de desarrollo, la empresa se tambalea.
Paradojalmente unas semanas después recibí una oferta de aquellas que no esperas que se repitan, y la acepté. Es complejo ver como la empresa en la que has trabajado tiene que empezar a considerar el plan B para todas las actividades en las que estabas involucrado.

¿Ustedes tiene un plan B en caso de?

¿Qué tan frágil es tu organización?

Habitualmente se dice que una organización es tan fuerte como su eslabón más débil, pero ¿qué tan frágil es?
La fragilidad de una organización, empresa, e incluso emprendimientos ligados al desarrollo viene dada por cuántos son los soportes que sostienen las actividades clave/sensibles/de vital importancia, y cuanto es el riesgo que se debe asumir si alguno de estos pilares ya no está en el equipo.

Por ejemplo: Un emprendimiento cuyo norte es entregar un producto de software no debiera depender de una sola persona para hacerse cargo del desarrollo (o de la parte TI si quieren ampliar el concepto). Si esta persona decidiera no seguir, si no hay como reemplazar sus experticias, es probable que tengan que replantear el emprendimiento en si.

Si miramos a las empresas como el juego de la Yenga, la fragilidad podría verse como  cuantos palitos puedes sacar antes que la torre de derrumbe. Mejor aún, dependerá además de que tan abajo o arriba estén los palitos que sacas (obviando el hecho que una torre no representa precisamente una pirámide organizacional).

Y claramente hay muchísimos otros factores que influyen.