TLDR; Este post es parte del episodio 4 de la segunda temporada de Café con Tech

El desarrollo de software es más que la colección de líneas de código escritas en un día, si no, es por sobre todo una actividad humana. Si!, a pesar de que por mucho tiempo se consideró que quienes desarrollaban software eran una especie de ermitaño computacional hoy en día podemos ver, vivir y sentir que nuestra actividad se ha convertido en un proceso donde la comunicación se ha vuelto tan o más esencial que el número de caracteres de código que escribes en un día.

Cuando desarrollamos software lo que en realidad hacemos es crear soluciones para resolver algún problema. Este problema es algo que otra persona presenta y desea resolver, es decir, estamos entregando a otro una herramienta.

Es común que cuando llega la hora de entregar algún producto de software, sea este un demo, un feature o el producto final el estrés aumenta, hay que trabajar horas extras, se crea aún más deuda técnica y un sin fin de malas prácticas, la mayoría evitables. ¿Por qué? Obviamente es un problema de múltiples variables, pero creo que una de gran importancia es como las cosas llegaron a ese momento.

Más de lo que pasó en el momento de la entrega (o próximo a ella) es más bien la historia tras ese proceso. ¿Cómo llegamos hasta aquí? ¿Qué es lo que esperábamos? Son las expectativas que cada persona involucrada en el proyecto tenía las que provocaron de una u otra manera el resultado final repleto de estrés.

Definir las expectativas, y hacerlo bien desde un primer momento lo cambia todo. Claramente no se eliminan las malas noticias y tampoco puedes prevenir todo simplemente al bajar las expectativas, pero si pueden aminorar el impacto final y suavizar las relaciones entre las personas.

Los seres humanos somos muy poco hábiles a la hora de estimar nuestras propias capacidades, normalmente estamos en uno de los extremos: sobreestimamos o sub-estimamos lo que somos capaces de hacer, y esto no deja de ser cierto en el desarrollo de software. Una práctica común, aunque bastante cuestionada por muchos, es la de entregar estimaciones para cada parte del proyecto, desde la estimación de tiempo/esfuerzo del proyecto como un todo hasta la estimación de cada tarea a realizar.

Es en esta práctica donde fijar expectativas entra en juego a diario. Cuando estimamos querámoslo o no estamos creando un compromiso de tiempo y esfuerzo, cuando este no se cumple una de las partes recibirá el estrés y desenfado de la otra.

Pongámoslo así. El manager o líder técnico del equipo describe una tarea en particular, se pregunta al equipo como enfrentaran el problema y al mismo tiempo se le dice "No se preocupen, tómense el tiempo que quieran". Obviamente el equipo o el desarrollador dirá. Ok. Ya que no es urgente lo resolveré cuando pueda. Pero, en realidad el manager quiso decir, "necesitamos esto luego, pero no te mates trabajando". Es diferente o no?. El manager tiene la expectativa de que la tarea descrita será resuelta en un tiempo moderado, ya que es relativamente urgente, pero el desarrollador entendió literalmente que podía tomarse todo el tiempo del mundo. Al final del sprint o ciclo de desarrollo, ambos estarán frustrados y quizá enfadados dado que no se cumplió lo esperado. La expectativa aquí fue mal declarada.

¿Como mejorar esta situación?

Ya lo comentaba en el episodio 12 de la temporada anterior una de las habilidades esenciales hoy en día es la comunicación, que debe ser clara y efectiva, mejorar en este aspecto te permitirá generar mejores expectativas.

Para comenzar, 4 puntos a trabajar

• Claridad: La ambigüedad en el mensaje es el principal riesgo a la hora de comunicar expectativas. Un mensaje claro, al grano y sencillo ayudará a declarar la expectativa de modo que todos comprendan lo mismo. Esta es una habilidad que se debe trabajar día a día. Hoy con el incipiente crecimiento del trabajo remoto la comunicación por mensajes de texto aumenta de forma exponencial y la cantidad de roces creados por un mensaje mal escrito o expresado es pan de cada día.
• Se honesto: Si, pero no solo con otros, si no, contigo mismo. Ya mencioné lo malo que somos - en general - para estimar nuestras propias fuerzas y debilidades, por lo tanto piensa bien en tu actual capacidad de resolver lo propuesto y responde con honestidad a esa pregunta repetitiva de ¿Cuánto tiempo tomará? ¿se puede hacer? ¿para cuándo estará? Etc. Piensa si realmente puedes cumplir con esa deadline o restricción de tiempo o si simplemente estás respondiendo que si porque es lo que espera tu equipo.
• Comunica los cambios: si ya declaraste una expectativa en la que todos están de acuerdo, pero por diversas circunstancias el escenario cambia y sabes que es expectativa no será cumplida entonces debes comunicar lo antes posible esos cambios. Nadie debería crucificarte por modificar la expectativa siempre y cuando sea a tiempo. Comunica la situación antes que sea demasiado tarde, antes de tener que decidir: me enfrento a la realidad y decepcionó a los demás en último momento o trabajo horas extra en exceso solo para cumplir lo acordado.

Es como avisar que llegarás tarde a una reunión. Si sabes que llegarás tarde y no fue alguna emergencia es adecuado avisar con anticipación así nadie estará esperando que llegues ni perdiendo su valioso tiempo.

Importante también es comunicar este cambio en las expectativas a todos quienes se verán afectados por la modificación no solo al Manager o tech lead.

Definir las expectativas de forma clara y honesta puede ser difícil e incluso incómodo y abrumante, pero mejor generar esa incomodidad antes que herir sentimientos o romper confianzas más tarde.

Es cierto que decir que una tarea te tomará 3 días cuando todos esperaban que fuese 1 puede sonar desesperanzador o incluso amenazante por la necesidad de encajar y de no ser visto como menos, pero es mejor comprometerse inmediatamente a lo posible que a lo imposible por cumplir expectativas falsas.

Definir buenas expectativas de forma temprana puede hacer la diferencia entre un proyecto exitoso y uno fallido.