BorrowBits
Guía para tratar con desarrolladores
Portada » Blog » Opinión » 9 Principios Efectivos para Trabajar con Desarrolladores. Guía del Product Owner

9 Principios Efectivos para Trabajar con Desarrolladores. Guía del Product Owner

A lo largo de los últimos años he podido trabajar tanto como desarrollador como manager, a veces haciendo las dos cosas al mismo tiempo. Eso me ha permitido experimentar los problemas del software desde dos perspectivas muy diferentes:

El código y el negocio.

El barro y… el otro tipo de barro.

En esta guía rápida comparto los principios más efectivos y que más me han ayudado como Product Owner a la hora de trabajar con Desarrolladores en equipos pequeños y grandes.

No me quedo corto si digo que el 90% de los problemas entre ingenieros y managers suelen ser de Comunicación. Por eso, la mayor parte de mis principios para comunicarme con los ingenieros se apoyan en un compendio de los siguientes:

  • transparencia,
  • respeto y
  • humildad.

El rol del PO suele acotarse como un «representante del negocio». Pero tu éxito como PO depende mucho más de lo bien que seas capaz de relacionarte con tu equipo.

Esta breve guía está escrita para Product Owners, IT Managers y Project Managers, pero se la dedico de corazón a mi equipo actual de Ströer. Ellos me han enseñado mucho de lo que aquí comparto.

Principio #1: Los desarrolladores no trabajan para ti: tú trabajas para ellos.

Cada vez hay más empresas que se oponen a otorgar el título de «Product Owner» a sus product owners. La palabra «owner» (dueño) ya implica una jerarquía, una autoridad.

Pero nada más lejos de la realidad.

Sin el respaldo de tu equipo no eres nada.

Como PO, tu principal tarea es asegurarte de que se implementa exactamente lo que hay que desarrollar en el momento adecuado, de forma que se entregue valor lo antes posible. En última instancia, es el equipo de desarrollo quien va a implementar tu visión del producto.

Así que no confundas el mapa con el territorio.

Por muy bonitos que sean tus mockups, un PowerPoint no es el producto. El equipo es el que va a transformar tu PowerPoint en algo real.

Aunque exista un Scrum Master o un Agile Coach que proteja al equipo de tu «tiranía», tú mismo debes tener ese mantra instalado: tú estás al servicio de tu equipo y no al revés.

Y por cierto: el hecho de que haya un Scrum Master para pararte los pies no te da permiso para ser un villano en cuanto éste se descuida. No vayas por ahí dando órdenes arbitrarias o delegando en ellos tareas que no son suyas.

Principio #2: Confía en las recomendaciones de los desarrolladores: ellos son los expertos.

Desde el punto de vista del Product Owner (incluso aunque tengas experiencia técnica) las cosas siempre parecen mucho más fáciles de lo que acaban resultando.

Tu trabajo como PO es definir «qué» y «cuándo». El «cómo» es cosa del equipo de desarrollo. Y en cuanto a esto, el equipo técnico suele tener razón.

Sin embargo, siempre existen varias alternativas para un mismo problema. Si no crees en la solución propuesta, pide una explicación (de alto nivel) de los desafíos, pros y contras de cada alternativa. En caso de duda, tomad una decisión conjunta poniendo en equilibrio las prioridades del negocio, la estabilidad y la seguridad de la aplicación, la potencial deuda técnica, etc.

El roadmap no lo es todo. Despreciar el impacto futuro de la deuda técnica es como encerrar un cachorro de león en tu dormitorio y alimentarlo constantemente con carne cruda: en algún momento tú podrías ser parte del menú. Muchos proyectos fracasan por ignorar este fenómeno.

Si al CEO de tu empresa le urge esa funcionalidad y quiere liberarla a toda costa, explícale los riesgos a los que se expone; si es necesario exige una exención de responsabilidad para ti y para tu equipo.

A muchos managers de alto nivel les encanta decir «hazlo en plan MVP», pero lo que en realidad quieren decir es «haz una chapuza para salir del paso».

Una cosa que todavía me sorprende es que el equipo técnico siempre se preocupa más que el negocio por la calidad, incluso cuando tiene un impacto directo sobre los clientes.

Principio #3: Comparte la visión del negocio constantemente, aunque nadie te pregunte.

Un minuto de silencio por esas costosas features que al final nadie usa…

Es mejor resultar un pesado, a que se implemente algo que nadie necesita. Lo he comprobado un millar de veces: cuanto mejor entiende un desarrollador lo que hay detrás de una decisión de producto, más acertada será su implementación, más rápida y más libre de errores.

Invierte el tiempo que sea necesario en asegurarte que se comprende la necesidad de negocio que hay detrás, porque será justo eso: una inversión.

Comparte el roadmap de vez en cuando y tus intenciones para release a producción.

Simplifica cuando sea necesario. Algunos Product Owner tendemos a pedir más cosas de las que en realidad hacen falta. Asegúrate de que los requisitos sean desglosados en requerimientos más pequeños, y que estos a su vez sean simplificados y priorizados correctamente (técnica MoSCoW por ejemplo). El equipo de desarrollo tiende naturalmente a desarrollar todo lo que tú le pidas. A veces incluso más de lo que pides. Esto se conoce como Scope Creep, que es el terror de los PO.

Ayuda al equipo a ponerse siempre en el pellejo de los usuarios, y siempre se implementará lo correcto solo hasta donde es necesario.

Principio #4. Sé radicalmente transparente.

No necesitas entender todo lo que los devs hacen, pero ellos sí necesitan entender lo que tú haces. Sé transparente. Al tratar con desarrolladores, no les ocultes los problemas.

Soy consciente de que esto va en contra de la cultura de muchas empresas, sobretodo de las más jerárquicas. También es cierto que hay que proteger al equipo de la presión exterior…

Pero en mi experiencia, si alguna circunstancia les afecta a ellos de forma directa o indirecta, no debes ocultarla. Primero, porque merecen saber lo que se cuece; y segundo, por lo mismo que comentaba en el Principio #3. Si los desarrolladores comparten tu comprensión de la realidad, te ayudarán a solucionar cualquier problema que se ponga por delante.

Aunque eso suponga romper algunas reglas.

Y desde dentro:

Si hay conflictos internos, no los evadas.

Si hay que mantener una conversación difícil, no la postergues.

En otras ocasiones resulta útil abandonar el modo «proxy», e invitar a los técnicos a las reuniones con ciertos Stakeholders. Asegúrate de que todas las personas involucradas asisten a todas las reuniones. Esto es especialmente importante cuando se trabaja en remoto.

Si recibes halagos de los usuarios, de los clientes o de los stakeholders, transmíteselos al equipo y procura que se sientan dueños de esos triunfos. Si recibes críticas negativas, compártelas también; pero después de que tú hayas asumido la responsabilidad absoluta.

En última instancia y de cara a los clientes/usuarios tú eres responsable del éxito o del fracaso de tu producto

Principio #5: Sé exigente.

Espera la excelencia para obtener resultados excelentes (efecto Pigmalión). Pero eso sólo funciona cuando tú mismo persigues la excelencia en lo que haces: es una carretera de doble sentido.

Dale a tu equipo lo mismo que esperas de ellos.

Pon las expectativas bien altas.

Sé claro también con las expectativas individuales de cada uno. Ayúdalos a dar lo mejor de sí. Por tu parte, cúrrate las historias de usuario y el backlog como si se te fuera la reputación en ello. Testea la aplicación concienzudamente y sé despiadado con los resultados.

Si una entrega no cumple tus expectativas, recházalo. No tienes por qué (y no debes) liberar nada de lo que no estés absolutamente convencido.

No se trata de herir sentimientos:

Si no has comunicado bien un requerimiento, asume la responsabilidad. Lo normal es que sea un fallo de comunicación del Product Owner o del Business Analyst. Asegúrate de que el equipo comparte tu definición de “terminado” (Definition of Done). Ése es tu mejor seguro antipatinazos.

Pero si al final algo sale mal, no le eches la culpa al DevOps, ni al Backend, ni al Frontend, ni al QA.

Es culpa tuya y punto.

La próxima vez, asegúrate de que el equipo cubra esa debilidad, y sobretodo de que todos aprendan de esos errores (para eso están las Retrospectivas). Lo único malo de los errores es no aprender de ellos.

Los errores son oportunidades de mejora que nadie debería dejar pasar.

Principio #6: No te entrometas demasiado: el micromanagement es de perdedores.

En la medida de lo posible, no asignes tareas. Permite al equipo decidir quién hace qué. Ellos están más capacitados que tú para ver quién va a ser más eficiente con cierta actividad.

Sin embargo asegúrate de que al final siempre haya un responsable: si todos son responsables, al final nadie lo es. Y la tarea se quedará sin hacer.

Aplica el micromanagement sólo en casos de emergencia extrema, en plan «se está quemando el edificio».

Por lo demás, deja que el equipo resuelva sus propios problemas de organización, aunque algunos de ellos te lo pidan (los desarrolladores principiantes o inseguros prefieren que el PO les diga lo que tienen que hacer). Incentiva la proactividad y la autonomía.

Dale responsabilidad a tu equipo, y entonces tanto ellos como el producto empezarán a brillar.

No te olvides de que un programador es una persona, no una máquina. A menudo 2 + 2 no es igual a 4, sino a 3. Esto es tanto más cierto cuanto más complejo es el producto. Es un error clásico que cometen muchos managers cuando planifican «recursos».

Dicho sea de paso: una vez empieza el desarrollo de una tarea, no la detengas para empezar otra más urgente. Los cambios repentinos de contexto exigen un gran esfuerzo mental.

Compréndelo: desarrollar código es un arte. Y todo arte necesita su espacio para prosperar. No presiones. No te metas en los detalles técnicos aunque te guste (especialmente si te gusta).

¡Tú a lo tuyo!

Principio #7: Las estimaciones no son más que eso: estimaciones.

He comprobado que los desarrolladores son por naturaleza optimistas.

Cuando un desarrollador te dé una estimación, aplica un buffer de contingencia del 20-30%. Si es junior puedes incluso permitirte un 50%. Nunca culpes a un desarrollador de haber tardado «más de lo estimado». Anima en cambio a que se comunique lo antes posible una subestimación/sobrestimación.

No preguntes constantemente cuánto falta para acabar.  Si un ticket tarda más de la cuenta en salir, asegúrate de que el desarrollador no se ha topado con algún impedimento.

Un story point nunca es el mismo story point. Cada feature puede ser un mundo. Aunque muchos desarrolladores se oponen a ello (especialmente los más senior), las estimaciones de las historias de usuario son útiles para el negocio: permiten planificar la liberación de software con una mínima sensación de certeza.

A algunos desarrolladores no les gusta estimar tickets por otras razones: puede percibirse como una herramienta de control del desempeño. Pero como Product Owner, nunca deberías usar las estimaciones para medir la velocidad individual.

El desarrollo de Software es un mundo VUCA (volátil, incierto, complejo y ambiguo), y el Product Owner debería sentirse cómodo con dosis elevadas de incertidumbre: he aquí la diferencia fundamental con un Product Manager tradicional.

Tanto tú como el equipo deberías tener claro que:

Una estimación no es una promesa, sino una forma heroica de planificar lo implanificable.

Principio #8: Disfruta del refinamiento de requisitos.

Si tú no te lo pasas bien en los refinements, el equipo tampoco.

Emociónate con los problemas, participa y sigue con atención el debate. Fomenta la discusión constructiva. No te distraigas y mantén tu presencia. Asegúrate que tus requerimientos se pueden dividir en unidades que no duren más de tres a cinco días (o el equivalente en story points, talla, etc). Si son demasiado grandes, pártelo todavía más (siempre se puede partir un poco más).

No fuerces la estimación cuando los requisitos no están claros. Es mejor abortar una sesión en la mitad y decir: «Lo siento, necesito averiguar más detalles sobre esto«.

Nunca supongas: vuelve al mundo real y comprueba.

Así evitarás los infames «change requests», sobretodo si ocurren de forma constante para una misma feature. Los cambios de requisitos constantes y al vuelo (en los ticket que ya están en progreso) son una fuente de frustración para todo el equipo.

No te aferres nunca al camino feliz (happy path).

Si algo puede salir mal, saldrá.

Murphy nunca se debería perder un refinement.

Valora y premia la detección temprana de posibles «corner cases». Prepara el material con antelación y exige que los desarrolladores lo lean antes de la sesión: mockups, ejemplos, contexto… Cuanta más información se aporte desde un principio mejor.

Y por el amor de $deity: refinar historias de usuario consume mucha energía, ¡no pongas esas reuniones después del almuerzo!

Principio #9. Siéntete parte del equipo.

Mójate en las retros, bájate del pedestal (si es que crees que estás en alguno).

Comparte tu opinión honesta y ábrete a las críticas de mejora, especialmente si no te gustan.

Nunca te lo tomes como algo personal.

Da igual si eres el dueño del producto: en el día a día formas parte de un equipo. Unas veces serás parte de la problemática y otras veces parte de la solución.

Celebra las victorias con ellos, acompáñalos en las releases difíciles. Trabaja cerca del equipo en el día a día: no te evadas demasiado en el «business». Intenta estar siempre disponible para el equipo para resolver dudas (sí, sé lo difícil que es esto).

Habla cara a cara siempre que puedas. No olvides tomarte un café con el equipo de vez en cuando.

Eres el puente entre el mundo de las corbatas y el mundo de las camisetas geeks. Y la programación es una actividad intelectual que se parece más al arte que a la mecánica.

Así que trata a los Artistas con el máximo respeto. 

La pregunta «cómo gestionar un equipo de desarrolladores» está mal planteada; en lugar de eso céntrate en cómo tratar con las idiosincrasias de las personas. Más allá de las apariencias y los estereotipos. He visto a otros PO hablar de su equipo con desprecio y autosuficiencia. No seas uno de esos capullos condescendientes.

Y hablando de eso:

No hay nada más condescendiente que un Product Owner regalándole a un Desarrollador un libro sobre cómo programar mejor, o más rápido, o cualquier otra cosa insultante… No hagas ese tipo de cosas. 

Los principios del buen Product Owner: cómo trabajar con desarrolladores

Reflexioné mucho antes de atreverme a publicar este post.

Después de todo, ¿con qué jeta se me ocurre dar consejos cuando yo mismo todavía no los aplico a la perfección?

Creo que no es fácil ser un buen Product Owner.

Requiere la capacidad incesante de encontrar compromisos, a menudo irreconciliables. Es un rol de malabarista solitario que sobrevive en la frontera de varios mundos y submundos. Un PO debe resistir bien la presión sin pasársela al equipo. La palabra más importante de su vocabulario es «No».

Llegar a ser un buen Product Owner es un work in progress constante, algo así como la aspiración al Nirvana. Un reto casi imposible. Y así con todo, un deber moral.

¿Entonces por qué publico estos principios?

Pues simplemente, porque me habría gustado que alguien me contara cómo trabajar con desarrolladores en mis comienzos. Muchas de estas cosas no las aprenderás en un cursillo de Udemy ni sacándote el PSPO I.

Así que si estás empezando y tienes que quedarte con una sola enseñanza, quédate con ésta: la comunicación es tu herramienta más importante.

Un Product Owner puede llegar a ser tan bueno, como buena sea su comunicación con su equipo. 

Por último, estos principios no están grabados en mármol. Son más bien un borrador perpetuo, y lo iré afinando conforme aprenda nuevas lecciones. De hecho, si tienes otros principios útiles basados en tu experiencia (ya sea como desarrollador o como product owner) que no he tenido en cuenta, escríbeme un comentario

¡Un saludo!

Angel H.

Tecnófilo irreparable y lector insaciable. Emigrante e inmigrante. Además de eso, Ingeniero de Telecomunicaciones y Product Manager. +10 años de experiencia en proyectos de Software, Cloud e Ingeniería de Redes. Me apasiona el DIY, la tecnología Blockchain y las Finanzas.

5 comentarios

  • Muy bueno, jaja, me gusta cómo piensas, como developer coincido, sobre todo la parte de los desarrolladores como artistas, y es que picar código, no es poner ladrillos! Saludos!

    • Gracias por tu comentario, Pablo. Seguramente muchos PO no coincidirán. Pero los buenos desarrolladores que sois tratados de albañiles acaban yéndose con la música a otra parte.

  • Me encantó tu post,soy PO y definitivamente coincido contigo,he visto en muchas empresas una guerra perpetua entre producto e ingeniería..supongo que se pierde de vista para quien se trabaja al final, las personas talentosas terminan yéndose porque se crea un ambiente demasiado hostil. Gracias por tus consejos tan útiles.

Angel H.

Tecnófilo irreparable y lector insaciable. Emigrante e inmigrante. Además de eso, Ingeniero de Telecomunicaciones y Product Manager. +10 años de experiencia en proyectos de Software, Cloud e Ingeniería de Redes. Me apasiona el DIY, la tecnología Blockchain y las Finanzas.

Suscríbete

¡Sácale el máximo partido a BorrowBits!

Apúntate para seguir recibir por email las nuevas publicaciones, noticias sobre Blockchain pre-filtradas y material exclusivo para suscriptores. De momento es gratis:

{subscription_form_1}

Categorías

Bits del pasado

Sitio patrocinado por:

JitKey rentabilización apartamentos turísticos

JITKey.- Startup enfocada en la gestión de alojamientos turísticos.