Que bueno que nos leemos de nuevo

Saludos desde un Vancouver con sol y calor al alza.

Antes de ir a lo bueno, quería contarte que:

• Decidí mover el día de envío de este newsletter a los jueves. Si bien, disfruto escribir en un fin de semana, quiero que ese tiempo sea exclusivamente para mi familia.
• Empezarás a recibir otro correo en la semana. Pero con audio 📢. Quiero experimentar con ese formato y ver cómo va.

Si crees que lo anterior no se ajusta a la expectativa cuando te uniste por primera vez, puedes desuscribirte. Nos vamos a llevar igual de bien ✅.

Y con eso, vamos a los temas.

👌🏻 La 3 mejores formas que conozco para mejorar la productividad en un equipo

La semana que viene viajaré a Seattle y podré al fin conocer a mi equipo. Nunca antes nos hemos juntado. Solo en reuniones por Zoom.

Nos reíamos la semana que pasó porque esa junta será parecida a una “cita a ciegas” pero sin la parte de cita 😅. Será incómodo pero a la vez entretenido.

Como yo y quizás probablemente tú, conocí a mi equipo actual el año pasado. Hemos tenido solo interacciones digitales y varios de los procesos que hemos creado carecen del componente oficina. No dependemos de ella.

La pandemia dentro de todo lo malo, nos dio una oportunidad. De redefinir rituales y actividades. Por ello, nuestra productividad ha ido en aumento y mejora constante.

Hoy quiero hablarte de maneras de medir y mejorar la productividad, mientras creas software.

Antes de entrar a los puntos, quiero dejar claro que las métricas son un arma de doble filo. Los mejores equipos en los que he trabajado usan métricas, y al mismo tiempo discuten abiertamente, experimentan y re-definen su concepto de éxito. Un “feedback loop” constante.

Por lo tanto, si bien los números entregan una idea de cuan productivo se puede llegar a ser, no te recomiendo basarte exclusivamente o abusar de estos para tomar decisiones.

Ahora vamos a los puntos 🙏🏻

🪚 Herramientas

Cuando un equipo se toma más en serio su productividad, inevitablemente empiezan a aparecer herramientas, utilidades y frameworks que optimizan procesos comunes al crear software.

Un lead de “developer productivity” y personas dedicadas exclusivamente al desarrollo de herramientas, empujará la calidad del código y felicidad de developers.

Una recomendación es, si vas a desarrollar y mantener herramientas que aceleren el software, entrega la mayor propiedad y capacidad de decisión posible a developers. No deberían existir dependencias externas que prevengan hacer mejoras o crear nuevas.

Cuidado también en introducir nuevas herramienta que automaticen procesos. Si bien, existen innumerables alternativas para revisar tu código, traducir de un lenguaje otro y hasta escribir código con inteligencia artificial, estas pueden no ajustarse a las necesidades del equipo.

Como gran fan del “open source”, admiro a las empresas que donan sus frameworks y librerías a la comunidad. React, TensorFlow y Xamarin son algunos ejemplos de lo anterior.

Así, developers externos se vuelven parte de la sucesión de mejoras y quitan presión al equipo mantenedor interno. ¿Los beneficios? Más ojos y opiniones al código fuente, mejoras más rápidas e incluso aumento de motivación para el equipo interno.

↪️ Las nunca bien ponderadas “pull request”

Los “pull request” (PR) son el orgullo de un developer y la mejor manera de validar horas y horas de trabajo. En equipos donde la productividad es alta, se tiende a optimizar la creación, feedback y aprobación de los PRs.

En empresas grandes, donde por ejemplo, una app móvil tiene 10 equipos trabajando en el mismo código fuente, el proceso de revisión se hace complejo. Principalmente, por el cambio de contexto. Un equipo sabe lo que hacen sus otros compañeros y al mismo tiempo carece de conocimiento de los features que trabajan los otros 9 equipos.

Si involucras a alguien que no trabaja contigo en la revisión de tu PR, probablemente volverá con comentarios técnicos o de arquitectura.

En cambio, si quieres obtener feedback de valor deberás invertir tiempo, ya sea a través de un video o escribiendo en la descripción de la misma, y así la que te está revisando tendrá una mejor visión del cambio propuesto.

Algunas métricas a observar y experimentar dentro del mundo de los PRs:

• El número de líneas o cambios. Dicen que el valor óptimo va por las 200 a 300 lineas de cambios.
• Número y tipo de personas involucradas revisando un PR. Más ojos y menos contexto del cambio que hay en el PR, menor será el éxito de aprobación de esta.
• Tiempo entre creación y primer comentario. Menor a 12 horas es óptimo. Mayor a 2 días es preocupante.

🤙🏻 Un equipo que se entiende

La productividad escalará exponencialmente cuando todos comparten una misma visión sobre el producto.

Es iluso pensar que un equipo que apenas se conoce, y que trabaja 4-6 meses en un proyecto (eso generalmente dura el desarrollo de una app o MVP), termine por entregar su mejor productividad.

Si ese mismo equipo continua mejorando el producto o comenzando uno nuevo, se pueden predecir mejores resultados.

El “pair programming” es un hábito poco usado. ¿Será que a los devs no nos gusta mucho pedir ayuda y que nos vean el código no terminado? 🧐 A mi me fascina y cada vez que quiero feedback, mando un mensaje a alguien de mi equipo para discutir un método o posible solución a un problema.

Cuando más haces eso, las siguientes llamadas de “pair programming” serán más efectivas y el equipo irá creando un conocimiento compartido de buenas prácticas.

Realizar demos es otra hábito sano que impacta en la moral de los developers. Acá ni siquiera es obligatorio tener un feature terminada. Un componente, una vista o un flujo entre pantallas puede valer para mostrar tu trabajo y recibir feedback públicamente.

La última práctica que te quiero recomendar para entenderse mejor, son las “retro” o “post mortems”. Básicamente, un espacio sin prejuicios donde se discuten mejoras para las siguientes semanas de desarrollo. Se producen momentos para conocerse más y reflexionar sobre situaciones desafiantes pasadas.

💡Resumiendo…

Las tres áreas anteriores son lo que considero tácticas primordiales para mejorar la productividad de un equipo.

Aprovechando el espacio, te doy otros tips rápidos

• Evita reuniones que no tengan un objetivo. Si lo puede discutir por Slack o Teams, mejor.
• Transforma reuniones diarias, en mensajes asincrónicos. Por ejemplo, en vez de actualizaciones diarias de 15 minutos, intenta probando solo de lunes a miércoles, y jueves/viernes hazlo por mensaje en Slack/Teams.
• Elige un día con tu equipo donde no hayan reuniones 👏🏻.
• Esquiva equipos donde pocas personas tengan conocimiento experto de algo. Agrega “más ojos” cuando sea posible y promueve un ambiente de aprendizaje constante.

¿Qué te pareció?

👉 ¿Agregarías otro tip? Responde a este correo si tienes otras formas de mejorar la productividad.

Tweet de la semana

¿Has compartido este newsletter con un amigo? Sería bacán si lo hicieras

Link de registro a newsletter

¿Tienes alguna pregunta para mí? Responde este correo.

Hasta la semana que viene.

Felipe

​Linkedin | Instagram | Twitter | Website​

❤️ Hecho con amor y dedicación.

💰 Puedes ayudarme a seguir haciendo este contenido con un tip en el “chanchito nerd”.