# Plan de mejora: autonomía, comunicación y gestión de tareas Documento de referencia para trabajar tres puntos de mejora identificados en sesiones de mentoría: 1. Comunicación y trabajo en equipo 2. Falta de pedido de ayuda a tiempo (loops de errores) 3. Mucho tiempo en la misma tarea, prueba cosas sin planear Cada sección incluye qué es la práctica, cómo aplicarla, un ejemplo concreto y preguntas de auto-reflexión. --- ## 1. Timeboxing + Regla de los 15/30/60 **Qué es:** Timeboxing es una técnica formal de gestión del tiempo (popularizada por James Martin en *Rapid Application Development*, 1991) que consiste en asignar un bloque fijo de tiempo a una actividad. La regla 15/30/60 aplicada a "pedir ayuda" es una convención de la industria documentada en guías de onboarding de empresas como GitLab y Stack Overflow. **Cómo se aplica:** - **15 minutos atascada:** releer el error, buscar en documentación oficial, googlear el mensaje exacto. - **30 minutos:** escribir el problema en un canal o doc personal (rubber duck escrito). - **60 minutos:** pedir ayuda formal a un compañero o mentor, usando el formato del punto 2. ### Ejemplo práctico Tarea: integrar un componente de date picker en un formulario React. - **Minuto 0:** empieza la tarea, lee la documentación de la librería. - **Minuto 12:** el componente no renderiza, ve un error de hooks en consola. - **Minuto 15:** copia el error literal en Google. Revisa issues del repo de la librería. - **Minuto 30:** no encontró nada. Abre un doc personal y escribe: "Estoy intentando montar DatePicker dentro de un form con react-hook-form. Espero que renderice el calendario al hacer click. En su lugar, tira 'Invalid hook call'. Ya probé: revisar versiones de React, mover el componente fuera del form, importar desde otra ruta." - **Minuto 35:** mientras escribe el "ya probé", se da cuenta de que tiene dos versiones de React instaladas. Problema resuelto sola. Si no se hubiera resuelto, el doc ya está listo para pegarlo en Slack al mentor al minuto 60. ### Preguntas de reflexión - ¿Estoy mirando el reloj o llevo perdida la noción del tiempo? - ¿Cuándo fue la última vez que cambié de approach? Si fue hace mucho, ¿por qué sigo con este? - Si tuviera que explicar ahora qué probé, ¿podría hacerlo de forma ordenada? - ¿Estoy probando cosas o estoy investigando? (Probar al azar no cuenta como avance.) --- ## 2. Formato estructurado para pedir ayuda **Qué es:** convención conocida como **"How to ask a good question"** (guía oficial de Stack Overflow desde 2010). También está relacionada con el concepto **XY Problem**: cuando alguien pregunta cómo hacer Y (su intento de solución) en vez de preguntar cómo resolver X (el problema real). **Estructura recomendada:** ``` 1. Qué estoy intentando hacer (objetivo de negocio o técnico) 2. Qué esperaba que pasara 3. Qué pasa en realidad (con error literal, no parafraseado) 4. Qué ya probé y qué resultado dio cada intento ``` ### Ejemplo práctico **Mal pedido:** > Hola, no me anda el login. ¿Me podés ayudar? **Buen pedido:** > Hola, estoy con el ticket de "login con Google". > > **Objetivo:** que al hacer click en "Sign in with Google" se abra el popup de OAuth y, después del consent, se redirija al dashboard. > > **Esperaba:** que el callback de NextAuth devuelva el session token. > > **Pasa en realidad:** el popup se abre, hago el login, pero al volver al callback la URL queda en `/api/auth/error?error=OAuthCallback` y la consola tira `[next-auth][error][OAUTH_CALLBACK_ERROR] state cookie was missing`. > > **Ya probé:** > - Revisar las env vars (GOOGLE_CLIENT_ID y SECRET están bien). > - Borrar cookies del browser y reintentar. > - Cambiar el `cookies.state` a `sameSite: 'lax'` (mismo error). > - Probar en incógnito (mismo error). > > Sospecho que tiene que ver con el dominio del callback que configuré en Google Cloud, pero no estoy segura. El segundo formato suele recibir respuesta en 5 minutos. El primero genera 4 idas y vueltas antes de empezar a resolver. ### Preguntas de reflexión - ¿Estoy preguntando por mi intento de solución (Y) o por el problema real (X)? - ¿La persona que lee esto puede reproducir mi problema con lo que escribí? - ¿Incluí el error literal o lo parafraseé? - ¿Mi pedido demuestra que ya hice mi parte, o suena a "resuélvemelo"? --- ## 3. Rubber Duck Debugging **Qué es:** técnica formal documentada en *The Pragmatic Programmer* (Andy Hunt, Dave Thomas, 1999). Consiste en explicarle el problema, paso a paso, a un objeto inanimado o a un texto escrito. El acto de verbalizar fuerza al cerebro a estructurar el pensamiento, y muchas veces la solución aparece sola. ### Ejemplo práctico Está debuggeando por qué un `useEffect` se ejecuta en loop. Sin rubber duck, prueba cosas al azar: saca dependencies, agrega un ref, comenta líneas. Con rubber duck, escribe en un doc: > Tengo este useEffect que hace un fetch cuando cambia `userId`. Las dependencies son `[userId, setData]`. Espero que se ejecute solo cuando cambia el usuario. Pero veo que se ejecuta en loop infinito. > > Si pienso bien: `setData` viene del padre como prop. El padre lo redeclara en cada render. Entonces `setData` es una referencia distinta en cada render. Entonces el effect detecta cambio y se vuelve a ejecutar. Entonces actualiza el estado del padre, que re-renderiza, que pasa un nuevo `setData`, que dispara el effect de nuevo. Ahí encontró el bug sin pedirle nada a nadie. La sola acción de escribirlo le obligó a seguir la lógica completa. ### Preguntas de reflexión - ¿Puedo explicar este problema en voz alta sin usar muletillas tipo "es que… no sé… algo raro"? - ¿Entiendo realmente lo que está haciendo cada línea, o asumo que "hace lo que tiene que hacer"? - Si tuviera que enseñarle esto a alguien que recién empieza, ¿en qué paso me trabaría? --- ## 4. Planificación previa: Spike y Design Doc liviano **Qué es:** dos prácticas formales que apuntan a "pensar antes de codear". - **Spike:** término oficial de Extreme Programming, introducido por Kent Beck. Tarea acotada en tiempo para investigar una solución antes de comprometerse a implementarla. El output es un documento corto, no código de producción. - **Design Doc / RFC:** convención usada por Google, Amazon y Stripe. Versión liviana para tareas chicas: un comentario en el ticket antes de empezar. **Estructura del mini-plan:** ``` - Archivos que voy a tocar - Approach en 2-3 bullets - Riesgos o dudas que tengo ``` ### Ejemplo práctico Ticket: "Agregar filtro por categoría en el listado de productos". **Sin plan previo:** abre el componente de la lista, empieza a agregar un `useState`, después se da cuenta de que el filtro tiene que vivir más arriba en el árbol, refactoriza, llega un PM y le dice que el filtro tiene que persistir en la URL, vuelve a refactorizar. Total: 2 días. **Con plan previo (15 min antes de codear):** > **Archivos a tocar:** > - `app/products/page.tsx` (lectura del query param) > - `components/ProductFilters.tsx` (componente nuevo) > - `lib/products.ts` (modificar la query a la API) > > **Approach:** > - Filtro como query param en la URL (`?category=shoes`) para que sea compartible y persista al recargar. > - Componente controlado que lee y escribe en el query usando `useSearchParams`. > - La query a la API ya soporta el parámetro `category`, no hay cambios en backend. > > **Riesgos:** > - No sé si el SSR del listado se rompe al cambiar el query. Habría que validar. > - ¿Múltiples categorías a la vez o una sola? Confirmar con producto antes de empezar. El mentor lee esto en 5 minutos, confirma el approach, y la junior arranca con dirección clara. Total: medio día. ### Preguntas de reflexión - ¿Tengo claro qué archivos voy a tocar antes de abrir el editor? - ¿Pensé al menos dos formas posibles de resolver esto, o agarré la primera que se me ocurrió? - ¿Hay algo que estoy asumiendo que debería confirmar antes (con el mentor, con producto, con diseño)? - Si tuviera que estimar esto ahora, ¿en cuánto lo termino? ¿Y si lo estimo después de hacer el plan? --- ## 5. Estimación previa y comparación con tiempo real **Qué es:** práctica estándar de metodologías ágiles. La forma más conocida es **Planning Poker** (Mike Cohn, *Agile Estimating and Planning*, 2005), pero para mentoría 1 a 1 alcanza con una estimación simple en horas. **Concepto clave:** la **falacia de planificación** (Kahneman y Tversky, 1979) explica por qué los humanos subestimamos sistemáticamente cuánto va a llevar una tarea. El objetivo no es acertar al inicio, sino que el gap se achique con el tiempo. ### Ejemplo práctico Planilla simple en Notion o en el mismo ticket: | Tarea | Estimado | Real | Gap | Motivo del gap | |-------|----------|------|-----|----------------| | Filtro de categoría | 4h | 6h | +50% | Subestimé el SSR | | Modal de confirmación | 2h | 2h | 0% | OK | | Migración de auth | 8h | 20h | +150% | No estimé el testing ni la doc | | Bugfix de validación | 1h | 30min | -50% | Era más simple de lo que pensé | Después de un mes, mirar la planilla muestra patrones: "siempre me olvido de incluir testing", "los bugfixes los sobreestimo", "las migraciones me cuestan el triple". ### Preguntas de reflexión - ¿Mi estimación incluye testing, code review y posibles cambios pedidos en review? - ¿En las últimas 5 tareas, mi estimación fue corta, larga o variada? ¿Hay un patrón? - ¿Estoy estimando lo que tarda "el código feliz" o lo que tarda "el código real con problemas"? - Cuando me paso del estimado, ¿cuál fue la causa más común? (scope poco claro, problema técnico, falta de contexto, otra cosa) --- ## 6. Daily Stand-up asincrónico **Qué es:** ceremonia formal de Scrum, en su variante **async stand-up** popularizada por GitLab y empresas remote-first. Las 3 preguntas clásicas: 1. Qué hice ayer 2. Qué voy a hacer hoy 3. Dónde estoy trabada ### Ejemplo práctico Mensaje diario en Slack, 5 minutos para escribirlo: > **Ayer:** > - Terminé el filtro de categoría (PR #234, listo para review). > - Empecé la integración con Stripe, hice el setup del SDK. > > **Hoy:** > - Seguir con Stripe: implementar el checkout session. > - Revisar el PR de Mariano si tengo tiempo. > > **Bloqueos:** > - Necesito las credenciales de Stripe de staging. ¿Quién las tiene? > - Duda sobre el flow de error: si falla el pago, ¿redirigimos o mostramos modal? @producto Beneficios concretos: - Si "Stripe" aparece 5 días seguidos, el mentor ve el loop sin tener que preguntar. - Los bloqueos quedan visibles para todo el equipo, no solo para el mentor. - Entrena la comunicación escrita, que es la habilidad más subvalorada en dev. ### Preguntas de reflexión - ¿Lo que escribí ayer y lo que escribo hoy muestran avance, o estoy con lo mismo hace varios días? - ¿Estoy reportando "bloqueos reales" o solo "estoy haciendo X"? Si nunca tengo bloqueos, probablemente no los estoy viendo. - Si alguien externo lee mi update, ¿entiende qué hago y en qué estado está? --- ## 7. Pair Programming dirigido **Qué es:** práctica formal de Extreme Programming (Kent Beck). Dos personas, una computadora. Para mentoría, la variante más útil es **Driver/Navigator** con roles fijos. - **Driver:** escribe el código. Acá va siempre la junior. - **Navigator:** guía, pregunta, sugiere, pero no toca el teclado. Esto fuerza a la junior a verbalizar lo que hace y al mentor a no resolverle el problema (cosa que tiende a pasar cuando el mentor toma el control del teclado "para ir más rápido"). ### Ejemplo práctico **Mal pair (el mentor termina haciendo todo):** Junior: "No me funciona el fetch." Mentor: "A ver, dame el teclado." (Tipea 10 minutos, lo arregla.) "Listo, era el header de auth." Resultado: la junior no aprendió nada. Mañana se va a trabar con lo mismo. **Buen pair (Driver/Navigator):** Junior: "No me funciona el fetch." Mentor: "Ok, mostrame el network tab. ¿Qué status code está devolviendo?" Junior: "401." Mentor: "¿Qué significa 401?" Junior: "No autorizado." Mentor: "Ok, ¿qué headers está mandando el request?" Junior: "Ah… no estoy mandando el token de auth." Mentor: "Bien. ¿Dónde lo agregás?" Resultado: la junior resolvió el problema con guía. La próxima vez va a mirar el network tab antes de pedir ayuda. ### Preguntas de reflexión (post-pair) - ¿Qué hice yo y qué hizo el mentor? Si el mentor tipeó más que yo, algo falló. - ¿Hubo algún momento en el que entendí algo nuevo? ¿Puedo explicarlo ahora? - Si mañana me toca un problema parecido, ¿lo podría resolver sola? --- ## Cómo medir el progreso Para que no sea solo sensación: ### Cycle time por tarea Desde "in progress" hasta "done" en el sistema de tickets (Jira, Linear). Si baja con el tiempo, hay mejora en planificación y desbloqueo. ### Ratio estimado vs real La planilla del punto 5. Meta: que la diferencia se achique mes a mes, no que sea cero. ### Tiempo hasta primer pedido de ayuda Cuando se traba, cuánto tarda en escribir. Track informal. Meta: acercarse a la regla de los 30-60 min. ### Calidad del pedido de ayuda Checklist simple cuando pide ayuda: - [ ] Incluye objetivo - [ ] Incluye error literal - [ ] Incluye intentos previos - [ ] Incluye contexto reproducible ### PRs con plan previo vs sin plan Los PRs que arrancaron con mini-plan suelen tener menos rondas de review. Buena proxy de calidad de planificación. ### DORA Metrics (para más adelante) Cuando tenga más rodaje, las cuatro métricas DORA (DevOps Research and Assessment, Google): - Lead time for changes - Deployment frequency - Mean time to restore - Change failure rate Son métricas de equipo, no individuales, pero sirven de marco general. --- ## Preguntas de reflexión semanal Para hacerse cada viernes (10 minutos): 1. ¿Qué tarea me llevó más de lo que esperaba esta semana? ¿Por qué? 2. ¿Cuántas veces pedí ayuda? ¿Esperé demasiado en alguna? ¿Esperé poco en alguna? 3. ¿Qué aprendí esta semana que no sabía el lunes? (Si la respuesta es "nada", revisar.) 4. ¿Hay algo que estoy evitando porque no lo entiendo? (Ser honesta con uno mismo acá es clave.) 5. ¿Hubo algún momento en el que estuve en loop más de 1 hora sin avanzar? ¿Qué hubiera hecho distinto? 6. ¿Mi mentor sabe en qué estoy trabajando y dónde estoy trabada, o tendría que preguntármelo? --- ## Recursos recomendados Libros con nombre propio que cubren estos temas: - *The Pragmatic Programmer* — Andy Hunt, Dave Thomas (rubber duck, autonomía técnica) - *The Effective Engineer* — Edmond Lau (apalancamiento, comunicación) - *Apprenticeship Patterns* — Dave Hoover, Adewale Oshineye (específico para juniors, gratuito en O'Reilly) - *Staff Engineer* — Will Larson (para más adelante, modelo de carrera) Convenciones documentadas online: - Stack Overflow: "How to ask a good question" - GitLab Handbook: secciones de async communication y stand-ups - Google: "How to write a design doc" --- ## Cierre El punto más importante: **blindar el espacio para pedir ayuda**. Si la primera vez que aplica la regla de los 30 minutos el mentor responde con tono apurado o le hace sentir que "eso era fácil", el sistema se rompe. Las primeras semanas el costo lo paga el mentor: responder rápido, validar el formato del pedido, y recién después exigir más autonomía en el diagnóstico.