# Cómo crear un producto solo con IA: de la idea al lanzamiento
> Un proceso práctico para usar IA en investigación, planificación, desarrollo, pruebas y lanzamiento sin delegar el criterio ni la responsabilidad del producto.
_Slug: building-products-alone-with-ai · 2026-07-15_
Antes, crear un producto exigía reunir a varias personas con especialidades distintas. Hoy, la IA permite que una sola persona avance con rapidez entre investigación de usuarios, planificación, diseño, desarrollo, pruebas y documentación. Eso no significa que la IA sustituya a todo un equipo. Significa que quien crea solo asume más decisiones y más responsabilidad.
Para mí, el valor de **crear un producto solo con IA** no consiste simplemente en generar código más rápido. Consiste en acotar el problema, eliminar trabajo innecesario y reducir la distancia entre una idea y un usuario real. Este es el proceso que sigo desde la primera definición del problema hasta el lanzamiento de un MVP y la llegada de comentarios útiles.
La IA aumenta la velocidad, pero no elige la dirección. Una persona todavía debe decidir qué crear, para quién y cuándo detenerse.
## La IA acelera el trabajo, pero no es un cofundador
Si le pides a una herramienta de IA ideas para una startup, obtendrás una lista convincente en segundos. El problema es que esa lista no conoce mi experiencia, los usuarios a los que puedo llegar, el tiempo disponible ni los riesgos que puedo asumir.
No trato a la IA como a un cofundador. La utilizo como un conjunto de asistentes con funciones limitadas.
- **Asistente de investigación:** organiza el mercado y agrupa enfoques competidores.
- **Asistente de producto:** ordena requisitos y cuestiona supuestos incompletos.
- **Asistente de desarrollo:** implementa cambios pequeños y explica el código.
- **Asistente de pruebas:** propone fallos posibles y escenarios de prueba.
- **Asistente editorial:** mejora el onboarding, la página de presentación y la documentación.
La decisión final siempre queda en mis manos. Sin ese límite, la producción se acelera mientras el producto crece silenciosamente en la dirección equivocada.
## 1. Definir el problema en una sola frase
Antes de construir, completo esta frase:
> **Ayudar a [una persona concreta] a reducir [un problema específico] en [una situación real] mediante [un enfoque claro].**
“Crear un gestor de tareas con IA” describe una solución, no un problema. “Ayudar a profesionales independientes con varios proyectos a elegir en cinco minutos el trabajo esencial de hoy” muestra un usuario, una situación y un resultado.
En esta fase no pido a la IA que invente la respuesta. Le pido que ataque los huecos de mi frase.
- ¿Este problema ocurre con frecuencia?
- ¿Cómo lo resuelve hoy el usuario?
- ¿La molestia justifica cambiar de comportamiento?
- ¿Puedo definir un primer usuario más específico?
- ¿Qué supuesto puedo comprobar sin crear un producto?
Un buen punto de partida no es una idea con muchas respuestas, sino una idea con preguntas claras.
## 2. Investigar con IA y verificar con personas
La IA es rápida durante la investigación inicial. Puede agrupar competidores, proponer segmentos de usuarios y preparar preguntas para entrevistas. Sin embargo, un resumen generado no debe confundirse con evidencia de mercado.
Separo los hallazgos en tres niveles:
1. **Hipótesis generadas por IA** — posibilidades útiles que aún no están verificadas
2. **Fuentes revisadas directamente** — páginas de producto, precios, reseñas y documentación pública
3. **Experiencia de usuarios** — entrevistas, observación y comportamiento real
La dirección del producto gana fiabilidad cuanto más se acerca al tercer nivel. Siempre que puedo, pregunto a cinco usuarios potenciales por el mismo problema. “¿Cómo lo resolviste la última vez?” es mejor que “¿Usarías esta función?”. El comportamiento pasado ofrece una evidencia más sólida que una intención futura.
## 3. Escribir una ficha de producto de una página
Después de investigar, preparo una ficha de una página en lugar de una especificación extensa. Solo contiene lo necesario para tomar la siguiente decisión.
| Campo | Qué escribir |
|---|---|
| Usuario | El único tipo de usuario al que sirve esta versión |
| Problema | Una dificultad concreta y recurrente |
| Promesa | El resultado que cambia después de usar el producto |
| Flujo principal | Las acciones desde la entrada hasta un resultado útil |
| Fuera de alcance | Funciones que esta versión no incluirá |
| Señal de éxito | Un comportamiento o número que revisar tras el lanzamiento |
| Riesgos | Privacidad, coste, precisión y carga operativa |
La IA ayuda a encontrar contradicciones, casos límite y expresiones vagas. La sección más importante suele ser **fuera de alcance**. Los productos individuales se detienen más por exceso de alcance que por falta de funciones.
*La IA conecta las etapas con mayor rapidez, pero quien crea el producto sigue decidiendo cuándo avanzar.*
## 4. Construir el flujo útil más corto para el MVP
Un MVP no es un producto final de mala calidad. Es el producto más pequeño capaz de probar el supuesto más importante. Normalmente limito la primera versión a cuatro pasos.
1. El usuario llega.
2. Introduce la información mínima.
3. El producto genera su resultado principal.
4. El usuario guarda el resultado o realiza la siguiente acción.
Configuración de cuenta, paneles, notificaciones, pagos y herramientas administrativas pueden esperar si no forman parte de la hipótesis principal. Un prototipo interactivo o incluso un servicio manual puede ser suficiente. A veces, entregar el resultado a mano a cinco usuarios enseña más que escribir las primeras mil líneas de código.
La IA facilita añadir funciones. Precisamente por eso necesito una regla de eliminación más estricta. No pregunto “¿puedo construirlo?”, sino “¿puedo comprobar la hipótesis sin esto?”.
## 5. Dar a la IA tareas de desarrollo pequeñas y revisables
“Construye toda la aplicación” puede producir mucho código, pero también crea un sistema difícil de revisar. Divido el trabajo en una pantalla, una acción de usuario o un flujo de datos cada vez.
Cada solicitud de implementación incluye cuatro elementos:
```text
Objetivo: permitir que un usuario inicie sesión con su correo electrónico.
Estado actual: explicar el framework y los archivos relevantes.
Restricciones: indicar la arquitectura, las reglas de seguridad y qué no debe cambiar.
Terminado: definir el camino correcto, los fallos posibles y las pruebas necesarias.
```
Cuando se genera el código, no salto inmediatamente a la siguiente función. Leo los archivos modificados, ejecuto el producto y reviso los caminos de error. El código que no puedo explicar es código que no puedo mantener. Si la explicación es débil o las pruebas son inestables, reduzco aún más la tarea.
### Mi secuencia de desarrollo asistido por IA
1. Explico a la IA la estructura actual y el objetivo.
2. Pido primero un plan de implementación y una lista de archivos.
3. Aplico un cambio pequeño cada vez.
4. Ejecuto comprobaciones de tipos, lint, pruebas y compilación de producción.
5. Verifico el flujo real del usuario en el navegador.
6. Registro por qué se hizo el cambio y qué riesgos permanecen.
Este proceso me permite dedicar menos tiempo a reescribir código generado y más a revisar, validar y tomar decisiones de producto.
## 6. No delegar las pruebas ni la seguridad
La IA puede proponer pruebas y detectar código sospechoso, pero “no encontré problemas” no es una garantía. Autenticación, pagos, datos personales, carga de archivos y API externas requieren una revisión humana deliberada.
Antes de lanzar, compruebo al menos lo siguiente:
- Probar entradas vacías, valores inválidos, solicitudes duplicadas y estados de error.
- Confirmar que secretos y datos personales no aparecen en el navegador ni en los registros.
- Verificar que un usuario no pueda acceder a los datos de otro.
- Diseñar la experiencia para respuestas incorrectas o ausentes de la IA.
- Establecer límites de uso y de coste antes de que aumente la demanda.
- Revisar móviles, redes lentas y accesibilidad básica.
Antes de enviar datos privados de usuarios o código confidencial a un servicio externo de IA, revisa su política de conservación de datos y confirma que tienes permiso para compartirlos.
## 7. Lanzar a pequeña escala y registrar el comportamiento real
El lanzamiento no es el final. Es el comienzo de la investigación más fiable. Empiezo con un grupo pequeño de personas que ya viven el problema, en lugar de intentar llegar a todo el mundo.
En un primer lanzamiento, estos comportamientos importan más que las visitas:
- ¿Los usuarios completan el flujo principal sin explicaciones?
- ¿Vuelven a utilizar el resultado o lo comparten?
- ¿En qué punto se detienen?
- ¿Se sentirían decepcionados si el producto desapareciera?
- ¿La disposición a pagar aparece en acciones y no solo en palabras?
La IA puede agrupar notas de entrevistas y registros para revelar patrones. Aun así, evito forzar opiniones diferentes dentro de una conclusión cómoda. El siguiente cambio debe resolver primero el problema más cercano a la promesa central del producto.
## Un ciclo de siete días para crear un producto solo
Un experimento pequeño puede organizarse en una semana.
| Día | Trabajo | Entregable |
|---|---|---|
| 1 | Acotar el problema y el usuario | Definición del problema en una frase |
| 2 | Investigar y hablar con usuarios | Tres hipótesis principales |
| 3 | Definir el flujo y lo que queda fuera | Ficha de producto de una página |
| 4–5 | Crear el flujo principal con IA | MVP funcional |
| 6 | Probar calidad, privacidad y seguridad | Lista de lanzamiento |
| 7 | Publicar para un grupo pequeño | Observaciones y siguiente decisión |
Un buen producto no estará terminado en siete días. Pero sí puedo reunir evidencia suficiente para decidir si merece otra semana. Ese ciclo de aprendizaje más corto es la razón más práctica para utilizar IA.
## Lo que puede hacer la IA y lo que sigue siendo mi trabajo
### Trabajo que delego activamente
- Primera clasificación y resumen de información
- Listas de preguntas y borradores de documentos
- Código repetitivo y estructura inicial de pruebas
- Explicaciones de errores e hipótesis de depuración
- Variantes de textos y borradores de traducción
- Organización de notas de entrevistas y reuniones
### Trabajo del que sigo siendo responsable
- Elegir qué problema merece una solución
- Interpretar las palabras de usuarios dentro de su contexto
- Fijar estándares de calidad, privacidad y seguridad
- Verificar la información y el código generados
- Decidir qué eliminar y cuándo lanzar
- Asumir el coste de los fallos y su impacto en usuarios
## Preguntas frecuentes
### ¿Puede una persona sin experiencia en desarrollo crear un producto con IA?
La IA puede ayudarle a crear un prototipo u ofrecer un servicio manual sencillo. Un producto real que guarda datos o acepta pagos todavía exige comprender arquitectura, seguridad y operaciones. Cuando el riesgo supera tus conocimientos, reduce el alcance o pide una revisión profesional.
### ¿Qué herramienta de IA debería elegir primero?
Elige la tarea antes que la herramienta. Identifica la parte más lenta de tu proceso —investigación, escritura, diseño, código o pruebas— y empieza con una sola herramienta que mejore ese paso. Un flujo repetible importa más que conectar muchas herramientas.
### ¿Puedo publicar el código generado por IA sin modificarlo?
No. Revisa su comportamiento, dependencias, licencias, seguridad y tratamiento de errores. Ejecuta todas las comprobaciones y la compilación de producción. El código que no puedes explicar se convierte en deuda del producto aunque hoy parezca funcionar.
### ¿Cuál es la métrica más importante para un producto individual?
Al principio, importa más cuántas personas resuelven el problema principal que el número total de registros. Busca usuarios que completen la acción clave, regresen, compartan el resultado o paguen por él.
## El producto sigue siendo una responsabilidad humana
La IA da manos más rápidas a quien crea solo. Reduce la distancia entre investigación e implementación y facilita comenzar tareas poco familiares. No crea automáticamente dirección, comprensión de usuarios ni valor para lanzar.
El mejor producto individual no es el que contiene más funciones de IA. Es el que **elige con precisión un problema pequeño, llega pronto a una persona real y convierte lo aprendido en la siguiente versión**.
Yo [entiendo la vida como un proyecto en marcha](/es/posts/built-slowly-updated-daily). Crear productos funciona igual: publicar una versión pequeña, registrar el resultado y tomar la siguiente decisión en lugar de esperar un plan perfecto. La IA no dirige ese proyecto; simplemente me ayuda a ejecutar el ciclo con mayor rapidez.
---
# Cómo validar el código de la IA: 8 principios para desarrolladores en solitario
> Errores en base de datos, mocks olvidados y APIs rotas al crear AttractiveWebAI y apps de Shopify. 8 principios prácticos para verificar código generado por IA sin perder el control.
_Slug: principles-of-maintaining-code-quality-with-ai · 2026-07-13_
#### El espejismo de la interfaz perfecta
Cuando logré compilar por primera vez mi aplicación de membresías para Shopify sin ningún error, sentí una euforia inmensa. En el navegador apareció un panel de control impecable. Los botones interactivos respondían al instante y los formularios para asignar puntos funcionaban con total fluidez. Cada clic desencadenaba una transición visual perfecta. Solo me había tomado dos días de darle instrucciones en lenguaje natural a un asistente de programación con IA. A ese ritmo, calculé que podría publicar la aplicación en la tienda de Shopify la semana siguiente.
La emoción desapareció en cuanto intenté realizar una transacción real. Usando una cuenta de prueba para simular una compra y acumular puntos, la aplicación no hizo absolutamente nada. Al revisar el código fuente, me topé con una realidad decepcionante: todos los datos del panel eran mocks (datos simulados) que la IA había introducido directamente en los componentes. Las integraciones con la API de pagos, los webhooks y los activadores de descuentos no existían. No se había escrito ni una sola línea de lógica real en el backend. Era una fachada hermosa, pero vacía.
No soy ingeniero de software de profesión. Trabajo como Product Manager (PM) y, en mi tiempo libre, actúo como creador independiente, lanzando proyectos con la ayuda de agentes de IA como Gemini, Claude y Codex. En el último año he desarrollado AttractiveWebAI (un SaaS de analítica web), complementos para tiendas de Shopify y una utilidad de gestión de ventanas para macOS.
Al principio, la velocidad me tenía deslumbrado. Describía una funcionalidad y en segundos obtenía cientos de líneas de código. Pero a medida que los proyectos crecían y los sistemas se conectaban, los cabos sueltos ocultos bajo la superficie empezaron a pasar factura al mismo tiempo.
---
#### 10 maneras en que la IA rompió mis proyectos
Mi registro de desarrollo está lleno de fallos específicos y dolorosos que las herramientas de compilación pasaron por alto:
1. **La base de datos fantasma**: La interfaz mostraba un mensaje de \"Guardado con éxito\", pero los datos nunca llegaban a Supabase; vivían y morían en la memoria temporal del cliente.
2. **API desconectadas**: Formularios y botones maquetados de forma impecable, pero sin las funciones de comunicación con los endpoints del backend.
3. **Mocks olvidados en producción**: Datos de prueba y respuestas simuladas que se quedaron activos en el servidor de producción.
4. **Duplicación de lógica**: La IA, al no tener la estructura completa en mente, creaba funciones auxiliares repetidas con nombres ligeramente distintos, llenando el repositorio de código innecesario.
5. **Errores de regresión**: Arreglar un pequeño detalle visual en una sección rompía de manera silenciosa la gestión del estado global en una ruta completamente diferente.
6. **La trampa del build exitoso**: La aplicación compilaba sin errores en la terminal, pero al abrirla en el navegador mostraba una pantalla en blanco debido a un caso límite no controlado.
7. **Código incompleto**: El asistente aseguraba haber terminado la tarea, pero al revisar el archivo, la lógica de negocio estaba sustituida por un comentario: `// TODO: Implementar lógica de facturación real`.
8. **Esquemas de base de datos ausentes**: Al cambiar de una base de datos de pruebas a la de producción, actualicé las variables de entorno, pero olvidé migrar las tablas de SQL, relaciones e índices.
9. **Lógica de negocio omitida**: La interfaz de la app de Shopify estaba lista, pero los procesos críticos de la API de cobros y webhooks no estaban enlazados.
10. **Permisos de sistema ignorados**: En la herramienta para macOS, la configuración mostraba los permisos de accesibilidad activos, pero el código en ejecución no detectaba la autorización del sistema operativo.
Resolver estos problemas me enseñó una lección fundamental: el verdadero cuello de botella al programar con IA no es escribir el código. **Es el proceso humano de verificación: demostrar que un cambio realmente funciona y es seguro.** Si no aplicas esta disciplina, tu código se convierte en un pantano imposible de mantener.
Aquí están las 8 reglas de verificación que utilizo para proteger la calidad de mis desarrollos.
---
#### Regla 1: Define los criterios de aceptación antes de preguntar
Pedirle a una IA que \"cree una pantalla de registro\" es una invitación a que tome atajos. En su lugar, incluyo en el prompt una lista de criterios de aceptación detallada:
```markdown
[Criterios de Aceptación]
1. El usuario debe poder registrarse con su cuenta de Google OAuth.
2. La sesión debe mantenerse activa al recargar la página o reiniciar el navegador.
3. Al hacer clic en \"Cerrar sesión\", el token debe eliminarse y redirigir a la página de inicio.
4. Las llamadas no autorizadas a endpoints privados deben devolver un estado 401 Unauthorized.
5. Las políticas RLS de la base de datos deben limitar el acceso a la información solo al dueño de la sesión.
6. Ningún token o credencial sensible debe imprimirse en la consola del navegador.
```
Al marcar límites claros, la IA escribe código de validación y gestión de errores desde el primer intento.
#### Regla 2: Desconfía siempre del estado \"Terminado\"
Cuando la IA afirma que una funcionalidad está completa, es cuando más debes dudar. Siempre respondo exigiendo un desglose detallado:
* Lista de todos los archivos modificados o creados.
* Cambios específicos en cada archivo y la razón técnica detrás de ellos.
* Indicación de cualquier dato simulado (mock) o marcador que se haya quedado en el código.
* Ubicación de comentarios `TODO` o sentencias `console.log`.
* Limitaciones o casos extremos que no se hayan cubierto.
Hacer que la IA explique su trabajo revela con frecuencia soluciones a medias y la obliga a reescribir bloques que había dejado pendientes.
#### Regla 3: Separa el éxito de compilación del éxito funcional
Que el proyecto compile sin errores es solo el punto de partida. Una vez finalizado el build, hago una validación manual rigurosa:
* **Prueba de persistencia**: Introduce información, guarda, recarga la pestaña del navegador y confirma que los datos se lean correctamente desde la base de datos real.
* **Prueba de estrés**: Envía formularios vacíos, haz clic repetidamente en los botones de acción y escribe caracteres no válidos para comprobar la robustez.
* **Prueba de accesos**: Cierra la sesión e intenta ingresar directamente a las rutas del panel de control para comprobar que no se filtre información.
* **Auditoría de consola**: Mantén abierta la consola de desarrollador durante las pruebas para detectar advertencias silenciosas o errores de red.
#### Regla 4: Reduce el alcance de cada solicitud
Pedir \"un panel de control completo con gráficos y métricas en tiempo real\" suele terminar en código desordenado y partes incompletas. Prefiero avanzar en tareas pequeñas y secuenciales:
1. Diseñar el esquema de base de datos e implementar las tablas.
2. Crear y probar los endpoints de la API de forma independiente.
3. Construir la interfaz de usuario con datos estáticos.
4. Conectar los endpoints de la API real a la interfaz de usuario.
5. Añadir componentes de control de errores para gestionar caídas de red.
6. Validar el funcionamiento en staging y refactorizar.
#### Regla 5: Usa una IA para escribir y otra diferente para revisar
El mismo hilo de chat que generó el código suele tener un sesgo cognitivo hacia sus propias respuestas y pasará por alto los errores de lógica.
Para solucionarlo, copio el código generado, abro una conversación completamente nueva (o uso un modelo de IA diferente) y le asigno un rol crítico:
> \"Eres un ingeniero de sistemas sénior y un especialista en control de calidad muy exigente. Revisa este código en busca de posibles fallos de seguridad, excepciones no controladas, problemas de rendimiento y lógica ineficiente. Sé estricto.\"
Este método me ha permitido detectar fugas de conexiones a bases de datos y fallos de seguridad críticos antes de que llegaran a producción.
#### Regla 6: Gestiona el estado del desarrollo en una matriz detallada
Decir que una sección está \"lista\" es demasiado ambiguo. Como desarrollador en solitario, necesito claridad absoluta. Mantengo una matriz de estados para cada funcionalidad:
* [ ] **No iniciado**: Planificado, sin código escrito.
* [ ] **Solo Interfaz**: Componentes visuales maquetados, sin conexión con el backend.
* [ ] **Simulado (Mock)**: Elementos interactivos operando con datos estáticos locales.
* [ ] **API Conectada**: Comunicación funcional con los servicios del servidor.
* [ ] **DB Persistida**: Escritura y lectura correctas en la base de datos real.
* [ ] **Validado en QA**: Pruebas de errores y casos límite superadas.
* [ ] **Validado en Prod**: Comprobado y en funcionamiento en el servidor real.
Esta matriz evita que dé por terminado un proyecto solo porque la interfaz se ve bonita.
#### Regla 7: Exige un análisis del contexto antes de modificar el código
Si le pides a una IA que cambie un archivo directamente, creará parches que ignorarán las decisiones de diseño previas. Primero pídele que analice el entorno:
> \"Quiero modificar este archivo. Antes de escribir código, analiza los patrones de diseño existentes, el flujo de datos y cómo interactúa con otras partes de la aplicación. Identifica qué funciones se verán afectadas.\"
Solo cuando el asistente ha mapeado correctamente las relaciones, le permito proponer los cambios en el código.
#### Regla 8: Registra la deuda técnica de forma visible
A veces es inevitable tomar atajos para cumplir con una fecha límite. Lo peligroso es olvidar dónde dejamos esos parches. Mantengo un archivo llamado `tech-debt.md` en la raíz de mis proyectos:
```markdown
## Deuda Técnica Activa
* [AttractiveWebAI] El gráfico principal usa datos simulados (conectar la API real antes del lanzamiento oficial).
* [Shopify App] Falta validación de firma en el webhook de cobros (riesgo de seguridad alto; corregir antes de enviar a revisión).
* [macOS Utility] Tiempo de espera para verificar permisos en disco hardcoded a 3 segundos (cambiar por un detector de eventos del sistema).
```
Tener esta lista visible asegura que la siguiente sesión de desarrollo comience con prioridades claras.
---
#### Hacia un producto de calidad real
El desarrollo asistido por IA da la sensación de que programar es una tarea ligera. Ver cómo aparecen cientos de líneas de código a partir de frases sencillas genera un falso sentimiento de control.
Sin embargo, el éxito de un software no se mide por la cantidad de líneas que genera, sino por las excepciones controladas, los casos extremos probados y las simulaciones eliminadas. Un software construido sobre supuestos de IA sin revisar se desmorona en cuanto el primer usuario real interactúa con él.
La IA es una asistente excelente y escribe a una velocidad increíble. Pero la tarea de definir qué es correcto y asegurar la calidad sigue estando en manos del ser humano. Revisar los registros, analizar la base de datos y leer el código sigue siendo la verdadera esencia de la ingeniería de software.
---
# Reseña de aprobación del examen PMP Parte 2: Gestión del tiempo el día del examen y consejos finales para aprobar
> Comparto la experiencia real de tomar el examen PMP en el centro Pearson VUE, la gestión del tiempo para las primeras 60 preguntas, los descansos de 10 minutos, repasar el cuaderno de errores justo antes del examen y qué preparar.
_Slug: pmp-pass-review-part-2 · 2026-07-05_
En la [Parte 1](/es/posts/pmp-pass-review-part-1) resumí qué tipo de certificación es el PMP y cómo utilicé las clases en línea, el PMI Study Hall, los cuadernos de errores, GPT y NotebookLM durante unas 7 semanas.
En la Parte 2, compartiré la experiencia desde el momento en que ingresé al centro de exámenes hasta que recibí la hoja de resultados de Aprobado en orden cronológico. Aunque fue difícil darse cuenta al estudiar, después de tomar el examen en persona, sentí que **la resistencia, la gestión del tiempo y la gestión de los descansos son tan importantes como el conocimiento**.
Este artículo es una reseña de cómo tomar el examen PMP antes de la reforma del 3 de julio de 2026. PMI implementó el nuevo examen el 9 de julio de 2026. Verifica la estructura actual del examen y los porcentajes de dominio en la [Guía Oficial PMP del PMI](https://www.pmi.org/certifications/project-management-pmp).
## El día del examen de un vistazo
| Elemento | Mi experiencia |
|---|---|
| Lugar del Examen | Centro de exámenes Pearson VUE |
| Estructura del Examen en ese Momento | 180 preguntas, 230 minutos |
| Estructura de las Sesiones | 3 sesiones de 60 preguntas cada una |
| Tiempos de Descanso | Dos descansos de 10 minutos entre sesiones |
| Tiempo Dedicado a las Primeras 60 Preguntas | Aproximadamente 80 minutos |
| Bocadillos Preparados | Barras de chocolate, nueces, almendras |
| Resultado Final | PASS (Aprobado) |
Mirando solo la estructura del examen, es fácil pensar: "Solo necesito resolver 60 preguntas tres veces". Sin embargo, leer y juzgar preguntas de situaciones similares de forma continua durante aproximadamente 4 horas fue mucho más agotador de lo que esperaba.
## Al llegar al centro Pearson VUE
Tomé el examen en un centro Pearson VUE. Había resuelto Full Mocks durante mis estudios y pensaba que estaba preparado hasta cierto punto, pero entrar al centro de exámenes se sintió completamente diferente.
Desde el momento en que verificaron mi identidad, organizaron mis pertenencias personales y me senté en el escritorio del examen, la tensión comenzó a aumentar. Cuando apareció la primera pregunta en la pantalla, terminé leyendo las oraciones durante más tiempo de lo habitual y seguí dudando incluso de las opciones sencillas.
Las pautas del centro y las reglas de registro pueden variar, por lo que es mejor verificar la hora de llegada, las identificaciones y las reglas de almacenamiento en el correo electrónico de reserva con anticipación. En particular, verifiqué dos veces si mi nombre en inglés y la información de mi identificación coincidían exactamente con los detalles de la reserva.
## El examen real se sintió más difícil de lo esperado
Personalmente, el examen real se sintió más difícil de lo esperado. Aunque había visto muchas preguntas de formatos similares en Study Hall, la tensión en el centro de exámenes hizo que las pequeñas diferencias entre las opciones se sintieran mucho mayores.
Cada vez que resolvía una pregunta, se repetían pensamientos como los siguientes:
- Ambas opciones suenan correctas, ¿qué debo hacer primero?
- En esta situación, ¿es primero el análisis o la acción?
- ¿Es momento de escalar ahora?
- ¿Es esta una situación ágil (Agile) o predictiva (Predictive)?
- ¿La pregunta pide `FIRST` (Primero) o `NEXT` (A continuación)?
Las preguntas que requerían elegir una de dos opciones consumieron mucha más energía que aquellas en las que no tenía idea de la respuesta. Intentar obtener una certeza absoluta en cada pregunta hizo que el tiempo desapareciera rápidamente.
## Dediqué 80 minutos a las primeras 60 preguntas
Me tomó unos 80 minutos resolver la primera sesión de 60 preguntas. Cuando salí para el primer descanso, pensé: "Si voy a esta velocidad, ¿no me quedará poco tiempo más adelante?"
La razón por la que tomó tanto tiempo en la primera sección fue simple:
- Leí las preguntas repetidamente debido al nerviosismo.
- Volví a revisar respuestas que ya había elegido claramente.
- No pude avanzar de las preguntas difíciles de inmediato.
- Me concentré en la pregunta individual actual en lugar del tiempo general.
Durante el primer descanso, intenté no pensar en la puntuación ni en las preguntas difíciles. Bebí agua, comí un poco de la barra de chocolate y de las nueces, y estiré el cuello y los hombros. Alejarme por completo de la pantalla y de las preguntas, aunque fuera por poco tiempo, fue de gran ayuda.
Cuando volví a entrar, cambié mi estrategia:
> **No vuelvas a leer las preguntas que conoces con claridad. No dejes que una pregunta difícil te quite el tiempo para resolver preguntas fáciles más adelante.**
Después de eso, primero verifiqué si la pregunta requería `FIRST`, `NEXT` o `BEST`, eliminé las opciones que eran claramente incorrectas y tomé mi decisión. Gracias a esto, me quedó algo de tiempo en la sesión final.
## Método de gestión del tiempo que me funcionó
Si tuviera que prepararme para el examen de nuevo, no dividiría el tiempo por pregunta de forma perfectamente equitativa. En su lugar, revisaría el tiempo restante en unidades de 60 preguntas y reduciría los momentos en los que me quedo en una pregunta durante demasiado tiempo.
### 1. Comprobar primero la acción exigida por la pregunta
Antes de leer la descripción de la situación, mirar lo que el director del proyecto debe hacer `primero`, `a continuación` o `cómo` en la última oración hizo que el enfoque de la pregunta fuera un poco más claro.
### 2. Terminar las preguntas claras de una vez
Si eliges una respuesta clara pero la lees de nuevo solo por ansiedad, el tiempo se acumula. Intenté distinguir entre las preguntas que realmente necesitaban revisión y aquellas de las que dudaba simplemente debido al nerviosismo.
### 3. Dedicar tiempo limitado a las preguntas difíciles
Si seguían quedando dos opciones, tomaba una decisión después de revisar las palabras clave de la pregunta y la Mentalidad PMP nuevamente. Terminar todo el examen era más importante que obtener una confianza perfecta en una sola pregunta.
### 4. Mirar el tiempo restante antes de que finalice la sesión
Mirar el reloj en cada pregunta puede romper tu concentración. En su lugar, verificar el tiempo restante a intervalos regulares y antes del final de una sesión funcionó mejor para mí.
## Comprueba los descansos de 10 minutos tú mismo
Si tomas el examen en un centro Pearson VUE, te recomiendo verificar los tiempos de descanso tú mismo. **10 minutos pasan mucho más rápido de lo que piensas.**
Ir al baño, comer bocadillos y pasar por los controles de identificación y seguridad para ingresar nuevamente toma tiempo rápidamente. Superé ligeramente los 10 minutos durante el primer descanso.
Es seguro revisar el reloj frente a la puerta del centro o en el lugar indicado antes de moverte. Es posible que no se te permita usar tu teléfono móvil, por lo que es más seguro no asumir que puedes verificar la hora con tu teléfono. Asegúrate de seguir los procedimientos exactos del centro.
### Lo que realmente hice durante los descansos
1. Bebí agua.
2. Comí un poco de barra de chocolate y nueces.
3. Estiré el cuello, los hombros y la cintura.
4. No recordé preguntas pasadas.
5. Verifiqué únicamente el tiempo restante y la estrategia de la siguiente sesión.
Repasar las preguntas durante los descansos solo aumenta la ansiedad sobre las sesiones que ya has enviado. Para mí, vaciar mi cabeza y mover mi cuerpo fue mucho más efectivo.
## El estudio que más ayudó justo antes del examen
Lo más útil justo antes del examen no fue leer el libro de principio a fin de nuevo. Fue mirar las preguntas que había fallado y **explicar por qué las había fallado en mis propias palabras**.
En particular, a partir de dos días antes del examen, repetí las siguientes dos cosas en lugar de agregar contenidos nuevos:
### 1. Cuadernos de errores existentes
Miré los errores que repetía en lugar de las respuestas correctas.
- No leí la pregunta hasta el final.
- No distinguí entre `FIRST` y `NEXT`.
- Escalé antes de hablar con el equipo.
- Elegí una solución antes de encontrar la causa.
- Ejecuté antes de analizar el impacto de un cambio.
- Confundí situaciones ágiles (Agile) y predictivas (Predictive).
### 2. Mentalidad PMP
Justo antes del examen, repasé brevemente el orden básico de juicio en lugar de la amplia lista de procesos.
> **Comprender la situación → Comprobar la causa → Colaborar con el equipo → Analizar el impacto → Actuar según los procedimientos**
Por supuesto, esta no es una fórmula que se aplique a todas las preguntas de la misma manera. Sin embargo, sirvió como referencia para evitar que elija apresuradamente acciones fuertes en situaciones de tensión.
## Elementos que es bueno llevar al centro de exámenes
Bajo la premisa de verificar primero las regulaciones del centro, los siguientes preparativos fueron personalmente útiles:
- Una identificación válida que coincida con los detalles de la reserva
- Bocadillos que se puedan comer rápidamente, como barras de chocolate
- Frutos secos como nueces o almendras
- Agua
- Ropa cómoda que se pueda ajustar a la temperatura
- Una nota con la ubicación del centro de exámenes y la hora de llegada
En lugar de comer muchos bocadillos, era bueno reponer azúcar y energía ligeramente durante los descansos sin sentirme pesado. Estirar ligeramente el cuello, los hombros y la cintura también ayudó a recuperar la concentración para la siguiente sesión.
## Asegúrate de experimentar un simulacro de examen de 4 horas
Obtener buenas puntuaciones en conjuntos de preguntas cortas y continuar tomando decisiones durante aproximadamente 4 horas fueron experiencias diferentes.
Resolver un Full Mock hasta el final te permite verificar cosas distintas al conocimiento:
- ¿En qué sesión cae más la concentración?
- ¿Estoy resolviendo las primeras 60 preguntas demasiado lento?
- ¿Cuánto tiempo me toma concentrarme de nuevo después de los descansos?
- ¿Cuánta agua y bocadillos debo comer para sentirme cómodo?
- ¿Están bien mi cuello y mi cintura al estar sentado durante mucho tiempo?
Recomiendo alejar tu teléfono móvil, cronometrarte y usar solo los tiempos de descanso designados para resolverlo de la manera más similar posible al examen real. Puedes reducir al menos un elemento que experimentes por primera vez el día del examen.
## Si tu puntuación de Study Hall está en el rango del 60%
Si tu puntuación de Study Hall está en el rango medio-alto del 60%, es posible que te sientas ansioso al compararla con las puntuaciones altas de las reseñas de aprobados. Mis puntuaciones de Full Mock también fueron de 66% y 65%, y el promedio general fue de aproximadamente 62%.
Aprobé el examen real con esas puntuaciones, pero no quiero afirmar esto como un estándar de que "el 60% significa aprobación incondicional". Las experiencias individuales con las preguntas resueltas, los niveles de análisis de errores y las condiciones del día del examen difieren.
En su lugar, espero que verifiques las siguientes preguntas:
- ¿Puedes explicar la razón por la que cometiste un error en tus propias palabras?
- ¿Evitas repetir el mismo error en situaciones similares?
- ¿Puedes terminar un Full Mock dentro del límite de tiempo real?
- ¿Puedes aplicar el orden de juicio del PMI sin memorizar las respuestas?
Las respuestas a estas preguntas mostraron mi estado de preparación mejor que el número de puntuación individual.
## La IA fue un compañero de repaso, no una hoja de respuestas
GPT y NotebookLM fueron útiles para organizar cuadernos de errores, repasar la Mentalidad PMP y comparar conceptos confusos. Especialmente justo antes del examen, fueron útiles para convertir contenidos dispersos en preguntas cortas y resúmenes.
Sin embargo, no recomiendo ingresar preguntas de PMP directamente y verificar los errores basándose únicamente en las opciones seleccionadas por la IA. La IA puede malinterpretar diferencias sutiles entre las opciones y presentar con confianza respuestas incorrectas con explicaciones plausibles.
Incluso al usar la IA, debes realizar los siguientes procesos tú mismo:
1. Escribe primero por qué elegiste esa respuesta.
2. Verifica las explicaciones y fuentes oficiales.
3. Pregunta a la IA sobre las brechas en tu proceso de pensamiento en lugar de la respuesta correcta.
4. Si las descripciones difieren, verifica nuevamente basándote en materiales oficiales.
5. Al final, deja un principio de una sola línea en tus propias palabras.
## Cuando recibí la hoja de resultados
Cuando terminó el examen y verifiqué el resultado de Aprobado, la primera emoción que sentí fue alivio. Aunque dudé cada vez que vi puntuaciones bajas y preguntas difíciles durante la preparación, al final, esos cuadernos de errores se convirtieron en los recursos que me hicieron pensar una vez más en la sala de exámenes.
Mis resultados por dominio fueron People Below Target, Process Target y Business Environment Above Target. Aunque un dominio estuvo por debajo del Target (Below Target), el resultado general fue PASS (Aprobado). Sin embargo, este es solo mi resultado personal, y no significa que los criterios de aprobación del PMI puedan calcularse simplemente utilizando las calificaciones de dominio.
## Palabras finales
En lugar de pensar "¿Por qué fallé en esto?" cuando ocurre un error, sería bueno aceptarlo como "Esta es una pregunta que aumentó la probabilidad de acertar en el examen real". Definitivamente hay preguntas que es un alivio fallar antes del examen.
Lo importante no fue la puntuación en sí, sino **descubrir de qué manera cometo juicios incorrectos a través del análisis de errores**.
Si te estás preparando para el examen, intenta dedicar tiempo a convertir los contenidos ya estudiados en tus propios criterios de juicio en lugar de agregar continuamente materiales nuevos. E intenta sentarte durante aproximadamente 4 horas antes del examen. Podrás resolver las preguntas de manera mucho más estable cuando el conocimiento, la resistencia y la gestión del tiempo se preparen juntos.
Apoyo a todos los que se están preparando ahora. ¡Mucho éxito! 💪🍀
**Leer desde el principio:** [Reseña de aprobación del examen PMP Parte 1: 7 semanas de preparación y el camino desde el 60% en Study Hall hasta el Aprobado](/es/posts/pmp-pass-review-part-1)
---
# Reseña de aprobación del examen PMP Parte 1: 7 semanas de preparación y el camino desde el 60% en Study Hall hasta el Aprobado
> Un resumen del proceso de estudio de 7 semanas para aprobar el examen PMP el 3 de julio de 2026, utilizando clases en línea, PMI Study Hall, cuadernos de errores, GPT y NotebookLM.
_Slug: pmp-pass-review-part-1 · 2026-07-03_
Hola. **El viernes 3 de julio de 2026 realicé el examen PMP y finalmente obtuve el APROBADO (PASS).**
Durante la preparación del examen, leí reseñas de aprobados en comunidades de PMP coreanas y publicaciones en [Reddit r/PMP](https://www.reddit.com/r/pmp/) casi todos los días. Me ayudó mucho ver si las personas con puntuaciones similares en Study Hall lograban aprobar, qué tan difícil era el examen real y qué preparar para el día del examen.
Habiendo leído siempre las reseñas de otros, escribir una yo mismo se siente extraño pero muy bien. Espero que este artículo sirva como una pequeña referencia para quienes se sienten ansiosos por sus puntuaciones actuales o aún no han definido una dirección de estudio.
Este artículo se basa en la experiencia de tomar el examen antes de la reforma del 3 de julio de 2026. PMI implementó el nuevo examen PMP, que refuerza la IA, la sostenibilidad y la entrega de valor, a partir del 9 de julio de 2026. Asegúrate de verificar el tiempo del examen, el peso de las secciones y los criterios del examen en la [Guía Oficial PMP de PMI](https://www.pmi.org/certifications/project-management-pmp) y en la [Guía de Reforma del Examen 2026](https://www.pmi.org/certifications/project-management-pmp/new-exam).
*Hoja de resultados recibida en el centro Pearson VUE inmediatamente después del examen. El resultado general fue PASS (Aprobado), y los resultados por dominio fueron People Below Target, Process Target y Business Environment Above Target.*
## ¿Qué es la Certificación PMP?
PMP (Project Management Professional) es una certificación profesional en gestión de proyectos otorgada por el PMI (Project Management Institute). No se limita a una industria específica o a una única metodología, sino que evalúa si puedes gestionar **personas, procesos y prioridades comerciales** mientras lideras proyectos.
Está muy lejos de ser un examen que simplemente comprueba cuánto has memorizado del contenido del PMBOK. La mayoría de las preguntas reales presentan situaciones que podrían ocurrir en un proyecto y le piden al director del proyecto que juzgue **qué hacer primero** o **qué acción tomar a continuación** en esa situación.
Por lo tanto, aunque comprender la terminología y los procesos es importante, fue más crítico aprender el orden en que se analizan las preguntas y la actitud que el PMI espera de un director de proyecto.
Los requisitos de elegibilidad incluyen experiencia en liderazgo de proyectos según el nivel educativo y requisitos de educación en gestión de proyectos. Estos criterios también pueden cambiar, por lo que verificar tus condiciones directamente en los [Requisitos de Elegibilidad Oficiales del PMI](https://www.pmi.org/certifications/project-management-pmp) es lo más preciso.
## Resumen de mis resultados de preparación PMP
| Elemento | Detalles |
|---|---|
| Fecha del Examen | Viernes 3 de julio de 2026 |
| Período de Preparación | Aproximadamente 7 semanas |
| Lugar del Examen | Centro de exámenes Pearson VUE |
| Materiales Principales de Estudio | Clases en línea, PMI Study Hall, Cuadernos de errores |
| Study Hall Full Mock 1 | 66% |
| Study Hall Full Mock 2 | 65% |
| Promedio General de Study Hall | Aproximadamente 62% |
| Herramientas Auxiliares | GPT, NotebookLM |
| Resultado Final | PASS (Aprobado) |
Mirando solo la hoja de resultados, el proceso de preparación parece haber ido según lo planeado, pero en realidad, me sentía ansioso cada vez que revisaba mis puntuaciones de Study Hall. Cuanto más leía reseñas de aprobados con puntuaciones altas, más me preguntaba: "¿Está bien programar el examen con esta puntuación?"
En retrospectiva, lo más importante que la puntuación en sí fue **identificar qué tipo de mentalidad me hacía cometer errores repetidos**.
## ¿Por qué tomé el examen existente en 7 semanas?
Al principio, considerando cuándo cambiaría el examen PMP, comencé a estudiar con libros de texto basados en la 8ª edición del PMBOK. Planeaba prepararme lentamente en función del nuevo examen.
Sin embargo, una vez que comencé a estudiar, terminé las clases en línea más rápido de lo esperado y todavía quedaba espacio para programar un examen antes de la reforma. Dado que los principios fundamentales que ya había estudiado se conectaban con el examen existente, decidí concentrarme y tomarlo de acuerdo con el examen actual en lugar de extender el período de preparación.
Lo importante en esta elección no fue el hecho de que miré el libro más reciente, sino **volver a alinear el Exam Content Outline y los tipos de preguntas del examen que tomaría**. Si te estás preparando para el PMP, es mejor verificar primero los estándares oficiales del examen aplicados a la fecha de tu examen, en lugar de mirar solo la edición del libro de texto.
## Cómo estudié durante 7 semanas
Mi proceso de estudio se dividió principalmente en cuatro etapas.
### Etapa 1: Comprender la estructura general a través de clases en línea
No intenté memorizar todos los detalles del PMBOK desde el principio. Mientras escuchaba las clases en línea, capté primero el gran flujo: en qué se diferencian los enfoques predictivos, ágiles e híbridos, y qué papel debe desempeñar el director del proyecto en cada situación.
Los días laborables, escuchaba clases incluso un poco después del trabajo. Los días que tenía energía, escuchaba varias clases seguidas; los días difíciles, terminaba al menos una sección corta. Los fines de semana, repasaba lo que había escuchado durante la semana o resolvía preguntas.
No soy el tipo de persona que se concentra y estudia durante mucho tiempo después del trabajo. Así que en lugar de cumplir perfectamente con un volumen de estudio diario, me concentré en **reducir el número de días en los que dejaba de estudiar por completo**.
### Etapa 2: Aprender el método de juicio real con Study Hall
El recurso que más utilicé después de escuchar las clases básicas fue el PMI Study Hall. Resolver preguntas revelaba inmediatamente si no conocía un concepto, si leía mal una pregunta o si elegía la opción de Escalar demasiado rápido.
Al principio, solo miraba el número de respuestas correctas. Si la puntuación era baja, pensaba que mi estudio era insuficiente, y buscar reseñas de personas con puntuaciones altas me ponía más ansioso. Pero a medida que resolvía preguntas repetidamente, aprendí que incluso con la misma puntuación, la información contenida en ella era diferente.
- Preguntas falladas porque no conocía el concepto en sí
- Preguntas donde pasé por alto la intención de palabras clave como `FIRST`, `NEXT` o `BEST`
- Preguntas donde asumí arbitrariamente situaciones que no estaban en el problema
- Preguntas donde escalé inmediatamente al Patrocinador (Sponsor) o a la alta dirección
- Preguntas donde intenté reemplazar personas antes de hablar con el equipo
- Preguntas donde implementé un cambio antes de analizar su impacto
Clasificar las razones de los errores convirtió las puntuaciones de una simple evaluación en datos que me indicaban la siguiente dirección de estudio.
### Etapa 3: Experimentar unas 4 horas con los exámenes Full Mock
Mi Study Hall Full Mock 1 fue de 66%, el Full Mock 2 fue de 65% y el promedio general fue de aproximadamente 62%. Para ser sincero, no era una puntuación tranquilizadora.
Aun así, no enfoqué el propósito principal del Full Mock únicamente en predecir la probabilidad de aprobar. Verifiqué si podía mantener la concentración durante mucho tiempo, en qué sección disminuía mi velocidad y si podía sumergirme nuevamente en las preguntas después de los descansos.
El examen PMP evalúa no solo el conocimiento, sino también la resistencia y la gestión del tiempo. Ir al centro de exámenes después de haber resuelto solo conjuntos de preguntas cortas te hace experimentar la fatiga del examen real por primera vez. Recomiendo cronometrarte y resolver un Full Mock de principio a fin al menos una vez antes del examen.
### Etapa 4: Centrarse en los cuadernos de errores en lugar de nuevas preguntas
Cuando se acercaba el examen, no agregué muchas preguntas nuevas. Intenté responder las siguientes preguntas mientras repasaba las preguntas que ya había fallado:
> "¿Por qué elegí esta opción?"
> "¿Por qué esta respuesta es más apropiada que las otras opciones desde la perspectiva del PMI?"
Si memorizaba la frase correcta, cometía un error de nuevo cuando las palabras cambiaban ligeramente en una situación similar. En cambio, si podía explicar mi proceso de juicio, podía aplicar el mismo principio a preguntas nuevas.
## Mentalidad PMP que ayudó en el examen
No acepté la Mentalidad PMP (PMP Mindset) como una fórmula de memorización que se aplica incondicionalmente. Esto se debe a que existen excepciones que requieren una acción inmediata, como la ética, las leyes, la seguridad y los riesgos urgentes. Sin embargo, en situaciones típicas de conflicto o cambio, el siguiente orden ayudó a mi juicio:
1. **Comprender la situación y encontrar la causa antes de actuar.**
2. **Hablar con el equipo primero para los problemas que se pueden resolver dentro del equipo.**
3. **No escalar inmediatamente ni transferir la responsabilidad al Patrocinador (Sponsor).**
4. **Intentar el entrenamiento (coaching), la colaboración y la resolución de conflictos antes de reemplazar a las personas.**
5. **Encontrar la Causa Raíz (Root Cause) en lugar de los síntomas de un problema.**
6. **Procesar las solicitudes de cambio de acuerdo con los procedimientos formales después de analizar el impacto.**
7. **El director del proyecto apoya al equipo y elimina obstáculos en lugar de controlarlos.**
En las preguntas reales, varias opciones parecían plausibles. En esos momentos, la respuesta que "comprende la situación y ayuda al equipo a resolverla" solía ser más apropiada que la respuesta que "toma la acción más fuerte de inmediato".
## ¿Fueron suficientes las clases en línea?
Personalmente, quedé satisfecho con las clases en línea. Fueron suficientes para captar el gran flujo y la mentalidad necesarios para el examen.
Al principio, me preguntaba si debería tomar clases presenciales costosas. Pero en mi caso, la combinación de aprender la estructura básica a través de clases en línea, resolver preguntas de Study Hall y analizar los cuadernos de errores funcionó muy bien.
Sentí que el tiempo dedicado a **resolver preguntas, cometer errores y reorganizar los procesos de juicio** después de escuchar las clases fue más crítico que qué clases elegí. El hecho de haber completado una clase por sí solo no me permitía elegir opciones en situaciones de examen.
## Cómo utilicé GPT y NotebookLM
También utilicé mucho GPT y NotebookLM en el proceso de preparación del PMP. En lugar de usar la IA como una herramienta que elegía las respuestas correctas por mí, la utilicé como un compañero de repaso para explicar y comparar los contenidos que comprendía.
### Uso de GPT
- Comparar la diferencia entre dos conceptos confusos en una tabla
- Explicar mi proceso de pensamiento para la respuesta elegida y recibir preguntas sobre premisas omitidas
- Clasificar las causas de los errores en deficiencia de conceptos, interpretación de preguntas o errores de mentalidad
- Hacer que me vuelvan a explicar conceptos complejos con ejemplos de proyectos del mundo real
- Crear preguntas cortas de repaso basadas en los contenidos organizados
Por ejemplo, en lugar de pedir la respuesta correcta, preguntaba así:
```text
Juzgué que debía informar inmediatamente al Patrocinador en esta situación.
Encuentra las suposiciones ocultas en mi juicio,
y dime qué acción debería verificar primero desde la perspectiva del PMI en forma de pregunta.
No me digas la respuesta correcta de inmediato para que pueda juzgar de nuevo.
```
### Uso de NotebookLM
Reuní los cuadernos de errores y materiales de repaso que organicé en NotebookLM y los utilicé para encontrar temas recurrentes dentro de los materiales.
- Resumir únicamente las mentalidades que fallaba con frecuencia
- Repasar las situaciones ágiles (Agile) y predictivas (Predictive) por separado
- Comparar temas confusos como la gestión de cambios y la gestión de conflictos
- Crear una lista corta de repaso para verificar justo antes del examen
Si se mezclan varios materiales, resulta difícil comprobar qué criterios se utilizaron para responder. Por lo tanto, me centré en materiales oficiales con fuentes claras y notas que revisé directamente.
No recomiendo introducir las preguntas de Study Hall directamente en la IA y verificar los errores únicamente mirando las respuestas seleccionadas por la IA. Las preguntas del PMP dependen en gran medida de diferencias sutiles entre las opciones y del contexto de la situación. La explicación de la IA también puede ser errónea, por lo que debes verificarla directamente basándote en materiales y explicaciones oficiales.
## Lo que aprendí de las puntuaciones del 60% en Study Hall
Mis puntuaciones fueron de 66% y 65% en los Full Mocks, con un promedio general de aproximadamente 62%. Mirando solo estas puntuaciones, es posible que desees retrasar el examen. Yo me sentí igual.
Sin embargo, como resultado, las siguientes tres cosas fueron más importantes que la puntuación:
- ¿Está disminuyendo el número de preguntas falladas por la misma razón?
- ¿Puedo explicar el proceso de juicio sin memorizar la respuesta?
- ¿Puedo mantener la concentración durante el tiempo del examen real?
Por supuesto, mi puntuación no puede ser un estándar de aprobación para todos. Las puntuaciones de Study Hall y los resultados reales del examen varían según el individuo. Sin embargo, quiero decir que no es necesario negar toda la preparación solo por el simple número del 60% medio-alto.
El error no fue un veredicto de que "no estoy listo", sino **una pregunta que creó la posibilidad de acertar una vez más antes del examen real**.
## Conclusión de la Parte 1
El mayor cambio durante las 7 semanas fue el orden en que se miraban las preguntas, más que la cantidad de conocimiento memorizado. Poco a poco me familiaricé con verificar la situación antes de actuar de inmediato, hablar antes de cambiar a las personas y analizar el impacto antes de realizar cambios.
En el próximo artículo, registré mi experiencia desde el momento en que ingresé al centro de exámenes Pearson VUE, cómo se vio afectada mi concentración al dedicar 80 minutos a las primeras 60 preguntas, el descanso de 10 minutos, los bocadillos y estiramientos, hasta la gestión del tiempo en la sesión final.
**Continuar leyendo:** [Reseña de aprobación del examen PMP Parte 2: Gestión del tiempo el día del examen y consejos finales para aprobar](/es/posts/pmp-pass-review-part-2)
---
# Mi manera de registrar la vida
> Documento el trabajo, los proyectos, los viajes, la comida y mis propios pensamientos. Este blog es un cuaderno de trabajo personal para organizar experiencias y errores del pasado, con el fin de tomar mejores decisiones en el futuro.
_Slug: built-slowly-updated-daily · Sat Feb 07_
Mi manera de registrar la vida
Trabajo como gestor de proyectos (Project Manager).
Mi trabajo consiste en organizar calendarios, identificar problemas y coordinar opiniones de diferentes personas para obtener un único resultado. Quizás por eso, a menudo me encuentro pensando de una manera similar en mi vida diaria.
Organizo lo que quiero hacer y luego lo ejecuto. Si los resultados no son los esperados, analizo las razones y pienso en qué cambiar para la próxima vez. Hay muchos días en los que las cosas no salen como las planeé, pero a través de ese proceso, voy construyendo poco a poco mis propios estándares.
Comencé este blog para capturar esas experiencias.
Comparto lo que aprendo mientras trabajo, los ensayos y errores por los que paso durante los proyectos, y los temas sobre los que reflexiono al crear nuevos servicios. También documento historias más personales, como los lugares que descubro en mis viajes, la comida que me dejó una buena impresión y las ideas que me vinieron a la mente en esos días.
Cada tema puede parecer diferente, pero al final, todo son cosas que he vivido de primera mano.
No quiero dejar solo historias de éxito ordenadas. Quiero registrar honestamente por qué fallaron los planes, qué partes fueron más difíciles de lo esperado y aquellas decisiones que parecían las mejores en su momento pero que luego resultaron ser lamentables.
Registrar las experiencias asegura que no se desvanezcan simplemente con el tiempo.
Me permite recordar qué decisiones tomé bajo qué circunstancias y me ayuda a hacer mejores juicios cuando me enfrento a problemas similares. Si mis pensamientos cambian con el tiempo, esa misma evolución se convierte en otro registro valioso.
A largo plazo, mi meta es dirigir una empresa propia y hacerla crecer hasta convertirla en un negocio con un valor de más de 1 millón de dólares.
Aún estoy en las etapas iniciales y hay muchos detalles por definir. Así que en lugar de mostrar solo un resultado terminado, planeo dejar el registro del proceso hacia esa meta. Documentaré constantemente lo que intenté, lo que salió mal y lo que cambié después.
Este blog no es un espacio para grandes historias de éxito.
Es más bien un cuaderno de trabajo de un proyecto personal para evitar olvidar las cosas que experimenté en el trabajo y en la vida diaria. Es suficiente con que sea un registro que me permita entender mis pensamientos y decisiones cuando lo vuelva a leer en el futuro.
En lugar de empezar cuando todo esté perfectamente preparado, planeo ir registrando las cosas una a una a partir de ahora.