learning-front

Nivel 12 · Cómo es el trabajo de verdad

Ownership: hacerte dueño de tu trabajo

Responsabilizarte del resultado de punta a punta, no solo de cerrar tu ticket: definir qué es 'hecho', pensar los bordes, comunicar bloqueos pronto y velar por que funcione en producción. Y el límite que casi nadie cuenta: ownership no es heroísmo.

El capítulo anterior te dejó un panorama incómodo: el proceso se tuerce, las prioridades cambian y hay cosas que caen entre dos tickets y no son de nadie. ¿Qué sostiene el trabajo cuando el marco falla? La respuesta corta es: gente que se hace dueña de lo suyo. Eso es ownership, y es probablemente la cualidad que más se valora —y menos se enseña— en una persona de equipo.

Cuidado, porque es una palabra que suena a póster motivacional y se malinterpreta enseguida. Así que vamos a definirla bien, con ejemplos, y a marcar también lo que NO es, que es donde la mayoría se equivoca.

Qué es ownership (y qué no)#

Tener ownership es responsabilizarte del resultado de punta a punta, no solo de cerrar la tarea que te asignaron. La diferencia está en dónde pones la frontera de “mi trabajo”:

  • Sin ownership: “hice mi parte, el ticket está en review, lo demás no es asunto mío”.
  • Con ownership: “me aseguro de que esto resuelve de verdad el problema del usuario, y si en el camino aparece algo que lo impide, me ocupo”.

No es hacer el trabajo de todos, ni no dejar que nadie toque tu código, ni —esto es clave y lo veremos al final— echar horas hasta reventar. Es responder de lo que entregas.

El test del “¿y qué?” se ve mejor por su ausencia. Cuando nadie se siente dueño de algo, pasa lo que se llama difusión de responsabilidad: como es de todos, es de nadie. Un bug en producción en una zona que tocaron tres personas, y las tres dicen “eso no lo hice yo”. Un test que falla en CI de forma intermitente desde hace semanas y nadie arregla porque “no es de mi feature”. El problema rebota entre la gente y no lo coge ninguno, mientras el usuario lo sufre. El antídoto es simple de decir y difícil de practicar: que alguien se haga dueño.

Definir “done” antes de empezar#

La primera forma de ownership ocurre antes de escribir una línea de código. Cuando te llega un ticket ambiguo, la tentación es ponerte a programar lo primero que se te ocurra. El dueño hace lo contrario: para y lo deja trabajable.

Imagina que te asignan “TB-50: guardar el equipo del usuario”, sin más. Eso puede significar guardarlo en el navegador o en un servidor, con o sin sesión iniciada, un equipo o varios. Antes de tocar nada, defines qué es “hecho” (apoyándote en los criterios de aceptación y en la Definition of Done del equipo) y preguntas lo que falta. ¿Y qué pasa si te saltas este paso? Construyes una versión a ciegas, y cuando llega la review resulta que el PO esperaba otra cosa: a la basura y a empezar. Pensar primero es más barato que rehacer después.

Pensar los bordes#

El camino feliz es la parte fácil. Lo que distingue a un dueño es pensar los casos límite antes de que muerdan. En el filtro por rol del roster: ¿qué pasa si un rol no tiene héroes? ¿Si el roster aún no ha cargado? ¿Si la búsqueda no devuelve a nadie?

Quien tiene ownership cubre esos casos, o al menos los saca a la luz y los pregunta. ¿Y quien no? Los casos límite no desaparecen por ignorarlos: reaparecen en producción, con un usuario delante, convertidos en un bug y en un “¿cómo no se pensó en esto?”. Cubrirlos cuesta minutos ahora; descubrirlos en caliente cuesta mucho más.

Comunicar los bloqueos pronto#

Te quedas atascado: necesitas un dato de la API que nadie te ha dado. La actitud de ownership es sacar ese bloqueo cuanto antes —en la daily, o directamente a quien puede resolverlo—, no quedarte semibloqueado en silencio.

¿Y qué pasa si lo escondes hasta el final? El día del deadline aparece el “llevo tres días esperando esto”, cuando ya no hay margen para reaccionar, y tu tarea arrastra al sprint entero. Avisar pronto no es admitir que eres lento: es darle al equipo la oportunidad de ayudarte o replanificar mientras todavía se puede.

Dueño hasta producción#

Tu Pull Request se ha mergeado. ¿Está hecho tu trabajo? Con mentalidad de ownership, todavía no: está hecho cuando funciona de verdad en producción, para los usuarios. El merge es un hito, no la meta.

Eso significa vigilar que el despliegue va bien y, si algo se rompe al salir, hacerte cargo de que se resuelve. Ojo: “hacerte cargo” no es necesariamente arreglarlo tú a las dos de la mañana —de eso va la siguiente sección—, sino asegurarte de que está atendido y no mirar para otro lado porque “mi parte ya estaba”. Quien considera “hecho” el merge y desconecta deja un agujero por el que se cuelan los problemas de producción.

Aquí está lo que se ve, sin ownership y con ownership#

El mismo ticket, dos formas de vivirlo:

text
SIN OWNERSHIP
TB-50 llega vago → programa lo primero que cree → PR → merge →
en producción falla con usuarios sin sesión → "eso no estaba en el ticket"
→ el bug rebota → se rehace una semana después.

CON OWNERSHIP
TB-50 llega vago → aclara "done" y casos límite, pregunta dónde se guarda →
programa lo acordado, cubre los bordes → PR → merge → vigila el despliegue →
funciona → si algo falla, se ocupa de que se resuelva.

No es que el segundo trabaje más horas: trabaja con la cabeza puesta en el resultado, no solo en cerrar la tarea. Esa es toda la diferencia.

El límite: ownership no es heroísmo#

Y aquí la parte que casi nadie te cuenta, y la más importante del capítulo. Es muy fácil confundir ownership con heroísmo: quedarse cada día hasta las nueve, asumir el trabajo de todos, echar la noche antes de la entrega. Eso NO es ownership. Es el camino al síndrome del salvador y a quemarte.

Responder del resultado no es trabajar gratis ni cargar con todo. De hecho, el heroísmo hace daño por partida doble. Primero, el “héroe” se quema y, tarde o temprano, se va. Y segundo —menos obvio y más grave—, su esfuerzo tapa el problema real: si una persona compensa a base de horas un equipo mal dimensionado o un proceso roto, ese problema queda oculto y nunca se arregla, porque desde fuera “siempre se llega”. Un equipo que depende de héroes es un equipo frágil.

El ownership sano es sostenible, y a veces consiste justo en lo contrario de sacrificarse: en levantar la mano y decir “con este alcance y este tiempo no llegamos” a tiempo, con datos y con alternativas. Decir eso es más responsable que callar y echar la noche, porque protege el resultado de verdad —y a ti— en lugar de esconder el problema un sprint más.

Hacerse dueño, entonces, es las dos cosas: ocuparte de que lo tuyo salga bien de punta a punta, y cuidar de que el sistema (y tú) podáis seguir haciéndolo el mes que viene.

Comprueba lo que sabes#

Pregunta 1 de 10

¿Qué significa tener ownership de tu trabajo?

Tu turno#

El ejercicio es justo el primer acto de ownership: coger un ticket vago y dejarlo trabajable antes de programar. No hay editor de código; produces el análisis y lo comparas con las tres soluciones, que suben de “lista de hecho” a un análisis de dueño con riesgos priorizados y a quién preguntar.

Ejercicio · hazlo en local

Hazte dueño de un ticket vago

El PO ha dejado el ticket "TB-50 · Guardar el equipo del usuario" sin criterios ni detalles. Antes de programar nada, conviértelo en algo trabajable: una Definition of Done, una nota de riesgos y casos límite, y las preguntas abiertas con a quién preguntar. Las soluciones muestran tres niveles de ese análisis. Hazlo tú primero y compara.

Paso 1: Una idea básica de "hecho"

  • Defines qué significa que el ticket está hecho, con algún criterio.
  • Cubres el comportamiento principal (guardar y recuperar).

Cómo hacerlo en local

Clona el repositorio del curso, entra en la carpeta del ejercicio y abre el index.html en tu navegador. Toda tu solución va en solucion.js. 

git clone <repo>
cd exercises/nivel-12/ownership
# abre index.html en el navegador y edita solucion.js
Ver soluciones 
# TB-50 · Guardar el equipo del usuario

## Definition of Done

- El usuario puede pulsar un botón "Guardar equipo".
- El equipo guardado se vuelve a ver al recargar la página.
- Funciona sin errores en el navegador.

## Notas

Lo programo y, cuando guarde y se recargue bien, lo doy por hecho.

Por qué este nivel

  • Ya es más de lo que hace quien se lanza a programar sin pensar: hay una idea de qué es "hecho". Pero se queda en el camino feliz —guardar y recargar— y no se pregunta nada de lo que el ticket deja en el aire.
  • Su consecuencia: en cuanto aparezca un usuario sin sesión, o el guardado falle, o haya que decidir dónde se persiste, el trabajo se para o se rehace. El "done" cubre lo fácil y deja lo difícil para que muerda más tarde. El tier "mejor" saca esos bordes a la luz antes de empezar.