Qué cambió en mi trabajo después del PMP: más que el certificado, mi forma de hablar

En el artículo anterior hice un plan de 60 PDU para mantener el PMP durante tres años. Entonces, ¿vale la pena mantener esta certificación? Hoy respondo a la mitad de esa pregunta: la que tiene que ver con el trabajo.

En tres líneas — Lo que cambió el PMP no fue tanto cuánto sé, sino el orden en que hago las cosas. Ahora uso las mismas palabras con el mismo significado, evalúo antes de actuar ante un incidente, recibo los cambios por escrito y pregunto por el valor más que por los entregables. Eso sí: aprobé hace menos de tres meses, y un certificado no hace el trabajo por ti.

Primero, dónde trabajo

Hoy trabajo como Global Tech PM en Concentrix. Me encargo de implementaciones y mejoras de comercio electrónico en ShopifyShopifyUna plataforma de comercio global que aloja tiendas digitales y físicas, apoyando traducciones localizadas, pagos y aplicaciones personalizadas.Read More → y Magento para clientes corporativos, y me ocupo de todo el recorrido: ordenar prioridades, gestionar riesgos, la UAT (pruebas de aceptación de usuario), los lanzamientos de versiones y la estabilización justo después de la puesta en marcha.

Trabajo con los equipos de la sede central de los clientes, sus filiales en cada país, proveedores globales y equipos técnicos en el extranjero. Para dar una idea de la escala: me encargué de mejorar un SaaS generador de PDP (páginas de detalle de producto) para un grupo global de belleza y de extenderlo a 5 marcas y 27 sitios de comercio electrónico. Es una estructura en la que una sola decisión se propaga a la vez por varias marcas y varios países.

Antes fui Software Development PM en Hyperhire, a cargo de proyectos web, de apps, SaaS y blockchain. Los desarrolladores con los que trabajaba estaban en India, Pakistán, Indonesia, Nigeria y Etiopía. Cinco países, y cada uno con su zona horaria.

En entornos así, creo que los proyectos se tuercen más a menudo por las palabras que por la técnica. Por eso, casi todo lo que cambió después del PMP tiene que ver con las "palabras" y el "orden".

Por cierto, todo esto ya lo hacía antes de obtener el PMP. El certificado no cambió mi trabajo; lo que fue cambiando poco a poco es la manera de hacerlo.

Lo primero que cambió fueron las palabras

Como PM, ya usaba palabras como scope, change request o risk mucho antes del PMP. Pero al estudiar para el examen, los límites entre ellas se volvieron mucho más nítidos. Estas son las cinco que hoy distingo a propósito en reuniones y correos globales:

Término	Lo que quiero decir	Por qué lo distingo
Scope (alcance)	Lo que acordamos hacer esta vez, y lo que acordamos no hacer	Si no dejas por escrito también lo que "no se hará", más adelante las versiones no coinciden
Change Request (solicitud de cambio)	Una solicitud formal para cambiar el alcance, el cronograma o el costo acordados	Aunque parezca pequeño, si tiene impacto, debe decidirlo quien tiene la autoridad
Risk (riesgo)	Algo incierto que aún no ha ocurrido, pero podría ocurrir	Permite planificar una respuesta con antelación
Issue (incidente)	Algo que ya ocurrió y que está afectando ahora	No necesita un plan, sino resolverse e informarse
Acceptance Criteria (criterios de aceptación)	Las condiciones para dar un entregable por "terminado"	En la UAT separan el "parece que ya está" del "ya está"

De todas, la que más me ha servido es la distinción entre riesgo e incidente. "This is a risk" y "This is an issue" envían señales completamente distintas a quien escucha. La primera dice "preparémonos"; la segunda, "actuemos ya". Si las mezclas, el otro no sabe cuánto debe preocuparse.

Cuando personas con distintas lenguas maternas trabajan en inglés, una palabra precisa vale por un párrafo entero. Y como el PMP es un examen que se rige por el mismo estándar en todo el mundo, estas palabras funcionan casi como una lengua común: una de las pocas que se entienden igual aunque cambien el país y la empresa.

Ante incidentes y cambios: primero evaluar, primero dejarlo por escrito

Siendo sincero, mi instinto en el trabajo es "arreglarlo ya". Mientras estudiaba, los fallos que más se repetían en mi cuaderno de errores iban justo en esa dirección: elegir una solución antes de encontrar la causa y ejecutar antes de analizar el impacto.

La lista de audios en coreano que generé con NotebookLM mientras estudiaba cuenta lo mismo. Dos títulos contienen la expresión "실무 본능" (instinto práctico) y otros dos, "PM도 틀리는" (que hasta los PM fallan). Lo que escuchaba camino al trabajo trataba, al final, de la brecha entre el instinto del día a día y la respuesta correcta del PMP. Cómo los creé y cómo los escuchaba lo cuento en la Parte 7.

La lista de resúmenes en audio en coreano que generé con NotebookLM mientras estudiaba para el PMP, en junio de 2026. "Instinto práctico" y "que hasta los PM fallan" aparecen dos veces cada uno en los títulos.

Cuando estalla un incidente

En el comercio electrónico, los incidentes llegan sin avisar. Supongamos que, justo después de un lanzamiento, empiezan a llegar consultas por errores en el paso de pago. Mi instinto es mandarle de inmediato al equipo de desarrollo un "¿Pueden revisarlo?".

Ahora, antes de enviar ese mensaje, anoto primero tres cosas:

1. Impacto: quién está afectado, dónde y cuánto. ¿Todos los países o un medio de pago concreto?
2. Naturaleza: ¿es un incidente que ya está ocurriendo o un riesgo que todavía es solo una posibilidad?
3. A quién avisar y quién decide: quién tiene que saberlo y quién debe tomar la decisión.

Anotarlo lleva unos minutos. Esos minutos evitan que el equipo de desarrollo busque donde no es, y hacen que el cliente y yo veamos el mismo panorama.

Claro que hay excepciones. Si se cayó todo el sistema de pago, primero se recupera y después se evalúa. Como escribí en la Parte 1, la mentalidad PMP también tiene excepciones que exigen actuar de inmediato, como un riesgo urgente. Aun así, cuanto más urgente es la situación, más me esfuerzo por no saltarme el paso de comprobar "hasta dónde y por qué".

Cuando llega una solicitud de cambio

En los proyectos de mejora de e-commerce llegan solicitudes pequeñas todo el tiempo: el texto de un botón, un filtro, un país más. Cada una parece mínima, pero no son pocas las que terminan tocando QA, traducciones y la UAT de cada país.

La gestión de cambios también fue una de las áreas en las que más fallaba al estudiar. En la lista de arriba incluso hay un audio titulado "현업 PM도 틀리는 PMP 변경관리 함정" (la trampa de la gestión de cambios del PMP en la que caen hasta los PM en activo, 23:34). Como dice el título, es un área en la que, si respondes guiándote por el instinto del día a día, es fácil equivocarse.

Por eso ahora, cuanto más pequeña es la solicitud, más evito darle el visto bueno solo de palabra. Como mínimo, dejo registradas estas cinco líneas:

[Solicitud de cambio] p. ej.: añadir un banner con información de envío en la página de detalle de producto
1. Solicitud: quién la pidió y por qué
2. Impacto: cronograma / costo / alcance / calidad (repetir QA y UAT) / riesgo
3. Opciones: incluirlo en este lanzamiento / pasarlo al siguiente / no hacerlo
4. Quién decide: quién lo aprueba
5. Decisión: qué se decidió y cuándo

Es el mismo orden que el examen PMP da por correcto: analizar el impacto, obtener la aprobación por el proceso formal y, si se aprueba, actualizar el plan y comunicarlo. Al principio a veces me preocupa parecer quisquilloso. Pero cuando queda un registro, a la persona de contacto del cliente le resulta mucho más fácil explicar el cambio dentro de su propia organización. Una solicitud de cambio protege al PM, y también a la persona del lado del cliente.

Preguntar por el valor, no solo por los entregables

En mi lista de audios también hay uno titulado "버그 없는 프로젝트가 인수를 거절당한 이유" (por qué rechazaron en la aceptación un proyecto sin bugs). El título ya es una pregunta: si no tenía bugs, ¿por qué lo rechazaron? La respuesta que yo leo en él es esta: se construyó lo que se había acordado, pero no se le dio al cliente lo que de verdad quería conseguir.

En el trabajo de PM es fácil confundir entregables (outputs) con resultados (outcomes). "Hicimos el lanzamiento" o "la funcionalidad ya está en producción" son entregables. La razón por la que el cliente pagó viene después: que la operación sea más sencilla, que sus clientes compren con más facilidad, que los sitios de varios países funcionen con el mismo criterio.

Por eso, ahora, cuando recibo requisitos, añado una pregunta más:

Cuando esto salga a producción, ¿quién podrá hacer qué mejor? ¿Y cómo lo vamos a comprobar?

Y luego reviso si esa respuesta quedó reflejada en los criterios de aceptación de la UAT. No es lo mismo una UAT que solo verifica que la funcionalidad responde que una que comprueba también el resultado que se buscaba desde el principio.

El PMI se ha movido en la misma dirección. El esquema del contenido del examen (ECO) del PMP renovado en 2026 usa tal cual la definición de proyecto de la 8.ª edición de la Guía del PMBOKPMBOKProject Management Body of Knowledge: Una colección de procesos, mejores prácticas, terminologías y pautas compiladas por el PMI.Read More →: "una iniciativa temporal en un contexto único, emprendida para crear valor". En el dominio Process se añadió una tarea nueva, "Help ensure value-based delivery" (ayudar a garantizar una entrega basada en el valor), y el peso de Business Environment subió del 8% al 26%. Todos los cambios los resumí en la Parte 5.

Proveedores y equipos offshore: apoyar más que controlar

Lo confieso: en mi resultado del examen, el dominio People salió Below Target. Me da un poco de vergüenza escribir que "cambió mi forma de tratar con la gente" cuando justo ahí saqué la calificación más baja de los tres dominios.

Aun así, el patrón detrás de mis errores en las preguntas de People estaba claro: escalar a los superiores antes de hablar con el equipo, o querer cambiar a alguien antes de entender la causa. La respuesta que busca el PMI es justo la contraria: el PM no está para controlar al equipo, sino para apoyarlo y quitarle obstáculos del camino.

Esa mirada sirve todavía más con equipos que pertenecen a otras organizaciones y trabajan en otras zonas horarias. Los proveedores globales con los que trabajo hoy no son mi equipo directo: trabajan para otras empresas, bajo otros contratos. En mi etapa en Hyperhire trabajaba con desarrolladores de cinco países, cada uno en su zona horaria. Con equipos así, creo que el liderazgo de servicio (servant leadership) empieza por preguntar "¿qué está frenando el trabajo?" antes que "¿por qué se retrasó?".

Los obstáculos que un PM puede quitar son más concretos de lo que parece:

• Requisitos ambiguos: responder las preguntas antes de que pase un día entero, o conectar enseguida con quien pueda responderlas.
• Decisiones pendientes: dejar resuelto lo que necesita aprobación del cliente antes de que empiece la jornada del otro equipo.
• Permisos y entornos: ocuparse de lo que un desarrollador no puede resolver solo, como permisos de acceso, datos de prueba o el entorno de staging.
• Prioridades cambiantes: resumir en una línea qué va primero y compartirlo.

Apoyar no significa bajar la exigencia. Al contrario: dar criterios de aceptación claros desde el principio es el mayor apoyo que puedes darle a un proveedor. Pocas cosas desgastan tanto como trabajar sin saber qué hay que construir para que algo cuente como "terminado".

Saber elegir entre lo predictivo y lo ágil

Los proyectos de comercio electrónico corporativo en los que he trabajado son, por naturaleza, bastante híbridos. La fecha de lanzamiento y el presupuesto suelen aprobarse y fijarse de antemano, y la UAT y los lanzamientos tienen que pasar por puntos de control definidos. En cambio, las solicitudes de mejora posteriores al lanzamiento y el backlog operativo cambian de prioridad constantemente.

Lo que me dejó estudiar para el PMP es una forma de ver lo híbrido: no como "un poco de cada cosa", sino como "el resultado de elegir qué usar y dónde". En un proyecto de e-commerce, por ejemplo, se podría repartir así:

Gestionar con enfoque predictivo	Llevar con enfoque ágil
Fecha de lanzamiento, presupuesto, alcance contratado	Backlog de mejoras y sus prioridades
Calendario de UAT y criterios de aceptación, aprobación de lanzamientos	Desarrollo por sprints y demos
Orden de despliegue por país	Atención de incidentes de estabilización tras el lanzamiento

El examen PMP renovado en 2026 también dedica alrededor del 40% a enfoques predictivos y el 60% a enfoques ágiles (adaptativos) o híbridos. En la 8.ª edición del PMBOKPMBOKProject Management Body of Knowledge: Una colección de procesos, mejores prácticas, terminologías y pautas compiladas por el PMI.Read More →, la adaptación (tailoring) ya no figura en la lista de principios, pero las pautas de adaptación siguen ahí. Yo lo leo así: la adaptación no es un eslogan, sino una decisión que tomas todos los días.

Cambió una línea de mi currículum, pero…

Después de obtener el PMP, cambié la primera línea de mi currículum por "PMP® | Global Project Manager".

El correo que confirma que obtuve el PMP, recibido de madrugada el 4 de julio de 2026 (hora de Corea). Indica que la insignia digital de Credly llega aparte, por correo, en una o dos semanas.

En la colaboración global, creo que esas tres letras funcionan como una breve presentación. Para un contacto de la sede central o un proveedor extranjero que te conoce por primera vez, el PMP se lee más o menos así:

• Tienes experiencia liderando proyectos durante un periodo mínimo (36 meses con título universitario, y el PMI además audita solicitudes al azar)
• Estudiaste el mismo vocabulario y el mismo marco de decisión que define el PMI
• Sigues aprendiendo, porque para mantener la certificación hay que sumar 60 PDU cada tres años

Pero, siendo honesto, todavía es pronto. Aprobé en julio, así que mientras escribo esto no han pasado ni tres meses. Por eso no incluí en este artículo ni una sola historia de "lo que conseguí gracias al certificado". Tres meses es muy poco tiempo para contar algo así.

Y un certificado no hace el trabajo por ti. Las cifras de mi currículum (por ejemplo, que el backlog operativo de un cliente global de electrónica de consumo bajara de 104 a 48 elementos y que el tiempo de resolución de incidentes se redujera un 27%) no las produjeron tres letras. Salieron del trabajo diario. El PMP solo me dio un lenguaje un poco más preciso para explicar ese tipo de trabajo.

El certificado abre la conversación. Lo que la mantiene viva, al final, es el trabajo.

En el próximo artículo voy a ir un paso más allá: defender que esta forma de pensar es todavía más potente para quienes no son PM, es decir, para desarrolladores, diseñadores o profesionales de marketing. Y si te interesan el salario y la contratación, en la Parte 14 lo repaso con cifras y ofertas de empleo reales de Corea.

Siguiente: El PMP puede valer más para quien no es PM

Preguntas frecuentes

¿Obtener el PMP cambia tu trabajo de inmediato?+

Nada cambia en el momento en que recibes el certificado. En mi caso, lo que cambió fue que el orden de decisión que practiqué para el examen se convirtió en hábitos de trabajo: evaluar el impacto antes de actuar ante un incidente, recibir las solicitudes de cambio por escrito y preguntar por el valor más que por los entregables. Eso sí, lo cuento cuando aún no han pasado tres meses desde que aprobé.

¿Es cierto que las respuestas del PMP no coinciden con el instinto práctico?+

En parte, sí. El instinto del día a día tiende a arreglar y decidir rápido, mientras que las preguntas del PMP suelen pedir primero entender la situación y analizar el impacto. Pero ese orden también me resultó útil en el trabajo. Hay excepciones que exigen actuar de inmediato, como una caída total del sistema de pago, así que es mejor entender el porqué que memorizarlo como una fórmula.

¿Sirve el PMP si trabajo en un equipo ágil?+

El examen PMP renovado en 2026 dedica alrededor del 40% a enfoques predictivos y el 60% a enfoques ágiles (adaptativos) o híbridos. Si tu proyecto es híbrido y combina una fecha de lanzamiento fija con mejoras basadas en un backlog, te ayuda a tener un criterio para decidir qué partes gestionar de forma predictiva y cuáles llevar con un enfoque ágil.

¿Cómo pongo el PMP en mi currículum?+

Yo cambié la primera línea de mi currículum por PMP® | Global Project Manager. Aun así, creo que la experiencia en proyectos que aparece debajo importa más que el nombre de la certificación. El certificado abre la conversación, y lo que la mantiene es la experiencia.

Fuentes

• PMI: información oficial sobre el PMP
• PMP Examination Content Outline 2026 (PDF)
• Blog del PMI: el cambio del examen PMP (10 de julio de 2026)
• PMI: Guía del PMBOK®
• Manual CCR del PMI: requisitos para renovar la certificación (PDF)