Dos and Don'ts para un equipo de Ingeniería de Producto

Puedes leer este post en inglés aquí.

Ningún equipo de Ingeniería de Producto es perfecto pero todos tienes la necesidad de mejorar. Esa mejora se realiza bajo algún tipo de guía. Existen muchos posts sobre Principios de Ingeniería. Personalmente me gustan y me inspiran los de Monzo o Medium. Los Principios de Ingeneniería son necesarios pero suelen ser genéricos y estáticos.

El hermano menor de los Principios de Ingeniería son los Dos and Don’ts. Es sólo una lista de reglas específicas. Se enfocan en problemas específicos que tiene un equipo más pequeño en un momento determinado. Los Dos y Don’ts tienen que recordarse constantemente hasta que formen parte de la mentalidad del equipo. Pueden y van a cambiar con el tiempo. Escríbelos en alguna parte, crea un bot de Slack que se lo recuerde al equipo automáticamente o crea un poster y cuélgalo donde todos puedan verlo. Puedes incluso plasmarlos en un blog post, como lo estoy haciendo yo aquí. Los siguientes Dos y don’ts son específicos para mi equipo actual. Los tuyos podrían y quizá deberían ser diferentes. Esta herramineta puede funcionar o no para tu equipo dependiendo de tu contexto. No existen balas de plata y es triste que tenga que hacer este disclaimer.

Puedes suscribirte a mi newsletter With a grain of salt y recibir un email con novedades cada cierto tiempo.

Pregunta “por qué” más de una vez y prepárate para lo mismo

Cuando hagas una presentación para exponer una nueva iniciativa de producto o estrategia técnica, prepárate para ser preguntado “por qué” hasta cinco veces. Investiga de antemano tan profundamente como sea necesario para tener respuestas, pero sigue siendo pragmático.

Pregunta por datos y prepárate que te pregunten por datos

En el mundo de la Ingeniería de Producto, respaldar tus argumentos con datos es obligatorio. No digas “necesitamos construir esa feature”. Junto con los por qué, reúne y expon los datos para respaldar tus decisiones y crear argumentos convincentes. Si no hay datos, perderás tu credibilidad y respeto como Ingeniero de Software, Product Manager o Diseñador de Producto. Cualquier miembro de un equipo de Ingeniería de Producto tiene la obligación de crear una cultura basada en datos.

Investigua más de una posible solución

Trabajar en un equipo de Ingeniería de Producto requiere tanto creatividad como proceso. En general, la solución obvia no la mejor. Investiga múltiples soluciones sin juzgarlas, realiza spikes, recopila datos, crea diagramas, escribe pros y contras, haz una lista de tus sesgos y ten un decision day.

Haz pair programming

Pair programa todo lo que puedas y más. Tiene tantos beneficios que es difícil de encontrar argumentos convincentes en contra. Usa la técnica que mejor se adapte a tu entorno. Perfecto si haces Ping-Pong-TDD. Driver-Navigator también está bien.

Disclaimer. Hacer pair programming tiene retos, específicamente la fatiga mental. No es obligatorio hacer pair programming todo el tiempo. Como con cualquier otra herramienta, úsala de la forma en la que te traiga más beneficios.

Manten tus PRs pequeñas y fácies de revisar

Mantén tus PRs lo más pequeñas posible y tu código tan fácil de entender como sea posible. Como con cualquier otra cosa, evalúa e intenta mejorar tus code reviews de vez en cuando.

Mantén staging siempre limpio

Múltiples equipos llevan su código a staging, y como de rápido pueda a producción, múltiples veces al día. En cualquier momento, lo que está en master puede ir a producción. Esto no es un problema, así que no intentes crear entornos adicionales para probar tu código. Hay equipos de Ingeniería de Producto por ahí que han abandonado completamente los entornos de staging. Piensa en los problemas con antelación y lleva a master código que simplemente funciona. Si no estás seguro, colócalo debajo de una feature flag.

Asegúrate de que el código que pones producción, funciona

Idealmente, deberías tener tests end-to-end automatizados en producción. Hasta que eso no sea una realidad, prueba manualmente que no hayas roto nada. Ten en cuenta que, a medida que aumenta la complejidad, las pruebas manuales en producción se vuelven cada vez más difíciles. Cuanto antes empieces a automatizar, mejor.

Mide lo que pones en producción

“Hecho” significa que una feature se puede medir desde el punto de vista de negocio, producto e ingeniería. Esta es la única forma de evaluar que lo que construyes tiene valor. Para ingeniería, puedes empezar con las cuatro señales de oro e ir iterando. Para negocio, puedes empezar con algunos de estas métricas clave e iterar. Para producto, necesitas encontrar las métricas que importan para tu producto, pero puedes empezar con algunas analíticas de comportamiento e iterar conforme vayas aprendiendo.

No te compliques demasiado. Mantén tu código simple

La simplicidad es la característica más subestimada del diseño de software. Mantenlo lo más simple posible y no dejes que la entropía se convierta en un problema. Tu futuro yo te lo agradecerá.

No esperes que alguien te responda de inmediato en Slack. Nada es urgente. Nunca

Pues eso. Además, no te disculpes por no responder de inmediato.

No tengas reuniones para todo, a veces un mensaje de Slack es suficiente

Algunos incluso piensan que las reuniones son tóxicas y las reuniones en línea son peor aún. Yo no soy tan radical. Pero si realmente se necesita una reunión, asegúrate de que esté bien planificada: tiene un propósito, documentación para prepararse, una agenda y un resultado.

Wrapping up

Se supone que estas reglas van moldeando poco a poco al equipo hacia una mentalidad y una cultura de producto más saludables. Forman parte de la utopía y nunca serán respetados el 100% del tiempo. Nuestro entorno es complejo e impredecible y somos mejores que seguir ciegamente una lista de reglas. Se sabio.

Muchas gracias a undraw.co por las ilustraciones. Puedes suscribirte a mi newsletter With a grain of salt y recibir un email con novedades cada cierto tiempo.