Monthly Archives

julio 2024

Jul 10
0

Seleccionando nuestros pinos desde la semilla

By | 10pines

(To read this post in English, follow this link)

Les voy a contar dos historias sobre la contratación de gente y su proceso:

La contradicción de la frase “no tenemos tiempo para lo importante”

Un dia mi amiga Camila vino quejándose sobre su equipo. Hablaba de integrantes vagos, no comprometidos con su trabajo, sin experiencia y de cómo se había decepcionado al ver trabajar a la última ingresante en base a la experiencia que decía tener.

Un par de días más tarde, me dice que está buscando una persona nueva para incorporar al equipo.

“¿Cómo van a elegir a esta persona?”, le pregunté. Teniendo en cuenta lo que me había comentado, supuse que habría repensado su estrategia.

Pero adivinen cuál fue la respuesta…

“No tengo tiempo para esto, el departamento de RRHH se encargará del asunto”

La carpintera de casas naranjas

La segunda historia es más divertida y es cortesía de la web.

Imaginemos una entrevista para un puesto de carpintería en una “constructora de renombre”. Este sería el diálogo entre la persona reclutadora de RRHH y la candidata:

– RRHH: Bueno, trabajás en carpintería, ¿no?

–Carpintera: Sí, me dedico a eso.

–RH: ¿Hace cuánto que estás haciendo esto?

–C: Diez años.

–RH: Genial, eso es bueno. Ahora, tengo un par de preguntas técnicas para hacerte, y así saber si aplicás al puesto, ¿está bien?

–C: Claro que sí.

–RH: Primero que nada, estamos trabajando en una subdivisión, construyendo un montón de casas naranjas. ¿Construiste casas naranjas antes?

–C: Bueno, soy carpintera, construyo casas, y generalmente la gente las pinta a su gusto.

–RH: Si, comprendo, pero ¿me podrías dar una idea de cuanta experiencia tenés con casas naranjas? A ojo.

–C: La verdad no sé. Una vez construidas no me interesa saber de qué color las pintan. ¿Seis meses quizá?

–RH: ¿Seis meses? Bueno, estamos buscando postulantes con mucha experiencia en naranja, pero veamos algunas preguntas más.

–C: Bueno, está bien, pero la pintura es sólo pintura, ¿no?

–RH: Si, claro. Bueno, ¿Qué podés decir del nogal?

–C: ¿En qué sentido?

-RH: ¿Trabajaste con nogal alguna vez?

–C: ¡Claro! Nogal, pino, roble… lo que quieras.

-RH: ¿Pero cuantos años de nogal tiene?

–C: Mmm, no se realmente… ¿se suponia que tenia que contar los nogales?

-RH: ¿Y no podrias hacer una estimacion aproximada?

–C: Ok, diría que un año y medio de nogal.

–RH: ¿Dirías entonces que sos un jr en nogal o un gurú en nogal?

–C: ¿Qué es un gurú en nogal? Yo usé nogal, eso seguro.

–RH: ¿Pero no sos un gurú en nogal?

–C: Soy una carpintera, trabajo con toda clase de madera, y hay diferencias, pero creo que si sos una buena carpintera…

–RH: OK. Bueno, una última pregunta. Nosotros usamos Roca 5.1 para golpear clavos, ¿usaste alguna vez Roca 5.1?

–C: [palideciendo…] Bueno, sé que un montón de colegas están usando rocas para clavar desde que ArtesanosUnidos compró una mina, pero siendo honesta, me llevo mejor con mi engrapadora. O un martillo. Con la roca me lastimo mucho los dedos, y me molesta la mano porque la roca es demasiado grande.

–RH: Pero las demás empresas están usando rocas. ¿Estás diciendo que las rocas no sirven?

–C: No, no digo eso precisamente, sino que pienso que la engrapadora es mejor herramienta.

–RH: Bueno, todos nuestros arquitectos comenzaron a usar rocas, ¡y les encanta!

–C: Seguro que les encanta, pero yo me la paso con clavos todo el día, y… bueno, necesito el trabajo, así que estoy dispuesta a usar rocas si quieren. Estoy abierta a nuevas herramientas.

–RH: Mmmm bueno, tenemos que seguir entrevistado a más personas, pero nos contactaremos con vos.

–C: Bueno, gracias por tu tiempo, fue un gusto.

-AL OTRO DÍA:

Ring…

–RH: ¿Hola?

–C: Hola. Soy la carpintera que entrevistaron por el trabajo de las casas naranjas, ¿me recuerda?. Me contacto para saber si ya tomaron una decisión.

–RH: De hecho, sí. Nos gustó tu perfil y experiencia, pero decidimos avanzar con alguien que trabajó mucho con el naranja.

–C: ¿En serio? ¿O sea que no conseguí el trabajo por no haber usado suficiente naranja?

–RH: Bueno, un poco eso, pero también nos resultaba más barata otra persona.

–C: ¿En serio? ¿Cuánta experiencia tiene?

–RH: Bueno, en realidad no trabaja en carpintería, vende autos, pero vendió un montón de autos naranjas y trabajó con terminaciones en nogal.

–C: [click]

Nuestra receta para elegir las semillas adecuadas

Creo que estas historias ejemplifican claramente los grandes problemas al reclutar personas en una empresa tradicional.

  • No se le dedica tiempo al proceso
  • No se comprende la importancia de este punto de entrada a la empresa
  • Se terceriza el proceso en alguien que no comprende el trabajo. Hace un tiempo escuché una charla de Raffi Krikorian (ex ingeniero de Twitter, ahora de Uber) recomendando: “¡no tercericen el reclutamiento!”
  • El equipo no puede elegir con quienes trabajar
  • El o la postulante no son evaluados en una situación laboral similar a la postulada

Nuestro modelo organizacional en 10Pines está basado en la confianza, no existen organigramas ni jerarquías rígidas. En lugar de eso, es una empresa auto organizada con mucha flexibilidad y libertad. Por lo tanto, una persona abusiva o dañina en la empresa, podría causar conflictos que perjudiquen nuestro proceso colaborativo. Es por esto que uno de los temas más importantes cuando se fundó la empresa fue cómo elegir las personas correctas con quienes trabajar.

Los temas importantes consumen tiempo para poder resolverlos. Por lo tanto, si las personas son importantes, es necesario tomarse el tiempo para elegirlas.

Por este motivo, nuestro proceso de selección de personal es atípico y consume un tiempo considerable, pero creemos que cada minuto invertido en eso vale la pena.

Citando uno de los libros de ingeniería de software más reconocidos, «The mythical man-month»:

«Good cooking takes time. If you are made to wait, it is to serve you better, and to please you.»
Menu of Restaurant Antoine, New Orleans.

Que su traducción aproximada es:

«Cocinar bien lleva tiempo. Si se te hace esperar, es para servirte mejor y complacerte.»

Nuestra receta para elegir las semillas correctas se compone de 4 pasos:

  1. Entrevista inicial
  2. Ejercicio tomando ejemplos de trabajo reales
  3. Entrevista técnica
  4. Entrevista grupal

1. Entrevista inicial

Generalmente cada nueva semilla/postulante es recomendada o sponsoreada por algún miembro de 10Pines. Entonces, el primer paso es una entrevista entre el referente interno, el candidato y alguien más. Últimamente hemos estado explorando búsquedas más abiertas sin un referente interno, pero de todas formas, esta primera entrevista es como una cita, donde tratamos de mostrar por qué 10Pines es bueno para esa persona, y viceversa. (En relación a esto, pueden leer el siguiente artículo sobre similitudes entre una entrevista y una cita romántica)

2. Ejercicio simulando la realidad

Luego de la primera entrevista, le enviamos al postulante un ejercicio para resolver en casa. La complejidad del ejercicio está basada aproximadamente en la experiencia de la persona entrevistada. Si parece ser junior, le damos un ejercicio para juniors.

Tratamos de utilizar ejemplos reales que emergen de nuestro día a día, para no alejarnos mucho de la realidad.

Las condiciones para resolver el ejercicio son:

  • elegí el lenguaje de programación que quieras
  • lo tenés que hacer solo

El resto corre por tu cuenta:

  • Podés preguntarnos lo que necesites. De hecho, es una buena señal que la persona tenga dudas, ya que implica habilidades de análisis
  • Podés usar google, stackoverflow o cualquier herramienta que usarías en el mundo real. No nos interesa saber si memorizaste todo el protocolo de la interfaz de streams de Java 8 . Lo más importante es cómo resolvés los problemas y tu capacidad de aprendizaje
  • Podés resolverlo a tu propio ritmo

La idea es simular un entorno de trabajo real. Por eso les dejamos usar una computadora, internet, una IDE, etc. Nadie programa en un pizarrón en el mundo real.

Obviamente esta no es una simulación real pero consideramos que es lo suficientemente real como para vislumbrar el comportamiento de la persona para su tarea más importante como desarrolladora: escribir código.

3. Entrevista técnica

Luego del ejercicio, la persona comparte el código de alguna manera (un repositorio privado, o simplemente por email). Luego,  le proponemos revisar su ejercicio en conjunto. Para esta entrevista, elegimos a dos entrevistadores diferentes que en la primera entrevista, y que ya vieron la solución y conocen el ejercicio.

En esta segunda entrevista, le pedimos a la persona que explique y justifique sus decisiones al desarrollar el ejercicio. Por ejemplo: “¿por qué elegiste modelar esta clase?” o “¿por qué elegiste utilizar herencia sobre delegación acá?” o “¿qué pasaría si esta parte cambiara? La idea es:

  • validar que haya escrito el código por sus propios medios
  • entender su manera de pensarlo
  • observar su reacción y propuestas ante los cambios
  • observar su respuesta a las críticas (porque también criticamos la solución)

4. Entrevista grupal

Imaginá una mañana de lunes perfecta, una sonrisa radiante, pájaros cantando, el Pastoral de Beethoven como música de fondo, un café en la mano. Llegás a la oficina, el ascensor está ahí esperándote. La vida te sonríe.
Finalmente llegás a tu escritorio, y ¡BOOM! Al lado de tu asiento hay una persona nueva. No pediste una persona nueva para tu equipo, no sabés nada sobre su experiencia, no sabés si es psicópata o qué. Asumís que puede escribir código, pero al rato te pregunta: “¿Para qué sirve esta palabrita function?”, con lo que tu lunes perfecto se esfuma.

Para evitar este escenario dramático, incluimos un último paso.

Si todo salió bien en las etapas anteriores, la entrevista final incluye a toda la gente de 10Pines (la pinada) y a la nueva semilla. La idea es que podamos elegir con quién trabajamos. Esta semilla puede terminar siendo tu compañero o compañera, entonces es importante participar en la decisión si queremos trabajar en conjunto. Por otro lado, la semilla puede ver todo el abanico de posibilidades que hay en la empresa, y no sorprenderse el primer día (o la primera semana). Esta entrevista es mucho más relajada y suele mezclar preguntas técnicas con preguntas personales. Fomentamos que cualquiera pregunte y comparta sus experiencias.

Resumiendo, el objetivo de este último paso es que la gente del lado de 10Pines pueda responder “¿Me gustaría trabajar con esta persona?”. Y desde el otro lado, la pregunta es similar: “¿Me gustaría trabajar con este grupo de personas?”

Conclusiones

Una cuestión a resaltar y que quizás no queda clara, es que nosotros no tenemos departamento de RRHH. Todo 10Pines participa de elegir a nuestra propia gente. Cada pino y pina puede y debe involucrarse en este proceso, por lo que la tarea de reclutar es transversal a otras tareas que cualquiera realiza.

Resumiendo las 4 etapas, tratamos de identificar en la semilla cosas que realmente nos importan:

  • Capacidad de aprendizaje
  • Habilidades de análisis
  • Que el código pueda mostrar su intención. Ver el código como medio de comunicación.
  • Comportamiento en grupo
  • Calidad humana (sí, ya sé, ¿qué es la calidad humana? Eso merece todo un post aparte) Por último, en 10Pines gozamos de una tasa muy muy baja de rotación, y pienso que nuestro proceso de reclutamiento es una de las causas.
Jul 10
0

10 años en 10Pines

By | 10pines

Va un post emotivo, así que abróchense el cinturón!!!

Los que me conocen saben de 10pines, pero quizás no sepan que en el 2019 cumplimos 10 años de esta locura. A veces me pregunto si tuvimos suerte… ¿les cuento una historia acerca de la suerte…?

Como saben algunas personas, tengo 2 hermanos más, menores. Yo soy el mayor. Cuando era chico, 7 u 8 años, había días en que mi papá nos llevaba a la escuela.

Uno de esos días pasó algo que me quedó grabado en el recuerdo. Ya rumbo a la escuela, yendo por la calle los 4, mi papá, mis dos hermanos y yo, una señora grande (en esa época, para mí era una “vieja”, pero quizás ahora que lo pienso era una jovenzuela de 40 años), al vernos pasar frente a ella, se agachó y se tocó las rodillas. El gesto pasó inadvertido para mí y mis hermanos, pero no para mi papá… que se enojó bastante con la señora y le dedicó un par de comentarios no felices. En ese momento no entendimos nada y seguimos de largo, contentos a la escuela. Pero al tiempo me quedé pensando qué pasó. Recuerdo contarle a mi mamá sobre esta secuencia. Ella me explicó: “resulta que hay una superstición que dice que ver a un “negro” es de mala suerte! Como un gato… Peroooo, para contrarrestar la mala suerte, tenés que tocarte las rodillas…”. Entonces, en ese momento, entendí un poco la molestia de mi papá.

Luego de estas experiencias me quedé pensando mucho y cada vez que me miraba al espejo pensaba si me daría mala suerte a mí mismo, si estaría maldito de por vida, o si tendría que hacer algo para contrarrestar mi suerte. La creatividad no tiene fin cuando uno es niño!

A partir de ese momento, el tema de la suerte empezó a ser una obsesión para mí. Y la pregunta de si tengo mala suerte estuvo, por mucho tiempo, siempre presente en lo que hice.

Ya de grande me crucé con “El gen egoísta”, un libro que me gustó mucho y que toca de costado el tema suerte. En mi opinión, tiene buenas intervenciones sobre este tema. Una cita, por ejemplo, dice que “La suerte, buena o mala, golpea al azar, y un gen que permanentemente se encuentra en el lado de los sobrevivientes no es que sea afortunado: es un buen gen para la supervivencia.”

También me crucé con pensadores, como Pasteur, que concluyeron sobre la fortuna que “La suerte beneficia a las mentes preparadas”.

Mi conclusión es que la suerte es el resultado directo de nuestro comportamiento, condicionado o influenciado por el entorno en el que elegimos actuar o movernos. Y en ese contexto o entorno hay azar, cosas que suceden que no controlamos. Pero esas cosas nos afectan más o nos afectan menos según estemos más preparados o menos.

Para que quede claro: la suerte (¿o el destino?) es el balance entre mis acciones y lo que hago con el contexto que me tocó. Algo así como el proverbio sartreano “uno es lo que hace con lo que hicieron de sí”.

Por eso, esto que construimos TODAS LAS PERSONAS que formamos 10Pines definitivamente no fue suerte. Y tampoco fue casualidad. Muchas veces nos han dicho (y aún nos lo dicen): “bueno, ustedes pueden hacerlo porque son pocos”, o “porque son de sistemas”, o “porque blah”. Sin embargo, no es porque somos “pocos” ni es porque “somos de sistemas”, ni es porque “estamos en otra época” o todas esas excusas que suelen poner.

En realidad, es porque las personas que estamos acá le hemos puesto pasión, amor, dedicación, tiempo, convicción, persistencia, coherencia, PASIÓN (sí sí, dos veces) y mucha energía. NO ES CASUAL. ES CAUSAL. Trabajamos para que pase y mucho. ¿Nos equivocamos? Sí. Pero aprendimos y trabajamos convencidos y con PASIÓN. La pasión nos une. La pasión para demostrar que otro mundo es posible, que otras formas son factibles.

Y hoy estamos acá porque encontramos una combinación de genes que funciona: La apertura, la participación (o colaboración), la horizontalidad, y la confianza. Y trabajamos mucho para entenderla, para encontrarla y para construirla. No alcanza con solo identificarla, hay que estudiarla, cultivarla, cosecharla y ceder cosas para cuidarla. Entender eso nos llevó 10 años.

Lo importante para mí, y que quiero transmitir, es que, después de muchos años de ese incidente que conté al principio de la señora tocándose las rodillas, y después de justamente 10 años de estar formando parte de este increíble grupo, realmente me doy cuenta que lo de la suerte era todo una mentira… y que mi preocupación fue en vano.

Hoy me sigo mirando al espejo, como cuando tenía 7 años. Sin embargo ya no me pregunto si voy a tener mala suerte. Veo el reflejo y recuerdo a toda la gente que trabaja en 10Pines, a todo este grupo increíble y toda esta energía que emana y pienso: “¡No puedo tener mala suerte, realmente soy un afortunado de formar parte de este grupo!”. Gracias por hacer de este lugar un gran lugar para vivir.

Jul 10
0

¿Por qué escribimos inclusivo?

By | Cultura

«Entonces Dios dijo: «Que exista la luz». Y la luz existió.»

Génesis, 1:3

El rol del lenguaje en la historia

 

Se suele decir que la “historia” de la humanidad no comenzó hasta la aparición del lenguaje escrito cerca del 4000 a.C. Hasta ese momento vivíamos en la “prehistoria” y gracias a la tecnología del lenguaje escrito empezamos a poder capturar nuestras realidades en forma de conceptos escritos, palabras: No sólo registrar lo que pasaba, además poder aprender de ello.

El lenguaje escrito nos permitió, además, compartir nuestras realidades, captadas en conceptos, con las siguientes generaciones. Gracias a esta herencia, una generación podía elegir qué conceptos conservar y cuáles transformar, o adoptar nuevos para mejorar su realidad y llegar a la siguiente.
Es entonces que el lenguaje no sólo fue una forma de registro del pasado, también se convirtió en una herramienta para modificar la realidad del futuro que se pasa de generación en generación y permite evolucionar la realidad colectiva, lo que se conoce como cultura.

Construcción de sistemas con lenguajes

 

Esta noción de construir realidad con el lenguaje no es ajena a cualquier persona que programa. Utilizamos múltiples lenguajes escritos para crear sistemas informáticos que, hoy en día, afectan nuestras vidas de una manera que nunca se vió en la historia.

Nunca fue tan claro que a través de los lenguajes se puede modificar la realidad.

Una de las principales lecciones que aprendí cuando pasé de programar en C a hacerlo en Smalltalk, fue la importancia de contar con buenos nombres en los métodos, clases, variables y objetos. Pasé de tener variables con nombres como “x”, “n”  o “var1” a otros más descriptivos como “estadoCansado”, “cantidadDeEnergia” o “estudiantesOrdenadosAlfabeticamentePorNombre”.

Este concepto es lo que se llama “intention revealing” (revelación de intención), y es una de las ideas que más me marcó cuando cursé “Paradigmas de programación” en la Universidad.

Intention revealing es un patrón que justamente propone “revelar” la intención al programar, es decir, buscar ser lo más explícito posible y decir el “qué” se quiere hacer cuando se está escribiendo código.

Según Kent Beck en el libro “Smalltalk best practice patterns”, intention revealing es “nombrar las cosas de forma tal que comuniquen qué es lo que van a hacer en lugar de cómo lo van a hacer. Es cómo comunicas tu intención (como persona que programa) cuando implementas algo. Comunicación. Es reconocer que lo más importante es que el código está ahí para comunicar.”

Escribir código no es más que comunicarse. Puede ser con la computadora, con otra persona que programa, e incluso comunicarse con mi yo del futuro.

Y como personas que desarrollamos software sabemos la importancia de esa comunicación y de tener buenos nombres cuando codeamos, para que el sistema final sea más fácil de entender y adaptar.

Cuando terminé de cursar esta materia, donde aprendí Smalltalk, esa “obsesión” por pensar y buscar los mejores nombres o palabras para describir las cosas se me contagió. Y no se quedó sólo en la programación, trascendió a otros aspectos de mi vida, como pasa con muchas ideas buenas. Este fue uno de los primeros momentos en que me dí cuenta el poder que tienen las palabras y el lenguaje. Y cómo este lenguaje puede ser usado de forma más o menos expresiva, más o menos declarativa. Cómo el lenguaje crea realidades y las visibiliza. Y si bien sabemos que pensamiento y expresión son dos procesos que van atados, entendí que es sumamente importante plasmar lo que estás pensando con palabras para poder comunicarlo y visibilizarlo.

A mi criterio Wittgenstein lo expresa increíblemente genial en su obra Tractatus Logico-Philosophicus cuando dice: «los límites de mi lenguaje significan los límites de mi mundo» («Die Grenzen meiner Sprache bedeuten die Grenzen meiner Welt»). Lo que no se puede decir, no se puede pensar.

Por eso, la forma en que hablamos construye realidades. Por eso es muy importante ponerle nombre a las cosas y tomarse el tiempo para esto cuando programamos, porque nombrarlas las crea. El asignarle un nombre me permite hablar de eso, me permite verlo, me permite pensar y comunicarlo mejor. Ponerle un nombre a algo es el primer paso a hacerlo visible. Las palabras y el lenguaje tienen la capacidad de ser transformadoras de la realidad.

Incluso existen muchos estudios científicos que hablan de cómo nuestra percepción puede estar condicionada a nuestro lenguaje diario. Y de cómo el lenguaje influye en el pensamiento. Esto es lo que plantea a grandes rasgos la hipótesis Sapir-Whorf (versión no determinista): “la semántica puede afectar al modo en que los hablantes perciben y conceptualizan el mundo”1.

Uno de los experimentos que demuestra esto es el de la científica Lera Boroditsky y los colores azules rusos. El idioma ruso tiene diferentes palabras para diferenciar azules claros (goluboy) de azules oscuros (siniy). Lo que se observa es que los hablantes de ruso son más rápidos para discriminar un objeto azul claro de un conjunto de objetos azul oscuro, mientras que a los de habla inglesa les implica más tiempo identificarlos, e incluso algunos no llegan a encontrar las diferencias. Esto se explica porque nuestra percepción de los colores no solo está relacionada con los colores que vemos, sino también por las palabras que les asignamos a los mismos. Tener una palabra para un color hace que lo puedas identificar más fácilmente.

Por todos estos motivos, cuando la idea del lenguaje inclusivo surgió me pareció muy potente y una solución mejor al modelo que veníamos teniendo, donde no se terminan de capturar algunos aspectos de la realidad, donde se generan situaciones ambiguas y donde se invisibilizan personas. Es decir que aporta una mayor precisión y elimina ambigüedad.

Evolución del lenguaje en 10Pines

 

Así como los programas evolucionan con el tiempo, y las palabras elegidas cambian a medida que el sistema mejora, los lenguajes usados para programar también cambian.

Cualquiera que sepa de programación sabe que los lenguajes de programación van mejorando con el tiempo, y se crean nuevas “versiones” que incluyen cambios necesarios para adaptarse a las nuevas tecnologías o prácticas.

Los lenguajes naturales no son ajenos a esto, pero de forma más sutil. Desde 1780, la RAE ha creado 23 ediciones de su diccionario. Casi 1 edición cada 10 años. El diccionario de la lengua española, a través de su autoridad más reconocida, nunca se ha mantenido estable en el tiempo, y siempre ha sabido evolucionar para adaptarse a las nuevas tecnologías que ofrece la nueva versión.

En 10Pines hemos decidido evolucionar nuestra cultura y adoptar la nueva tecnología2 que nos ofrece el lenguaje inclusivo tal como lo define wikipedia:

“El lenguaje inclusivo es un lenguaje que intenta evitar el sesgo hacia un sexo o género social en particular”

Por este motivo, desde 10Pines anunciamos oficialmente que comenzaremos a usar el lenguaje inclusivo en nuestras comunicaciones oficiales. Si bien ya venimos haciéndolo de forma implícita, creemos que es importante manifestarlo explícitamente.

¿Qué significa esto? En las comunicaciones oficiales vamos a hacer nuestro mayor esfuerzo para no dejar afuera a ninguna de las personas a las que nos estamos refiriendo. Usaremos diferentes estrategias según lo que mejor aplique en el contexto, a saber:

  1. Variante sin género: Sin modificar el lenguaje, la primer opción es buscar un workaround3 al lenguaje actual y entonces visibilizar un poco más la realidad, usando por ejemplo “persona que programa” o “quien programa” en lugar de programador.
  2. Inclusivo usando la “e”: Podemos crear nuevas palabras que carezcan de género explícito y completen más la descripción de la realidad por ejemplo creando la palabra “ingeniere”.
  3. Nombrar todas las posibilidades. Si ninguna de las opciones anteriores cubre nuestra necesidad, la opción es hablar de “ingenieros, ingenieras e ingenieres”. Aquí la “e” sirve para visibilizar la realidad de géneros no binarios.

Al desarrollar software generamos abstracciones, creamos palabras y conceptos nuevos constantemente. Como personas que programamos apasionadas por la calidad, nos comprometemos en la búsqueda de la mejor abstracción en nuestro código. Ahora, como integrantes de esta sociedad sentimos la responsabilidad de extender este compromiso a nuestras comunicaciones oficiales.

Definitivamente tener buenos nombres no asegura un buen diseño, pero ayuda. No es condición suficiente pero sí es condición necesaria. Lo mismo ocurre con el lenguaje inclusivo. Desde 10Pines queremos evolucionar nuestro lenguaje para construir una realidad que evite sesgos. No destierra la desigualdad y la injusticia del mundo, pero ayuda a visibilizar un poco más la variedad de personas que integramos este planeta y a mejorar el mundo en el que vivimos. Este es el fin último de nuestra organización.

  1. Esta cita no se escribió en inclusivo para respetar la cita original.
  2. Entendiendo tecnología como un conjunto de teorías y de técnicas que permiten el aprovechamiento práctico del conocimiento científico.
  3. Un workaround es un arreglo temporal para solucionar algo cuando la solución real aún no se puede implementar: https://en.wikipedia.org/wiki/Workaround.

Algunos links y referencias

Russian blues reveal effects of language on color discrimination: https://www.pnas.org/content/104/19/7780

TED Talk “How language shapes the way we think”: https://www.ted.com/talks/lera_boroditsky_how_language_shapes_the_way_we_think

Hipótesis de Sapir-Whorf: https://es.m.wikipedia.org/wiki/Hip%C3%B3tesis_de_Sapir-Whorf

Intention Revealing Names: https://wiki.c2.com/?IntentionRevealingNames

Jul 10
0

Resumen del primer Gemba Expedition

By | GEMBA

¿Qué es el Gemba Expedition?

Gemba Expedition es un viaje para personas que lideran empresas en LATAM buscando imprimirles una mirada más adaptativa, ágil y autosugestionada. Durante esta expedición recorrimos y conocimos empresas españolas con historias de logros y aprendizajes significativos e implementaciones únicas y particulares. También es un espacio que llama a la reflexión entre pares, sobre cómo estamos gestionando nuestros equipos y compañías. Incluso, es una buena oportunidad para nutrir y fomentar un tejido empresarial sano al ponerse en contacto con empresas con una visión similar en cuanto al tipo de management al que buscan evolucionar en sus empresas.

En esta primera edición, que duró 10 días, recorrimos 4 ciudades (Madrid, Barcelona, Bilbao y La Coruña), descubrimos más de 10 empresas y conocimos a más de 50 personas.Como todo, esto nace como un experimento que queríamos probar Ariel Ber, Jorge Roldán y yo, Jorge Silva, donde la hipótesis era validar si había valor en esto, si había gente que estaría dispuesta a viajar a España, conocer empresas y organizaciones atípicas, reflexionar sobre sus propias empresas y generar networking con personas con valores similares. Luego de mucho esfuerzo y organización, a mediados de noviembre, salió la primera expedición y este fue el resultado:

¿Qué hicimos?

La primera parada fue en Madrid, hermosa ciudad donde se puede sentir en el aire el desafío de un centro cosmopolita. Allí nos recibieron Israel Alcazar, Diego Rojas y Naty Calafell de Thinking with you junto a algunos de sus clientes: gente de Roche España, RSI y Novo Nordisk. Acá es donde tuve uno de mis primeros insights: ¡qué importante es la presencialidad! Podríamos haber hecho un webinar con el mismo temario de lo que hicimos en las oficinas de TWY y no hubiera sido ni la mitad de lo que nos llevamos al estar cara a cara. Estar presentes ahí, con el foco puesto en la conversación, teniendo feedback completo de todo el cuerpo, sumado a las charlas que se generan espontáneamente cuando hacemos un break, bajamos por un ascensor o caminamos hacia un restaurante, es insuperable.

Gemba Expedition en las oficinas de Thinking With You

Visitamos también a José San Román en ING, donde nos hicieron un lindo tour por sus oficinas y nos contaron todo su recorrido, aprendizajes y reflexiones liderando el cambio organizacional hacia la agilidad.

Fue súper interesante conocer este famoso caso de éxito en un banco de la talla de ING.

Gemba Expedition en las oficinas de ING

El segundo día de Madrid fue de los más locos y sorprendentes del viaje, una de las experiencias que más nos marcó: de la mano de Jose Manuel Sanchez y Julie Loriot visitamos una escuela ágil en el Boalo, en las afueras de Madrid, llamada Origami for Change. Sí, una escuela donde los alumnos aprenden usando como herramienta la agilidad y la sociocracia. En el marco de trabajo Agile Learning Center, esta escuela forma parte de una organización mundial. Ellos se definen como una “Comunidad de aprendizaje intencional, que usa la agilidad y sus herramientas como base para darle soporte a una educación autodirigida. Es un marco que fomenta la autogestión y la educación desde la experiencia y el involucramiento de todos los actores diferentes que participan en la formación de niños y niñas”. Incluso se plantea que el campo de la educación no está limitado por las paredes de la escuela, sino que se extiende a todo el pueblo donde está la escuela, por eso parte de la educación es presentar una propuesta al ayuntamiento, por ejemplo. Fue increíble ver como un niño de apenas 11 años facilitaba una especie de retrospectiva con sus compañeros y ver cómo identificaba tensiones para conversarlas. Nos fuimos de esa experiencia con un montón de preguntas sobre nuestra formación y sobre la educación que le queríamos dar a nuestros peques.

Gemba Expedition en la escuela Origami

Luego nos recibieron David Soler Soneira, Pia Rodriguez y Ana Perez, de Invesyde, para contarnos su recorrido por la implementación del enfoque NER (Nuevo estilo de relaciones). Una charla súper interesante y con un calor humano más que agradable.

La segunda parada fue Barcelona. Increíble ciudad donde aún se respira la innegable herencia que dejó Gaudi. Nuestro primer encuentro en esta nueva locación fue Runroom, una empresa de desarrollo de software. Carlos Iglesias y Montse Pachon nos contaron sobre su gran forma de gestión colaborativa, ágil y humana. Un modelo ad hoc increíblemente motivado por muchos de los drivers que motivó a 10Pines en sus orígenes: transparencia, colaboración, bien común, confianza, respeto y equidad. Esta parada fue muy interesante no sólo porque conocimos a la gente de RunRoom, sino porque también nos abrieron las puertas a algunos clientes y amigos como Jordi Gelabert y Jordi Medina de Hola Luz y Aritz Suescun Sánchez de Biko2. También se sumó gente de Deerns España de la mano de Miquel Castellvi, quien nos comentó otra implementación del enfoque NER de K2K en una consultora de ingeniería subsidiaria holandesa. Y aquí se abrió un espacio de discusión entre unas 20 personas en torno al management, la autogestión, la gestión de clientes en este tipo de organizaciones y los nuevos roles que toman los directores, fundadores y líderes.

Una frase que me dejó esta conversación y que me encantó fue la que pronunció Montse: “Cuando el trabajo es de todos, los problemas son de todos también”.

Esta sesión nos llevó todo el día. Permanecimos allí hasta las 4 de la tarde, momento en el cual decidimos ir a visitar la Sagrada Familia y ponerle fin a nuestro primer día en Barcelona.

Gemba Expedition en las oficinas de RunRoom

El segundo día en Cataluña nos llevó a las oficinas de Voxel. Esta empresa implementó un modelo sociocrático muy interesante. Tuvimos una charla muy cautivadora con Xavier Albaladejo, principal coach que impulsó la implementación y Àngel Garrido, su CEO. En la charla con Ángel, una de las cosas que me sorprendió fue ver en sus orígenes la inspiración de un gran conocido: Ricardo Semler. Luego de esto hicimos un juego llamado «Next Level Serious Business Game», creado y facilitado por Mathieu Durrande donde introdujimos el concepto de la teoría evolutiva de Ken Wilber y las ideas de las organizaciones Teal que se detalla en el libro de Laloux, Reinventing Organizations. Mientras jugábamos a ser una organización y hacerla evolucionar hasta ser teal, tuvimos muchas risas y también muchas revelaciones sobre el comportamiento humano y organizacional.

Gemba Expedition en las oficinas de Voxel jugando al teal game
Gemba Expedition en las oficinas de Voxel jugando al teal game
Gemba Expedition en las oficinas de Voxel jugando al teal game

Cerramos nuestra visita a Barcelona con un almuerzo rápido para luego ir al aeropuerto rumbo a Bilbao, ciudad del gran Koldo.

Una mención especial que quiero hacer es el acompañamiento que tuvimos en Barcelona de Ingrid Astiz Jensen, agilista de origen argentino, convertida al barcelonismo, que nos hizo de puente para que nuestra estancia fuera un éxito. Nos ayudó con temas varios: desde lo logístico hasta hacernos reflexionar y acompañarnos en un open space que improvisamos en Voxel.

A Bilbao llegamos por la noche del martes, así que comimos unos pinchos, unas cañas, recorrimos brevemente la rambla y el imponente Museo Guggenheim.

Gemba Expedition en Bilbao

Temprano, en la mañana lluviosa del miércoles, nos esperaban Koldo Saratxaga y Óscar Garcia en la fábrica de Lancor, una fábrica de motores de ascensores que fue la primera en implementar el enfoque NER hace más de 10 años y que hoy funciona en un nivel  sorprendente de autogestión y transparencia de la información. Recorrimos la fábrica, conocimos a sus trabajadores y nos emocionamos con las lágrimas de una trabajadora que contaba cómo había cambiado su vida desde que trabajaba en Lancor. Lo que nos recuerda que cambiar el modelo de gestión no es un tema operativo, es el cambio de mindset que no sólo impacta a las personas en su trabajo, sino que también lo hace en el resto de sus vidas.

Luego, tuvimos nuestro plato fuerte, una charla mano a mano con Koldo y Oscar sobre el estilo K2K y su filosofía. Pudimos conversar, emocionarnos, reflexionar, discutir y conocer un poco más al legendario Koldo. Una persona fuera de serie: Lúcido, rebelde, generoso, humano.

Gemba Expedition en la fabrica Lancor junto a Koldo

Como no podía ser de otra manera, cerramos nuestro fugaz paso por Bilbao en una cantina vasca con extraordinaria comida y profundas conversaciones y reflexiones.

Nuestra última parada fue en La Coruña, donde participamos de la CAS y efectuamos el cierre del viaje. En la CAS nos volvimos a encontrar con varias de las personas que visitamos en la semana y, también, con grandes referentes de la comunidad ágil española. Algunas de las charlas y personas más interesantes, para mí, fueron la key note de Bas Vodde, cocreador de LeSS; la charla sobre Estrategias de transformación desde el Comité de Dirección de Xavier Albaladejo y la charla de cierre de Carmen Vidal, referente del agilismo español, contando aprendizajes y reflexiones de su carrera profesional.

Gemba Expedition en la CAS

Cerramos la CAS y nuestro viaje con una retro donde pudimos conversar como nos atravesó el viaje, qué aprendizajes nos llevamos y, lo más importante, reflexionando sobre cuál sería nuestro gran primer pequeño paso en el camino de la autogestión.

Gemba Expedition - Cierre en las CAS

Algunas reflexiones finales

Quería compartir, a modo de conclusión, algunos puntos que me llevé, producto de esta experiencia:

  • Una revelación interesante que tuve, coherente con el espíritu del viaje, es que entendí que no fuimos a visitar empresas, sino personas. Conocimos experiencias, aprendizajes e historias de personas. Lo importante del viaje fue conocer a estas personas. Desde luego, las empresas están de fondo, generando identidad en grupos. Sin embargo, el valor del viaje no está en ir a conocer una empresa, sino a una determinada persona que trabaja en dicha empresa circunstancialmente. Por eso es importante guiarse por las personas que encontramos en el camino más que por los grandes nombres de las empresas.
  • Como siempre, algunas de las joyas de este tipo de eventos son las conversaciones en los pasillos, en los taxis, almuerzos, donde pensamoss, junto a los viajeros, sobre lo visto y lo analizamos más profundamente, lo desafiamos y lo intentamos procesar para llevarlo a nuestra realidad laboral diaria.
  • Luego de ver la emoción de una trabajadora en Lancor, charlando con el grupo, se nos ocurrió que una buena métrica de salud organizacional en tu empresa podría ser cuánta gente se emociona al hablar de la compañía en la que trabaja.

¿Próximos pasos? ¿Querés sumarte al próximo?

Con Ariel y Jorge Roldan quedamos muy entusiasmados y pudimos ver todo el valor que este viaje aportó. Pudimos validar la hipótesis de que hay gente dispuesta a hacer el viaje, hay gente dispuesta a recibir a los viajeros y, como resultado final, esa interacción le aporta valor a ambos lados. Por eso, ya estamos organizando un nuevo viaje para abril. Así que si te interesa sumarte o saber más, visitá nuestra web y escribínos: https://liqueed.org/cursos-abiertos/gemba-expedition/

Gemba Expedition - Despedida del viaje en la CAS
Jul 10
0

Semco y 10Pines, una historia de amor

By | GEMBA

Allá, por el 2006, un compañero de la facultad me acercó un resumen de un libro que tenía algunas ideas “locas” sobre management de empresas. Como yo en ese momento era un estudiante de último año de Ingeniería, defensor de los desarrolladores y su rol protagónico, todo lo relacionado al management me sonaba a “humo” o estrategias de cómo exprimir a los empleados.

En el 2009 ya estaba cansado de pasar de empresa en empresa y sufrir siempre los mismos problemas: poca transparencia en el management generando desconfianza en los equipos, alta rotación, bajo compromiso y una consecuente baja calidad del producto construido. Por eso, en ese momento junto con Emilio Gutter, Alejandra Alfonso y Hernán Wilkinson pensamos en unir fuerzas para crear una empresa de desarrollo de software, donde apuntáramos a resolver esos problemas de raíz, usando como guía los principios y valores de la agilidad: colaboración, autogestión, transparencia e involucramiento.

Sorpresivamente, ese mismo año Emilio me compartió el mismo resumen que había llegado a mis manos en el 2006. Esta vez decidí prestarle atención. Buscaba inspiración para resolver los desafíos clásicos de liderar una empresa que estaban empezando a asomar, y por eso le di una nueva oportunidad. Ese documento era un resumen del  libro Maverick, de Ricardo Semler, CEO de Semco. En él se narra todo el recorrido, a lo largo de los años, por el que esta importante empresa industrial brasileña transformó radicalmente su organización, para alcanzar un estadio de organización colaborativa y transparente para sus integrantes. Las reflexiones y anécdotas del propio Ricardo, responsable inicial de este proceso transformador, ilustraban un camino recorrido, que, en el plano de los resultados económicos, implicó un cambio en la facturación, pasando de 4 millones de dólares en 1982 a 212 millones de dólares en 2003. Yo quedé enamorado de las ideas que se planteaban en el resumen del libro y de la visión de Ricardo. Cuando terminé de leerlo sabía que tenía que conseguir el libro y estudiarlo completo. Sonaba todo increíble, y por eso quería conocer los detalles.

Cuando por fin conseguí y leí el libro, entendí que esa era nuestra nueva brújula. Las ideas innovadoras y la lucidez con la que Ricardo describe los desafíos de las empresas y modelos tradicionales resonaban en mi mientras pasaba las páginas. No solo el modelo filosófico me resultaba coherente, la implementación que gestó con las prácticas que detalla en el texto me parecían increíbles. Prácticas como la definición de salarios por los mismos trabajadores, el reparto de ganancias con todos las personas que trabajan, la participación de los todo integrante colaborador en el proceso de recruiting, entre otras. Semco lograba bajar a implementación muchas de nuestras ideas abstractas. Fue para nosotros una fuente de inspiración y de acompañamiento. De inspiración porque tomamos muchas ideas y las remixamos para nuestra realidad. Y de acompañamiento porque nos hizo sentir menos solos, sentir que no éramos los únicos locos que veíamos que el modelo clásico no nos representaba.

Así fue cómo descubrí las primeras ideas de Ricardo Semler y su empresa, Semco.

Para mi, Semco fue una inspiración desde que 10Pines nació y Ricardo una guía (sin que él lo supiera). Encontramos en Semco el puente que unía nuestras ideas ágiles y el management. Es decir, al venir del mundo ágil, nuestra mentalidad estaba 100% alineada con buscar proyectos de desarrollo de software ágiles. Pero después de haber trabajado en muchos espacios antes de 10Pines, entendimos que si el management no acompañaba este mindset de agilidad, no podríamos tener mucho éxito. Comprendimos que existe un mismatch entre la agilidad y el management clásico, con lo cual no podíamos ser ágiles y tener una empresa con las prácticas de management tradicionales como tener un jefe, un organigrama, la lucha de poder por ocultación de información, la separación en departamentos, etc. Cuando conocí Semco entendí que era una gran forma de llevar el mindset de la agilidad, al management. Y, por eso, entendimos que era la mejor forma de gestionar la empresa: basándonos en la confianza, tomando decisiones de forma colaborativa, compartiendo la información y distribuyendo de una forma más justa las ganancias.

En ese momento Maverick era todo lo que había. Solo un libro, algunas charlas TED. De vez en cuando se publicaba algún nuevo video de Ricardo, o alguna nota, que devorábamos apenas nos llegaba.

Desde que descubrimos la historia de Semco, uno de nuestros grandes sueños fue conocer a Ricardo y trabajar con él y su empresa.

En el 2018 me enteré de la creación de Semco Style Institute (SSI), una organización que había puesto en teoría la práctica y el caso Semco. Ricardo, junto a algunas personas más, creó un framework tratando de sintetizar el aprendizaje de Semco a lo largo de toda su vida, y compartirlo y contagiar otras empresas y cambiar el mundo del trabajo y la gestión empresarial. Esta organización estaba en Holanda, el material estaba principalmente en holandés y los cursos y charlas, también. Con lo cual quedé un poco triste porque las posibilidades de interactuar eran pocas. Sólo me quedó la esperanza de que en algún momento adoptarían el inglés como lengua secundaria.

Los caminos se siguieron cruzando como una premonición del futuro que nos uniría. En marzo del 2020 publicaron en el newsletter de SSI un post de 10Pines donde contaban cómo hacíamos recruiting. Ver que Semco hablaba de nosotros fue una hermosa caricia al alma. Nuestra inspiración ahora nos citaba como ejemplo!

Finalmente en junio del 2020, en medio de la pandemia, llegó el contacto definitivo: un mail a mi casilla que decía “Semco Style Consultancy Certification Program”. En ese momento supe que tenía que sumarme y terminar de estudiar lo que había comenzado hacía más de 10 años. Luego de varias conversaciones con Daphne (representante de SSI), conseguí inscribirme en el primer programa internacional que SSI hacía online. 4 meses después, estaba rindiendo mi examen de certificación, una evaluación autogestionada por los asistentes que me resultó una genialidad por la coherencia que tenía con lo que habíamos estudiado en el programa.

Para coronar este evento, llegó uno de los hitos que recuerdo con más emoción: como parte del programa tuvimos una sesión con Ricardo Semler para hacerle preguntas e intercambiar ideas en una charla en vivo.

No soy una persona que tenga héroes o idolatre personas. Tampoco, una persona que tenga el concepto de “sueño de mi vida”. La emoción que sentí significó que me estaba dando cuenta que podía lograr cosas que hasta ese momento creía muy difíciles, casi imposibles o muy distantes. Era sentir un reconocimiento al trabajo de años y una señal de “ok, completamos un capítulo”. Compartir una charla con él, ser parte de Semco, eran cosas que había imaginado por mucho tiempo, pero veía distantes, lejanos… Finalmente estaban pasando. No estaba cumpliendo el «sueño de mi vida»; estaba alcanzando un hito de mi vida, en el cual estaba haciendo cosas que creía casi imposibles, viviendo momentos que por mucho tiempo imaginé utópicos y conociendo de primera mano ideas, personas y organizaciones que fueron formando la persona que soy hoy.

Luego de esto, en el 2021, comenzamos lo inevitable. SSI y 10Pines tenían mucha afinidad en el trato. Había muy buena comunicación y nos entendíamos muy bien porque a pesar de tener idiomas nativos diferentes, hablábamos el mismo idioma humano: el de la colaboración y la confianza. Así surgieron nuestras primeras conversaciones para crear Semco Style Argentina. En junio del 2022 firmamos el partnership y así dimos comienzo a una formalidad que sentíamos desde que el resumen de Maverick tocó mis manos.

Hoy, 14 años después de haber escuchado las primeras ideas de Ricardo y enamorarme de Semco y su filosofía, estoy muy contento y emocionado de anunciarles que 10Pines va a estar representando a Semco Style Institute en Argentina. Creemos que compartimos el propósito, los valores, la práctica, el amor, la pasión y el esfuerzo de luchar por ver un mundo mejor, trabajando desde el impacto en las empresas y organizaciones.

Hoy, 14 años después de leer las primeras hojas de Maverick, 10Pines y Semco Style Institute se unen y dan nacimiento a Semco Style Argentina.

Ahora nos toca empezar un nuevo capítulo.

Hoy más que nunca, estamos listos para construir el futuro del trabajo, juntos.

Jul 03
0

CFP: el primer paso para presentar en una conferencia

By | Tips

Nahue nos cuenta qué es un CFP, qué debe tener una propuesta y cómo abordar este proceso.

 
If want to see this post in English, click here.

¿Qué es un CFP?

CFP (por sus siglas en inglés, Call for Papers o Call for Presentations) es un paso que tienen muchas conferencias que ayuda al comité organizador a elegir las mejores propuestas para el evento en cuestión.

A menudo se lo ve como un paso difícil y a veces nos da miedo aplicar (por razones varias), lo cual nos puede llevar a que quizás algunas buenas ideas no lleguen a ser escuchadas.

Veamos qué debe tener una propuesta y cómo abordar este proceso…

Secciones comunes de una propuesta

La información requerida para enviar una propuesta no es siempre la misma, depende de la organización del evento. Pero en líneas generales incluyen secciones como:

  • Título: cómo se va a llamar tu presentación, y cómo va a aparecer en caso de ser seleccionada o anunciada.
  • Resumen: también conocido como Abstract o Elevator Pitch, es en mi opinión la parte más importante de la propuesta debido a que resume tu idea y, a la vez, es el lugar en donde “vendés” tu presentación.
  • Descripción: una explicación en profundidad de la presentación, qué tópicos va a cubrir, en general responde a la pregunta de qué es lo que va a esperar la audiencia de tu presentación. Es válido agregar cualquier información que no esté en el resumen y que creas relevante comentar.
  • Notas para el comité de selección: a veces, las personas que van a seleccionar nuestros trabajos necesitan conocer algo más que la descripción, especialmente más contexto. Esta es una sección en donde podés convencer a los revisores de que tu charla es apropiada para el evento y contás con la experiencia para que salga bien. Pueden incluso pedirte experiencia previa con charlas o links a trabajos que soporten lo que vas a presentar.
  • Detalles de la presentación: este es un lugar donde los organizadores preguntan cuestiones como el formato de presentación, duración, nivel de conocimiento de la audiencia, o requerimientos especiales que necesites.
  • Información del presentador: tu nombre, biografía, pronombres, foto de perfil, links a redes sociales, blogs y/o sitio personal, y cualquier otra información que sirva para conocerte más. En algunas ocasiones, para evitar sesgos en la selección, es una información que no se ve en una primera instancia de la revisión.

Tips para crear una buena atractiva

Aquí va una colección de tips que, en mi corta experiencia, he podido identificar y quizás puedan serte de utilidad.

Haz tu propuesta atractiva

Hay un gris entre vender algo que no tenemos (dicho de otra manera, generar demasiadas expectativas) y ser demasiado humilde al punto de desestimar nuestro propio trabajo. En este área gris es donde debe estar la propuesta. La honestidad es lo más importante, pero no olvides destacar las cosas que más orgullo te generan. Sé consciente de tus propios sesgos, intentá validar la propuesta con personas de confianza para obtener feedback inmediato en momentos previos a presentar tu idea. Usá palabras clave; por ejemplo, si el evento es sobre clean code podés mencionar la palabra refactoring siempre y cuando esté relacionada con tu tema.

Haz tu propuesta única

Los CFPs tienen un aspecto competitivo: es muy alta la posibilidad de que varias personas intenten hablar del mismo tema. ¿Por qué la audiencia debería escucharte a vos? No olvides incluir experiencias, tips y cualquier otro toque personal que hayas hecho como parte de la propuesta.

Presenta un plan

Un plan puede ser un aspecto atractivo más allá del contenido. Ayuda a comunicar qué está en tu mente. ¿Tu charla tiene etapas bien definidas? ¿Una sesión de live coding quizás? ¿Algo de tiempo para interactuar con la audiencia? ¡Menciónalo!

Conoce tu audiencia

Tu propuesta necesita ser atractiva no sólo porque el contenido es bueno, sino porque la audiencia que la va a ver encuentra ese contenido atractivo. Una cosa que suelo hacer al momento de aplicar a una conferencia, es revisar su sitio web, redes sociales, registros de eventos pasados, feedback de personas que participaron, con el fin de identificar esa audiencia. Las preguntas más importantes que podés hacerte son:

  • ¿Cuáles son los diferentes niveles de experiencia que vas a encontrarte?
  • ¿La conferencia es sólo para desarrolladores o incluye otros roles también?

Practicar, practicar y practicar

Las personas que hacemos software no estamos muy acostumbradas a escribir este tipo de propuestas. Así que es totalmente válido que las cosas no salgan bien, debemos tomarlo como algo natural y no bajar los ánimos si nuestra propuesta no es aceptada.

La única manera de mejorar en este aspecto es haciéndolo varias veces. Comencé a practicar con una o dos propuestas en 2018, el año siguiente apliqué a 8, y el siguiente envié 15 propuestas. ¿Estoy esperando un 100% de porcentaje de aprobación? ¡Claro que no! Mi objetivo es aprender.

Algunas conferencias ofrecen feedback en caso de rechazar la propuesta. Esa información es muy útil para repensar la propuesta, adaptarla y presentarla en la próxima edición o en otro evento (sobre todo si sospechamos que podría tener mejor recepción en otra audiencia).

Aplicar a conferencias pequeñas puede ser una buena idea para aumentar las chances de aceptación. Pero no dejes de aplicar a conferencias grandes, que son más desafiantes, y te ayudarán a medir qué tan lejos podés llegar. Sólo lleva tiempo escribir una propuesta, el proceso de aplicación es gratis.

Sí, se puede repetir una presentación

Las propuestas pueden repetirse en diferentes conferencias, sin importar si fueron aprobadas o no. La audiencia cambia y siempre puedes encontrar personas que encuentren tu contenido interesante. De todos modos sugiero realizar variantes, tener en cuenta el feedback de presentaciones anteriores, el aspecto único que le queremos dar a la propuesta, como así también los aprendizajes y mejoras que quieras aplicar.

Conclusiones

  • Tener un tema para presentar no es suficiente, debemos diseñar cómo queremos presentarlo y sobre todo conocer a quiénes presentarlo.
  • Hacer la propuesta atractiva haciendo énfasis en aquellas partes clave, sin prometer cosas que no vamos a cumplir pero a la vez resaltando lo valioso de tu trabajo.
  • Hacer la propuesta única incluyendo opiniones, experiencias, tips. Intenta que la gente quiera oír del tema de vos antes que de alguien más.
  • Los detalles de la presentación son muy importantes. ¿Cómo te imaginás presentándola?
  • Practicá lo más que puedas, y no sientas que fallaste si no aceptan tu propuesta. Siempre es una oportunidad para aprender y encontrar mejoras. Apóyate en el feedback rápido de tus pares y personas de confianza.
  • Se pueden repetir las presentaciones, aunque es una buena idea buscar variar en alguna manera pensando siempre en el evento y la audiencia.
 
Jul 03
0

Piensa antes de actuar

By | Cultura

Las organizaciones buscan estar en control de la situación para asegurarse los resultados esperados. Pero cuidado, estar en control no es necesariamente sinónimo de controlar.

“Intuición, suerte, errores, casualidad: ahí tienes cuatro conceptos empresariales vitales que todo directivo debería conocer.”

                            -Ricardo Semler

El término burocracia (del francés bureaucratie, compuesto de bureau ‘oficina’, ‘escritorio’ y -cratie, procedente del griego krátos ‘poder’, ‘dominación’) se refiere a una organización o estructura que se caracteriza por procedimientos centralizados o descentralizados, división de responsabilidades, especialización del trabajo, jerarquía y relaciones impersonales.

El sociólogo Max Weber definió a la burocracia como una forma de organización que realza la precisión, la velocidad, la claridad, la regularidad, la exactitud y la eficiencia conseguida a través de la división prefijada de las tareas, de la supervisión jerárquica, y de detalladas reglas y regulaciones desde un solo sitio de trabajo. La burocracia en sí es un tipo de gobierno.

Entonces… la burocracia no es tan mala… ¿o si?

Las organizaciones buscan estar en control de la situación para asegurarse los resultados esperados. Pero cuidado, estar en control no es necesariamente sinónimo de controlar, ¿verdad?

El control consiste en reducir el riesgo. Habitualmente una parte importante del control se centra en el comportamiento de las personas, prevenir las malas intenciones, posibles fraudes, desvíos, trampas. Las organizaciones gastan muchísimo tiempo y dinero en corroborar si las personas salen y vuelven de sus vacaciones cuando dijeron que lo iban a hacer, si los días de enfermedad son los correctos de acuerdo a la dolencia, si es verdad que los días de estudio fueron utilizados para estudiar, desde dónde y en qué horarios trabajan las personas, hasta elaboran complejas matrices de autorización de gastos donde dicen cuánto dinero y en qué condiciones puede disponer cada quien.

Estos controles se basan en estándares y manuales y reglas y procedimientos y auditorías y… lo siento, esto sólo les va a aportar una falsa sensación de seguridad. O lo que es peor, estas reglas pueden conducir a desviaciones que antes ni se les hubieran ocurrido. Entonces se genera una nueva regla para prevenir esa otra desviación y así hasta el infinito.

¿Te preguntas por qué se empezó a aplicar determinada regla en una organización? Por ejemplo, te llama la atención que en las actas de reunión se pone mucho detalle en registrar qué dijo cada persona en vez de las conclusiones, o se pone quiénes estaban invitados además de quienes asistieron. Cuando son muy detalladas en general existe una anécdota de fondo que cuenta la vez que alguien hizo algo y entonces a partir de ese momento apareció este control extra y toda la organización la sigue ciegamente. ¿Es realmente necesaria? ¿Se podría simplificar de alguna manera? ¿Cuál es el motivo ulterior? ¿Qué sentido tiene? A medida que pasa el tiempo, y la organización empieza a convivir con esta nueva regla, ya nadie se hace estas preguntas.

Así comienza a engrosarse el aparato burocrático. Cada vez más reglas detalladas, cada vez menos espacio para pensar. Abro el manual, leo la regla, acciono. Listo, se terminó el trabajo. No aprendí, tampoco innové. Sólo seguí reglas pre-establecidas.

Cuando no hay tantas reglas

Si se me plantea una situación que no tiene un instructivo detallado de cómo resolverla, ¿qué hago?

Puedo empezar a hablar con otras personas que trabajan conmigo para tener referencias o pedir ayuda (ah sí, está permitido intercambiar experiencias y colaborar). También puedo intentar resolverla de la misma manera que lo hacía en otro trabajo, en la facultad o hasta en mi casa. O, por último, quizás pueda descubrir una manera nueva y totalmente innovadora de hacerlo.

En el momento que me enfrento a una situación así posiblemente voy a estar activando algunos de los grandes valores: ese día aprendí algo nuevo, pedí ayuda y la recibí, sentí en primera persona la colaboración y hasta tuve espacio para innovar. Ya gané.

Las reglas en su justa medida son necesarias, sirven para marcar los límites de actuación y que las personas puedan tener una idea dentro de qué parámetros moverse. Lo desafiante es encontrar la cantidad justa de reglas que den pautas y no apaguen el sentido común.

Llegar a una organización donde no hay nada escrito y cada cosa debe ser repensada cada vez puede volverse bastante trabajoso y poco eficiente. Entonces, no pensemos en ese extremo, los extremos no son buenos.

Burocracia por sentido común

El sentido común se puede desarrollar en las personas de una organización. Esto se hace a través de conversaciones, dinámicas, espacios de reflexión, sesiones de alineamiento y explicitación de intereses, compartir casos de éxito y error, poner en común las diferentes formas de hacer las cosas que se tiene en cada equipo, tomar decisiones en forma participativa, disponer de información y capacitación para entender esta información.

Si hacemos esto, se genera una red de experiencias que simplifica por mucho mi árbol de decisiones y, al no ser restrictivo como una regla, da espacio a seguir innovando a partir de las experiencias compartidas. Tengo el espacio para proponer nuevas formas de hacer las cosas, para probarlo y aprender.

Cuando se desarrollan equipos más fuertes y competentes, el poder de las reglas no escritas y el control social pueden ofrecer una alternativa a las bibliotecas de archivos con procedimientos escritos. De esa manera, ofrecer un trabajo de calidad se convierte en el objetivo principal, en lugar de seguir ciegamente reglas o procedimientos.

Para una empresa, es esencial mantener el control y conocer el impacto de las decisiones tomadas. Definitivamente es importante trabajar con descripciones de procesos, KPI, etc. Pero las preguntas que es necesario plantearse son: ¿Dónde se puede simplificar el trabajo? ¿Dónde están los desperdicios en el proceso? ¿Dónde puede encontrar espacio para el sentido común y la responsabilidad personal?

Cuando se acaba con la burocracia

Desde Semco Style se considera fundamental el poder acabar con la mayor parte de la burocracia en las organizaciones. Sustituirla por confianza, transparencia, autonomía. Siendo uno de los pilares del principio de Controles Alternativos que se proponen en el framework, destaca los siguientes beneficios asociados:

  • Se incrementa el sentimiento de pertenencia
  • Crece la responsabilidad individual
  • Se reduce la complejidad y el desperdicio de recursos
  • Proporciona espacio para el intercambio y la colaboración
  • Aumenta la autonomía, agilidad, eficiencia
  • Aumenta la creatividad y flexibilidad
  • Mejora los resultados

¿Ahora empieza el lío?

¡Claro que no! Al contrario, ahora empieza el orden real. El que es pensado, sentido y adaptado a cada momento y situación. Las personas no quieren que les digan a cada momento qué hacer o necesiten atravesar muchísimos medios de control para hacer cada cosa. Lo que esperan es sentir que les tienen confianza, que si necesitan guía o ayuda la pueden obtener. Los controles generan desconfianza cruzada. La burocracia saca las ganas de hacer las cosas. Cumplir con el procedimiento termina siendo más importante que obtener mejores resultados.

La invitación es a confiar en que las personas no son tontas, las contratamos por su valor profesional y algunas veces lo desperdiciamos pidiéndoles que sigan reglas sin pensar. Es más fácil equivocarse al ejecutar un procedimiento que al usar el sentido común.

Si, el desafío de alinear ese sentido común lo tienen las organizaciones, líderes, gerentes.

Si, es más desafiante que escribir procesos, procedimientos, reglas, normas, etc. Pero los resultados serán infinitamente más valiosos. Promesa.

¿Cómo lo hacemos en 10Pines?

10Pines es una empresa de desarrollo de software con alrededor de 100 integrantes. Nuestra gestión interna está basada en la confianza y modestamente creo que nos va bastante bien.

Esto no quiere decir que no tengamos reglas, pero sí es importante destacar algunas características fundamentales:

  • Toda regla puede tener alguna excepción si consideramos que sería más justo en el caso de una persona que lo requiere.
  • Las reglas son dinámicas, se escriben y refinan tantas veces como sea necesario.
  • Todas las personas tenemos acceso a estas reglas que se encuentran en un lugar de fácil acceso.
  • La cantidad de reglas son acotadas y son usadas como orientación para la gestión
  • Cada nueva regla propuesta o cambio sobre alguna regla actual debe tener el consentimiento de todas las personas de la empresa.

Un ejemplo entre muchos

Como nos interesa incentivar el movimiento y vida saludable, quisimos tener un beneficio de gimnasio que nos satisficiera. Al empezar a investigar, ninguna de las propuestas terminaba de convencernos. Es que en 10Pines hay intereses muy diversos, desde yoga hasta crossfit, pasando por básquet, danza, artes marciales, acrobacia, etcétera, etcétera.

Fue entonces que propusimos disponer de un valor mensual tope y que cada persona lo pudiera usar para su actividad física preferida. Si tu cuota mensual es inferior a ese tope, solamente usás lo que necesitás. Si tu cuota mensual es mayor a ese tope, la diferencia se paga de forma individual. Si no hacés actividad física no lo usás.

Sin burocracia. Sin controles. Simple, flexible, aplica a todos-todos los gustos y necesidades. La información es transparente. El procedimiento es extremadamente sencillo. Los valores tope e indicaciones están disponibles en un lugar accesible y conocido.

Basado en la confianza. Nunca hubo ni un sólo problema.

¿Por qué considerar este tipo de práctica?

Siempre que surgen situaciones cotidianas, como qué tipo de billetes reservar para viajar o cuánto entregar para facturas médicas, los empleados suelen estar confundidos acerca de qué está bien y qué no. Si bien se entiende que utilizan su capacidad de juicio y sentido común para tomar estas decisiones, puede que no siempre sea la mejor decisión porque no cuentan con información de contexto.

El sentido común difiere de persona a persona (sobre todo entre quienes son más nuevos en la empresa), por lo que establecer algunas normas puede ayudar a evitar confusiones o malentendidos. Si los empleados saben que sólo pueden gastar $10.000 al mes en gasolina o en viajes, entonces planificarán sus viajes en consecuencia. Si no existiera tal norma, algunos podrían tomar vuelos más baratos y otros no. Y esto eventualmente causaría divisiones y tensiones innecesarias entre los empleados.

Es importante encontrar el punto de equilibrio entre la burocracia y el caos. Contar con algunas normas y parámetros, que no sean demasiadas y que ayuden a tomar mejores decisiones a las personas. Lo que no está escrito, si la organización está madura, se resuelve desde el sentido común.

Algunas pautas

Déjenlo claro: asegúrate de que cada regla o norma vigente esté claramente definida; esto evita confusión sobre los tecnicismos más adelante porque los conflictos aumentan cuando las personas tienen diferentes suposiciones tácitas. También asegúrate de que cada norma o límite (lo que se puede hacer y lo que no) se discuta y que todos estén de acuerdo con los términos antes de aplicarlos.

Hablen sobre esto: las discusiones abiertas son una excelente manera de resolver conflictos y asegurarse de que todos estén en sintonía. Dado que las personas pueden ser tímidas o tomarse un tiempo para adaptarse a las situaciones, es bueno esforzarse por tener conversaciones abiertas y honestas sobre cada norma con regularidad. De esta manera, las empresas obtienen opiniones más honestas y abiertas y entienden qué quieren los empleados y con qué no están de acuerdo.

No hay bien ni mal:  cuando hablamos de normas y límites, es importante comprender que no se trata de «leyes» rígidas. En pocas palabras, son pautas. Además, cuando hay problemas entre los empleados, es importante saber que no existe el bien ni el mal. Hay un malentendido o una confusión debido a suposiciones u opiniones de ciertas personas y no está bien pensar que es un error. Es la confusión lo que hay que abordar. Entonces, lleguen a un entendimiento juntos y busquen un acuerdo flexible sobre las normas. Esto ayudará a construir una relación de confianza entre todas las partes.

Establezcan un contrato social:  esto aborda preguntas como «¿Cómo queremos estar juntos en el lugar de trabajo?» La respuesta sería: queremos ser abiertos, honestos, auténticos, amables, respetuosos, etc. Luego, cuando las personas tengan claros los conceptos básicos, hablen sobre cómo quieren que esto suceda y con qué se sienten cómodos haciendo. También es importante hablar sobre conductas que se deben excluir y qué no se debe hacer en la oficina. En 10Pines, por ejemplo, generamos un Protocolo de Género donde establecemos ciertas conductas no deseadas y los pasos a seguir en caso de ocurrencia.

Expliquen con ejemplos:  tengan siempre ejemplos y situaciones concretas para hacer que las normas y los límites sean tangibles para las personas. Traten de evitar descripciones muy amplias y superficiales para las interpretaciones; en su lugar, entren en detalle con ejemplos explícitos. Y cuando analicen un ejemplo, asegúrense de que todos lo comprendan y estén en sintonía.

Sean coherentes:  es importante alinearse  continuamente con las normas, los límites y el sentido común . Asegúrense de que una vez que se establezca una norma o límite, se cumpla durante el resto del año (por ejemplo, con actualizaciones periódicas o revisiones cada 6 meses). Esta es una forma saludable de saber si todos avanzan en la dirección correcta.

 

Escrito por Mariana Mier

Basado en el contenido de Semco Style Institute

Jul 03
0

iOS – Signing Certificates y Provisioning Profiles

By | iOS

Uno de los requisitos fundamentales a la hora de distribuir una app para iOS es la generación de Signing Certificates y Provisioning Profiles. En este artículo serán identificados los pasos necesarios para generarlos y poder manipularlos.

Los Signing Certificates son archivos encriptados provistos por Apple que nos permiten firmar las aplicaciones permitiendo asegurar la autenticidad de estas.

Los Provisioning Profiles también son archivos provistos por Apple pero en este caso no están encriptados. Se utilizan para asociar el identificador de nuestra app con funcionalidades provistas por Apple (push notifications, Apple Pay, mapas, etc.) y/o dispositivos de desarrollo.

Los Signing Certificates y Provisioning Profiles[1] (en adelante SCyPP) pueden ser de desarrollo o de distribución. Los de desarrollo servirán para ejecutar nuestra app en simuladores y los de distribución para ejecutar nuestra app en dispositivos reales y para distribuir nuestra app en AppStore.

Si bien xCode nos facilita la gestión automática de estos, entender cómo funcionan es importante si necesitamos compartirlos para trabajar en equipo o si queremos automatizar el proceso de distribución de nuestra app.

Credenciales

Para poder obtener SCyPP es necesario contar con un Apple ID asociado a Apple Developer Program.

El Apple ID es la cuenta que se utiliza para acceder a los dispositivos y servicios de Apple. Este se puede obtener a través de https://appleid.apple.com/. Podemos asociarnos a Apple Developer Program a través de https://developer.apple.com/programs/enroll. Es habitual que el dueño de la aplicación que estemos desarrollando sea un tercero, en ese caso, debemos solicitarle que asocie nuestro Apple ID a su organización.

Una vez que contamos con un Apple ID asociado a Apple Developer Program podemos generar SCyPP a través de https://developer.apple.com/account en el apartado Certificates, IDs & Profiles o a través de xCode.

Vamos a detallar el proceso a través de xCode que es más sencillo de ejecutar.

1. Abrir el proyecto en xCode, seleccionar la pestaña Signing & Capabilities y habilitar la casilla Automatically manage signing.

En este caso, se trata de un proyecto creado a través de Flutter, por lo que el proyecto y el target principal se denominan Runner.

2. En el desplegable Team seleccionar la organización asociada a Apple Developer Program. En el caso que xCode no tenga configurado nuestro Apple ID podemos agregarlo a través de la opción Add an account… del desplegable Team.

3. xCode se encargará de generar y/o descargar los SCyPP correspondientes. Durante el proceso nos solicitará la clave de nuestro Keychain para almacenarlos localmente.

4. Podemos chequear la correcta generación de SCyPP ejecutando nuestra app. Para verificar los de desarrollo, lo hacemos en un simulador y para verificar los de distribución, en un dispositivo real.

5. Abrir la aplicación Keychain Access.

6. Seleccionando el keychain login y la pestaña My Certificates podemos ver los certificados generados.

7. Podemos exportar cada certificado haciendo click derecho sobre su nombre. Nos solicitará un nombre para el archivo, su formato (Certificate o Personal Information Exchange) y una clave para proteger el archivo. Cualquiera de los dos formatos es de utilidad.

8. Los provisioning profile generados serán almacenados en archivos de extension .mobileprovision dentro de ~/Library/MobileDevice/Provisioning Profiles

De esta manera obtenemos:

  • certificado de desarrollo
  • certificado de distribución
  • provisioning profile de desarrollo
  • provisioning profile de distribución

Accediendo a Provisioning Profiles

Al momento de compilar una aplicación será necesario indicar el provisioning profile que utilizaremos. Habitualmente xCode se encarga de resolverlo automáticamente, pero, si compilamos manualmente, necesitaremos indicar el nombre del provisioning profile que utilizaremos.

Hay dos formas de obtener el nombre de un provisioning profile:

Para hacerlo desde el sitio web debemos ingresar a http://developer.apple.com/account y, en el apartado Certificates, IDs & Profiles, seleccionar la opción Profile. Luego serán listados los provisioning profiles creados, accediendo a cada uno podemos ver su nombre y el ID de la app a la que está asociado.

Si tenemos el provisioning profile almacenado localmente podemos accederlo mediante la ruta ~/Library/MobileDevice/Provisioning Profiles, el contenido de cada archivo de extensión mobileprovision corresponde a un provisioning profile, su contenido se encuentra encriptado. Podemos desencriptarlo con el siguiente comando

/usr/bin/security cms -D -i [ruta al archivo]

Los campos application-identifier y name son los que contienen la información que necesitamos. Mediante estos podemos especificar que provisioning profile utilizaremos para nuestra app.

Conclusiones

Aplicando los conceptos detallados anteriormente y mediante el uso de las herramientas indicadas podemos firmar y distribuir nuestra app iOS de manera segura y cumpliendo con los requisitos de Apple. Además, fueron descriptos los pasos necesarios para obtener y manipular SCyPP con la finalidad de automatizar el proceso de distribución de nuestra app iOS.

[1] Se conservaron estos términos y otros en su idioma original debido a que así es como figuran en xCode y en la web de Apple que son las herramientas que utilizamos para gestionarlos.

Jul 03
0

Hablemos de Fake News

By | Research

Entre tanto bombardeo constante de información, distinguir lo verdadero de lo falso se hace cada vez más difícil. En este post exploramos las noticias falsas y nos preguntamos cómo abordar este problema en busca de soluciones.

Ejemplo del uso de "notas" de X para añadir contexto a una publicación.Ejemplo del uso de «notas» de X para añadir contexto a una publicación.

Jul 03
0

Una guía rápida para optimizar tests con Kotlin y Spring Boot

By | Testing

¿Trabajas con Kotlin + Spring Boot + Gradle y tus tests son demasiado lentos? Este artículo es para vos.

You can read this post in English here.

Esta lista de puntos problemáticos sobre el rendimiento de los tests y las recomendaciones para abordarlos proviene de mi experiencia con una suite de tests en un proyecto de Kotlin + Spring + Boot + Gradle con aproximadamente 1500 tests. Comenzamos con 13 minutos por ejecución y terminamos con 5 minutos (ejecutandolos en el mismo contexto).

¿Por qué es importante tener tests rápidos?

Los tests lentos pueden ser un dolor de cabeza en casos como:

  • Cuando haces TDD (Test-driven development) y necesitas ejecutar un test varias veces (cambiando algo pequeño y corriendo el test una y otra vez).
  • Cuando cambias el código y querés ejecutar todas los tests para ver si todo sigue funcionando bien.

Problemas abordados

Tiempo de inicialización de JVM

Probablemente viste este mensaje en tu IDE de Intellij cuando ejecutas tests localmente:

Esta es la Máquina Virtual de Java (JVM) iniciándose. A veces, esto toma demasiado tiempo y, cuando querés ejecutar solamente un test, es un problema. Investigando un poco, noté que ejecutar los tests con la configuración de JUnit en lugar de la configuración predeterminada (Gradle) mejora mucho este tiempo de inicialización.

Para ejecutar tus tests con JUnit en lugar de Gradle:

Vas a Preferencias → Construcción, Ejecución, Despliegue → Gradle y pones la configuración «Elegir por test» y cuando quieras ejecutar un test, una clase de test o una suite, podes elegir ejecutarlas con JUnit:

Contexto de Spring

Algunos tests necesitan inicializar el contexto de Spring antes de ejecutarse. Estos son las que tienen, por ejemplo, la anotación @SpringBootTest arriba.

Esto puede tardar demasiado, por lo que deberíamos intentar reutilizar el contexto de Spring Boot entre las clases de test, para iniciarlo menos veces.

El contexto se reutiliza por defecto, a menos que hagas cosas como:

  • Usar anotaciones de Mockito o Mockk, como @MockBean o @SpyBean, que generan su propio contexto personalizado.
  • Usar la anotación @DirtiesContext que crea explícitamente un nuevo contexto (ejemplo de uso común: en caso de que estés cambiando clases singleton en dos clases de test y no quieras afectar una clase de test con la otra, agregas esta anotación).

¿Cuál es la solución?

  • Probá diferentes alternativas para evitar usar @MockBean y @SpyBean.Dos ejemplos:

1) Si tenes un test de Controlador que quiere probar el caso en el que se devuelve un 404 cuando el coche que estás buscando no existe en la base de datos:

No hagas esto ❌

@SpringBootTest
@AutoConfigureMockMvc
class CarControllerTest {
    @Autowired
    private lateinit var mvc: MockMvc
    @MockkBean
    private lateinit var carService: CarService

    @Test
    fun `a 404 code is returned if you are asking for a non-existent car`() {
        every { carService.find(1) } throws NoSuchCarException()

        mvc.perform(MockMvcRequestBuilders.get("/cars/").param("carId", "1"))
        .andExpect(MockMvcResultMatchers.status().`is`(HttpStatus.NOT_FOUND.value()))
    }
}

No mockees ni del servicio ni del repositorio, en su lugar: pedí un coche que sabes que no existe en la base de datos (por ejemplo, id = 9999), o elimina el coche con id = 1 a través del CarRepository antes de pedirlo a través del Controlador.

Hacer esto es una ventaja, ya que estás probando esta funcionalidad de una manera más realista y sin usar mocks.

2) En algunos casos, podes reemplazar un @MockBean creando un mock normal pasándolo a través del constructor de la clase que necesitarás, en lugar de usar @Autowired para esa clase. También te vas a deshacer de la anotación @SpringBootTest:

  No hagas esto ❌

class CarServiceTest {
    @MockkBean
    private lateinit var weatherGateway: WeatherGateway
    @Autowired
    private lateinit var carService: CarService

  Hace esto ✅

class CarServiceTest {
    private var weatherGateway: WeatherGateway = mockk()
    private var carService = CarService(weatherGateway)
  • Si tenes MockBeans que son difíciles de sacarlos de encima, podes crear una clase padre con esos mocks y heredar de la misma en todas las clases de test de SpringBoot, de modo que el contexto sea siempre el mismo contexto personalizado.Por ejemplo: tenés una clase que tiene un mockbean «A» y otra que tiene un mockbean «B». En ese caso hay 2 contextos personalizados diferentes ❌✅ La solución puede ser crear una clase padre que tenga tanto mockbean «A» como mockbean «B», para que el contexto personalizado sea único en ambas clases hijas.

    ⚠️ Tené en cuenta que algunas clases de test pueden necesitar la instancia real de esa clase y no el mock, por lo que probablemente deberías «desmockearla» en la clase en la que la estás haciendo mock después de usarla.

 

  • Evita el uso de anotaciones como @DirtiesContext al identificar qué beans se compartieron y cambiaron entre las clases de test y limpiando esos beans antes de que otra clase los use.Ejemplo: Notamos que estábamos usando el mismo bean en muchas clases de test: un repositorio JPA. Y aunque eliminábamos todo en el repositorio después de cada clase de test, teníamos algunos tests inestables. Esto se debe a que no importa si eliminas objetos en el repositorio, los ids siguen incrementándose, y teníamos algunos tests que dependían de un id específico.Por ejemplo: creo algo en el repositorio, y luego verifico algo con el id 1 porque es la única entidad en el repositorio… suposición incorrecta! ❌

    ✅ La solución es hacer tests que no dependan de un id específico y codificado.
    Un ejemplo de esto:

@Test
fun "an exception is thrown if the car doesn't have enough fuel to travel"() {
    val car = carRepository.save(Car(type = CarType.FORD_FOCUS, remainingFuelLiters = 35))
    
    val exception = assertThrows<NotEnoughFuelException> { carService.travel(car.id, 400) }
    assertEquals("Your car has not enough fuel to travel 400 km", exception.message)
}

Otras cosas útiles

Configuraciones personalizadas de ejecución/debug y tagging

Podes crear tus propias configuraciones de JUnit para ejecutar solo los tests de una clase específica, un directorio específico, un paquete y más.

También podés crear un tag sobre una clase de test específica, usando la anotación @Tag de JUnit:

@SpringBootTest
@Tag(“integration-test”)
class CarServiceTest {

Luego podés crear una configuración combinando diferentes tags (los tags pueden usarse como campos booleanos, por lo que se pueden usar todos los operadores booleanos). Por ejemplo, esta configuración ignora los tests de integración:

También podés marcar la opción «Guardar como archivo de proyecto» para guardar una configuración y agregarla al repositorio para que todos los demás la tengan.

Profiling

Medir cuánto tiempo toma ejecutar los tests y qué es lo que toma más tiempo. Podés hacerlo de varias maneras. Sin embargo, los números pueden no ser realmente representativos de lo que está sucediendo. Por ejemplo, a veces el IDE indica que los tests se ejecutan en aproximadamente 1 minuto. Pero ese no es el caso. Simplemente no está computando el tiempo de buildeo y los tiempos de creación del contexto de la aplicación.

Para ver informes con más detalles y números en tiempo real, podés exportarlos con estas 2 opciones del IDE:

Recomendaciones y Conclusiones

  • Los puntos problemáticos mencionados acá no son los únicos que podés encontrar, pero pueden disminuir mucho el rendimiento de tus tests.
  • Intentá usar JUnit en lugar de Gradle para ejecutar tests, especialmente si estás ejecutando suites simples y queres conocer el resultado más rápido.
  • Inicializar el contexto de Spring no es barato, hacelo solo si es necesario. El uso de anotaciones como @SpringBootTest generalmente está asociado con tests de integración, y para evitar caer en el anti-patrón del cono de helado, se recomienda tener más tests unitarios que tests de integración, así que no pongas la anotación @SpringBootTest en todas partes.
  • Si estás usando @SpringBootTest, intentá reutilizar el contexto tanto como puedas, evitando el anti-patrón que mencioné antes y haciendo alguna investigación si ves que no se está reutilizando y no estás usando las anotaciones que mencioné (para entender en qué tests se está inicializando el contexto de Spring, tenes que mirar en qué clase de test aparece el logotipo de SPRING).
  • Usá mocks solo si es necesario, por ejemplo, en caso de que el contexto sea difícil de reproducir. No hagas mock de todo porque al final no vas a estar probando nada.