¿Qué hace que un producto o app sea excelente?

Su experiencia de usuario, facilidad de uso, rapidez, claridad, si es útil para la persona que lo usa, entre otras.

Tras participar en numerosos proyectos de creación de productos, he identificado un elemento crucial, que es la comunicación entre los miembros del equipo que trabajan en el producto respectivo.

O sea:

Calidad de comunicación de equipo proporcional a calidad del producto

En software, esto lo vemos reflejado principalmente entre los grupos de producto e ingeniería (lo que hablaba con Nick la semana pasada en esta sesión premium).

En este post, quiero mostrarte algunas formas de equilibrar la balanza, cuando se refiere a desarrollo de features y acabar con la famosa deuda técnica.

🧯 El impacto de no encargarse de la deuda técnica

La deuda técnica puede tener un efecto negativo en el desarrollo de productos en varios aspectos. Por ejemplo, puede retrasar la entrega de nuevas features ya que el equipo de desarrollo debe invertir tiempo en solucionar problemas causados por decisiones previas.

Esto también puede afectar la capacidad de una empresa para responder rápidamente a las necesidades de su mercado, lo que podría resultar en una pérdida de oportunidades de negocio y de ingresos.

Además, la deuda técnica puede causar problemas de calidad en el producto final. Las soluciones temporales pueden conducir a errores, fallas de seguridad que afectan negativamente la experiencia del usuario.

Por último, la deuda técnica puede generar un ambiente de trabajo desmotivante para los developers, que pueden sentirse frustrados al tener que lidiar constantemente con problemas del pasado en lugar de centrarse en innovar y o crear nuevas soluciones. Esto puede conducir a la disminución de la moral del equipo y menor productividad.

📑 Comunicación con equipo de producto

El primer gran paso que puedes dar para encontrar esta sincronía es juntarte con tu equipo de producto y crear un documento que liste el scope y estimación de cada una de las cosas que se quieren hacer. Esto funciona bien para temas generales y así tener un idea de lo que está en juego.

Lo siguiente, y en especial si existen varios equipos o productos, es importante utilizar una herramienta para crear épicas y tickets con el detalle necesario. Acá hay un sin fin que podemos discutir (JIRA, Clickup, Basecamp, Asana, Monday). Lo valioso es entregar otra oportunidad de discusión en más detalle y refinar el scope y estimación.

Al tener todo lo anterior, y no menos crítico, es saber como se va a distribuir el equipo para atacar nuevos features y deuda técnica. En mi experiencia, es más productivo dejar que las personas se enfoquen en solo una área, en vez de estar alternando entre las dos. Si una persona desea trabajar en las dos, se pueden definir bloques de períodos (ejemplo: 2 meses para un feature, 3 semanas para actualizar el SDK).

🪛 Entregando prioridad a la deuda técnica

Viniendo esto desde un developer que ya lleva 15 años creando apps, entiendo perfectamente la motivación y objetivo detrás de mejorar el código fuente e infraestructura tech.

Pero una habilidad esencial cuando se habla de deuda técnica, es determinar si es urgente o si puede esperar a ser resuelta. ¿Cuándo es urgente? Algunos ejemplos.

• La versión de una librería creó un hoyo de seguridad donde se filtran datos personales.
• No se está capturando suficiente información de analytics para saber si se está cumpliendo un objetivo de negocio.
• La empresa está creciendo muy rápido y se está perdiendo mucho tiempo en hacer onboarding. Se necesita documentación actualizada.

Los managers o jefes juegan un papel sustancial al definir que importa y que no. Ellos deben hacer un esfuerzo para acercarse a los detalles técnicos y el porque se está pidiendo hacer algo. Desde ese punto, detectar patrones y no caer en la influencia de opiniones extremas sobre alguna tecnología o framework.

Aquí también se encuentran tareas que no son famosas por tener prioridad. Es el caso de la mantención de documentación. Mi consejo aquí es considerar ese tiempo al momento de estimar un ticket o épica. Además, la documentación no tiene hacerse al final necesariamente. Puede partir como un mapa mental, lista de temas y evolucionar a medida que evoluciona el código.

🌀 Tiempo para innovar

Me encanta esta estrategia, pero he notado lo difícil que es implementarla o hacerlo sustentable en el tiempo. Básicamente, se trata de “regalar” tiempo a los equipos de software para construir nuevos features o resolver deuda técnica.

Acá el principal desafío es (nuevamente) alinear los equipos de producto y de ingeniería en un roadmap común. Hay equipos que también definen conceptos para un período de innovación. Por ejemplo, “dar vida a la app con animaciones” o “usar algún servicio de inteligencia artificial”.

Una vez más, mantener el scope limitado es una buena recomendación para que el trabajo no impacte el curso normal del desarrollo del producto.

En algunas situaciones, el líder del equipo de desarrollo debe dar un paso extra y comunicar de forma más pro activa la libertad y flexibilidad que tienen los developers en estos bloques para innovar.

Por último, los developers deben tener en cuenta que el equipo de producto es el que por default tiene la responsabilidad de transmitir el éxito de estos períodos de innovación. Ellos comunican las analíticas que se alinean con los objetivos de negocios y entregan input a los diseñadores para mejorar la experiencia de usuario.

Quiero terminar este post con un par de preguntas para ti.

¿Crees que es sano tener deuda técnica? ¿Existe algún momento del año donde es mejor atacar la deuda técnica?

Te leo en los comentarios.

Podcast - nuevo episodio

Valiente, generosa y apasionada por la comunidades latinas. Así es la invitada del nuevo episodio de mi podcast.

Andrea Griffiths, colombiana de origen, es una apasionada del mundo “DevRel” (un tema que me ha estado interesando mucho en los últimos meses). Actualmente trabaja en Github, apoyando a comunidades latinas y enseñándoles sobre como la tecnología puede crear nuevas oportunidades.

Escucha el nuevo episodio acá:

Nerd From Chile Podcast #24: Andrea Griffiths

May 2, 2023

Listen now (66 min) | Justo al momento de terminar la grabación con Ramón, el me sugirió y presentó a Andrea para hacer el mismo ejercicio. ¡Fue una excelente recomendación! Andrea Griffiths, colombiana de origen, es una apasionada del mundo “DevRel” (un tema que me ha estado interesando mucho en los últimos meses). Actualmente trabaja en Github, apoyando a comunidades latina…

Read full story →

Quote de la semana

Esta semana tuve la oportunidad de escuchar a Camille Fournier en una charla por Zoom. Me hizo recordar (por enésima vez) lo excelente que es “The Manager’s Path”.

En uno de los puntos de la charla, hizo énfasis en lo importante que es como líder evitar ser simpático con nuestro equipo, y que al contrario, debemos concentrarnos en ser generosos y considerados.

Otros updates

• Dense un momento y escuchen este episodio del podcast de Tim Ferris, junto a Derek Sivers. El es uno de mis mentores imaginarios (acabo de inventar ese término). Comparto muchos puntos que tiene el de como vivir la vida y afrontar nuevos negocios. Saqué 3 conclusiones del episodio que describo en este post.
• Moví todo el contenido literario a un nuevo newsletter en Substack, con un toque de cafeína. Eres muy bienvenido .

Como cada semana, disfruté mucho recopilando y escribiendo este newsletter.

Un abrazo y disfruta lo que queda de jueves.

Felipe

Cuéntame que te pareció esta edición:

• 👍 Motivador e interesante. Sigue así Felipe.
• 😐 Estuvo más o menos
• 👎 No me interesó para nada.