Aprende gestión de proyectos: planificación y ejecución de proyectos con Microsoft Project y JIRA

1. Introducción a la clase magistral PM: Según el PMI, el Instituto de Gestión de Proyectos, para 2027, buena necesidad del empleador 87.7 millones de individuos que trabajan en los roles orientados a la gestión de proyectos. Estas extensiones de empleo están lideradas por los siguientes sectores, manufactura y construcción, servicios de información y atención sanitaria, industria del petróleo y gas, finanzas, seguros, empleos, y muchos más. Hay muchos caminos para convertirse en gestor de proyectos y no hay un enfoque correcto o incorrecto. manera anual, los empleadores necesitarían 2.2 millones de profesionales que trabajaran en la industria de gestión de proyectos entre ahora y los próximos siete años. Por lo que hay muchas oportunidades para que sobresalga en la carrera de gestión de proyectos. En promedio, un gerente de proyecto hace algún lugar entre $65 a $220 por hora, lo que equivale a alrededor 100 mil a 200 mil por año. Hola, soy Nikhil. Si PMP y CSM 75 Profesional de Gestión de Proyectos. Me alegra que hayas revisado este curso online y no puedo esperar para empezar. La clase está repleta de mucha información. Y actualmente estoy trabajando en una de las empresas Fortune 100 en Estados Unidos. Y he mentorizado y entrenado a muchos gerentes de proyectos a lo largo de mi carrera. Y esta es la primera vez que comparto mi industria dentro del conocimiento, mi experiencia como gerente de proyectos y programas aquí en la comunidad online, me alegra que estés aquí para ganarlas conocimiento que he adquirido hasta mi mandato como gestor de proyectos en la última década, sobre múltiples fracasos y éxitos. He adaptado este curso online de una manera que incluso si eres un gestor de proyectos con experiencia o un principiante, independientemente de dónde estés en tu trayectoria profesional actual, ganarías la conocimiento que sería capaz de aplicar en su carrera de gestión de proyectos. Inmediatamente después de completar este curso, podrá comprender plenamente los fundamentos de la gestión de proyectos, procesos de gestión de proyectos, herramientas, técnicas, y cómo gestionar con éxito . Obtendrá una buena comprensión de cómo utilizar la herramienta de gestión de proyectos, como el proyecto JIRA y MS. Puedes usar la herramienta adecuada para tu proyecto. Podrás usar estas herramientas con confianza y podrás impresionar a tus grupos de interés y equipo. Podemos conocimientos y pericia. También aprenderá sobre las habilidades blandas que necesitas como gestor de proyectos. Cómo realizar un seguimiento y preparar el informe de estado, cómo crear unas presentaciones impresionantes cuando se tiene que presionar en su administración superior y estado y plazos y más. También aprenderás sobre los certificados de gestión de proyectos estándar de la industria que agregan valor a tu asunción y cómo puedes prepararte para esos exámenes. También te compartiré consejos sobre prepararte para tu próxima entrevista de trabajo de gestión de proyectos. Qué preguntas esperar y cómo responderlas. Bueno, si todo esto te suena interesante, entonces toma el control de tu carrera y el curso. Te veré por dentro. 2. Qué es un proyecto: Hola, En esta lección vamos a echar un vistazo a la definición del proyecto. Qué es un proyecto. Un proyecto es de naturaleza temporal, lo que significa que tiene una fecha definida de inicio y fin. Un proyecto crea un resultado o servicio único. Entonces si nos fijamos en algo que se está fabricando, que ellos línea de fábrica, eso no es un proyecto porque continuamente está repitiendo los pasos para producir lo mismo. Entonces si el proyecto nunca produce lo mismo una y otra vez, va a producir algo único y puede ser servicio o producto. Ahora, proyecto va a completar la obra en algún momento. Completar la palabra no significa que el proyecto esté completo. Podríamos completar el proyecto porque nos quedamos sin dinero tiempo o algo más. Podría ser que el alcance del proyecto ya no sea válido y tengamos que cerrar el proyecto. Entonces en cualquier momento, proyecto definitivamente va a terminar independientemente del servicio, ya sea entregado o no, todo el producto se crea o no. Recuerda estos tres puntos. Y ahora echemos un vistazo a la definición de PMI. El Instituto de Gestión de Proyectos. El proyecto es un empeño temporal emprendido para crear un producto, servicio o resultado único. Así que ahora veamos un ejemplo de operaciones de un call center por la propia palabra. Revela que es una operación y no un proyecto. El motivo por el que un call center es una operación y no un proyecto es porque no tiene inicio y fin. Se va a configurar una vez y los clientes van a llamar a ese call center día tras día. Por lo que no hay fin a ese proceso. Entonces eso es una operación. Ahora echemos un vistazo a otro ejemplo. Pintar una habitación. ¿ Es esto un proyecto o un conjunto operativo? Entonces la respuesta es, este es un proyecto porque ese es un alcance definido, que se define como pintar tu hogar. Por lo que va a terminar una vez finalizada la pintura, tiene una cronología definida donde podrán completar la pintura en una semana o un mes. Hay un inicio y un fin para pintar un hogar. Por esas razones, es un proyecto que puedes tomar cualquier cosa que veas en el día a día y analizar si se trata de un proyecto u operaciones. Simplemente recuerda los tres viñetas que proyectan definitivamente es a corto plazo, lo que significa que tiene una fecha de inicio y fin. A corto plazo no significa que seis meses, podría ser tal vez diez años, pero definitivamente hay un inicio del año uno y terminando un oído diez. Entonces por esa razón va a ser un proyecto. Si, si ese proyecto produce un resultado o servicio único, entonces fluido que liberando su un proyecto y definitivamente se va a completar en algún momento del tiempo. No va a ser continuo y repetitivo. Esa es una buena definición de un proyecto y cómo se puede identificar un proyecto. 3. Qué es la gestión de proyectos: En esta lección, vamos a enfocarnos en la gestión de proyectos que pueda aprender sobre lo que es un proyecto en la clase anterior. Así que hoy echemos un vistazo a lo que es una gestión de proyectos. Así que voy a cambiar al modo de diapositiva y me pondré en la esquina. Entonces echemos un vistazo a la definición. gestión de proyectos es el proceso de liderar el trabajo de un equipo para lograr las metas del proyecto dentro de las limitaciones dadas. Por lo que hablaremos de las limitaciones en un minuto. Pero la primera sección es bastante sencillo. Es el proceso de liderar el trabajo de un equipo. Por lo que obviamente como gerente de proyecto, tienes un equipo que estaría haciendo el trabajo real. Y como líder de gestión de proyectos o PM, estarías liderando ese esfuerzo para asegurarte de que se logren los objetivos del proyecto. Pero echemos un vistazo a cuáles son las limitaciones de las que estamos hablando. El primero es obviamente el alcance. Es decir, echemos un vistazo al proyecto que discutimos en la clase anterior, que es pintar tu casa. ¿ Cuál es el alcance del proyecto? Si alguien pregunta, el alcance es pintar el interior y exterior del hogar. Incluso puedes ir en detalle en el alcance e idealmente tu ****, porque interior y exterior es un alcance muy vago, de alto nivel. Pero quieres sumergirte profundamente en volver a pintar las paredes, están repintando la puerta. Estamos pintando el techo para que pueda aumentar o disminuir el alcance. Si quieres bloquear siempre tu alcance, pero tienes una opción para actualizarlo más adelante. Pero estas son las limitaciones que aquí estamos hablando que impactarían en el proyecto si no se mantienen bien, se manejan bien. Echemos un vistazo a la siguiente restricción, que es el costo. Entonces, ¿cuál es el presupuesto para hacer este cuadro? ¿ Tienes $5 mil o tienes $10 mil? Entonces, ¿cuál es el costo para completar este proyecto? Por lo que depende completamente del cliente, o digamos que eres el cliente y estás buscando pintores para hacer el trabajo, tendrías una cantidad fija de dinero que has dejado de lado para completar la obra. Podría ser $1000.100000000000. Una vez que empieces a conseguir las canchas, entonces podrías volver a visitar el alcance y decir, solo tengo 1 $1000. Entonces no pintemos el exterior. Vamos a cortarlo al interior. Por eso estas limitaciones dependen el uno del otro. Entonces vamos a echar un vistazo con un ejemplo en un minuto aquí. Pero veamos el siguiente que es horario. El horario no es más que la línea de tiempo. Entonces, ¿cuánto tiempo tienes para completar este trabajo? Ben, ¿necesitas que este trabajo de pintura sea hecho por dos? Lo necesitas antes de la próxima semana o lo necesitas para fin de día de hoy? Porque si el horario o la línea de tiempo no es flexible que el costo puede subir. Digamos que quieres que alguien complete el cuadro hoy, entonces puede ser posible. Puede que no sea posible. A lo mejor alguien tiene 20 personas vienen y completan todo en un día. Es bastante posible, pero entonces estás pagando por 20 personas en lugar de si tienes un mes para completar el proyecto. Y tal vez solo puedas pagar a una persona y hacer que lo haga en 20 días más o menos. Obviamente estos dependen el uno del otro. Y si alguno de estos cambios, puede impactar en la calidad del proyecto. Por lo que hay que mantener o administrar su alcance, costo, y horario. Y en el mundo de la gestión de proyectos, escucharía esto como triple restricción, un proyecto limitaciones. Por lo que esto es muy básico y siempre escucharás en el mundo de la gestión de proyectos como las triples limitaciones. Por lo que hay que entender que están hablando ya sea de alcance, costo, y línea de tiempo o de los tres. Porque si alguno de ellos cambia durante la duración del proyecto, definitivamente impactará en la calidad del proyecto. Porque si quieres pintar tu casa y digamos solo tienes 1000 pavos. Así que tal vez alguien que le guste calificada o menos experiencia puede venir y hacer el trabajo, pero tal vez no va a ser tan ordenado como usted está pagando a alguien para llegar a casa pintada profesionalmente. Entonces eso es justo. Puedes relacionar estos ejemplos son ocasionados horario de pliegues de puntuación a pintar tu casa. Como ejemplo fácil de recordar, veremos en detalle en un ejemplo aquí en la pizarra. Así que déjame saltar a la Pizarra aquí. Digamos que tengo que pintar sólo una habitación. Tienes cuatro muros. Entonces tu escuela es de cuatro muros. El cuarto tiene puerta. Entonces ¿quieres pintar la puerta más el techo? Entonces cuando tienes esto como tu alcance, digamos que solo tienes presupuesto como 500. Y hay que hacer esto en una semana. Digamos que la primera cita que recibiste es, vale, no puedo hacer este muro de 400 dólares. Sólo por la pared. Después se convierte en 400 para la pared, más 100 para la puerta, más 50 para el techo. Por lo que obviamente 400 más ciento quinientos. Por lo que este costo es de 550, que está por encima de su presupuesto de 500. Entonces bajaste el costo y dices, oye, no necesito que se haga el techo. Esto ahora impactó la calidad. Por lo que tienes una habitación ordenada, techo sucio. ¿ Eso tiene sentido? Entonces así es como se puede ver gestión de proyectos y la triple restricción como ejemplo aquí, cualquiera de las restricciones cambia como el costo, un horario o alcance, entonces va a impactar el proyecto de una forma u otra. Entonces como ejercicio de clase, quiero que mires y pienses en algún otro proyecto que tienes en tu hogar y veas cómo manejarías tu costo escolar y cronología para manejar ese particular proyecto o yo chicos, así que eso es todo por esta clase. Vamos a atrapar en la próxima clase, que va a ser metodologías de gestión de proyectos. Hablaremos de las diferentes metodologías disponibles que se practican en común en estos días. Y vamos a echar un vistazo a cuáles son esos. Muy bien, así que vamos a terminar esta clase y te veré en la siguiente. 4. PMO: Un PMO es oficina de gestión de proyectos. Alguna organización podría tener PMO y algunos pueden no serlo. La idea general de su oficina de gestión de proyectos es establecer directrices y proporcionar a los gerentes de proyectos para ejecutar un proyecto o varios proyectos. Si tienes una oficina de gestión de proyectos en tu organización. Por lo que la PMO proporcionaría que lineamientos en cuanto a qué los KPI y cómo se debe medir, los indicadores clave de desempeño. También tendrían un proceso en marcha para solicitar gerentes de proyectos para diferentes proyectos dentro de su organización. Y esos gestores de proyectos formarán parte de la oficina de gestión de proyectos de PMO. Se asignarán al proyecto para llevar a cabo ese proyecto. Y una vez que lo habían hecho, regresan a PMO y luego repiten ese ciclo. Si su organización tiene una oficina de gestión de proyectos, normalmente es ahí donde se establecen la mayoría de los procesos, cómo se rastrearon los KPI y cómo se rastreó el proyecto. Todos los lineamientos y capacitación serán proporcionados por la oficina de la PMO. Y como gestor de proyectos, quienes se reporten a PMO deben seguir los lineamientos de la oficina de gestión de proyectos que se establecen. 5. Metodología de gestión de proyectos: Chicos, bienvenidos de nuevo a la clase. Echemos un vistazo a las metodologías de gestión de proyectos. Por lo que principalmente hay dos metodologías importantes en las noticias, sobre todo en el software, es ágil. Agile se puede utilizar en todas las industrias, pero está obteniendo mucha tracción en el lado del desarrollo de software. Agile y Waterfall son las dos metodologías primarias que hoy existen. Echaremos un vistazo a ambos. Las dos metodologías principales que vamos a cubrir hoy son gestión de proyectos de cascada y la metodología de gestión de proyectos ágil. Entonces hablemos primero de cascada. Podría estar familiarizado con este gráfico. Está en la industria desde hace tantos años y se han completado tantos proyectos utilizando cascada. Todavía hay organizaciones que se están ejecutando ágiles siguen metodologías de cascada para cierto tipo de proyecto. Y vamos a echar un vistazo cada uno de esos en la sesión de hoy. Para que como se puede ver en el nombre y el diagrama aquí, cascada es muy secuencial. No se puede saltar de un paso a otro. Como casi realmente. Hay que completar la primera fase y luego pasar a la segunda fase, como se puede ver en el gráfico aquí. Por lo que comienza con la planificación de proyectos en la parte superior. Ahí es donde comienza todo. Por lo que la planeación se hace por primera vez y siempre hay una manera de ajustar el plan. Y como sabemos más, siempre podemos modificar el plan. Pero en metodologías de cascada que se considera Como un enorme dolor de cabeza porque hay mucho papeleo involucrado en cambiar el plan de alcance, cosas así en cascada. Si tienes un alcance predefinido y no va a cambiar, entonces cascada es ideal. Pero si no estás seguro lo que va a ser este proyecto, ¿cuánto es el esfuerzo? Y sólo se puede saber más a medida que hace más cosas de lo que la caída puede no ser la opción. Y ahí es donde entra en juego el Agile. Pero hablaremos de lo ágil en un minuto. Vamos a pasar por las diferentes fases en el modelo de cascada. Entonces el primero en la parte superior, como se puede ver aquí, es la fase de planeación del proyecto. Esa es la fase en la que observamos los requisitos del proyecto, qué hay que hacer, cuánto va a costar en el alto nivel, ¿qué recursos se requieren? Por lo que vamos a echar un vistazo a todos aquellos en la planeación del proyecto luego viene la fase de requerimiento. Entonces en requerimiento, miramos un requisito detallado por parte del patrocinador o del cliente y lo revisaremos y haremos preguntas y lo refinamos antes de saltar a las siguientes fases, queremos asegurarse en el modelo de cascada que se recoja el requisito tanto como podamos antes de proceder a los siguientes pasos. Porque una vez que iniciamos el proyecto, entonces típicamente implica conseguir los recursos reservados o bloqueados por cierta cantidad de tiempo. Por lo que es muy difícil cambiar. Siempre es un esfuerzo más doloroso en metodología de cascada para cambiar el recurso o cambiar el alcance y el costo y cosas por el estilo. Por eso es muy crítico reunir tanta información como podamos durante la fase de requerimiento para que no tengamos que cambiar mucho en las caras que se ve para seguir. Una vez hecho el requisito, entonces pasamos al análisis. Se dedicará a esta materia expertos en esta fase. Y echa un vistazo al requisito ver cómo podemos llegar a una solución. que ese requisito podría ser que necesito construir un puente a través de este río y tiene dos millas de longitud y tienes un Carlin de cuatro bits o cualquiera que sea el requisito. Dependiendo del requisito, el experto en materia haría el análisis y elaboraría lo que es lo mejor que podemos hacer por este conjunto de requisitos una vez hecho el requisito. Por lo que típicamente el análisis y el diseño se combinan en una sola etapa. Es solo documentar cuál es el enfoque que vamos a tomar para entregar este requisito, para entregar el producto final basado en el requisito, este es nuestro análisis y así es como lo haríamos diseñar la solución para entregar los productos. Entonces es ahí donde se combinaron las etapas de análisis y diseño, típicamente en el proyecto. Y es muy crucial para el equipo de diseño o el equipo de desarrollo, que aquí se demuestra como codificación. Si no es un proyecto de software, entonces podría ser el desarrollo real, lo que sea que estemos construyendo, esa fase constructiva. Ahí es donde el diseño y análisis es clave porque el producto se construye a partir del diseño. Entonces si te equivocas el diseño, entonces. Y nada puede salir mal en el desarrollo según fase. Una vez hecho el desarrollo, entonces el desarrollador o quien esté construyendo ese producto, harían la prueba unitaria, lo que significa que harían las pruebas básicas para ver si cumple con eso requisito mencionado en la segunda fase. Y también cumple con los documentos de diseño. Entonces una vez hecho eso, lo entregarían a pruebas, que sería un grupo independiente de personas porque están tan enfocadas en la solución y el resultado y no en busca a través de las lagunas. Entonces ahí es donde entraría el equipo de pruebas y harán una prueba de extremo a extremo. Si serían pruebas funcionales, pruebas integración, y todo tipo de pruebas diferentes que tenemos. Para que eso se hará en la fase de prueba. Una vez realizada la prueba, el cliente está satisfecho con el resultado, luego desplegamos en producción o entorno en vivo. Si tenemos que tomar un ejemplo de un sitio web. Entonces la planeación del proyecto incluiría, vale, qué, ¿qué debería servir el sitio web? ¿ Necesita un login y qué tipo de clientes van a entrar en este sitio web. Entonces eso se hace todo en la planeación del proyecto y la sesión de requisitos lo detallaría sobre qué método usar para verificar el inicio de sesión. ¿ Cuáles deben ser las credenciales? ¿ Deberían usar nombre de usuario y contraseña? ¿ Necesitamos alguna otra información del usuario, cosas así? Una vez que eso se define durante la fase de análisis y diseño es donde se realizaría el diseño del sitio web, incluyendo la funcionalidad. Y en base a ese diseño, entonces el desarrollador, desarrollador web desarrollaría un sitio web y estaría listo para probar. Daremos ese producto al cliente para que haga algunas pruebas adicionales, incluyendo las pruebas alfa y beta. Y una vez que todo se ve bien, está listo para ir a la predicción. Entonces firmarían y desplegaríamos el entorno de producción en vivo. Pero así es típicamente como funciona una metodología de cascada. Y estos pasos se siguen uno tras otro. Muy bien, así que ahora echemos un vistazo al proceso Agile. Así que déjame moverme de derecha a izquierda para que puedas ver la pantalla. Muy bien, creo que eso es mucho mejor. Agile es típicamente un proceso iterativo que es Scrum y Kanban en ambos casos, es mejora continua. Ese es el lema primario de Agile. lo que la razón ágil entró en vigor es, como se ve en cascada, tenemos una limitación de que si la fase de análisis de diseño sale mal, entonces obviamente el resto del rostro va a caer aparte. Y es un proceso que consume mucho tiempo volver atrás y arreglar las cosas. En Agile, la idea es que entregemos temprano o fracasemos temprano, decir, al inicio del proyecto, tendríamos información limitada, por lo que comenzaremos el proyecto con esa información. Y a medida que aprendemos más, tenemos una opción para mejorar e iterar y construir mejores productos. Entonces ese es todo el concepto de Agile. Si miras el círculo 12345, verías que todas las diferentes fases que tenemos en cascada, en realidad se hace en Agile, pero en piezas más pequeñas. Por lo que el primero es la planeación y priorización. Segundo es requisito. Tercero es diseño y análisis, implementación a revisar. Entonces todos estos cinco pasos son exactamente los mismos que la cascada. Pero que cinco pasos son el proceso central se hace para la pieza muy pequeña del rompecabezas. Lo que significa digamos que si estás construyendo un sitio web, así que primero construiremos una página en blanco. Y eso es todo. El aplicado la página en blanco y ver si se renderiza y tienen los colores correctos, y cosas por el estilo. Entonces básicamente la planeación sería, quiero una página en blanco con un fondo blanco. Entonces, ¿se puede hacer? Pasará por los requisitos de planeación, desarrollo y pruebas, y si se hace, para que se haga el negocio. A continuación, veremos la página de inicio de sesión y diremos, Ok, ahora quiero introducir nombre de usuario y una contraseña y luego ver si valida las credenciales y el usuario pueda iniciar sesión. Eso volvería a pasar por los requisitos, análisis, pruebas de diseño y despliegue. Por lo que el ciclo continúa hasta que todas las piezas pequeñas se ponen en su lugar, entregamos un valor menor lugar de todo el proyecto como un despliegue de big bang. Entonces ahí es donde Agile es más eficaz. Porque si algo anda mal, entonces podemos identificarlo por primera vez. Y esa es una oportunidad para que el equipo rectifice eso antes de liberar el Big Bang. Por lo que esas son las dos metodologías de gestión de proyectos, cascada y ágil. Junta tiene su propio lugar en el mundo de la gestión de proyectos. Pero en estos días, cada vez más industrias y organización prefirieron tener ágiles porque TI ágil es muy ágil rápido y el equipo puede adaptarse muy temprano y muchas veces entregar mejor resultados que cascada en metodología de cascada, cuando te des cuenta que algo está mal, será demasiado tarde. Considerando que en Agile, porque estamos entregando componentes más pequeños, Producto Mínimo Viable o lo que sea el mejor valor que el usuario pueda obtener. En una etapa muy temprana, entonces los clientes están satisfechos así como el equipo recibe retroalimentación que se puede incorporar a la posterior construcción y lanzamiento. Por lo que esas son las dos metodologías destacadas de gestión de proyectos. Y en la siguiente lección, vamos a echar un vistazo a los liderazgos mueren y el estilo de gestión de proyectos para cada una de esta metodología. Porque como gerente de proyecto, liderarías el proyecto completamente diferente en Waterfall versus Agile. Y Cascada, Es una regla muy comandante frente a una ágil. Es más es el liderazgo de sirvientes. Echaremos un vistazo al estilo de mando o liderazgo en la siguiente lección o en el siguiente capítulo. Y nos fijamos en la autoridad de liderazgo para cascada y ágil. que eso concluya esta lección y saltaremos a la siguiente lección para mirar estilo de liderazgo y la autoridad. 6. Ceremonias de gestión de proyectos: En la clase anterior, miramos los estilos de liderazgo y hoy vamos a echar un vistazo a las ceremonias tanto en cascada como ágiles. Esto debería darle un ejemplo, una idea de por qué ciertas autoridades de liderazgo se ejercen en Cascada versus Agile. Así que déjame mostrarte esta presentación de diapositivas aquí. En cascada, tal y como miramos en la clase anterior, tenemos un jefe de proyecto con mando autorizado que está explicando al equipo qué hacer, no necesariamente cómo, sino cuándo hacerlo y entender esa razón, hay que mirar las ceremonias. Por lo que en un proyecto típico de cascada, tendrías grandes reuniones en las que tendrías múltiples participantes asistiendo a la reunión de status. Si miras los detalles del equipo en una cascada, veces tendrías clientes que se unieran a la reunión. Tienes tu equipo de productos, tu equipo de proyecto. En ocasiones debe haber un patrocinador del proyecto atendiendo a la convocatoria o un cliente. Por lo que hay múltiples grupos grandes de personas que se unen a una llamada. Podrían tener interés en piezas más pequeñas dentro del proyecto, pero no como un proyecto general. Por supuesto, tu cliente y patrocinador tiene la idea de completar el proyecto o el alcance que te pidieron completar. Pero podría haber otro equipo multifuncional dentro del equipo más grande donde estén participando para hacer ciertas tareas en el proyecto. Por lo que podrían no estar completamente al tanto de tu proyecto o no interesarte en el proyecto completo. Entonces por eso el gerente del proyecto tiene que estar en una posición dominante para controlar la reunión, para asegurarse de que se discutan las cosas y solo se discuten las cosas que son relevantes. Por lo que tiene que tomar el control. Tiene que estar a cargo para asegurarse de que el resultado que el equipo del proyecto y yo digo PM, lo que él o ella está buscando que se logre desde la reunión. ceremonias típicas en cascada incluyen la reunión semanal de status donde el equipo del proyecto discutiría el estado. El gerente del proyecto miraría el riesgo y problemas y vería si algún riesgo o problema necesita ser manejado en este momento en las decisiones discutir se iniciará sesión, y si hay algún otro cosas que hay que comunicar, esas cosas surgirán durante la reunión de status. D controla una reunión de estatus de extremo a extremo. Entonces por eso tiene que ser autoritario. Ahora echemos un vistazo a la próxima ceremonia, que es una ágil. Y típicamente, como hemos visto en la clase anterior, Agile Scrum Masters son líderes sirvientes, lo que significa que son más como un facilitador. Entonces, ¿por qué es ese el caso? Porque en ágil, más que reunión de status, es stand-up diario donde el equipo viene colaborativamente y se gestionan en las tareas que están trabajando. No necesitan mucha aportación del maestro de Scrum porque es un equipo autogestionado y saben qué hacer y cómo hacerlo. Entonces si miras a este equipo de cram, tienes Propietario de Producto, Equipo de Desarrollo, y Scrum Master. Por lo que es un equipo central que se centra en un solo motivo que es el alcance del proyecto para completar ese proyecto, por lo que no hay disrupción como tal. Entonces Scrum Master no tiene que ser autoritario ni mandante para cuidar nada porque es tu equipo central. No tienes que preocuparte por controlar lo principal. Es sólo coaching al equipo para asegurarse de que sean autogestionados. Para que en pocas palabras, es la razón por la cual el jefe del proyecto versus combusted todo tiene que ejercer su poder autoritario mandante de una manera diferente por la naturaleza de la metodología que está en uso en la gestión de proyectos, eso es algo que hay que tener en cuenta al ejecutar Cascada versus Agile. Ahora, en próxima clase vamos a echar un vistazo a los diferentes frameworks dentro de Agile, los dos más utilizados una vez o Scrum y Kanban. Y veremos cómo usan esos dos y cuál es la diferencia. 7. Gobernación de proyectos: De acuerdo, así que ahora echemos un vistazo a la gobernanza del proyecto por definición, la gobernanza del proyecto es el marco de gestión dentro del cual se toman las decisiones del proyecto. Quisiera agregar que los convenios del proyecto es el marco y la estructura sobre la cual se va a ejecutar este proyecto en particular para que todos en el equipo tengan una misma idea, misma comprensión de qué hacer cuando por definición, la gobernanza del proyecto es el marco de gestión dentro del cual se toman las decisiones del proyecto. Lo que eso significa es cómo se ejecutará este proyecto. ¿ Cuál es la estructura general? ¿ Qué aspecto tiene el equipo? ¿ Cómo nos comunicamos el uno con el otro? ¿ Qué pasa cuando tenemos un problema? ¿ Cómo escalamos un tema? ¿ Qué pasa cuando se van a tomar decisiones? ¿ A quién se debe abordar para tomar decisiones? ¿ Quién es la autoridad para tomar esas decisiones para el proyecto? ¿ Cómo obtenemos aprobaciones? ¿ Qué pasa si hay un cambio en los artistas del proyecto cambian el trabajo de gestión quién es responsable de qué? Por lo que básicamente está estableciendo una gran directriz para todo el equipo del proyecto. Entonces todo el mundo tiene muy claro cuál es su responsabilidad y rendición de cuentas. Y algunas de las cosas que haces como parte de la gobernanza del proyecto es matriz RACI. El RACI no es más que un gráfico donde se enumera a cada miembro del equipo individual y los marca como responsables, responsables , consultados o informados. Entonces, si alguien tiene que hacer el trabajo real, serían los responsables de ello. lo que nunca ejemplo del proyecto del sitio web, las personas que son responsables de diseñar la página web o de los desarrolladores finales amigos. Entonces cuando se tiene una tarea de proyecto y el plan que dice diseñar la página web front-end. Por lo que entonces asignarías ese desarrollador web como el responsable. Como gestor de proyectos, te marcarás como responsable de esa misma tarea. Y entonces tendrías el equipo de diseño que entregó el diseño a ese desarrollador. Estarían marcados como consultados y todos los demás actores de proyectos quedarían marcados como en PharmD. Por lo que en cualquier momento dado, cada línea de rubro en tu plan de proyecto, es bueno tener un RACI responsable, responsable , consultado e informado para que cada parte del proyecto sepa qué ellos son responsables, quién es responsable de ello, y quién debe ser consultado si tienen preguntas, y quién debe mantenerse en la fuente. Eso es realmente crítico definir como equipo y entender y llegar un acuerdo que estas son las responsabilidades del proyecto y así es como vamos a gestionar el equipo y ejecutar el proyecto. A continuación se encuentran las aprobaciones. Entonces digamos que tienes un presupuesto más y planeas gastar 100 mil dólares, pero ahora tienes que tener un 150 mil. ¿ Cómo establecería trabajos de aprobación? Quién aprueba ese presupuesto extra y cuando el proyecto golpeó esas cosas, entonces sabes exactamente cómo conseguir las aprobaciones y avanzar. En lugar de averiguarlo en el momento de la ejecución, entonces tienes comunicación que es muy crítica. ¿ Cómo se comunica entre equipo, dentro y fuera del proyecto y todo eso. Por lo que en la lección posterior, vamos a echar un vistazo a sitios de colaboración y cómo se configuran los antes del proyecto fuera para que el miembro del equipo tenga un lugar donde puedan almacenar documentos, pueden comunicarse y todo eso. Entonces hay que definir también el compromiso de las partes interesadas, cómo se reportaría el estado del proyecto, ¿cuántas reuniones asistir? ¿ Cuáles son las reuniones críticas? ¿ Quién debe asistir a esas reuniones? ¿ Cómo se toman las decisiones? ¿ Quién debe estar involucrado en la toma de decisiones? Todo eso combinado, esa es la gobernanza del proyecto. Entonces una vez que desarrolles este proyecto lineal se va a un buen comienzo porque ahora tienes unas pautas adecuadas. Así que piénsalo como tú y tus amigos yendo a una noche de cine. Entonces teniendo un buen plan delante que vamos a llamar a Uber, vamos a llegar a las exhibiciones y luego de ahí vamos a conseguir los boletos. Cenarán afuera, todas esas cosas diferentes. Entonces todo el mundo está algo alineado en lo que tiene que pasar cuando llega esa noche de cine, día. puede pensar en el gobierno como similar a eso, para ponerlo de una manera fácil aquí en algunos casos, si no tiene un PMO, la oficina de gestión de proyectos, entonces tal vez tenga que configurar esto por sí mismo. Nuestro amigo en cierta organización hay oficina de gestión de proyectos PMO. Tendrían plantillas estándar para cada uno de los ítems discutidos aquí, como aprobaciones racy, Reunión, plantillas, y formato. Para que puedas pedirle al equipo de PMO que te proporcione todas las plantillas y puedas reutilizarla. Pero aunque no lo tengas, es solo definir cómo van a pasar estas cosas, documentarla y compartirla con el equipo para que todo el mundo esté alineado antes de que comience el proyecto. En ocasiones podrían ser requisitos del comité directivo. Comité Directivo podrían ser los líderes que estén interesados en su proyecto. Podrían tener una cartera de proyectos. Digamos que están trabajando en una implementación digital más amplia de la organización. Y tu proyecto de página web es solo uno de los proyectos. Por lo que en general, quieren conocer toda la cartera bajo la implementación digital y el proyecto de página web siendo uno de ellos. Podrían tener requisito específico de que presiones en el estado del proyecto y a fin de mes. Tales cosas también tendrán que definirse para que todo quede envuelto en torno a la gobernanza del proyecto. Y se define por primera vez antes de que se inicie el proyecto, puedes descargar las plantillas para cada uno de estos ítems enumerados aquí para que consigas una mejor comprensión de lo que significa y cómo se ve como en un proyecto del mundo real? 8. Herramientas comunes de gestión de proyectos: Ahora que tenemos una buena comprensión de la cascada y la gestión ágil de proyectos, ahora echemos un vistazo a las diferentes herramientas que utiliza el gerente de proyecto o scrum master para proyectos de cascada y ágiles. Así que déjame saltar a la presentación de diapositivas aquí. Por lo que al administrar un proyecto de cascada, el gerente del proyecto está utilizando principalmente herramientas que le ayudan a planificar y crear informe de estado, así como mostrar dependencias y flujo de trabajo. Así que empecemos desde arriba. Entonces el primero es Microsoft Visio. Visio es una herramienta utilizada por los gerentes de proyectos y diseñadores para mostrar la dependencia en formato de carril de natación. Puedes mostrar diagrama y cosas diferentes en fisios y eso es muy útil para mostrar cuáles son las dependencias del proyecto, cómo se ve el flujo de trabajo. Aquellos que son externos al proyecto. Entienden un cuadro de muy alto nivel. Y vizio es una poderosa herramienta para demostrar que la segunda TI más utilizada en la dendrita superior izquierda, que es PowerPoint y Excel. En la mayoría de los casos, los gerentes de proyecto prefirieron crear plan y proyecto MS, pero es una herramienta tan compleja que una vez que desarrollas el plan cuando hace algunos cambios sutiles, es difícil mantener eso planta, por lo que la gente prefiere ir con excelente lugar y también es fácil compartir el Excel luego MS Project porque si la otra persona no tiene licencia y no pueden abrirla y entenderla. Como PM, tienes una buena manija en el proyecto MS, pero para otros dentro del equipo, una mejor manera de mirar el plan y una línea de tiempo sería Excel. Excel también se usa para manipular datos, crear tablas dinámicas y analizar datos, cosas por el estilo. Entonces Excel se usa mucho en un proyecto de cascada. Si miras el informe de estado y otras cosas que tienes que presentar como gerente de proyecto. Ahí es donde se utilizan los documentos PPT y Word. Si tienes que documentar el flujo de trabajo o anotar el proceso, ahí es donde entra la palabra. Pero hay que hacer un informe de estado o hacer una presentación ante el liderazgo. Ahí es donde se utiliza el Microsoft PowerPoint. Aparte de eso para almacenar todos estos documentos, solía ser SharePoint en el pasado. Ahora la mayor parte de la organización se ha trasladado a Microsoft en 18. Y en algunos casos podrían ser Google, OneDrive, y muchas otras cosas donde se almacenan todos estos artefactos del proyecto. Y estas son las principales herramientas utilizadas para cascada como gestor de proyectos. En algunos casos para análisis detallado de bases de datos y cosas por el estilo. Microsoft Access también se utiliza como herramienta, pero en casos muy raros. Ahora echemos un vistazo a la Agile. En Agile, las dos herramientas primarias de uso común, nuestra Jira y Confluencia. Jira es tu tablero donde se mantienen las notas adhesivas y sprints y el atraso de productos. Y Confluence es similar a SharePoint donde se toda la documentación relacionada con mantiene toda la documentación relacionada conesa junta directiva de Jira. Aparte de la confluencia GLN, el equipo o el Scrum Master también utilizan cualquier herramienta que sea buena para la planeación retrospectiva y también para la estimación. La herramienta que se utiliza comúnmente para apuntar historias es la planificación del póker. Echaremos un vistazo a los que más tarde en la clase. Pero estas están en el alto nivel, las herramientas generales utilizadas por el gerente de proyectos o scrum master para la gestión y ejecución de proyectos. 9. Gerente de proyectos VS Scrum: Muy bien, entonces en la clase de hoy, vamos a hablar estilos de liderazgo en la gestión de proyectos. Hay principalmente diez estilos de liderazgo diferentes, pero la clase de hoy lo vamos a basar fuera del jefe de proyecto frente al rol maestro de Scrum. Para que puedas entender mejor cuando estás manejando un proyecto de cascada, qué tipo de autoridad de liderazgo heredes frente a cuándo estás haciendo un papel maestro de Scrum, qué tipo de rol de liderazgo deberías o qué tipo de rol de liderazgo debe ejercer? Entonces echemos un vistazo al rol de gerente de proyecto y el rol maestro de Scrum y veamos cómo el liderazgo difiere en ambos roles. Entonces soy un firme creyente que una imagen representa más que palabras. Entonces, para el gerente de proyecto, así es como típicamente se comporta un gerente de proyecto. Es que tiene plena autoridad y control sobre el equipo. Él comunica su ese centro cae entre el equipo, el cliente, el patrocinador de las partes interesadas y todo el mundo, ¿verdad? Por lo que se convierte en el único obligado a dirigir a todos para que logren los objetivos del proyecto. Entonces eso es lo que ves en la imagen donde el gerente del proyecto está encima. Está anunciando el micrófono, ¿qué hay que hacer? No necesariamente cómo, pero él pone el escenario para el equipo. Por lo que el equipo tiene la mayor responsabilidad ejecutar en la tarea. Pero como gerente de proyecto, tiene más poder de mando, tiene más autoridad si no está haciendo nada del equipo o del equipo multifuncional. Tiene la capacidad de escalar y obtener ayuda. Está más en el control que en el equipo. Ahora echemos un vistazo a la foto para ScrumMaster. Aquí. El ScrumMaster es más como un líder sirviente. Es entrenador y facilitador más que el poder comandante que el gerente del proyecto ha rasgado el ScrumMaster es más como un entrenador y está guiando al equipo sobre cómo y qué hacer y el equipo tiene que controlar. Para que como se puede ver, el maestro scrum está llevando la carga para asegurarse de que el equipo pueda progresar bien y eliminando impedimentos. Por lo que ahora también hablaremos de las ceremonias que tenemos en la gestión de proyectos en cascada. Echemos un vistazo a la izquierda donde el gerente del proyecto tiene reuniones de status donde pasará por el status y no necesariamente está resolviendo el problema, Pero está más cobrando el estatus y la comprensión de cuál es el tema. Siempre se puede tratar de resolver el tema. Pero en la mayoría de los casos en cascada, él o ella desde el equipo necesita comunicarse con el gerente del proyecto sobre qué ayuda se requiere. Y el gerente de proyecto tiene el mando y el control sobre el equipo. Y si alguien no está haciendo el trabajo, puede escalarlo o puede resolverlo por su poder de mando. Por otro lado, es algo parecido, pero ScrumMaster es más como un facilitador en un standup diario, su estatus de no coleccionismo. Nuestro maestro está más tratando de facilitar las cosas principales para que el equipo pueda auto y manejar la tarea. Y el Scrum Master está ahí para entender si el equipo está haciendo buenos avances y si tienen un impedimentos Bell, necesitan maestros ayuda para resolverlo para ellos principalmente, yo diría que el rol de gerente de proyecto en cascada es más como ver al equipo y continuamente pidiendo estatus y su seguimiento en un maestro de sistemas. Depende del equipo sobre cómo hacerlo y qué hacerlo. Gran Maestro está tratando facilitar el progreso general del proyecto. Y ayuda al equipo a entender si hay algo que esté parando de hacer ese progreso y puede ayudar a resolver esos temas. Por lo que tanto la intención está bien, hacer que el equipo haga el trabajo y elevar cualquier tema. Pero el ScrumMaster se parece más a un líder sirviente frente al gerente del proyecto es más como, Hey, autoridad al mando. Si nos fijamos en otro ejemplo de cómo va esta reunión en la cascada, la gestión de proyectos, el gerente de proyecto decide qué prioridad de tarea y asignará al encargado del proyecto asignaría al equipo. De acuerdo, estos están priorizados y supieron caminar sobre él. En tanto que en la Agile, el equipo surge con la prioridad dependiendo de lo que el propietario del producto haya priorizado con base en que ese equipo prioritario pueda decidir en qué quiere trabajar. Ellos pondrían al día a este gran maestro que estoy trabajando en esto y así es como está progresando. Entonces esa es la diferencia entre un líder sirviente de este lado de los grandes maestros frente a un jefe de proyecto comandante y autorizado. Por el lado de las cascadas, es solo una forma diferente de ejecutar el proyecto para avanzar en el proyecto. Entonces ese es un estilo de tiro rápido de liderazgo tanto en cascada como en metodología ágil. En la siguiente clase, vamos a mirar en detalle en la ceremonia es que cada una de esta metodología de gestión de proyectos tiene Cascada versus gramo. Y lo que un gestor de proyectos típicamente decimal cascada y lo que hace un ScrumMaster por un proyecto ágil. 10. Agile SCRUM y KANBAN: De acuerdo, en esta clase vamos a echar un vistazo a los marcos Scrum y Kanban utilizados en metodología ágil. ¿ En qué se diferencia y cuándo usar qué? Por lo que primero vamos a echar un vistazo al Scrum Framework. Scrum framework, si recuerdas la clase anterior discutimos sobre iniciar, planificar, ejecutar, monitorear, y controlar y cerrar el proyecto. Y en el marco de Scrum, es un repetido varias veces. Entonces por eso es un enfoque iterador donde todas las fases de gestión de proyectos se repiten varias veces a lo largo del framework Agile Scrum, y se repite durante el cuadro de tiempo en diablo llama print. Puedes tener un sprint de una semana o hasta cuatro semanas. Y típicamente la mayoría del equipo del proyecto ejerce un sprint de dos semanas donde es suficiente planificar y hacer las cosas. Y al final de la hebra, hay que hacer ciertas ceremonias. Por lo que una semana será para marear para la mayoría de los equipos. Normalmente lo que hemos visto en la industria es que la gente va de dos a tres semanas de primavera, mayoría del equipo haciendo tres semanas y algún equipo haciendo en dos semanas, si se trata de apoyo de predicción, incluso podrían ir por un sprint mensual, que es un sprint de cuatro semanas. Y a finales de mes pueden hacer el ciclo de lanzamiento. Entonces cualquier producto que desarrollaron o mejoras que hayan hecho que se pueden liberar a la producción a finales de ese mes. Ahora echemos un vistazo a esta diapositiva más cerca y pasemos por cada una de esta imagen y lo que significa. Muy bien, por lo que partiremos desde la izquierda e iremos hacia la derecha. Por lo que primero a la izquierda se puede ver al propietario del producto. El propietario del producto es quien interactúa con el cliente o el cliente y recoge todos los requisitos y lo pone en el atraso. Backlog tiene toda la lista de deseos del propietario del producto y propietario del producto refina continuamente el backlog para priorizar los artículos que necesitan ser entregados primero. Entonces cualquier requisito en el que el equipo tenga que trabajar, tienen atraso de producto como referencia y por lo general el equipo puede recogerlo desde la parte superior del atraso porque así es como el propietario del producto debe priorizar los requisitos en el Registro de Producto. Todo lo que necesite ser entregado temprano viene por encima, y cualquier cosa que pueda retrasarse o entregarse más tarde que vaya en la parte inferior del atraso. Ahora veamos si el equipo ha decidido trabajar en ciertas cosas y eligen cinco artículos de la parte superior de la cartera de productos. Eso sucede durante la reunión de planeación sprint. El propietario del producto, el equipo, y el Scrum Master hicieron durante esta reunión de migajas y planean los artículos para los que quieren trabajar. Digamos que en este caso, un equipo tiene un sprint de dos semanas. Verán en qué pueden trabajar durante las próximas dos semanas. Por lo que recogerán tal vez cinco artículos de la cartera de productos y acordarán trabajar en esos. Entonces durante ese picking, estimarían cuánto diamante se va a llevar. Y eso se basa en la experiencia. Y más adelante en la clase discutiremos sobre apuntar historias y cuán efectivo es ese método, cómo usar la planificación del poker y cómo el equipo madura a medida que pasan por múltiples sprints. Pero por el momento, sólo entiende que el equipo puede escoger las tareas que piensan que pueden terminar en las próximas dos semanas. Y eso entra en un atraso de sprint. Si hay 50 artículos en la cartera de productos, eligen los cinco primeros y bajando a algo llamado backlog sprint. Y durante la reunión de planeación, si el dueño del producto del equipo y el maestro scrum está de acuerdo en la escuela, entonces inician ese sprint para las próximas dos semanas. Una vez que se inicia un sprint, entonces el equipo hizo diariamente para mirar dónde están, discutir sobre lo que están haciendo, lo que han hecho, y cualquier impedimento que necesite ayuda con. Y eso continuará durante las próximas dos semanas lo largo del final de este sprint y al final de este sprint, el equipo podrá tomar ganancia por revisión sprint y para demo el ítem terminado al producto propietario. Eso es típicamente el Scrum Framework, y esto se repite hasta que se los requisitos del producto de la etiqueta final completenlos requisitos del producto de la etiqueta final en el registro de producto. Podría tomar múltiples sprints para completar el atraso en profundidad. Al finalizar el último sprint es donde el equipo tendrá un producto terminado que sea totalmente funcional. Cuando nos fijamos en un ejemplo práctico práctico, comprenderías más sobre el backlog de productos, sprint, backlog, el sprint en sí. Y no te preocupes demasiado solo para entender diferentes terminologías en este momento. Y cuando hagamos un proyecto práctico, entonces tendrás más comprensión de cada uno de estos ítems. Y también veremos quemar y quemar carta abajo. Algo que no se menciona aquí es el gráfico de velocidad. Esas son métricas e informes que ayudan al equipo a entender cómo se desempeñan y qué necesitan ajustarse para entregar puntos de historia consistentemente similares. Muy bien, a continuación, pasar al marco Kanban. En el marco Kanban tenemos una junta directiva que es similar a la revuelta, pero no hay activos atrasados de primavera. Es una junta continua, por lo que tenemos un atraso de productos a la izquierda y luego equipo decide en qué necesitan trabajar y ponerlo en ToDo. Una vez que tengan ciertos ítems para ese mes en particular, comenzarían a escoger uno de la lista de tareas pendientes y comenzarían a progresar. Y en ese momento se trasladarán a en curso o en curso las garantías que se haga esa tarea. Se moverán a hecho. Y una vez que esté completamente hecho, se moverán a archivar o simplemente tachar como completo. Por lo que en este caso, el equipo tiene un límite. Solo pueden trabajar en cierto número de puntos de historia en un mes. Se puede pensar en Kanban como decir, sistema de venta de entradas. Entonces digamos que tienes un parque local. Si alguien tiene que entrar al parque, necesita conseguir un boleto. Y cuando salgan del bicho, repartirán ese boleto de vuelta al guardia de seguridad. En este caso, digamos que la capacidad del parque es de diez personas. En la puerta de entrada, el guardia de seguridad tendría diez boletos, lo que significa que no hay nadie dentro del parque y el parque y permitiría entrar hasta diez personas. Entonces piensa en la gente que ingresa al parque, pidió la tarea, ingresando al tablero una vez se entregan los boletos de entrada para diez personas, eso significa que él, el dios, no tiene más boleto para traspaso. Entonces cualquiera que espere en fila tiene que esperar hasta que salga una de las diez personas que están dentro del parque las diez personas que están dentro del parque para que cuando una persona salga, ese boleto se recoja de vuelta y se pueda dar a la siguiente persona. Cualquier punto de tiempo. Sólo podría haber diez personas dentro de la parte. Esa es la capacidad o límite del parque en Kanban es el mismo concepto. Tu equipo ácido tiene una capacidad que puedes entregar para ese periodo de tiempo. Digamos que su periodo de tiempo es de cuatro semanas o un mes. En un mes, puedes dejar decir, administrar diez puntos de historia desde el backlog, puedes recoger hasta diez artículos o diez puntos de historia que se pueden poner en lista de tareas pendientes. Y una vez que alcanza los diez, entonces ya no deberías estar recogiendo del atraso porque esa es tu capacidad para ese mes para el equipo. Entonces una vez que tengas la capacidad, entonces empiezas a hacer ese trabajo. Y eso entra en curso. Y Dan, después de que hayas completado tu primera tarea, entonces has liberado algo más de capacidad para que ese tiempo puedas ir a escoger de tareas pendientes y pasar a continuo y seguir haciendo estas cosas hasta allá no queda nada que hacer en ese momento, se puede volver al atraso y recoger más artículos que se puedan completar en la misma primavera o planear para el siguiente sprint. Entonces esa es la diferencia entre Scrum y Kanban, donde kanban se basa en limit, mientras que com se basa en eso no es límite. O el equipo realiza sprint después de Sprint, pueden mejorar y entregar más puntos de historia si es necesario. 11. Plan de gestión de alcance: Muy bien, por lo que en esta lección hablaremos sobre plan de manejo de alcances. Pero antes de saltar al plan de gestión del alcance, es importante saber que tenemos un plan general de gestión de proyectos. Por lo general, es posible que haya visto línea de tiempo del proyecto MS y la mayoría de las veces eso es solo un horario. Normalmente, no ponemos el alcance y otros planes de gestión de proyectos en el gráfico de Gantt porque se usa principalmente con fines programados. Así que permítanme hablar de los diferentes planes que tenemos en el plan general de gestión de proyectos. Y luego saltaremos al plan de gestión del alcance. Si comparto mi pantalla aquí, dirías que hay nueve planes de proyecto diferentes disponibles en el plan general del proyecto. Empezando con el alcance, el horario, el costo, la calidad, recurso, la comunicación, el riesgo, la adquisición y la gestión de partes interesadas. Todos estos planes combinados se denominan plan general de gestión de proyectos. Pero el 99% de la organización cuando están hablando del plan del proyecto, se están refiriendo a más probable es el plan de gestión del horario. Echaremos un vistazo al plan de gestión de horarios cuando lleguemos allí. Entonces en esta lección, primero veremos el plan de gestión de alcances en la fase de planeación de proyectos. Veamos a dónde pertenece en la planeación del proyecto. Es parte innovadora de la fase de planeación. Y lo que conlleva es en general los requisitos. Si piensas en un proyecto que obviamente es un requisito del patrocinador o de las partes interesadas, incluso antes de que el gerente del proyecto esté abordado, tienen una idea de alto nivel lo que querían. Digamos que quieren lanzar un sitio web donde puedan vender sus productos en línea. Entonces si ese es el requisito de alto nivel, entonces en el plan de manejo de alcances, una vez que involucres al PM o usaid PM, tendrías que profundizar en esos requisitos porque cuando un casos de negocios juntos, No está en el nivel detallado, es en un nivel superior lo que son las necesidades empresariales y en base a la estrategia que la organización quiere, el caso de negocio se agrupa a ese nivel. Cuando entras en la fase de planificación de proyectos es cuando tomas ese caso de negocio y luego haces una inmersión profunda en los requisitos. En una cascada, tendrías un analista de negocios o un arquitecto empresarial o alguien más para ayudarte con este proceso. De no ser así, hay que comprometerlos para obtener estos requisitos del negocio una manera muy detallada. Este es el documento o la salida del plan de gestión de alcance sería el que puedes compartir con tus desarrolladores son quien esté trabajando en desarrollar ese producto. Por lo que es muy crítico que entiendas cuál es el alcance del proyecto y en qué nivel necesitamos sumergirnos profundamente en la escuela para conocer el proyecto o el interesado o los patrocinadores requisito. El primer año es el requisito. Obviamente, es necesario encontrar una forma de cobrar los requisitos. Se reuniría con los expertos del lado empresarial. Digamos que la idea aquí es lanzar un sitio web para vender ese producto en línea. Por lo que irías con el equipo de mercadotecnia, equipo de ventas, y recogerías los requisitos de cada una de esas funciones. También tendría que reunirse con la financiación cómo se debe tramitar el pago, todo eso. Hay que pensar el proceso completo de extremo a extremo y definir el alcance de cada función. Ese es el segundo punto de viñeta aquí que una vez que identifiques el requisito, entonces define el alcance de las ventas. Estas son las cosas que vas a hacer para la comercialización. Estas son cinco cosas que harías o que estarían disponibles en el sitio web o en el producto. Después se descomponen esas cosas en componentes más pequeños y manejables para que el equipo pueda trabajar. Así que típicamente si se trata de un proyecto Agile, todo esto entrará en el atraso de productos y luego se puede desglosar en historias más pequeñas y manejables. Eso es todo. Esta sección es. Una vez que hayas hecho eso, entonces tenías que basarlo, lo que significa que ese es tu punto de partida. Entonces todo el mundo tiene que ponerse de acuerdo en ese punto de partida. Y luego desarrollarías una matriz de trazabilidad de requisitos que solo es necesaria si estás ejecutando un proyecto de cascada. Normalmente no haces esto en un proyecto Agile porque todo lo que tienes se pone en el atraso del producto. Y si hay cosas nuevas que vienen, entonces trabajarías con el propietario del producto para agregar eso al atraso de producto al final antes de saltar al alcance, aprobaciones, requisitos, trazabilidad, si tengo que darte en el nivel superior, lo que significa es simplemente mapear los requisitos que has recogido en el primer paso y mapearlo a tu solución, cómo se cumplirá ese requisito en el diseño y desarrollo. Entonces eso es lo que requisitos es la trazabilidad. Es solo tu documento de Word o un Excel para mostrar a las partes interesadas o al patrocinador que hemos atendido todos estos requisitos y así es como se cumplirá. Por lo que dice documento recto, incluso se puede hacer en un PowerPoint, no un problema. Aprobaciones de alcance es algo que una vez que tenga el requisito de base o la línea de base de alcance y todos los requisitos se asignan a los documentos de diseño apropiados y cómo entregaremos esos nuevos. Presentar eso de vuelta al patrocinador o al grupo de interés y decir Así es como vamos a hacerlo. ¿ Demuestra que esta es la etapa en la que también mencionarías sobre solicitud de cambio. Significa que si hay algún cambio en lo que hemos definido aquí o lo que hemos proporcionado como se llama línea de base, entonces tenemos que hacer una solicitud de cambio, significa que cualquier cambio adicional a la línea de base sería incurrir en costo, tiempo y esfuerzo. Entonces es mejor plantear eso lo que eso procesa. Por lo que en un nivel muy alto, plan de gestión de alcances se ocupa de los requisitos de recolección, desglosándolo en componentes manejables más pequeños, y baselenándolo como punto de partida y obtener las aprobaciones y alinear a todos para estar de acuerdo en que esto es lo que van a hacer porque ayudará en las próximas fases de la gestión de proyectos. Muy bien, así es como desarrolla el plan de gestión del alcance del proyecto. Simplemente asegúrate de haber identificado todas las áreas y todas las funciones las han incluido en el proceso de cobranza de requerimientos para que no te pierdas ninguna función en particular. Mientras lo hagas, será muy suave en la fase de ejecución posterior. Cuando tengamos que entregar el producto. 12. Reunificación de requisitos: Muy bien, bienvenido de nuevo. En la lección de hoy, echaremos un vistazo a la reunión de requerimientos empresariales. Esta no es necesariamente una función que debes hacer como gerente de proyecto, pero alguien de tu equipo debe hacerlo. Si se trata de un proyecto Agile, entonces típicamente lo hace el propietario del producto que trabaja con el cliente para entender cuáles son los requisitos del negocio. Si se trata de una metodología tradicional de cascada, entonces tendrías patrocinador de negocios y el analista de negocios de su equipo trabajando de cerca para entender el requerimiento del negocio y documentado para el proyecto. Entonces en esta lección cubriremos cuáles son los diferentes tipos de requisitos? ¿ Cuáles son las diferentes técnicas que se pueden utilizar para recoger los requisitos? Y también cómo los requisitos se descompondrán en componentes más pequeños para que puedas planificar en tu plan de proyecto para lograr esos requisitos de negocio tanto en cascada como en metodología ágil. Así que empecemos con los diferentes requisitos de negocio que tenemos que mirar. Muy bien, entonces cuando nos fijamos en las sesiones de reunión de requerimientos empresariales, siempre hay que tener en cuenta cuál es el objetivo del proyecto. De lo contrario, podría haber alcance fluencia, que es sólo el alcance adicional que puede entrar como parte de esta reunión de requisitos. Si alguna de las partes interesadas del proyecto tiene requisitos adicionales y si no estás seguro de si está alineado el objetivo del proyecto o los entregables, entonces debes plantarlo y luego volver a él más tarde, recoger todos los requisitos que puedas. Pero solo debes enfocarte en los que estén directamente relacionados con los objetivos del proyecto. Entonces para darte un ejemplo, digamos que estás migrando en antigua plataforma heredada a una plataforma moderna. Digamos que tiene todas sus aplicaciones bancarias o financieras en sistemas mainframe heredados. Y quieres migrar eso una interfaz moderna basada en la web. Podría haber limitación para que el usuario utilice el sistema mainframe para hacer algo. Digamos que querían dibujar algo en la pantalla, que no es posible en el sistema mainframe porque ese es un sistema anticuado. Y en la moderna solución basada en la web, posiblemente puedas hacer eso en iPad o iPhone. Pero ese no es un requisito que esté alineado con el proyecto llamado objetivo del proyecto es mover el requisito o las funciones de negocio de los sistemas heredados de mainframe a los modernos sistemas basados en la web. Por lo que si ese es el requisito, entonces todas estas características adicionales que los usuarios quieren, se pueden presentar esas para su posterior versión como para no combinarlo con los requisitos del proyecto porque lo hará aumentar el alcance del proyecto y no serías capaz de entregarlo a tiempo y dentro del presupuesto que tienes para el proyecto se dice que vamos a saltar a diferentes requisitos. Uno es el requisito de negocio. Estos son los requisitos básicos de la función empresarial. Ya sea un patrocinador o quien se esté beneficiando del proyecto, indicarían este requisito en la idea de negocio de chárter del proyecto, un caso de negocio. Y aquí lo que estamos haciendo es descomponerse en más detalle para que podamos planear. Hice nivel detallado. El ejemplo de requisito de negocio podría ser como una compañía de seguros, quiero migrar toda mi aplicación heredada una plataforma moderna basada en la web. Ese requisito existe afirmando que lo que estamos utilizando actualmente está funcionando, pero quisiéramos tener más características y queremos poder integrarnos con otras cosas. Por lo que añada el negocio Estados ese requisito ya que tiene que ser una solución basada en la web, no hay requisito técnico que tenga que desarrollarse en dotnet o Java ni algo más. Ahí es donde entran los requisitos técnicos. El requisito técnico podría ser que ya que nuestra oficina actual solo soporta solución de oscurecimiento, por lo que podemos hacer esto en red oscura, ¿verdad? Por lo que entonces limitaría o tomaría ese requisito comercial y diría, el lado técnico, utilizaríamos el framework dotnet para desarrollar este proceso. Entonces si hay que pensar en requisito técnico, un paso más profundo que requisito técnico podría decir que cuando el usuario inicie sesión, entonces debe ingresar sus credenciales, el nombre de usuario, y contraseña para iniciar sesión en el sistema. Pero el requisito técnico o funcional detrás eso podría estar en esa página, un usuario debe tener una opción para restablecer la contraseña, establecer cuestionarios de seguridad, y luego obtener un autenticación secundaria como un mensaje o algo en su teléfono. Esos son requisito puramente técnico o funcional que se relaciona con ese requisito general del negocio de que el usuario pueda iniciar sesión eosin algunas credenciales. Entonces así es como se desglosa el requisito del negocio frente a los requisitos técnicos. También podrían ser algunos requisitos legales que hay que mirar. Por ejemplo, ciertos países europeos podrían tener restricciones para compartir la información personal fuera de Europa. Por lo que hay que entender cuando se define la solución. ¿ Existe algún requisito particular que pertenezca a un país local o una región que deba ser considerado. Por lo que también hay que pensar en esos requisitos. Y aquí es donde se involucraría con las partes interesadas, patrocinador, y otros para entender cuáles son esos requisitos. Entonces ahora que entendemos cuáles son los diferentes tipos de requisitos empresariales, técnicos o legales, veamos cómo podemos cobrar estos requisitos? ¿ Cuáles son las diferentes técnicas que podemos utilizar para recoger cualquier requisito de este tipo, ya sea empresarial, técnico, o legal, principalmente, diría que de tres maneras diferentes para hacerlo, pero hay múltiples formas. Entonces echemos un vistazo a las primarias. El primero es la lluvia de ideas. Facilitas una reunión con todas las personas importantes que están utilizando el sistema o que son los usuarios del sistema y una lluvia de ideas la idea es lo que quieren en el sistema que están utilizando. Digamos que en el ejemplo de migrar del antiguo sistema mainframe al sistema moderno basado en la web, entonces puedes hacer una lluvia de ideas para entender cuáles son las características y funciones que los usuarios están utilizando hoy en la plataforma heredada. Y si necesitan ser migrados a la plataforma moderna, o es solo que están haciendo algo por la restricción que tienen con los sistemas heredados. Para que puedas tener sesiones de lluvia de ideas para desglosar aún más los requisitos. El siguiente es una reunión o entrevista uno-a-uno. Puedes tener una reunión uno-a-uno con los líderes funcionales, ya sea finanzas, logística, mercadotecnia, ventas. Cada uno de ellos tendría sus propios requisitos o sus propias características y funciones que actualmente están utilizando y le gustaría agregar en la nueva aplicación que se está desarrollando. Esas cosas salen cuando te encuentras con ellos uno-a-uno. Entonces para entender cuáles son las necesidades específicas cuando se trata de requisitos. Y el tercero es un taller de un día donde se puede tener un taller de uno o dos días para llevar a todas las partes y usuarios relevantes a una sola sala y luego reunir todos los requisitos. Entonces cuando interactúan entre sí, entenderían cuáles son las dependencias y podría haber requisitos adicionales que salgan de esa sesión. Esa es otra forma de mirar. Existen varios otros métodos distintos a estos tres primarios. Así que saltemos rápidamente a través de lo que son esos. Algunas de las otras opciones que tienes, un envío de una encuesta, puedes enviar una pregunta o lista de cosas que quieres entender como cuestionario o encuesta a las personas que están utilizando esta aplicación o quiénes estarían utilizando en un futuro para entender cuáles serían sus requisitos, qué les gustaría ver en el nuevo sistema que podemos recabar toda esa retroalimentación y ver si se alinea con el objetivo del proyecto. Y se puede incorporar eso como requisito de negocio. Otro tipo de recolección de requisitos es la observación de sombras o de los usuarios. Simplemente Shadow persona de TI que está usando el sistema actualmente, digamos en este caso el sistema mainframe heredado, para entender lo que están haciendo hoy y cuál es la salida o el resultado haciendo esa tarea, una vez que entiendas lo que hacen y cuál es el resultado de esa tarea, entonces se puede tener una solución. La plataforma moderna, cómo hacer lo mismo, tal vez de manera diferente, o incluso se puede automatizar eso por completo para que el usuario no tenga que hacer mucho. Que se haga automáticamente en el nuevo sistema. Entonces, por ejemplo, digamos en el sistema heredado tienen diez empleos que necesitan ser presentados manualmente, digamos para procesar ciertos artistas. Por lo que tuvieron que hacer uno a la vez. Por lo que se presenta el primer trabajo, luego el usuario lo espera, y luego una vez que se complete, entonces él o ella presenta el segundo trabajo. Entonces al sombrear u observar al usuario, se puede tomar esa nota hacia abajo lo que hacen y por qué lo hacen. Y entonces tal vez en la plataforma moderna, no tienes que hacer ninguna intervención manual de este tipo. A lo mejor se puede automatizar o programar los trabajos de una manera que en cierto punto de tiempo cuando se cumple el gatillo y el trabajo se inicia automáticamente. Y luego después de la finalización del trabajo, se activarán los trabajos posteriores. Para que puedas automatizar todo el proceso entendiendo cuál es el escritorio del usuario hoy y cuál es el resultado de esa tarea. Otra forma de captar el requisito es el análisis documental. Digamos que en el sistema actual tienen algún tipo de documento en cuanto a por qué se diseñan ciertas cosas o lo que ciertas cosas hacen como función. Entonces pasarás por ese documento y verás y entenderás lo que hace el sistema actual. Y esa puede ser su entrada para entender y definir en el nuevo sistema cómo debe manejarse. Entonces esa es otra forma de reunir requisitos y diseñar en el nuevo sistema. Otra forma de recolección de requisitos es el análisis de interfaz. El análisis de interfaz está mirando todos los trabajos y lotes y otras cosas que están interrelacionadas con el sistema actual, pero ya sea de entrada o salida. Y entender lo que están haciendo. Y luego se puede evaluar si esas interfaces lo son. Es necesario actualizar los sistemas aguas abajo o aguas arriba o el sistema moderno puede entregar algo diferente para esas interfaces. Entonces al mirar la interfaz que existe hoy en día, podría ser capaz de entender lo que esas interfaces escriben hoy en día. Y entonces eso se convierte en un requisito de negocio que necesita ser diseñado en el nuevo sistema. De acuerdo, por lo que hay muchas otras formas en las que puedes hacer requisitos como el prototipado, análisis de casos de uso, y qué pasaría si los escenarios, cualquiera que sea la técnica que utilices, eso no importa mientras tú recoger los requisitos y entender lo que necesitan las partes interesadas del proyecto de este nuevo sistema o del proyecto en el que estás trabajando. Entonces eso es lo que recolectamos en la sesión de recolección de requisitos, documentados y luego obtenemos firmar de los usuarios que esto es lo que vamos a hacer como parte del proyecto. Por lo que ahora echemos un vistazo en cascada y ágil cómo desglosaríamos desglosaríamos esos requisitos de alto nivel en tareas más pequeñas y manejables para que podamos asignar la duración y el esfuerzo. Entonces una vez que tengas un requisito de alto nivel, entonces puedes reunirte con el equipo para analizar más a fondo. Entonces si se trata de una cascada, entonces lo que harías es documentar todo eso en algo llamado BRD, que es el documento de requerimiento de negocio donde tienes todos los insumos de la diferentes sesiones que tuvo con el negocio y documentan lo que el negocio necesita, cuál debería ser el resultado, y cuál es la expectativa del usuario. Una vez documentado el requisito de negocio, entonces puedes entregarlo al equipo técnico que puedan desarrollar la solución técnica para ello. Por lo que típicamente el equipo técnico revisaría el BRD y crearían los puentes documentales de especificación de requisitos de software , solo mapeando el requisito de negocio y en el alto nivel, definiendo en el SRS cómo se entregarán técnicamente esos requerimientos de negocio dentro de esta hora, ya que podría tener diagramas de alto nivel para mostrar cómo el requisito empresarial de alto nivel se mapea y cómo se entregará. También podría tener diseño de bajo nivel desglosando aún más esos componentes de alto nivel desde el SLD en componentes de menor nivel. Y luego, por último, con base en LLDP, tendría estructura de desglose del trabajo, que es la tarea y actividad reales para realizar y entregar ese requisito de negocio. Una vez que tengas la WBS, entonces es más fácil como gerente de proyecto reunirse con el equipo y comprender el esfuerzo implica completar esa tarea en particular. Porque mirando el requisito general del negocio, es difícil para el equipo calcularlo. Pero si el equipo ha hecho un gran trabajo al descomponer los requisitos en componentes manejables más pequeños, entonces sería mucho más manejable y fácil para el equipo calcularlo con precisión. Entonces ahora echemos un vistazo a cómo se hará esto en Agile. En metodología Agile, todos estos requisitos serán capturados como historias de usuarios. El plantilla de historia de usuario que hemos discutido en las lecciones anteriores, documentaríamos en el producto o documento Nobu cuáles son las historias de usuario para el requisito empresarial, Sea cual sea la persona que sea el usuario, se puede decir como persona financiera o líder de proyecto de activos, quiero hacer esto para que yo pueda lograrlo. Entonces esa es la plantilla que normalmente se mapea o se crea en historias de usuarios para entender quién es la persona y qué están tratando de hacer para lograr qué resultado. Una vez que tengas las historias de usuarios, entonces puedes definir a los hombres. Esas historias de usuario serán entregadas. ¿ Va a ser en la versión una versión , versión a estrenar? Por lo que volverías a eso una vez que tengas todas las historias de usuario están identificadas en el backlog del producto, las versiones se pueden desglosar aún más en épocas. Y desde la época se puede definir tarea y luego sub-tarea, que es equivalente a la estructura de desglose del trabajo y a la metodología de cascada. Una vez que tengas un nivel épico de ADN y tarea, entonces es más fácil para el equipo señalarlo porque ahora es más manejable. Y se puede definir qué tarea y usa historias va en qué sprint. Y luego según eso, puedes mapearlo a la versión de liberada que quieras liberar esas historias de usuario al usuario. Por lo que esto es en un nivel muy alto cómo se hacen las sesiones de recolección de requisitos. Nuevamente, como gerente de proyectos, eres más facilitador aquí que realmente haciendo el requerimiento reuniendo por ti mismo. Si tienes un equipo Agile entonces trabajó con el propietario del producto para hacer la recolección de requisitos y definir las historias de usuario. Y si tienes un proyecto de cascada, entonces tendrías negocio o tu analista de negocios o alguien del equipo funcional que estará ayudando con los requerimientos del negocio. Y como gerente de proyecto, mapearías esos requisitos de negocio a componentes más pequeños como la estructura de desglose del trabajo. Por lo que puedes incluir en tu plan de proyecto y luego planificar consecuencia para la entrega del requisito de negocio de Ted. Esa es la lección para reunir requisito empresarial. Por lo que ahora pasaremos a la siguiente lección. 13. Caso de negocio y carta: En esta lección, hablaremos sobre el caso empresarial y la carta del proyecto que ocurre en la fase de idea del proyecto. Antes incluso de que se inicie el proyecto, el patrocinador tiene que crear un caso de negocio para basado en las necesidades del proyecto y la estrategia y visión de la organización, el patrocinador del proyecto tendría que crear un plan de negocios que expone el proyecto en el alto nivel, obras que se activan en la inversión y todo ese detalle. Por lo que hay que conseguir el caso de negocio del proyecto y la carta del patrocinador. Pero en algunos casos, estas fuentes que involucrarían al PM de antemano. Entonces cuando tenga el caso de negocio, consultaría con el gerente del proyecto para modificar cualquier cosa. Y también pediría ayuda para la carta del proyecto vaya para que pueda ser posible que no te aprovechen para ayudar al patrocinador a crear la carta del proyecto. Pero idealmente debería ser creado por el patrocinador del proyecto junto con el caso de negocio. Muy bien, así que ahora echemos un vistazo a lo que debería tener la carta del proyecto. Definitivamente debería tener en el nivel muy alto, la escuela y las necesidades empresariales. Lo que está en un ámbito externo para el proyecto. Por ejemplo, digamos que estás construyendo un sitio web, tienes que tener ese requisito claramente establecido en la carta del proyecto y en el caso de negocio que el requisito es crear un sitio web donde se pueden vender productos. Entonces, cuando veas la carta, debería ir más en detalle sobre lo que está en el alcance y lo que está fuera de alcance. Es este sitio web atendido solo a Estados Unidos o Europa o a cualquier otra región o como internacional. Entonces esos deberían estar en la escuela. Y cualquier cosa que no esté en alcance, digamos que su producto no está permitido vender en la región europea debido a llevar a una regulación detallada. Entonces Europa está fuera de alcance, por lo que hay que tener los establecidos en la carta del proyecto. Si nos estás ayudando a CAPM, entonces deberías poner eso adentro. De lo contrario el patrocinador debe aclarar para usted, la carta del proyecto siempre debe tener una línea de tiempo de alto nivel para que usted entienda antes de que comience el proyecto y otorgue el plazo que usted tiene que entregar este proyecto. Obviamente durante la fase de planeación, va a cambiar y tal vez tengamos que ajustar la línea de tiempo. Pero siempre debes comenzar con la línea de tiempo cuando se debe entregar el proyecto. También debe contar con el presupuesto porque como parte del caso empresarial, el patrocinador ya contaba con un presupuesto aprobado para este proyecto junto con la contingencia. Entonces contingencias, cualquier cosa si el proyecto sale mal, tienes un buffer para tomar algún costo de eso. Por lo que siempre debes buscar el presupuesto del proyecto en el caso de negocio y poner eso en la carta. Carta debe toda base tener limitaciones. Si hay alguna dependencia del proyecto o limitaciones que se tenga que poner en la carta del proyecto. Entonces, por ejemplo, puedes colar sería que tal vez tu organización tenga secuela de Microsoft. Pero para este sitio web necesitas artículo. Es una restricción que se necesita para obtener Oracle para la base de datos para tener éxito. Y los supuestos podrían ser que se te permite ir a vivir con ciertas cosas. Y tal vez durante la ejecución o planeación del proyecto, validarías esos supuestos si es cierto o no. Entonces también tendrías que destacar el riesgo de que pienses que podrías terminar al ejecutar el proyecto en la carta del proyecto a un nivel muy alto, obviamente, el riesgo y los temas van a conseguir más grande y mejor una vez que empieces a planear y ejecutar. Pero siempre debes tener algún alto nivel de riesgo identificado como parte de la carta. Y por último, la carta del proyecto siempre debe darte una idea sobre quiénes son los grupos de interés, ¿para quiénes estamos creando este producto? Interesados directos e indirectos. Por lo que todos ellos deben formar parte de la carta del proyecto. Y solo recuerda que debió haber sido documentado por el patrocinador y entregarlo a usted. Entonces ese es un consejo rápido para recordar, pero en algunas organizaciones el patrocinador se acercaría a ti para ayudar con la carta. En ocasiones el gerente del proyecto tiene que ayudarlos o crear la carta para el patrocinador. Y esto sucede en la idea de fase. Antes incluso de empezar la fase de planeación. Carta del proyecto es un punto de partida que toma insumos del caso de negocio. 14. Evaluación de riesgos en planificación de proyectos: Muy bien, entonces ahora hemos hecho la planeación, ahora es el momento de hacer una evaluación de riesgos. Mira todos los proyectos, podemos ver cómo podemos mitigar el riesgo. Lo que identificamos como riesgo, ¿va a impactar el proyecto? Todas esas buenas discusiones antes de entrar, echemos un vistazo a la definición de riesgo. La definición de riesgo es que se trata de un evento incierto. No estás seguro si ese riesgo va a ocurrir o no. Es sencillo ejemplo podría ser tu seguro de auto. No sabes si te vas a quedar con un accidente o no cuando conduces un automóvil o tu vehículo de motor o una bicicleta. Pero sabes que existe una posibilidad potencial de que algo pueda pasar. Y si eso sucede, entonces necesita ser aceptada, migrada, o transporte. Entonces cuando tomamos un seguro de auto, todo lo que estamos haciendo es transferir el riesgo o el impacto del riesgo a la aseguradora pagando una prima mensual. Entonces digamos que te conociste con un accidente y si no tienes seguro y digamos que el daño es de $20 mil. Entonces eso es un riesgo que estás dispuesto a aceptar, entonces eso está absolutamente bien. Simplemente puedes tomar la póliza mínima de seguro que requiere el estado. Pero si estás dispuesto a aceptar ese riesgo, que si algo pasa, estoy dispuesto a pagar 20 mil o desechar el auto y comprar uno nuevo. Depende de ti en proyectos es lo mismo. Al identificar esos riesgos, tienes que decidir si quieres aceptar el riesgo o si quieres mitigar y reducir el impacto de la lista, o quieres transferir completamente el riesgo a otra persona. Entonces esas son las consideraciones que quieres hacer al mirar el riesgo y el plan de mitigación. Así que típicamente la forma más fácil de hacer es si algo, que son bajos en el espectro de riesgo, que es el fondo inferior aquí en verde, esos riesgos pueden ser aceptados, lo que significa que podría ser que el impacto sea bajo la probabilidad de que ese evento suceda es muy baja. Y no tiene sentido de ideas y gastar mucho tiempo evaluando ese riesgo si las posibilidades de ocurrir eso es demasiado bajo. Por otro lado, si el riesgo es demasiado alto, entonces debes tener un plan B. El alto riesgo es porque impactan, si sucede, es costoso. Podría impactar tu proyecto, tiempo o el costo de tu proyecto. Podrían ser ambas, o muchas otras cosas. Entonces, al final del día, si no estás seguro de querer impactar en el proyecto, entonces ese riesgo tiene que ser mitigado. Entonces esto es al alto nivel, cómo se mira el riesgo de este espectro. Y si es medio, entonces puedes tener plan de mitigación de transferencias. El típicamente todo esto es hacia y evalúa en un registro de riesgos. Puedes crear un registro de riesgos en formato Excel. Entonces echemos un vistazo al Excel y veamos cómo se ve. De acuerdo, para que como se puede ver aquí, aquí, he creado un Excel con columnas básicas que se utilizan típicamente en el registro de riesgos. Entonces primero tenemos número de serie, que es sólo el número, riesgo número uno también. A medida que identificamos más riesgo, agregaremos que para empezar con el riesgo, ¿Qué identificas del equipo del proyecto? El primer lugar a mirar es la carta de negocios. Por lo que el patrocinador, cuando estaba proponiendo la idea de convertirse en proyecto, él o ella podría ya haber identificado cierto riesgo que han identificado durante su descubrimiento. Por lo que importa esos riesgos primero. Y luego a medida que desarrolles el equipo, se asegura de que puedas hacer una lluvia de ideas con el equipo y ver si hay riesgo adicional. Tomemos un ejemplo. En nuestro caso, estamos desarrollando un sitio web para vender plantillas, plantillas de proyecto. Entonces digamos que en este caso quieres vender la plantilla para que alguien en Europa compre. Por lo que hay leyes en Europa que impiden su privacidad y qué tipo de datos que se pueden almacenar en el backend. Por lo que hay que evaluar los requisitos globales de privacidad de datos. Por lo que puedes agregar que como impacto GDPR al proyecto en detalles de riesgo, puedes agregar más detalles como al vender plantilla en Europa, evaluar el requisito de almacenar datos personales. De acuerdo, por lo que al vender en Europa, es posible que tenga que considerar cualquier impacto en la privacidad de almacenar datos, datos personales en el back-end en Estados Unidos o cosas por el estilo. Entonces si algo sale mal, entonces es posible que no puedas vender o quizá tengas impacto están bien. Quieres evaluar todos los requisitos globales de privacidad de datos y ver si hay algún impacto. Y si has identificado algo, entonces puedes agregarlo al registro de riesgos hasta completar la evaluación para asegurarte de que no haya riesgo. Entonces aquí está, tecnología o privacidad de datos. Por lo que yo diría datos. Como el tipo de riesgo. Y la probabilidad es que, esa es una alta probabilidad de que pudiera impactar en Europa. Por lo que las probabilidades en una escala de uno a cinco. Por lo que puedo añadir eso en los encabezados por lo que está muy claro. Y el impacto también está en una escala de uno a cinco. Y la razón por la que estos están en esa escala es por esos dos, la probabilidad y el impacto, determinaríamos el ranking de riesgos. Entonces en este caso, digamos que la probabilidad de cualquier problema con GDPR es probablemente media. Podría haber remediación. Entonces diríamos tres, si tiene un impacto y es un alto impacto, porque si usted está planeando vender en Europa, podría incurrir en multa y algo así. Por lo que el impacto es de cuatro. Por lo que se puede ver el rango de riesgo se calcula con solo multiplicar esas dos columnas. Ahora, se necesita un dueño de riesgo que pueda dar seguimiento y ver si eso tiene un impacto, si necesitamos mitigarlo y todo eso. Entonces dueño del riesgo, digamos que tenemos a alguien en el equipo llamado Jim. Por lo que siempre se necesita tener un dueño de riesgo que se encargue de monitorear ese riesgo y evaluar lo que hay que hacer. El mitigación del riesgo es si vas a aceptar el riesgo y no hacer nada o transferir el riesgo de que si impacta haces ciertas cosas o lo vas a mitigar. Entonces, si lo vas a mitigar, necesitas un plan de mitigación lo dirá como riesgo. Podemos llamar a esta columna como enfoque de riesgo. Ya sea que desee mitigar o transferir o aceptar. Puedes seguir adelante y hacer un dato aquí. Y llamémoslo como Validación de Datos. Y es una lista si se puede aceptar el riesgo, mitigar el riesgo, dispuesto a transferir el riesgo. Por lo que agregas esas tres opciones. Entonces cuando seleccionamos una opción en este caso, queremos mitigarla. Y luego si estás planeando mitigar, es mejor agregar otra columna llamada plan de mitigación. Tendremos que si impacta, entonces podremos obtener una licencia de control de exportación. Y la fecha de vencimiento para evaluar todo esto es digamos marzo primero antes de lanzarnos y el estatus a partir de ahora está abierto. Así es en un alto nivel como se prepara el registro de riesgos. Y siempre puedes filtrar por el estado aquí y revisar esos riesgos durante la reunión de estado de tu proyecto. O puedes tener una reunión semanal de revisión de riesgos para pasar por todos los ítems abiertos y ver si necesitas tomar alguna acción, si viene algo, hazlo, deberíamos haberlo cerrado idealmente y todo eso. Entonces esta es al alto nivel como crearías un registro de riesgos. Muy bien, entonces ahora digamos que tenemos un desarrollador que puede salir pronto del equipo del proyecto por tal vez razones de salud o lo que sea. Por lo que se puede ver la falta de disponibilidad de recursos de base de datos de recursos post Q1. Esto solo te está mostrando un ejemplo, cuáles podrían ser diferentes tipos y cómo agregarías esos detalles y qué enfoque de mitigación tomarías. Los detalles de riesgo aquí todavía está trabajando en la base de datos puede no estar disponible puesto Q1 debido a razones personales. Podría haberte dado alguna pista o al equipo del proyecto que tiene que Q1, no está disponible. Entonces eso es lo que estamos capturando aquí como un riesgo. Entonces el tipo de riesgo aquí es recurso y la probabilidad es de cinco porque ya te dijo que eso va a pasar. Y si sucede, ¿cuál es el impacto? ¿ Tiene otros miembros del equipo que puedan hacer ese trabajo? Si no, entonces esto es un alto impacto. Por lo que este definitivamente necesitas transferir. Por lo que te lo asignarías como gestor de proyectos a ti mismo. Y se quiere tener un plan de mitigación. Por lo que se teclearía mitigar. Y el plan de mitigación es entrevista, postulante de aplicación de base de datos y seleccionar un recurso para reemplazar a Joe. Y esto tiene que suceder antes del final del Q1. Y necesitas tener algo de tiempo para que Joe haga algunas transiciones. Por lo que podemos decir que para el MID de marzo, tienes tiempo suficiente para que Joe haga la transición y todo eso. Para que como puedes ver aquí, el registro de riesgos se está acumulando ahí arriba, como notaste en la diapositiva anterior, cualquier cosa que esté en alto riesgo, quieres encargarte de eso. Eso es lo que harías con ese riesgo de recursos, porque eso va a ser alta probabilidad de que vaya a suceder. Y el alto impacto que sería si ocurriera. Por lo que quieres tomar alguna película de acción, se asegura de que el riesgo siempre tenga un plan de mitigación. Si sucede, lo que vas a hacer. ¿ Está bien? Entonces el riesgo y los temas están atados en el sentido épocas potencialmente pueden convertirse en un tema en el sentido, digamos, cuando este riesgo eventualmente ocurrió y no se ha identificado un recurso de reemplazo para Joe, entonces en ese punto, se convierte en un tema porque ahora realmente sucedió y es, ha impactado el proyecto. Entonces, ¿recuerdas cómo es esa la relación entre el riesgo y los temas? Siempre un riesgo puede convertirse en un tema por tema no se convertirá en errores porque tema es un tema que sucedió o actualmente es un problema para tu proyecto. Verisk no ha sucedido. Puede o no suceder. Entonces esa es la diferencia crítica entre Aristóteles y un tema. Por lo que cualquiera de los ítems que identificaste en el registro de riesgos, puede o no convertirse en un tema potencial en el futuro. Entonces Eso es algo que vamos a echar un vistazo al registro de emisión, que sería similar al guante de riesgo, pero habrá diferentes columnas, pero eso es algo que se las arreglarías durante la ejecución del proyecto. Por lo que durante la fase de planeación, se están evaluando todos los riesgos potenciales que tiene la oportunidad de convertirse en un problema durante la ejecución. Entonces eso es lo que todo este registro de riesgos es apoyarte a hacer que la mejor manera de hacer es reunirte con el equipo y evaluar todos los riesgos que el equipo activo colectivamente lo que ustedes piensan, y luego empieza a documentarlo, asignar un propietario y una fecha de vencimiento, y siempre mira cuáles son las opciones de mitigación que tienes disponibles si sucede. Eso concluye la fase de planeación del proyecto. Ahora pasaremos a la emocionante ejecución del proyecto. Utilizaremos todos los documentos que creamos en la fase de planeación, sugiere el plan del proyecto, el GW, o el registro de riesgos y todo eso. Y vigilaremos y controlaremos de cerca toda esta documentación durante la fase de ejecución. Muy bien, por lo que has completado con éxito la fase de planeación. Ahora vamos a saltar a la ejecución del proyecto, que es la parte emocionante. 15. Descripción del flujo de trabajo de adquisiciones: Muy bien, por lo que el tema de hoy es algo emocionante y a veces hay que hacerlo. No siempre, pero es bueno entender el proceso que está procurando tus recursos. Los recursos pueden ser hardware, software o humanos. No importa. Cualquier cosa que tengas que comprar desde fuera contratando a terceros o a un vendedor. Ahí es donde contratarías a tu equipo de compras de tu organización. O si eres parte de una organización más pequeña, entonces tendrías que hacerlo con un equipo más pequeño. Pero típicamente cualquier organización tendrá un equipo de abastecimiento o adquisiciones que se comprometería con la negociación y el precio final. Pero como gerente de proyecto, hay que decirles el requisito para el proyecto. Y se comprometerían con usted y negociarían y tratarían con el vendedor para obtener las mejores tarifas. Echemos un vistazo a cuál es el flujo de trabajo de compras estándar. Antes de entrar en lo que es la contratación y todos los detalles, comprendamos lo contextual. Digamos que estás construyendo un proyecto de sitio web y necesitas Amazon Web Services. Y digamos que tu organización no tiene Amazon Web Services. Tienes que tener un acuerdo maestro entre Amazon y tu empresa. Eso se llama Acuerdo Maestro de Servicios. Y eso tendría todos los términos y condiciones sobre cómo se involucraría con Amazon. Una vez que tengas eso en su lugar, entonces puedes comprometerte con Amazon para venir a dar alguna prueba de concepto o lo que estés buscando para el proyecto, pueden venir y mostrarte lo que tienen para ofrecer. Entonces puedes decidir si quieres ir con eso o si tienes alguna otra alternativa u otros proveedores que puedan ofrecer el mismo servicio. Digamos que en este ejemplo solo tienes un servicio que necesitas y lo necesitas de Amazon. lo que típicamente le pediría la contratación o a su equipo de abastecimiento para ver si ya tienen un acuerdo negociado o un acuerdo de servicio maestro con Amazon. Y si lo hacen, entonces hay que proceder al siguiente paso donde puede referirse de nuevo a la MSA para escribir una SOW. Sembrar es la declaración de trabajo. En ese documento, acabarías enumerar tus requisitos de proyecto para este proyecto, este es el requisito específico que necesito de Amazon para entregar. Eso es lo que SOW es solo un subconjunto del contrato maestro o el MSE. Entonces una vez que tengas eso, entonces puedes involucrar a Amazon. Entonces ese es el contexto. Por lo general, ya sea Amazon o un proveedor externo o cualquier otro servicio o personas que esté contratando. Podría haber un proveedor con el que su organización se haya comprometido y puedan pasar por ese proceso. Y para que se apruebe ese flujo de trabajo, hay que trabajar con sus finanzas para asegurarse que su proyecto tenga fondos suficientes para apoyarlo. Por lo que hay que trabajar en estrecha colaboración con el equipo de finanzas y adquisiciones para satisfacer esa necesidad del proyecto. Digamos que si tienes que comprar algo completamente nuevo y no tienes idea qué empresa o vendedor quieres ir. Digamos que estás abriendo una empresa completamente nueva o una parte de tu organización. Y es necesario configurar servicios de correo electrónico. Tienes Microsoft Exchange, tienes Google Suite y otras variedades diferentes donde puedes obtener servicios de correo electrónico. Entonces, ¿cómo te vas por conseguir ese servicio? Por lo que lo primero que harías es solicitar propuesta. Básicamente es pedir al vendedor pujar y ver quién puede ofrecerte el precio más bajo por las cosas que quieres tener en tu proyecto. En este ejemplo, si estás buscando servicios de correo electrónico, dirías que quiero tener servicios de correo electrónico proporcionados para un 100 personas en mi organización. Entonces, ¿cuál es el mejor precio que puedes dar? Recibirán eso como solicitud de propuesta de RFP, y presentarán su oferta y luego podrá evaluar. Una vez que lo evalúas, tienes que hacer prueba de concepto para ver, digamos que ambos ofrecieron servicios de correo electrónico por un $100 al mes para 100 personas. Entonces quieres ver cuál se ajusta mejor a tus criterios. A lo mejor tienen, Google tiene algunas características que te gustan o Microsoft tiene algunas otras características. Por lo que quieres probarlo. Y si estás seguro de que vas a ir con uno u otro. Si no quieres probar nada, entonces puedes saltarte este paso. Pero solo lo estoy poniendo aquí para que normalmente sepas cómo es ese flujo de trabajo. Iniciarías datos, te seguirían, recibirás todas las solicitudes o el precio. Y entonces harías un POC, entonces puedes determinar con cuál ir. Una vez que hayas determinado que quieres ir con uno, Microsoft o Google, entonces volverías a contratar al equipo de compras para hacer la negociación final. Por lo que tal vez tengan mejores términos y condiciones en el lugar donde puedan seguir negociando y empatar en los términos legales en materia de cancelación, terminación, todo. Una vez hecho eso, entonces compras, ya que si se trata de una nueva ventana entrando, primero escribirían el convenio maestro de servicios. Una vez que tengas eso en su lugar, entonces puedes crear una SOW específicamente para el proyecto. Y luego decir, este es el presupuesto del proyecto y este es el requisito del proyecto, línea de tiempo, los supuestos, las dependencias y todo eso. Entonces así es como adquirirías recursos, ya sea hardware, software, o personas. Estos son genéricos a un alto nivel. Y no entraríamos en el detalle, sino simplemente entendemos que si ya tienes NMAC o una conexión existente entre tu organización y el proveedor de servicios, entonces puedes comenzar con la SOW. Pero si estás estableciendo una relación completamente nueva, entonces pasarías por los pasos y luego establecerías la SOW de MSA para iniciar tus requisitos de proyecto con ese proveedor. Eso es algo que tendrías que hacer en tu carrera de gestión de proyectos. No muy a menudo, pero la mayoría de las veces, compras y finanzas a tus amigos y ellos tendrán que estar en ti estás ayudando sitio. Muy bien, así que eso es todo por esta lección. Por lo que pasaremos a la siguiente. 16. MVP en Agile vs. POC en acuarela: En la clase de hoy, echaremos un vistazo al enantiómero MVP. Debe haber escuchado la palabra MVP. Y veamos por qué esa es una palabra clave tan importante y cuál es el significado de ella en Azure? Así que déjame cambiarlo a la pase de diapositivas. Y puedes ver aquí que tenemos entrega anticipada versus tardía dependiendo de Cascada versus Agile. En Agile, verás allí una palabra clave MVP, que es producto mínimo viable. Y en la cascada de la izquierda tenemos algo similar llamado prueba de concepto, pero realmente no cerca como MVP. Digamos que un cliente tiene un requisito de que necesite algo para conmutar desde el punto a para encontrar B en dos ruedas. Para que como se puede ver a la izquierda cuando hacemos POC, tal vez el paso uno al cuatro son solo diseño sobre cómo se verá ese producto. E incluso después de eso, solo se puede entregar el producto real una vez que esté completamente fabricado y entregado, que sale en el paso número seis. Y en ese momento el cliente tendría una moto bastante bonita para conmutar de punto a punto B. Y este proceso podría llevar algún lugar de en un mes a un año o diez años dependiendo de cuán compleja y cuán personalizada debe ser esa motocicleta. Pero digamos que el cliente solo buscaba un vehículo de dos ruedas para conmutar de un punto a punto B. Y en realidad no solo estaba pensando en motocicleta desde el principio. Entonces es ahí donde el producto mínimo viable en Agile es muy útil. Si miras antes de que la motocicleta se construya al final, indica al cliente, siempre tiene opción de volver atrás y conseguir una patineta de nosotros para que aún puedan comuna de punto a punto B. Entonces es entregar un valor, lo mínimo viable que puede hacer con el producto que entregamos. Entonces por eso Agile es muy potente porque lo que el cliente quiere, lo consigue en las primeras etapas. No tiene que esperar hasta que se complete el proyecto para obtener su requerimiento, Dan, sí, podría no tener la velocidad y agilidad de una motocicleta, pero aún así se puede conmutar de punto a punto B usando el patineta o scooter, o una bicicleta o un ciclo de motor. Entonces ese es el concepto clave de entrega temprana versus tardía. En Agile, siempre entregamos temprano, mientras que en cascada, siempre se entrega tarde. Y a veces es demasiado tarde que cuando me digas dónde puede estar la motocicleta, el cliente no quiere ese color o esa no es la forma y el estilo que buscaba y estará completamente infeliz. Entonces por eso Agile es una herramienta tan poderosa que siempre podemos obtener la retroalimentación de los clientes a medida que seguimos entregando en las primeras etapas del proyecto. 17. Consigue JIRA gratis: En la lección anterior, miramos cómo conseguir el Microsoft Project por 30 días de forma gratuita. Hoy te mostraré cómo conseguir el Jira y la Confluencia, lo cual es fundamental para gestionar proyectos Agile. Para este curso, te recomiendo encarecidamente que vayas a un sitio web de fin de clase. Te voy a caminar por aquí y apuntarme a Jira y Confluence. Esto va a ser muy útil cuando pasemos a las otras secciones de esta clase porque puedes aprender práctica Jira y Confluencia con el proyecto que vamos a discutir en las próximas clases. Entonces todo lo que tienes que hacer es buscar en Google para Atlassian. Y debería llevarte a un sitio web de Clase C and.com. Y ahí tienes una opción que probar. Ahora, al hacer click en eso, tienes opción para diferente sección de plan y pista donde puedes probar el software Jira y el software de confluencia. No tienes que descargarlo. Está en la Nube, así que solo tienes que registrarte usando tu correo electrónico y luego eso es todo lo que necesita. Para que como se puede ver en el sitio web de Jira, es completamente gratuito hasta por diez años más o menos. Es ilimitado. Puedes registrarte usando tu correo electrónico y puedes usarlo por tiempo que quieras porque Atlassian no cobra hasta por diez Estados Unidos, así que en terrorista no hay costos. Por lo que te recomiendo encarecidamente que te inscribas para esto y empieces a jugar con él. Y a lo largo de las lecciones de este curso, vamos a hacer proyecto práctico utilizando tanto Jira como Microsoft project. Por lo que es bueno tener un icono de Jira local para ti para que puedas jugar con el proyecto, crear tableros y hacer muchas más actividades a medida que aprendemos más sobre JIRA en este curso. 18. Descripción y recorrido en JIRA: Hola. En esta lección vamos a echar un vistazo a la herramienta Atlassian JIRA, que se utiliza para la Gestión de Proyectos Agile. En el video anterior, miramos cómo conseguir JIRA de forma gratuita hasta por diez usos. Todo lo que necesitas para obtener acceso a una cuenta de Jira gratis es registrarte usando tu cuenta de correo electrónico en el sitio web de Atlassian. Una vez que hayas hecho eso, entonces la página principal básica de Gita se vería algo así. Aquí tengo algunos proyectos que está pasando, pero cuando primero consigues tus datos, posible que quieras ir a la configuración y configurar un proyecto. Si eres parte de una organización que el administrador del sistema de TI ya configurará un proyecto para ti para que no tengas que hacerlo tú mismo. Pero solo te estoy mostrando para que en casa puedas crear este proyecto y empezar desde el principio. Normalmente en una organización, el acceso admin no se proporciona a los gerentes de proyectos, por lo que no tendría acceso a estos detalles. Podrás ver proyectos y acceder y diferentes proyectos a los que tengas acceso. No verías esa opción llamada Crear proyecto si no tienes acceso admin. Una forma de crear proyecto es hacer clic en el proyecto desde el menú superior y puedes crear un proyecto desde aquí. Pero en general, se quiere hacer eso entrando en la página de configuración y luego haga clic en la sección Proyectos aquí. Eso te dará una opción para crear un proyecto. Así que da clic en el botón azul en la esquina superior derecha llamado Crear proyecto. Al hacer clic en el botón Crear proyecto, le presentarán diferentes plantillas disponibles. Por defecto, Java cuenta con este desarrollo de software, gestión de servicios, gestión de trabajo, y todas las demás opciones que ves a la izquierda. En nuestro caso, vamos con esta plataforma de desarrollo de software o la plantilla. Pero porque ya estamos planeando utilizar el diseño web como proyecto a lo largo de este curso, que pertenece al desarrollo de software. Entonces en este caso tienes Kanban y Scrum y luego seguimiento de errores. Esto es para el equipo de aseguramiento de calidad. Pero entre Kanban y Scrum, recuerda que si se trata de un proyecto, entonces quieres ir con la plantilla Chrome. Kanban es típicamente cuatro operaciones donde no hay fecha de finalización, es una operación continua. Por lo que como se trata de un proyecto, comenzaremos con Scrum y se puede hacer click en Usar Plantilla. Ahora tienes una plantilla de proyecto por defecto, y ahora puedes decidir si es administrada por ti o por tu empresa. Entonces voy a decir que selecciona un proyecto gestionado por equipo y vamos a añadir un nombre de equipo. Entonces la prueba de desarrollo. Y luego por defecto crea una palabra clave. Y verás esto cuando se crean tareas e historias. Ahora haga clic en Crear proyecto. Una vez que creas el proyecto por defecto, se ha creado un tablero. Es por eso que al hacer click en el tablero del lado izquierdo, verás esta página ahora donde empezamos en JIRA es siempre con atraso. Aquí es donde crearías tus historias de usuario, tarea, y cualquier otra cosa que tenga que ir como parte del desarrollo de productos. Voy a omitir las instrucciones aquí. Si eres nuevo, puedes seguir eso. Por lo que eso dará algunas ideas sobre cómo usar esta herramienta. Ahora empecemos desde arriba. Estas partes son diferentes. Atlassian Software está disponible. Por lo que típicamente hemos instalado JIRA para la gestión de proyectos para usar la tarea de historias de usuario, cosas así. Confluence es su repositorio de documentos donde almacenaría todos sus documentos asociados a este proyecto. Vamos a llegar a eso en un poco. Empecemos con el software Jira, que es lo que estamos usando ahora mismo desde que creamos el proyecto, puedes ver otros proyectos aquí. El que acabamos de crear es la prueba de desarrollo web. Una vez que haga clic en eso, regresa a la página predeterminada del tablero. Ahora, podemos seguir adelante y crear tareas. Pero antes de hacer eso, veamos qué otras opciones tenemos aquí. Puedes filtrar aquí para ver cualquier tarea que te asigne. Pero esto aún no está listo para nosotros. Entonces volvamos a los proyectos. Se trata de diferentes proyectos que he creado en el pasado. El actual es los filtros de prueba de desarrollo web son consultas. Tienes gran cantidad de tareas que puedes ejecutar consulta para filtrar las que estás buscando. Puedes usar el filtro predeterminado sugiere los temas abiertos para mirar todos los temas que aún están abiertos para que todo lo cerrado se filtre. Echemos un vistazo al tablero. Por lo que este es el panel de muestra al que tengo acceso desde proyecto anterior. Pero si no has creado un dashboard, no verías nada aquí. Volveremos para crear un dashboard más adelante. Ahora veamos a la gente. Puedes invitar a otros a este tablero de Jira si estás ejecutando un proyecto. Aquí es donde invitarías a los miembros de tu equipo a formar parte de esta junta de proyecto. Las apps son otras cosas que puedes integrar con el Gita. Así que por el momento, no vamos a hacer eso. Entonces ese es el básico en la parte superior. Y de nuevo aquí a la derecha debajo configuración es donde administrarías tu flujo de trabajo, configuración de tu proyecto, cosas así. Por el momento, lo dejaremos como predeterminado y a medida que avanzamos, echaremos un vistazo. Si necesitas cambiar algo a la derecha, verás que tienes opciones para cambiar la configuración de tu perfil, tu configuración de inicio de sesión, y cambiar la contraseña, cosas así. Muy bien, ahora echemos un vistazo al lado izquierdo aquí. Siempre comenzaríamos con el backlog porque ahí es donde crearías historias de usuarios, tareas y cosas por el estilo. Y haces click en ese botón Crear, aparece esta ventana y verías diferentes opciones disponibles aquí. Antes de crear algo, veamos qué es una Hoja de Ruta. ruta a un nivel superior es el resumen de cómo las epopeyas están avanzando en el calendario. Volveremos a lo que es una épica cuando creamos nuestra primera tarea por el tiempo ser para gestión de proyectos, ignoramos el código. Aquellos que forman parte del equipo de desarrollo, necesitarían acceso a esto y jugarían con esto. Normalmente el equipo de DevOps usaría Bitbucket o GitHub o GitLab para administrar su código. Aquí, las páginas del proyecto están atadas a confluencia y aquí es donde puedes atar una confluencia JIRA y luego crear tu repositorio de proyecto se almacena bajo la página Confluence. Conectemos la confluencia. Ahora podemos crear un nuevo espacio que tenga el mismo nombre que el proyecto giga, donde lo llamaremos como desarrollo web, prueba y Create. Ahora hemos conectado a Jira y Confluencia. Entonces si vuelvo de aquí de vuelta a Confluence, verías que se ha creado un hogar de prueba de desarrollo web . Esto puedes pensar similar a un sitio web, puedes crear blog, puedes crear páginas. Y aquí es donde guardarías cosas diferentes. Entonces por el momento, no tengo páginas. Esta es la página de inicio, por lo que puedes hacer clic y agregar una página para el equipo. Llamémoslo como equipo de bienvenida. Bienvenido a la página de pruebas de desarrollo web. Entonces una vez que lo publiques, entonces cualquiera que se agregue al proyecto, tendría acceso a eso. Y verías esas páginas bajo la sección de páginas aquí. Así que ahora volvamos a Jira por un minuto. Ir a un proyecto. Y al hacer clic en las páginas del proyecto, verías lo que creamos en Confluence. Se muestra aquí también. Entonces así es como está estrechamente integrado entre JIRA y Confluencia. Entonces puedes cambiar la configuración del proyecto directamente desde aquí en lugar de pasar por la página de configuración en la parte superior derecha. Entonces eso es todo aquí. Entonces, típicamente lo que haces cuando tienes acceso a JIRA es que vayas directamente adelante a un atraso. Aquí es donde crearías toda tu tarea y luego crearías este sprint y moverías la tarea de un backlog a propagarse. Así que hagamos eso ahora. Haga clic en el botón Crear. Una vez que creas los diferentes tipos de tejidos como historias de usuario, tarea, bug y épica. El primer nivel es siempre EPEC. Para que sea fácil de entender. Digamos que tenemos una historia de usuario. Voy a crear uno y decir página de inicio de sesión. Aquí, el propietario de su producto definiría cuál es este requisito. Como usuario, necesito acceder a la página de inicio de sesión para ir a mi cuenta. En el sitio web. Este es un formato de historia de usuario y en otras lecciones hemos capturado lo que debe ser una historia de usuario, cuál es el formato, y por qué es importante tener la historia de usuario en un particular formato por el momento, seguiríamos adelante y lo crearíamos. Ahora verás en el backlog tenemos un problema de página de inicio de sesión creado. Y a la izquierda tiene un ícono que representa la historia de usuario. Ahora vamos a crear otro que puedas crear desde arriba o puedes crear desde abajo aquí. Cuando creas a partir de aquí, lo que sea que hayas creado por último, se establece por defecto eso. Y siempre se puede cambiar el tipo a una tarea. Entonces aquí diríamos diseño página de inicio de sesión para este requisito de usuario. Ahora el equipo técnico está creando una tarea. Para diseñar la página de inicio de sesión, haga clic en Entrar. Ahora vamos a seguir adelante y crear un EPEC. Si escriben deben ser páginas web. Epic es solo una colección de historias de usuarios y tareas asociadas a esa épica. Te puedes pensar en una cesta grande de ácido épico donde consolidarías y poner artículos similares en esa canasta. En este caso, vamos a llamar a esa página diseños y hacer clic en Crear. Muy bien, ahora verías que no tienes una épica creada aquí porque se crean selecciones en la parte superior. Entonces si miras aquí, verías la épica, la época que acabamos de crear. No se va a sentar bajo el atraso, va a estar sentado a la izquierda. En algunos casos, o en la parte superior. En este caso tenemos el Epic en la parte superior. Tenemos que habilitarlo para que ahora veas la época de la izquierda. Esta es la épica que acabamos de crear. Se puede ver bajo esta época no tenemos ningún otro problema creado porque no hemos asociado la historia de usuario para corresponder a esta época. Daré click en click fuera de ella para que pueda ver todo. Y digamos que llamamos todos los ítems relacionados con la página web para que formen parte de esta época. Ya que estos dos están relacionados con la página web, simplemente voy a arrastrar y soltar en esa épica. Seguirá en el atraso, pero es sólo una forma de asignar fácilmente una tarea o una historia a una epopeya. Sólo lo estamos vinculando para que sepa cuál. Sólo estamos vinculando el tipo de tema a una épica. Entonces es fácil ordenar cosas diferentes. Tendrá sentido si les doy un ejemplo más, si creo otra época y llamemos a esto como base de datos. Base de datos, ¿de acuerdo? Ahora cuando hago clic en esta épica y creo cualquier cosa, automáticamente asigna esa tarea a esa épica. En este caso, vamos a cambiarlo de nuevo a una historia. Y tal vez lo vuelva a cambiar a una tarea y decir autenticación de usuario a través de una conexión de base de datos. Entonces simplemente estamos diciendo que las credenciales de usuario deben almacenarse y autenticarlas desde la base de datos. Vamos a crearlo. Y podría haber creado fuera del ápice. Así que déjame hacer clic fuera de ella. Y así se puede ver que acaba de crear sin vincularse a una epopeya. En este punto, sólo puedo hacer clic y arrastrarlo a la epopeya de base de datos. Pero si quieres ver cómo hacer de otra manera, entonces puedes hacer click en el botón de los tres primeros para editarlo. Así que probablemente, tal vez este árbol y digamos agregar un patrón. Y en este caso vamos a decir base de datos. Entonces para cualquier tarea e historia, el padre es siempre una épica. Entonces por eso estás viendo sólo esas dos epopeyas que creamos. Por lo que ahora podemos cerrar esto. Ya se puede ver que está asociado a esa épica. Ahora podría ser capaz de ver la importancia de una épica porque se puede ver que son cosas similares se agrupan haciendo clic en la épica medida que el proyecto crece con múltiples tareas y épocas, es fácil de mirar en una sesión particular y mirar sólo la tarea asociada a ese apec. Por eso escogieron tan importante. Se puede volver a pensar en epigástrico, elemento grande donde múltiples usos, historias y tarea de un grupo juntos. Muy bien, entonces ese es el atraso de productos y ahí es donde crearías todo tipo de problemas. Y una vez que hayas terminado con la preparación del backlog con el propietario del producto, lo siguiente que harías es que crearías un sprint. Para hacer eso, hagamos clic en el atraso y cerremos la épica por el momento. Verías que ya se crea un sprint en este caso. Pero si no lo es, tendrías una opción en algún lugar aquí en la parte superior o en la parte inferior que dice Create Sprint. En este caso tenemos la opción aquí. Entonces todo lo que haces para un sprint es escoger uno de los elementos que quieras formar parte del sprint para mover el tema del backlog al sprint, siempre puedes arrastrar y soltar. Así que déjame hacer eso por el tiempo. Ahora estoy moviendo el primer ítem de atraso a sprint. Muy bien, entonces ahora que hemos creado los temas y entendido cómo pasarlo del atraso al sprint. Lo siguiente que queremos ver es diferentes campos disponibles para ese tema. Siempre se puede tener una descripción de usuario cuál es el tejido. Puedes asignar a alguien del equipo. Por lo que en este caso me asignaré a mí mismo, se pueden añadir otras etiquetas. Entonces en este caso voy a decir diseño solo para categorizar las cosas y solo para categorizar las cosas para AAC encontrando más tarde una vez que el atraso crezca tremendamente, ahora veamos qué otros ítems que tenemos para hacer aquí aparte de asignar etiquetas sprint. Lo otro importante que se quiere actualizar es el punto de historia por el tiempo siendo apenas poner tres en la otra lección más adelante durante la planeación del sprint, hemos tocado cómo llegar a la historia puntos, cómo calculamos y todos esos detalles por el tiempo siendo solo entender este es el esfuerzo. Entonces para esta historia de usuario en particular, el esfuerzo involucrado es punto de tres pisos. Ahora eso es todo. Puedes actualizar cualquier otro detalle para esa tarea. Y puedes hacer clic en la Configurar para agregar campos adicionales si es necesario, puedes tener la casilla desplegable y agregar otras cosas. Ese elemento de tarea en particular, así es como se agrega una tarea del backlog al sprint. Ahora vamos a añadir esto también al sprint y hacer lo mismo, volver y asignarlo a un miembro del equipo, y luego también storypoint. Para que puedas tener tal vez cinco puntos de historia para eso. Y una vez que tengas este punto de historia aquí, si miras a este amigo vería el sprint tiene ahora ocho puntos de historia porque jira automáticamente agregará los puntos de la historia para ti más tarde una vez que crea cada vez más sprints, y una vez que identifiques cuál es la velocidad de tu equipo, entonces sabrías que cuántos ítems puedes agregar del backlog al sprint actual antes de comenzar el sprint. Digamos que la capacidad de tu equipo es de solo diez puntos de historia. Entonces, ya sabes, al poner estos dos, casi habrás llegado a ese umbral de diez. Por lo que tienes espacio para agregar una tarea más, que es menor o igual a dos puntos de la historia. Por lo que eso es algo en lo que mantener un ojo mientras agregas más artículos a la férula, una vez que alcances tu umbral para el equipo, no debes agregar además, y debes llamarlo y comenzar el sprint. Ese es el walk-through off en JIRA y cómo crear historia, tarea y épica, y cómo agregar un sprint. Por lo que ahora hemos sumado un sprint. Podemos iniciar el sprint. sprints están en caja de tiempo y debe tener una cadencia particular, es decir, si tu amigo tiene una semana de duración. Por lo que cada sprint debe comenzar y terminar dentro de ese grande. Si tu sprint es, digamos de tres semanas de duración. Por lo que cada sprint que creas a partir de aquí en adelante debe tener ese periodo de tres semanas para la fecha de inicio y fin. Entonces en este caso, digamos que nuestro sprint va a empezar un lunes y es un sprint de una semana. Por lo que debería terminar el viernes para que el próximo sprint pueda comenzar el próximo lunes. Por lo que tendremos la fecha final como tercera y el gol del Sprint está completo. Los elementos de diseño. Piensa siempre en qué quieres lograr a partir de este sprint. Si alguna tarea no se alinea con el gol sprint, entonces sabes que esa tarea debe eliminarse del sprint antes de comenzar la división. Ahora has creado el gol sprint. Ahora puedes iniciar el sprint. El sprint está en vivo. Por lo que al hacer clic en el atraso aquí, verías que tienes un sprint que está en curso. Y tienes el atraso. Una vez que se inicia un sprint, no se quiere agregar más tareas porque ya está en curso. Si hay cosas nuevas que surgen ahora, entra en el atraso y en base a la prioridad, se puede colocar encima del atraso. Una vez terminada esta impresión, se puede poner eso en el próximo sprint. Y digamos una vez que hayas terminado con el viernes y has completado todas estas tareas, ahí es cuando irías y harías la actividad completa del sprint. Pero antes de que hagamos eso, echemos un vistazo a la junta. Una vez que tengas el sprint. Ahora deberías tener un tablero que debería tener estas columnas que dice que hay que hacer en curso y hecho una vez que inicies el sprint, todo por defecto se sienta en la lista de tareas pendientes. Y luego el lunes cuando el equipo recoge la tarea, comenzarían a trabajar en ella y pasarían a en progreso. Y una vez que hayan terminado con eso, entonces se moverán a hecho. Entonces así es como funciona el avance del sprint. Y siempre se puede ver el resultado del sprint. Usando los insights aquí, se puede ver que no se completa nada. Y una vez que esta tarea pase a hacer, entonces se mostrará que tienes un 50% hecho porque aquí solo tenemos dos ítems. Sólo otra cosa que quería mostrar aquí es una vez que comenzó un sprint, entonces deberías poder ver el gráfico de burndown. Entonces vamos a ver si puedo mostrarlo para otros proyectos que ya está en curso o I. Así que ahora para este proyecto, si miras aquí, tienes una opción llamada reportes. Y el informe que tengo es gráfico de burndown. momento, hay esta tendencia que debería haber cerrado hace mucho tiempo atrás, pero esto muestra el gráfico de burndown porque no he cerrado esta marca. Por eso se está mostrando de manera diferente, pero de lo contrario el gráfico de burndown se ve algo así, donde tienes esta línea gris que muestra cómo debe completarse cada tarea. Y a medida que avanzas la tarea, surge la línea roja. Y eso muestra si estás por delante o atrasado, cualquier cosa a la derecha a esta línea gris que muestra que estás por delante de tiempo. Y cualquier cosa a la izquierda o debajo de esta línea gris que te muestra un detrás. Entonces así es como leerías un gráfico de burndown y otros informes es Sprint y gráfico de velocidad. El reporte de Sprint es para cualquier sprint que se complete. Déjame volver a sprint uno para el otro proyecto. Se puede ver cómo progresó durante ese sprint. Y por último, pero no menos importante en el gráfico de velocidad, el gráfico de velocidad es el que muestra la velocidad de su equipo. En este caso, lo que me está diciendo es que nos hemos comprometido para que seis puntos de historia se completen cuando hicimos la planeación. Y en realidad los seis terminados. Y de nuevo en la primavera dos, luego aumentamos la velocidad a ocho y luego terminamos ocho. En situación del mundo real, no será así porque digamos en sprint uno, planeas seis y terminaste ocho, luego el siguiente Sprint, ¿sabes que el equipo puede hacer ocho historia puntos? Entonces lo planearías y el equipo solo completaría cuatro. Entonces en ese punto tomarías un promedio de 64 lo que el equipo completó en los dos sprints anteriores, y luego tomarías mediana de eso y usarías eso como tu guía para Equipos Capacidad para ese sprint. Entonces como haces de tres a cuatro hebras, entonces tendrías una mejor idea de cuánto puede tomar el equipo, cuántos puntos de historia pueden entregar, y luego planear solo entregar eso. Y así es como el gráfico de velocidad es crítico para entender lo que el equipo puede tomar durante una planta de una semana o dos semanas. Estos son los diferentes tipos de reporte que se echa un vistazo durante y después de la finalización del sprint, ese recorrido de seguridad de lo que tenemos en la herramienta JIRA. medida que hacemos más proyecto en ASPE, hacer más proyecto práctico, será más fácil de entender en este momento. Solo hay que entender dónde están enterradas cosas diferentes en esa página de inicio de Jira y cómo acceder a eso, cómo crear una tarea, temas e historia, y cómo iniciar y detener un sprint más tarde una vez que tengamos un proyecto ficticio, pasaremos y correremos por sprint real y cerraremos el sprint para que te pongas más idea. 19. Carta del proyecto: Bienvenido de nuevo. En la clase de hoy, vamos a echar un vistazo a qué es una carta de proyecto, por qué se utiliza y la importancia de la misma en gestión de proyectos y en qué fase de la gestión del proyecto se utiliza. Así que vamos a sumergirnos en la presentación aquí. Por lo que la carta del proyecto se utiliza al principio para documentar el caso de negocio o las necesidades junto con esta estrategia, el retorno de la inversión, o los supuestos que hicieron durante el desarrollo del caso empresarial, cualquier organización tiene su estrategia y con el fin de lograr esa estrategia podría ser la razón por la que están haciendo este proyecto. Cuando haces tu proyecto, obviamente tienes que pensar o no SAP, pero el patrocinador tiene que pensar en el retorno de la inversión. Necesitas hacer un proyecto para que tu negocio pueda crecer o el negocio pueda soportar algo, o es requisito ilegal para tu negocio exista, sea cual sea el caso. Recuerda siempre, la carta del proyecto no es responsabilidad del director del proyecto. Yo retraso en la situación del mundo real, se debe entregar al gerente del proyecto para que pueda desarrollar un documento detallado de planeación y alcance basado en la carta del proyecto. Entonces veamos qué contenido tenemos en la carta del proyecto. Típicamente tendrá metas de proyecto de alto nivel que el proyecto tiene que cumplir y el cronograma de alto nivel. El cronograma se crea a partir del conocimiento que tiene el patrocinador o discutiendo a alto nivel con otras personas. Entonces cuando inicias el proyecto, tomas eso como insumo y ves si puede cumplir con la línea de tiempo. O para cumplir con la línea de tiempo, qué recurso y otra ayuda necesitarías para lograr esa línea de tiempo. En ocasiones puede que no sea posible, pero si se trata de un plazo difícil, entonces planearías y volverías con el patrocinador y decir que estos son los requisitos para lograr el cronograma. ¿ Están dispuestos a hacer eso? Por lo que a veces cuando el patrocinador pensó en el costo, podría no haber pensado el costo de lograr esa línea de tiempo. Entonces ahí es donde yace la carta del proyecto. Tiene los objetivos de alto nivel y un cronograma que el patrocinador quiere o hacia las cosas que se puede lograr. Por lo que el siguiente punto aquí es proporcionarte una directriz que como gerente de proyecto, siempre puedes preguntarle al patrocinador si tiene una carta de proyecto con la que puedes empezar. En ocasiones el patrocinador involucra al gerente del proyecto temprano en la vida de la gestión del proyecto para crear la carta, o al menos un sistema en la creación de una carta. Por lo que siempre puedes pedir una carta de proyecto al patrocinador si ya lo tienes o no. Si no, siempre se puede ayudar a él o ella a crear uno. Pero la idea de la carta del proyecto es conseguir el caso de negocio, estrategia de requisitos de negocio, el objetivo del proyecto, y la línea de tiempo antes de que pueda entrar en la planificación detallada. Y puedes usar la carta del proyecto como principio rector a lo largo del proyecto. Entonces cuando el proyecto se está desviando con alcance, línea de tiempo, costo, y cosas así, siempre se puede volver atrás y mirar la carta del proyecto para ver por qué incluso empezamos este proyecto en la primera lugar. Y si sus objetivos actuales de proyecto aún se están alineando con el proyecto o el caso de negocio. Por lo que es una buena idea mantener siempre la carta del proyecto a mano para que puedas volver a referirte y asegurarte de que ese equipo y tú como PM aún estén alineados con la estrategia de casos de negocio y el proyecto metas definidas en la carta del proyecto. Según el Instituto de Gestión de Proyectos, tienes un método para crear la carta del proyecto. Se puede utilizar la entrada como documentos comerciales en los acuerdos, cualquier activo de proceso organizativo existente para crear la carta del proyecto utilizando las herramientas y técnicas aquí enumeradas, tales como juicio pericial, recopilación de datos, entrevista, o pedir a otros que sean expertos en el campo, realizar reuniones y entrevistar a personas. Puedes intentar reunir más información y puedes crear la carta del proyecto. Entonces la mayoría de las veces así es como el patrocinador podría haber creado si ya ha hecho el trabajo, así es como podrían haber llegado a la carta del proyecto. De no ser así, cuando el patrocinador, los gerentes de proyecto asistan para crear uno, se pueden utilizar estos insumos y herramientas y técnicas para crear uno. Esa es la carta del proyecto y por qué se utiliza, cómo se utiliza, en qué fase se utiliza, y cómo crear uno. Muy bien, nos vemos en la siguiente clase. 20. Identifica y gestiona partes interesadas: Muy bien, por lo que ahora hemos concluido la introducción y los fundamentos de la gestión de proyectos. Por lo que ahora estamos realmente saltando a la carne del curso. Y estas secciones están alineadas según el Instituto de Gestión de Proyectos. Si estás planeando y preparándote para el examen PMP, entonces todas estas clases de aquí en adelante definitivamente te beneficiarían para entender. Lee el libro, que es el libro Cuerpo de Conocimiento de Gestión de Proyectos que necesitas estudiar para el examen PMP. Por lo que está completamente alineado a eso. Por lo que sería bastante fácil leer ese libro una vez que pases por estas lecciones en este orden, la fase del proyecto, las primeras fases de iniciación. En este apartado, pasaremos por todas las cosas que sucedan como parte de la iniciación. Por lo que lo primero es identificar y gestionar a las partes interesadas. Echemos un vistazo a qué hacer en esta área. Por lo que identificar a una parte interesada es fácil porque cuando se inicia un proyecto, el patrocinador o quien financió, obviamente van a ser la clave. Y se les puede preguntar, ¿quién es el cliente? ¿ Quién soy yo aportando este valor o producto entregado a nosotros para que se conviertan en el cliente. En ocasiones podría ser el propio patrocinador, pero a veces podría ser externo, donde el patrocinador está interesado en completar el proyecto para entregar el producto al cliente. Entonces es así como identificas a las partes interesadas y a cualquier persona que esté interesada en tu proyecto, todos se convierten en alguna forma o dan forma a tu stakeholders, incluido el equipo del proyecto. De acuerdo, entonces ahora digamos que una vez que identifiques al interesado, ¿cómo los maneja? Ahí es donde tenemos dos secciones en eje x e y, que es la red de potencia e interés. Por lo que hay que categorizar a las partes interesadas en estos cuatro cuadrantes de esta cuadrícula. Entonces digamos que tenemos en la parte inferior izquierda. Por lo que son los interesados los que tienen bajo interés y baja potencia. Lo que sí fecha de interés es que tengan algún tipo de interés en su proyecto, pero no tan alto, ya sea que lo complete o no, no les va a afectar tanto. Tienen un interés mínimo, pero tienen algunos intereses, por lo que hay que seguir monitoreándolos para que no creen ningún pago para su proyecto. Y aunque lo hagan, asegúrate de que mientras no tengan poder para hacer ningún estragos en tu proyecto. Entonces el siguiente grupo de personas son personas con alto interés pero no tiene mucho poder. Es posible que no sean capaces directamente de detener o iniciar el proyecto. Pueden estar altamente motivados al completar este proyecto, o están en alguna forma o forma beneficiados de este proyecto. Por lo que tienen alto interés en este proyecto. Entonces este tipo de grupos, hay que mantenerlos en PharmD porque tienen algún nivel de interés. Y tal vez tengan alguna dependencia una vez que tu proyecto esté completo, tienen que hacer otra cosa. Por lo que siempre es bueno tener la comunicación abierta con ellos y mantenerlas informadas a lo largo del proyecto. El siguiente conjunto de partes interesadas son los que tienen alto poder y algo buenos intereses. Por lo que siempre y cuando tengan alta potencia, puede causar algún impacto negativo al proyecto. Entonces tienes que asegurarte de que los mantengas satisfechos. Por lo que podría ser tu oficina de gestión de proyectos o podría ser el patrocinador, alguien que tenga alto poder. Tienes que asegurarte de que los satisfaces. Y luego el siguiente conjunto de partes interesadas, los que tienen hiperconscientes así como de alto interés en la tendencia automovilística. Tenemos que asegurarnos de que los administre muy cerca en el sentido que tiene que mimarlos con información. Tenías que escucharlos, tienes que proporcionarles actualizaciones. ¿ Qué tienes que hacer para asegurarte de que se manejen de cerca para que no creen ningún problema para tu proyecto. Es por eso que ese grupo tiene que ser manejado y monitoreado de cerca. Pero esto es a un alto nivel, cómo se identifica a su parte interesada del patrocinador y luego construyendo a lo largo del proyecto la lista de partes interesadas y asignándolas o clasificándolas en uno de estos cuadrantes. que sepas manejarlos a lo largo del proyecto para que no te impongas el comportamiento. 21. Kickoff de proyectos: Por lo que ahora en esta lección vamos a echar un vistazo a la puesta en marcha del proyecto, y esta es la etapa final la fase de iniciación del proyecto. Después de la puesta en marcha, pasaremos directamente a la fase de planeación del proyecto. Entonces, ¿qué se requiere para el arranque del proyecto? ¿ Qué es un arranque de proyecto? Vamos a echarle un vistazo. Permítanme cambiar al modo de presentación. Y aquí se puede ver que en el arranque del proyecto hay que pensar en quién debe ser invitado. Entonces básicamente hay que pensar en las partes interesadas que hemos definido anteriormente. Es cualquiera que se vea afectada directa o indirectamente con los cambios del proyecto. Por lo que definitivamente tienes que incluir a tu patrocinador, tu equipo , tus usos comerciales, y quien esté relacionado con quien esté asociado a este proyecto, tienes que involucrarlos o invitarlos, al menos en el arranque del proyecto en las futuras reuniones que puedan ser selectivos sobre los participantes, quienes deben estar participando en esas reuniones. Pero para el arranque, es mejor invitar a cualquiera que esté directa o indirectamente involucrado. Y si se trata de un liderazgo superior, solo manténgalos como opcionales y puedan sumarse al esfuerzo requerido. Tienes que referirte como lista de partes interesadas y ver a quién debes invitar al arranque del proyecto, las mejores prácticas para invitar al equipo del proyecto y al patrocinador seguro, como mínimo, porque ellos son los que o el equipo del proyecto son los que tiene que hacer el trabajo. Por lo que tienen que saber de qué se trata este proyecto. Esto solo está preparando el escenario. Estás invitando al mundo y les estás haciendo saber que el proyecto está llegando. Tienes que asegurarte de que entienden la puntuación del proyecto y todo. Entonces echemos un vistazo a la agenda. Por lo que típicamente en el arranque del proyecto, se quiere empezar con la introducción del equipo porque esta es la primera vez que se están reuniendo equipo de activos, gerente de proyecto de activos, es posible que tenga interactuó con el patrocinador, pero este es el primer encuentro donde se está trayendo un grupo más grande de personas completo que forman parte de este proyecto. Por lo que siempre es una buena idea tener unas introducciones en equipo. Podría haber un equipo funcional múltiple y los miembros del equipo de cada función, pueden o no conocerse unos a otros. Por lo que esta es la primera vez que quieres tener una introducción. También quieres poner en la presentación esa estructura de equipo, cómo va a verse el equipo del proyecto y cuáles son sus responsabilidades. Raci algunas métricas que vamos a echar un vistazo en la clase posterior. Pero lo que Erase hace es que enumerará el nombre de la función o del miembro del equipo y los asignará a las tareas, ya sean responsables, ampliables, o si son consultadas o informadas. Porque dependiendo del RACI, pueden entender cuál será su papel en el proyecto. Por lo que si es posible, armar una racia y siempre se puede cobrar retroalimentación y bordea la deuda durante el arranque o después del arranque. Las siguientes cosas que hay que pensar para presentar el kickoff es obviamente la línea de tiempo. Por lo que es posible que no tengas una línea de tiempo detallada completa, pero deberías tener en el plan Milestone cuando tengas que golpear ciertas fechas y puedes bajar de la carta del proyecto. Por lo que siempre debes tener el plan de hito y las fechas clave para que todos estén en la misma página. También debes compartir el alcance del proyecto, la fecha oficial de inicio, y cualquier herramienta y cosas que estés planeando compartir con el equipo. Al igual que comentamos anteriormente, el lado de la colaboración, cómo pueden acceder si se agregan y todos esos detalles se pueden presentar y compartir durante el arranque. Y también si hay algún subproyecto que forme parte de este proyecto principal, pero esos también pueden ser arrancados durante este arranque del proyecto. La idea aquí es hacer un hombre grande y armar y asegurarse de que todos estén en la misma página. Por lo que tal vez durante el arranque, es posible que recibas retroalimentación de que deberías involucrar a algunas otras fiestas o a algunos otros miembros del equipo. Entonces recoge esa retroalimentación y si es necesario, agrégalos según sea necesario. Por lo que esta es la etapa final de la fase de iniciación del proyecto. Y después de esto, vas a saltar directamente a la planeación porque ahora tienes un equipo de proyecto, has compartido la estructura del equipo y todos entienden lo que tienen que hacer como parte de la Gráfico RACI. Por lo que entonces todos se reúnen como equipo y planean en la siguiente fase, que será la base para la ejecución. Por lo que concluye la fase de iniciación del proyecto. Por lo que saltaremos a la fase de planeación del proyecto en la próxima clase. 22. Planificación ágil con Jira: Así que ahora es la parte fácil. Hemos hecho la planeación con el equipo en la pared. Por lo que al menos hemos identificado las historias de usuarios y la tarea asociada en la pared. Ahora es sólo el proceso de transferirlo a una herramienta. Ya sea que uses la herramienta jira Atlassian o alguna otra herramienta, todo es igual. Básicamente si estás haciendo scrum, entonces tendrás un atraso de productos. Y luego pones en la herramienta todos los elementos establecidos que se identificaron durante la planeación sprint y establecidos que se identificaron durante la planeación sprint y la planificación de la acumulación de productos. Estoy usando Gita y la mayoría de la organización tiene JIRA o algunas versiones de otro software que se parecerán exactamente a Jira, donde tenemos backlog, sprint y otras cosas. Entonces para este enfoque, iremos con tres opciones. número uno es transferir las historias de usuario de la pared al atraso de productos de giro. Entonces para hacer eso, primero tenemos que crear un proyecto. Al crear un proyecto, puede ser un proyecto Scrum o un proyecto kanban dependiendo de lo que esté utilizando para su organización. Y si estás usando el método de cascada, entonces lo más probable es que la planificación no sea como una planificación de muro, pero es una actividad similar donde llamas a todos los miembros del equipo de tu proyecto y luego preguntarles ¿cuáles son las actividades que tienen que hacer para lograr los objetivos del proyecto? En la lección posterior, te mostraré cómo desglosar esas actividades y ponerla en Microsoft Project, que es la herramienta más utilizada para la metodología de cascada. Entonces saltemos primero al JIRA y veamos cómo se hace para un scrum. Y también vamos a echar un vistazo a cómo crear un tablero Kanban y cómo se hace en Kanban. Tengo todas las historias de usuarios en la pared aquí detrás de mí. Voy a agarrar rápidamente uno y luego hacer mi pantalla compartida para que puedas ver cómo crear un proyecto y cómo poner eso en un atraso. Muy bien, voy a tomar el primero aquí, que es éste. Esta es una historia de usuario. El personaje es como gestor de proyectos, quería descargar plantilla de plan de proyecto para poder utilizarla en mi proyecto. Entonces el proyecto que tenemos aquí es crear un sitio web de comercio electrónico donde tengamos todas las plantillas relacionadas con la gestión de proyectos. Y como usuario, que es un PM, él o ella quería descargar esa o compró esa plantilla y cómo hacerlo. Así que eso es básicamente esta historia de usuario es. Por lo que podemos desglosar esto en una tarea más pequeña, o el equipo se habría desglosado en tareas más pequeñas durante la planificación del muro. Ahora sólo es cuestión de transferir esto a la junta directiva de JIRA. Muy bien, ahora déjame saltar a la pantalla aquí como se puede ver, tengo un proyecto que ya tiene atrasado. En este caso, lo que voy a hacer es seguir adelante y crear un proyecto completamente nuevo. Si estás en una organización donde el Jira es administrado por tu software o equipo de TI fuera del proyecto. Entonces típicamente plantearía una solicitud y les pediría que crearan un proyecto de Jira Scrum o un proyecto kanban para usted. Entonces, cuál es el flujo de trabajo mundial que tienen, típicamente crearían el proyecto y te lo darían. Entonces tu punto de partida se vería algo así como un atraso y ahí es donde crearías. Pero solo por el bien de mostrarte el detrás de escena sobre cómo crear el proyecto. Voy a seguir adelante y crear un proyecto. Para ello, en la esquina superior derecha, haces clic en la barra de configuración y luego vas a Project. Tendrás una opción llamada Crear proyecto. Como ven aquí, he creado múltiples proyectos. Entonces en este caso voy a crear un nuevo proyecto. Y en ese momento, me da una opción si quiero crear un proyecto kanban o un proyecto Ashcan. Así que primero creemos un proyecto Scrum y veamos cómo se ve eso. Entonces, cualquiera que sea la plantilla predeterminada que tenga o el Jira me está ofreciendo, voy a usar eso. Aquí tienes diferentes opciones para plantillas de proyecto, voy a usar el desarrollo de software porque eso es lo que estamos usando. Entonces voy a usar esa plantilla. Y me da una opción si este proyecto va a ser gestionado por el equipo o por la empresa. Normalmente el proyecto será administrado a nivel de proyecto por el administrador de TI de la empresa o el administrador de Jira. Puedes, no verías todas estas opciones cuando estás en el nivel del proyecto gestionando proyectos. Así que sólo voy a crear proyecto gestionado por empresa porque soy dueño de esta plataforma GTR para este proyecto en particular. Entonces lo voy a nombrar como proyecto. Página web de plantilla. Muy bien, entonces estamos usando Scrum y creamos proyecto. Jira ha creado el proyecto y ha vuelto con las herramientas básicas que necesitas, que es atrasado y sprints. Para que a partir de ahora no tienes nada porque no hemos creado ninguna historia de usuario en la herramienta. Lo que hemos hecho es hacer la planeación en la pared. Entonces esto es lo que obtendrás cuando inicies el proyecto desde tu administrador de Jira. Básicamente no tendrías que crear un proyecto porque eso lo harán los administradores de TI. Veamos. Ahora tenemos un proyecto creado. Puedes hacer clic en Crear y empezar a crear las historias. Entonces solo comprobando si tenemos toda la información requerida aquí. Entonces la configuración del proyecto, como se puede ver, tiene que ver en progreso y hecho eso es en el sprint activo. Backlog, todo estará aquí. Tendrás épica. Y versión. Versión es el nivel superior. Si estás lanzando tu producto en múltiples versiones, entonces crearías la versión uno, la versión dos. En ocasiones se lanzan proyectos durante las diferentes temporadas del año. Por lo que sería falses de temporada de primavera y cosas así. Sea cual sea la versión que estés planeando hacer, puedes crearla. O si no creas ninguna versión, eso está bien. Puedes comenzar a nivel épico. Entonces lo que haremos aquí es que comenzaremos a crear las historias de usuarios reales, y luego decidiremos cómo queremos agruparlas en una épica. Epic es un conjunto más grande de actividades o un grupo de historias de usuarios y tareas agrupadas para mantener esa organización. Y épica puede ser amigo y diseño. Y otra épica podría ser la base de datos. Otra épica podría ser algo relacionado con la arquitectura. Para que puedas organizarte, es sólo una forma de organizarlo. Así que te estás rompiendo de la épica más grande, las historias más pequeñas y cosas así. ¿ Qué quieres hacer cuando transfieres las historias de usuario es que quieres ir a la acumulación desde la izquierda. Y quieres crear todo en el atraso porque tu sprint aún no ha comenzado. Estás en la fase de planeación y estás construyendo todas las historias de usuarios, requisitos del proyecto en el backlog. Entonces vamos a crear una historia que puedas escribir, empezar a escribir aquí, o puedes hacer clic en crear. Por defecto, tienes opciones, ya sea una historia, error de tareas o época. Así que vamos a crear una historia porque lo que tenemos en la nota pegajosa aquí, usted dice historias de usuario. Entonces voy a decir descargar plantillas de proyecto. Entonces aquí voy a escribir la historia de usuario como gerente de proyecto, que es la persona. Entonces en este caso, sólo para recordar el fondo es que estamos creando un sitio web donde los usuarios puedan entrar y descargar plantilla respectiva para el proyecto. El personaje es obviamente gerente de proyecto o líder de proyecto o alguien del equipo que necesita una plantilla. Por lo que en este caso, la persona es gerente de proyecto. Por lo que digo como gestor de proyectos, quiero descargar archivo de plantilla de plan de proyecto y sólo tenemos que proporcionar la razón por la que lo necesita. Entonces cuando miras el requisito, es muy claro para el equipo para que pueda usarlo en mi proyecto. Por lo que esta es una historia de usuario muy simple, y típicamente estos necesitan ser proporcionados por el propietario del producto y que hemos discutido en la planeación de la pared. Ahora en esta etapa, como ScrumMaster, solo estás tomando todos estos nodos e historias de usuario de la pared y poniendo en el software. Así que sigamos adelante y veamos cualquier otra cosa que se agregue aquí. Por lo que en este momento, si quieres agregar un cesionario de tu proyecto, puedes hacerlo. Si quieres clasificar aún más esto como cualquier etiqueta, puedes hacerlo. Entonces voy a crear una etiqueta llamada plantilla. Y si hay una épica creada, entonces puedes vincular la época. Pero a partir de ahora no hemos creado una época. Así que adelante y solo crea, como se puede ver ahora en el backlog, debería ser una historia de usuario. Y permítanme hacer click sobre él y ver que ha surgido. Para que como se puede ver aquí, se crea como una tarea en lugar de una historia. Tal vez por error, podría haber seleccionado eso. Tienes una opción siempre para cambiar eso. Por lo que todo lo que tienes que hacer es dar click en Mover. Y luego desde el proyecto actual, entrando como una historia y decir Next, dar algunas historias solo por el bien de poner algo, digamos cinco puntos de la historia. Y luego básicamente es convertir la tarea en una historia. lo confirmamos. Muy bien, perfecto. Ahora volvemos al registro bancario con icónico y vemos que ahora es una historia de usuario. Entonces ese es un buen error que hicimos porque ahora ya sabes cómo convertir de la tarea dos historia, tu historia a tarea o Subtarea Tarea dos. Se puede hacer eso con la opción de mover eso. Por lo que si quieres ver que puedes hacer click en el ítem y hacer click en los tres puntos aquí y hacer moverte. Y ese es un atajo si alguna vez te preguntas, así que haz click en la Tarea y escribe un punto o punto en ella. No te dio todas las acciones que puedes hacer contra de esa tarea en particular o historias de usuarios. Entonces eso es siempre un atajo que utilizo para crear una subtarea o registrar trabajo o asignarlo a mí o a un punto de historia, puedo hacer todo eso en lugar entrar aquí y buscar opciones. Así que recuerda que haga clic en la historia particular y escriba punto y enumerará todas las opciones que tengas. Muy bien, así que ahora hemos transferido la primera historia de usuario al atraso. Entonces echemos un vistazo a este segundo. Usa una historia. Así que voy a llegar a la pared. Se trata de las segundas historias de usuarios, que es analista de negocios ácidos. Quería descargar una plantilla de matriz de requisitos para poder asegurarme de que todos los requisitos estén completos. Por lo que los requisitos de la plantilla, para que puedas seguir adelante y crear un problema. Cuando creas en el Backlog directamente, sea cual sea el número anterior, creará el mismo tipo. Entonces si el número anterior era una tarea, entonces creará el siguiente tejido como tarea. Y siempre se puede cambiar, pero eso es algo de lo que hay que tener en cuenta. Ahora tenemos otra historia de usuario que es descargar plantilla de matriz de requerimiento. Muy bien, así que una vez que haces clic en eso, se ha creado un escritorio. No hay puntos de historia aquí. Ahora vamos a crear un punto y decir, no veo una opción para editar aquí. Así que tal vez tuve que ir aquí y editar en la ventana lateral aquí, añadir una descripción. Voy a empezar a escribir en el mismo formato, el formato de historia de usuario como analista de negocios que es la persona aquí, quiero descargar plantilla de matriz de momento tranquilo para que pueda asegurar nuestros requisitos son mapeados y completos. Da click en guardar, que la descripción se guarda y puedes asignarla a alguien a partir de ahora, no hay nadie en este proyecto aparte de mí. Entonces, una vez que asignes un dual, véalo en el desarrollo atrasado. Si tienes equipo de desarrollo, pueden integrarse con bitbucket dot Jenkins, y puedes crear rama y commit y todas esas cosas. Nuevamente, las etiquetas, es una plantilla. Así que una vez que empieces a escribir entero, se mostrará lo que ya hemos creado esos puntos de historia. Digamos que esto es tres. Hablaremos de puntos de historia en un minuto y prioridad. Muy bien, creo que aquí estamos bien. Por lo que ahora hemos creado dos historias de usuarios, ambas nuestras plantillas, y ahora creo que vamos a crear otra historia de usuario que está relacionada con la base de datos. Así que voy a crear un tema aquí, Historia, entorno de base de datos. Aquí. Esto es necesario para el más que el usuario. Esto es necesario para el administrador. Entonces ensaúdelo. Admin el proyecto. Necesito crear una base de datos para que pueda almacenar todas las plantillas de proyecto, credenciales de usuario, etcétera Muy bien, así que no estoy asignando ningún punto de historia y asignándole ningún recurso que acabo de crear por lo que puedo mostrarles cuál es la importancia de apec. Entonces si hago click en EPEC y diremos Crear EPEC desde aquí. Digamos que escogen el nombre es historias técnicas y tarea relacionada con el trabajo técnico. Para completar. El proyecto. Ahora tenemos una época aquí. Ahora vamos a crear otra época que se relaciona con plantilla. Todo el nombre recogido se llama descargas de plantilla. Todos los usuarios historias y tareas relacionadas con solo si puedo deletrear relacionadas con plantilla, descargando usuario solicitando plantillas. Muy bien, entonces ahora tienes dos épocas creadas aquí. Entonces si alguna vez tienes que mirar en el atraso, verías que las epopeyas están la izquierda y tienes que hacer click sobre ella. Y a partir de ahora, ninguno de los temas está mapeado. Por lo que la forma más fácil de mapear es o bien puedes hacer click en él e ir al enlace aquí. Por lo que un poco de enlace y se puede buscar uno en particular. Y en este caso esto es técnico. Se puede asignar eso. Pero si tienes gran cantidad de historias y tareas en el backlog, las formas más fáciles de minimizar los nombres épicos aquí. Y puedes seleccionar varias historias y tareas, pero luego puedes arrastrar y soltar en una época. Para que puedas seleccionar varias historias o tarea y luego arrastrar y soltar al apec donde quieres mapearla igual que ir a la historia y luego hacer clic en el enlace y vincularlo de esa manera, Me resulta mucho más fácil hacer un drag and drop. Así que ahora eso es eso. Por lo que ahora digamos que queremos crear una versión. Entonces vamos a un, esto es liberar uno o historias de usuario o liberar uno que crean. Ahora se crea. Y lo que puedes hacer es mapear la epopeya. Creo que sólo permite mapear las historias y tareas. Puedes seleccionar. Comando haga clic todo el camino hasta la parte inferior, y luego arrastre y suelte para soltar uno. Por lo que ahora tienes dos temas. A lo mejor no seleccioné esto, así que tengo que arrastrar y soltar eso. Muy bien, por lo que ahora se asignan tres temas al primer lanzamiento. Por lo que ahora hemos cubierto las versiones, versión épica y las historias y ellos escogen por los costados. Entonces si quieres ver los detalles, verías que por qué es importante es una vez que inicias tu hoja de ruta, entonces puedes ver cómo se mapean las epopeyas y luego esas se están entregando. Esa es una ventaja. Y luego puedes mirar solo lavando uno. Si tienes múltiples lanzamientos, entonces puedes escoger y elegir solo los lanzamientos que te interesen. Cuando se trata de hoja de ruta, Es bastante útil tener esas categorización de versión y épica asociadas a usar historias y tareas. Muy bien, por lo que ahora se hace la planeación. Hemos trasladado nuestras historias de usuarios y tarea desde la pared hacia el Gita. Y ahora es el momento de pensar en cómo queremos un punto de historia. El punto de la historia es siempre relativo. Entonces si tengo que darte un ejemplo, voy a tomar dos piezas que tengo sobre la mesa. Esto es algo que es quire y esto es algo pequeño. Y si digo aquí este ítem, si acabo de decir que esto es en un punto de dos pisos, y si les pregunto si esto es dos, ¿cuánto es este correcto? Porque todo es relativo. Para que como se puede ver, esto es casi tres veces más alto y longitud dos veces, tal vez 1.5 veces. Así que obviamente, si digo que se trata puntos de dos pisos en tu intuición natural es que esto serían seis puntos de historia porque tres veces el tamaño de esto. Así que idealmente, se quiere llegar a un punto en el que se pueda dimensionar la tarea y el turista relativamente, comparado relativamente dos historias diferentes en lugar de historia señalándola en base al número de días y horas. Para que a medida que maduras como equipo, como equipo de Scrum, también vendrá naturalmente. Hacer esa estimación de punto de historia relativa unos a otros en lugar de mirar horas. Entonces eso es eso. Y ahora tienes todo transferido al atraso como parte de la planeación. Cuando iniciamos la fase de ejecución del proyecto, es entonces cuando crearemos el sprint y decidiremos qué usos las historias deben transferirse del backlog al sprint y empezar ejecutando este lápiz. Volveremos a eso durante la ejecución del proyecto. Ahora mismo para el propósito de planeación, todo lo que estás haciendo es transferir todos los ítems del muro o durante la sesión de planeación lo que has identificado a la herramienta JIRA o a cualquier herramienta que estás utilizando para administrar un proyecto y estimarlo poniendo o asignando puntos de historia, asignando recursos. Y luego tenías que trabajar con el gerente de producto o el propietario del producto para priorizar, ¿verdad? Cualquier cosa que esté en alta prioridad, puedes ponerlo bajo versiones o puedes arrastrar y soltar y decir cualquier cosa encima del backlog que sea la máxima prioridad. Para que puedas hacer todas esas cosas con el equipo y el propietario del producto. Y eso completa la planeación utilizando la herramienta. Y de nuevo, recuerda que esto es sólo una herramienta, la planeación que has hecho con el equipo en la sala. Esa es la verdadera planificación. Y ahora estamos usando la herramienta para organizarlo una manera que iniciamos el sprint. Es fácil ver qué se está completando. Y sé cómo se está desempeñando el equipo y todo eso. Muy bien, así que ahora vamos a echar un vistazo a lo mismo con incluso si tienes tablero Kanban, el concepto de atraso sigue siendo el mismo. Es solo que no tendrías resortes activos y Kanban, pero el proceso de transferirlo a una herramienta y crear un proyecto sigue siendo el mismo. Entonces durante la fase de ejecución del proyecto, vamos a profundizar en la diferencia entre la ejecución de Scrum y Kanban y los gráficos e informes que típicamente observamos durante Scrum y Kanban. Muy bien, para que cubra esta lección. Y en las lecciones posteriores echaremos un vistazo a cómo haríamos estas tareas en historias de usuarios en Microsoft Project. Si tienes que hacer gestión de proyectos en cascada. 23. Planificación de proyectos en Microsoft Project: Muy bien, Así que ahora como las cosas emocionantes vamos a hacer un proyecto simple, proyecto práctico. Y veremos cómo desglosar requisitos del proyecto en tareas más pequeñas. Y antes de saltar a la herramienta real en MS Project o Jira para hacer la planeación. Veamos una pizarra. Como se ve la planificación del proyecto suelen ser cómo un proyecto evolucionó de una etapa de idea a un proyecto real y planificación diferente y diferentes tareas e hitos y cosas así. Así que permítanme volver a la junta aquí y ojalá ustedes puedan verme. Llamaremos a esto un proyecto para pintar una habitación y cuenta con cuatro paredes. Habitación típica estándar. Entonces digamos que tienes una habitación aquí que necesita ser pintada. Entonces digamos que ese es el alcance. Ahora para poder hacer esta pintura, primero, tenemos que contar con recursos para hacer el trabajo. Necesitas un pintor. Obviamente necesitas pintura. Necesitas brash y accesorios, tal vez para cubrir tu piso o dos ahí para que no te derrame pintura, entonces podrías necesitar guantes y productos de limpieza. Muy bien, entonces digamos que estas son cosas que necesitas. Necesitas un pintor, necesitas una pintura, pincel y accesorios, necesitas guantes y materiales de limpieza. Entonces digamos que si estás haciendo todo esto por ti mismo, entonces tal vez tengas que preocuparte por todas estas cosas. Pero si estás haciendo esto con un pintor de lo que traería todos estos artículos, solo tienes que conseguir una cotización de él. Digamos que lo estás haciendo tú solo por el bien de gestionar un proyecto por ti mismo. Entonces digamos que no tienes que pintar o no tienes que pagar por la pintura ahí porque te estás haciendo tú mismo. Pero hay que acomodar por el costo de la pintura. Tienes que acomodar por costo de accesorios. Podrían ser materiales de limpieza de pinceles, una sartén para hacer la pintura se mezclan la pintura en cualquier cosa que se te ocurra. Y luego u en el tiempo, sólo por el bien de ver si es una buena idea hacerlo usted mismo, o es mejor externalizar? Es el pintor. Entonces digamos que en este caso, lo estás haciendo solo o una o dos latas de pintura a bronceado pardusco para mezclar guantes. Y entonces su tiempo, digamos que toma una hora por muro. Si estás buscando horario, tienes el costo aquí. Ahora este es tu horario. Este es tu costo. Y si recuerdas la triple restricción, tenemos el alcance, el tiempo y el costo al que impactará la calidad. Por lo que hemos discutido sobre el costo y el horario, y ya tenemos el alcance aquí. Pero solo para pintar una regla, así es como se verá un pequeño proyecto. Quieres descomponerlo $1 por muro en tarea más minuciosa. Por lo que entonces diría 13 minutos para quitar pintura vieja, luego en 20 minutos para aplicar imprimación, luego entrar a la pintura de diez minutos, esa pared en particular. Necesitas una hora por muro. Aquí tienes cuatro paredes. Eso significa en cuatro horas para completar la habitación. Este es un ejemplo muy sencillo de cómo planearías un proyecto donde hay que mirar a esta escuela. Y dependiendo de la escuela, hay que mirar el costo y el horario. Puedes desglosar ese horario o pintar una habitación en pintar para paredes. Y dentro de esas cuatro paredes, cuánto puedes descomponerlo, eliminar el dolor, aplicar imprimación y aplicar el primer código y el segundo código. Entonces así es como rompes la tarea. Ahora veamos cómo si tienes que entrar a esto en un MS Project o Jira, cómo se ve eso para que tengas una buena comprensión de cómo usar la herramienta para hacer lo mismo que tenemos discutido en la Pizarra. Muy bien, así que déjame saltar al Proyecto MS. Muy bien, así que tenemos un proyecto en blanco aquí. Y lo que vamos a hacer aquí es, digamos que el nombre del proyecto es pintar una habitación. Entonces cuando abres el proyecto, esta es la vista predeterminada que obtendrías. Tenemos la siguiente lección para guiarte por las diferentes secciones del proyecto. Y para entender en detalle. Pero por el momento siendo justo lo que teníamos en la Pizarra, traduciremos aquí y veremos cómo se ve eso. Por lo que teníamos nuestro proyecto gastando tu habitación. Y después tenemos muro 1234. Por lo que hemos puesto eso para completar la sala, tenemos que completar estos cuatro. Y puedes ir a la tarea y hacer una intensa para que sepas que todas estas tareas pertenecen bajo pintar una habitación y dentro una pared uno solo puedes hacer clic derecho y decir Insertar tarea y puedes insertarlo continuamente siempre y cuando lo necesite. Entonces en este caso, voy a insertar aquí tres tareas, como discutimos, 123. Por lo que dijimos para pintar la primera pared, necesitarías quitar pintura vieja. Entonces quita la pintura, entonces tienes que cebar la pared y luego aplicar pintura nueva. Estas son las tres actividades para Baldwin. Puedes seleccionar todos esos tres y luego pretendía que cuando hagas eso, ¿sabes que son artículos que pertenecen al Muro número uno, puedes repetir lo mismo o puedes simplemente Control C en Windows, y solo puede aplicar el control V aquí para pared a, después de la pared tres, ¿controlamos V? Y después para el control V. Nuevamente, por cada muro, tenías que hacer una intensa que esos sean tarea separada bajo eso, harías lo mismo aquí, tenerlo. Ahora cuando miras esto, has establecido las diferentes tareas para pintar una habitación. Se ha desglosado a cada muro y dentro de la pared se ha abigarrado hasta la tarea de subnivel minuto. Nos hemos desglosado. Esto se llama Estructura de Desglose del Trabajo, se han desglosado en detalles. Y si hace clic con el botón derecho e inserta aquí una columna y busca WBS, todo lo que está haciendo es asignar subsecciones para cada uno de estos elementos. Entonces uno es el proyecto de nivel superior, 1.11.21.31 para la tarea. Y luego está haciendo cada vez más intimidación para crear las tareas de desglose de trabajo o nivel de minutos. Entonces lo siguiente, ¿qué haces en la herramienta en MS Project o Excel? qué estamos usando es crear una dependencia para, digamos pared uno y pared a pared tres, pared cae ya que solo eres tú quien está haciendo el trabajo, tal vez no lo tengas. No se puede hacer multitarea. Tenías que terminar uno para pasar a la siguiente. Entonces dirías con el fin de arrancar muro a necesito completar mientras uno, ¿verdad? Entonces si miras a la izquierda aquí, verías un número dos. Entonces ese es el número de serie o los números de tarea. Entonces dirías, vale, tengo una dependencia y eso está ambientado en predecesores. Entonces si nos fijamos en los prejuicios, digamos que se puede decir que tengo una dependencia del número de tarea a la finalización. Entonces lo que hace el proyecto es que automáticamente toma la fecha de finalización y fuera de la tarea dependiente y luego asigna al día siguiente como fecha de inicio. Entonces aquí tenemos un problema. Digamos que en la Pizarra dijimos que va a tardar 20 minutos, una hora para hacer esto, por lo que eventualmente terminará en el mismo día. Pero por el bien, manera fácil de entender, supongamos que todo esto lleva un día H quitando la pintura, cebar una pared y aplicar pintura nueva tomaría un día de edad. Por lo que este muro uno tomaría tres días. Por lo que voy a sumar 111. Se va a llevar un día H. Y de nuevo, se tiene que hacer secuencialmente uno tras otro. Para hacer eso, puedes configurar manualmente la dependencia como dije, bueno, cebar un muro, dirías, bien, mi predecesor es tres. Pero si, si es muy secuencial, sólo puede hacer clic aquí llamado enlace la tarea. Y eso configurará automáticamente al predecesor. Haz lo mismo por estos y digamos vincular la tarea. Y haremos lo mismo por estos, vincular esa tarea. Entonces es sólo asegurarse que sea dependiente el uno del otro. Por lo que para iniciar el 16, se tuvo que completar el 15 y con el fin iniciar 17 años para completar 16. Entonces ese es el plan de proyecto se desarrolla. Por lo que de nuevo, hay que agregar todos estos para poder seleccionar estos y presionar control y seleccionar esto, todo esto. Y hay una manera fácil de actualizar si hay la misma cantidad de horas o días que tenemos que actualizar en el plan del proyecto. Puedes acudir a la información y puedes hacer una actualización grupal de un día. Se aplicará eso para todos los proyectos seleccionados que no tenga que hacerlo manualmente. Ahorra un día para cada uno de eso. Ahora que tenemos, ese día está definido para cada uno de eso, todo lo que le falta a predecesores para que pueda quitar la pintura en val2 sólo después de que usted complete el muro uno, que es el número cinco. Entonces voy a añadir eso aquí. Lo mismo con el muro Número tres. Sólo se puede comenzar una vez que haya terminado con la tarea número nueve aquí. Entonces voy a añadir eso aquí. Y en este caso, como ustedes saben, son 13, que necesitan leer completado antes de poder iniciar esta tarea. Ahora, una vez que hayas establecido las dependencias, correcto, tienes un proyecto todo el día. Con solo crear un plan de proyecto, sabrías que para completar esa habitación, se necesitan dos días. Entonces lo siguiente que quieres asignar son los recursos. En este caso, todo lo hace usted mismo. puede decir que todo está hecho por un recurso. De lo contrario, si cada uno de estos se hace por diferentes recursos, puedes y añadirlo como recurso. En este caso, nos muestra el rojo porque piensa en un proyecto damasco cosas que Nick está haciendo este trabajo, pero también les está haciendo proyectos muertos para que no tenga tiempo. Para que ese tipo de cabezas, digamos que si esos recursos se sobrecargan o no, digamos que aquí es una tarea aleatoria. Tarea aleatoria, pero necesitaba ser terminada, digamos el mismo día. Por lo que tiene una dependencia de ello es una manera de un día pero no tiene dependencia de nada. Y pensé, Ok, puedo hacer esto y le asigno aquí un recurso. Entonces te dirá que, Oye, ahí puedes hacer esta tarea. Todo lo que puedes hacer esta tarea porque Buda comienza y termina en un mismo tiempo y has tomado por completo ese recurso para ese día. No tienes el ancho de banda. Entonces esa es una forma de proyecto diciéndote que cualquier recurso sobrecargado, esto se llama nivelación de recursos. Entonces en cualquier momento que veas un recurso sobrecargado, tienes que nivelar el recurso o asignarlo a otra persona, digamos Sam, entonces en ese caso, tienes que contratar un recurso más para hacer esas tareas aleatorias porque Nick no está disponible. Muy bien, por lo que ahora tienes un buen plan de proyecto a un lado, y esto se llama el gráfico de Gantt, donde se puede ver la referencia visual de cómo fluye la tarea diferente y el inicio y el fin. Y en la parte superior tienes una vista de línea de tiempo. Y si desea agregar algún elemento a la línea de tiempo, puede hacer clic con el botón derecho y decir Agregar a la línea de tiempo. Por lo que le dirá mientras uno se llevaría de 1011 a 1013. Y mientras que a, puedes agregarlo de manera similar a la línea de tiempo. Y eso es bueno agregar para que puedas mostrártelo a tu patrocinador. Sólo esta vista. Obtienen la imagen completa de cuándo se completará cada una de las paredes. Ahora tienes un plan de proyecto completo. Con base en ese sencillo proyecto de pintar a todos mal sal, desarrollarías tu plan de proyecto desde cero, asignarías la duración, dividirías la tarea en componentes más pequeños. Estructura de desglose de libros no S, duración de tiempo asignado y recursos, y gestionar el proyecto que tenemos. Ese es un buen ejemplo pequeño donde ahora tienes una buena comprensión de cómo tu proyecto básico que discutimos en Blackboard se puede poner en la herramienta en el proyecto MS. Muy bien, por lo que próxima clase veremos cómo se hace el mismo proyecto en Agile y cómo se desarrolla para la planeación en herramienta GDI. 24. Cómo añadir fiestas y tiempo de descanso en MS Proyecto: Hey ahi, bienvenido de vuelta. En el video de hoy, te mostraré cómo agregar vacaciones en tu proyecto MS de esta manera, cuando calculas el número de días o la duración, se excluyen las vacaciones. También puedes agregar un calendario de recursos similar a los días festivos. De esta manera, si tienes recursos o grupo de recursos trabajando en diferentes regiones, digamos en Estados Unidos y Asia. Y si tienen vacaciones diferentes, entonces puedes agregar todo eso. Entonces cuando el proyecto calcula la duración del tiempo, excluye todos esos días festivos y tiempo libre. Y es una forma bastante rápida y fácil de hacer esto. Así que solo gritas para tenerlo una vez. Siempre se pueden copiar calendarios entre recursos y entre el plan estándar son, puede configurarlo para cada región. Así que saltemos a la derecha en MS Project y te guiemos a través de cómo hacerlo. Antes de eso, si eres nuevo aquí, soy Nikhil, gerente de proyectos certificado por PNP y CSM. Estoy aquí para ayudarte a avanzar en tu carrera en gestión de proyectos. Entonces eso es algo interesante. Por lo que considera suscribirse a este canal y manténgase atento para más videos. Muy bien, así que vamos a sumergirnos aquí en el Proyecto MS. Cuando abres el proyecto, esto es lo que tienes. Por lo que voy a crear un proyecto de prueba aquí y lo llamaremos como vacaciones del proyecto. Digamos que tengo por el tiempo, permítanme cambiar todo a horario automático que calculamos automáticamente. Echemos un vistazo al proyecto aquí. Entonces la información del proyecto. Entonces el proyecto va a empezar, digamos martes 11 de enero. Y en Estados Unidos, el 17 de enero es un día festivo. Así que vamos a añadir eso. Vamos a decir, está bien, digamos mi tarea de la semana uno. Por ejemplo, es una tarea de cinco días. Y esto cae bajo, puedes presionar Alt Shift y flecha para pretenderlo para que caiga bajo el proyecto. Para que como pueden ver, si empiezo el martes, termina el 17 porque el proyecto no sabe que es un día festivo. Entonces, ¿cómo superamos eso? Es que tienes que cambiar el tiempo de trabajo por lo que no hay calendario ni nada más que tengas que cambiar. Vaya por debajo de la pestaña Proyecto en la parte superior y haga clic en cambiar el tiempo de trabajo aquí. Se pueden añadir todas las excepciones. Entonces por defecto, tenemos calendario de proyectos estándar. Y si usas eso, entonces el defecto y el día y la hora es de ocho a 121 a cinco. Si quieres cambiar eso, puedes cambiar entrando en Archivo y Opciones. Esa es una opción para cambiar el horario. Por lo que aquí puedes cambiar que ocho a cinco opciones son si tu semana comienza en un día diferente. Entonces aquí es donde lo cambias. Y si tienes más de un dólar al día o 40 horas por semana, puedes cambiar todo eso bajo las opciones del proyecto. Pero lo que vamos a hacer hoy es no cambiarlos. Estoy de acuerdo con el estándar. Entra en la pestaña Proyecto, haz clic en cambiar el tiempo de trabajo. Y quería anuncio y quiero sumar unas vacaciones. Entonces digamos que el 17 es día festivo del MLK. Por lo que da click en esa fecha en particular y solo puedes dar cualquier nombre. Por lo que es mejor dar el nombre real del día festivo y presionar Enter. Así que ahora si hago clic en Aceptar, notarás que en lugar de terminar el proyecto el 17, proyecto ahora sabe que el 17 es un día festivo y de ahí empujó la fecha a un día más. Por lo que de esta manera, puedes incorporar todas las vacaciones hasta amigo, digamos, ya sabes que alimentado por las vacaciones de marzo AC. Por lo que vas a FEB, marzo y sumas esos días festivos. Por lo que las próximas vacaciones para nosotros en EU es el Día de los Conmemorativos el día 25. Por lo que puedo dar click en el 25 y añadir ese Memorial Day. Por lo que ahora eso se suma. Por lo que en cualquier momento el proyecto calcula cualquier duración entre estos dos días, se saltará esos días donde los marcamos como vacaciones. Entonces eso es genial. Entonces eso son días festivos generales. ¿ Y cómo agregamos un calendario de recursos? Entonces en cualquier momento, digamos que si agrego una tarea y le asigno un recurso, el proyecto asigna automáticamente un calendario de recursos. Entonces si voy al recurso y miro mi hoja de recursos, así que déjame revisar aquí y ver hoja de recursos. No tengo ningún recurso en este momento porque no he asignado nada. Entonces si vuelvo a la carta de Gantt, digamos que las tareas de la semana dos tienen que ser hechas por Nick. Lo siento, columna equivocada. Tuve que agregarlo bajo recursos, así que voy a añadir nick aquí. Y ya que la segunda semana procede después de la primera semana, se puede agregar aquí un predecesor escribiendo en el número dos allí que nosotros después de completar estas dos tareas se inicia. Entonces ahora si voy a la hoja de recursos del equipo y miro eso, aquí tienes un recurso estándar. Ahora el calendario para este calendario estándar de recursos. Entonces si quieres cambiar eso, para que todo lo que puedas hacer es volver al proyecto, cambiar el tiempo de trabajo. Ahora verás que es un calendario para Nick. Por defecto, sea cual sea lo que agregamos al calendario en el calendario estándar, por ejemplo, agregamos MLK Day ese false en porque estamos usando eso como calendario base. Ahora digamos que Nick se está tomando vacaciones el 18 de 19 y durante toda esa semana, digamos del 18 al 21. Se puede decir PTO. Ahora, si le asignas alguna tarea al cuello, y si volvemos al proyecto, volvamos a y Gan Chad, se puede ver que a pesar de que esta primera tarea termina el 18, nada comienza hasta el 24. Porque ahora estamos usando un calendario de recursos para el cuello y automáticamente sabe que Nick está de vacaciones durante esa semana. Y de ahí empuja hacia fuera. Eso es eso. Y digamos que la segunda semana tenemos a alguien más trabajando en el mismo nuevo recurso. Digamos que también trabaja en dos días y mismo predecesor. Y digamos que su nombre es Sam. Para él, comienza el 19 porque si miras el calendario Sands y acudes a Project y da click en cambiar el tiempo de trabajo y mira el calendario de arenas. Sam no tiene del 18 al 21 como vacaciones. De ahí que lo que agregamos para Nick solo impacta a Nick y no a Sam. Entonces esa es la ventaja de usar un calendario de recursos y cómo podemos agregar vacaciones y tiempo libre al proyecto MS. De esta manera, cuando estás planeando el número de días o la duración es más precisa. Espero que esto ayude. Y si te gustó este video, dale un like, y te veré en el siguiente. Cuídate. Adiós. 25. Seguimiento y ejecución de proyectos: Muy bien, entonces ahora hemos completado toda la planeación y ahora es la emocionante fase donde estamos ejecutando el proyecto. Es emocionante porque la mayoría de las veces nada de lo que planeamos en la fase de planeación es ir según el plan. Si alguna vez has planeado una noche de cine con tus amigos o si tienes una cita con el médico. A veces llegarás tarde porque las cosas no funcionaron, son las cosas no salieron según lo planeado. En proyecto grande o pequeño. Va a suceder en algún momento. Como gerente de proyecto, es entonces cuando eres fuerza entra en juego, cuando las cosas se descarrilan. Ahí es cuando hay que organizar y repensar y volver a estrategias todo. Si va todo según lo planeado, entonces no necesitas un gerente de proyecto. Se lo puede dar fácilmente a alguien más y ejecutar el plan. Por eso es extremadamente importante entender que las cosas no van a funcionar exactamente como estaba planeado. Es posible que siempre tengas que retocar y bordes como ego. Y en esta sección veremos metodología Cascada y Agile. Y dentro de Agile Scrum y Kanban para ver qué necesitamos rastrear, cómo lo rastreamos, y cómo nos ajustaríamos si algo no sale como estaba planeado? Ahora vamos a sumergirnos en los detalles CSO, hablaremos primero sobre la cascada antes de saltar a ágiles. Y luego dentro del Agile, vamos a echar un vistazo tanto al marco Scrum como a Kanban y veremos cómo rastreamos y bordes en esas áreas. Lo único importante a recordar cuando hablamos de ejecutar el plan del proyecto es que lo que creamos previamente en la planeación es un horario detallado de las plantas. Entonces eso no es todo. Cuando se piensa en las plantas, existen múltiples plantas que existen. La mayoría enfatiza dado al horario y el costo. Porque si recuerdas en los capítulos iniciales, esas son las triple restricciones de un proyecto. Si cambia el alcance, el costo o el horario, entonces va a impactar primero en el proyecto antes de que algo más salga mal. Entonces si nos fijamos en las plantas aquí tenemos plan de control de cambios, plan gestión de comunicación, iteración de costos, compras, plan de gestión de proyectos como plan de calidad general, plan lanzamiento , plan de requisitos , plan de recursos y planes de riesgo. Por lo que todos estos son parte de la planeación cuando planeamos con anterioridad, miramos la evaluación de riesgos. Entonces en base a ese riesgo, cuál es el plan para mitigar excepto o transferido que hay que pensar todos estos planes en el fondo de su mente. Pero el 99% de las veces, como gerente de proyecto, solo miramos el horario, que es el plan de proyecto que construimos para cascada. O si estás mirando ágil que el atraso y cómo podemos completar esos artículos atrasados. Ese es puramente el alcance y la línea de tiempo. Pero recuerda que siempre hay un costo, alcance, recurso humano, y todas las demás cosas enumeradas aquí a las que hay que prestar atención. Si tiene que enviar comunicación a cierto intervalo a los interesados y otros equipos dependientes. Si no tienes un plan, entonces te vas a perder eso. Por eso todas estas plantas son muy críticas. Es posible que no tengas un Plan de Proyecto MS detallado o en el tablero Agile, pero definitivamente tienes que tener en algún lugar donde puedas iniciar sesión en los diferentes elementos de acción que debes tomar para completar el cambio o comunicación o contratación, todo eso. Déjame darte un ejemplo de plan de gestión de la comunicación. Si estás planeando implementar algo en predicción o entorno de control de calidad, piénsalo. Es posible que la organización tenga un Q&A más grande Si desea hacer algunas pruebas, es posible que desee actualizar ese entorno de control de calidad con los últimos datos de predicción. Si no planeas esa comunicación hasta amigo, entonces es posible que no consigas el QA y Wyman por ti mismo porque podría haber otros proyectos haciendo algunas pruebas y todo eso. Entonces es por eso que es importante la Comunicación dominical antes de tiempo y decir, está bien, en este momento vamos a tener una actualización de QA. Necesitamos que se haga la actualización de QA a partir de la predicción basada en este estado. Y tenemos que hacer la prueba, y completaremos la prueba en esa ventana de uno o dos meses. Y luego puedes refrescar las preguntas y respuestas. O si quieres un nuevo entorno por completo, entonces tienes que planearlo. Entonces es posible que tenga que adquirir recursos adicionales, espacio u otro entorno, que incluye la planificación de la gestión de adquisiciones. Necesitas simplemente, no puede simplemente salir y empezar a usarlo. Puede que tenga que solicitar se construya completamente un nuevo entorno. Recuerda todas estas cosas que se les pidió que se cuiden en algún lugar de tu planeación o de la fase de ejecución porque no va a estar en el alcance ni en el plan de gestión de horarios que construimos en MS Proyecto. Entonces digamos que tienes todos estos y vamos a centrarnos en el horario por un momento porque el costo de programación son las cosas clave que si no va en camino, entonces tu proyecto va a descarrilar. Entonces, ¿cómo hacemos un seguimiento todas estas actividades tienes que usar cómo medir. Por lo que podrían ser indicadores clave de desempeño. Podrían ser métricas de entrega, pronóstico del valor del negocio de recursos, todos estos combinados juntos, se puede pensar como algo con lo que se comprometió o desde el plan del proyecto. Piensas que a fin de mes uno, puedes entregar esta cosa. Y si no está sucediendo a mediados del mes, si el 50% de esa entrega o ese componente no está completo, entonces se puede como que tenga la sensación de que va a perder el objetivo completando por fin del mes. Así es como rastreas para cada uno de los artículos, ya sea el costo del horario o alcance, miras el progreso y ves si puedes cumplir con el objetivo. Digamos que tu ventanilla es de un mes para entregar algo. Al 10 del mes, debes por lo menos completar 1 tercio de esa entrega. Si el equipo no ha completado 1 tercio, entonces se puede ver que las cosas se van a resbalar ligeramente. En ocasiones el equipo puede maquillarse durante la ejecución, pero de nuevo, se hace un puesto de control en el día 15. Por lo que en ese momento, al menos 50% de las cosas debe completarse. Y si el equipo no ha terminado, entonces es posible que tengas que volver a evaluar y ver si realmente puedes cumplir con el cronograma de entregar eso a fin de mes. Y lo importante aquí es otra vez, comunicación y mantener al equipo y a los interesados comprometidos a lo largo del proceso. Tendrías que enviar reporte de estado cada semana para compartir el estatus y liderar a las partes interesadas sepan dónde estamos. Si crees que estamos atrasados y vamos a maquillarnos y estar en buen camino para el día 20. Entonces comunícate que tienes que mantenerlos al tanto de toda la comunicación. Porque lo último como gerente de proyecto que quieres es el día 30, vienes y dices que, Hey, por cierto, nos perdimos una entrega, eso no es aceptable. La única opción es que tienes que mantener como las cosas empiezan a deslizarse, tienes que comunicarte eso y ver si necesitas escalar y obtener ayuda adicional. Para mí liderazgo sobre ti. Te buscan como gestor de proyectos para comunicarles qué ayuda necesitas o qué ayuda necesita tu equipo. Asegúrate de que lo estás rastreando y sea cual sea esta fecha del proyecto, estás comunicando eso de manera transparente para que todo el mundo esté al tanto del estado actual del proyecto. Así que ten en cuenta eso cuando te estés comunicando. Y cómo recogemos, ¿cómo recogemos los datos? Dijimos que vamos a mirar el 10 del mes y ver dónde estamos haciendo. Por lo que hay múltiples formas de recopilar todos estos datos, pero principalmente estas cosas surgirán ya sea en el Daily Standard o durante las reuniones de status. Entonces esos son los dos aquí arriba, que es el stand-up diario y la reunión de status. Ahí es donde estás recolectando y entendiendo el rendimiento del proyecto y ves si hay que ajustar algo. Por lo que recuerda también que durante la fase de ejecución del proyecto, no se trata sólo de recopilar y reportar el estado. Eso también es continuo. Otras áreas de mejora que hacemos como avance del proyecto por delante, refinamiento atrasado. Entonces cuando hicimos la planeación inicialmente, podríamos haber puesto en todas las cosas que estábamos conscientes en ese momento. Pero a medida que el equipo empieza a hacer están avanzando en el proyecto, podría haber cosas adicionales que descubramos y necesitamos volver a priorizar y sumar esas al atraso. Entonces esas son las reuniones de refinamiento atrasadas si algo necesita ser re-priorizado o agregado de nuevo a acumulación o sacarlo del atraso. Tienes que asegurarte de que esas discusiones ocurrieran en la reunión de refinamiento atrasado o priorización atrasada. La siguiente es la videoconferencia. Entonces conferencias beta que si tienes que comprar un producto, por ejemplo, tienes un software que necesitas como parte del proyecto Testing. Y hay múltiples proveedores que están brindando esta herramienta. Y no sabes cuál tienes que comprar. Entonces si es cascada o ágil, harías una prueba de concepto o haces conferencia de postores para entender cuál es el precio que Kenny permite eso en tu presupuesto de proyecto y una demo y todas esas cosas para entender con qué proveedor debes ir y comprar el producto. Entonces hay tablero de control de cambio. Por lo que la mayoría de las veces a medida que avanza el proyecto, las cosas pueden no ir según lo planeado. A veces es posible que se esté quedando sin presupuesto o tiempo. Y la mayor parte de la organización tendría un umbral de diez a 15%. Entonces digamos que tienes un proyecto de diez meses y estás planeando gastar un 100 mil para tu proyecto. Y en el mes uno entonces idealmente deberías haber gastado 10 mil. Y en el MnO2 próximos 10 mil si el horario es tal que todas las entregas suceden en cada mes por igual. En ese ejemplo, digamos a finales del mes uno, en lugar de gastar 10 mil, ya gastaste 20 mil. Estás más de presupuesto en un 10% adicional la mayor parte del tiempo que desencadenaría la junta de control de cambios. Y tienes que hacerlo. Solicita presupuesto adicional o proporciona una explicación a la junta de control de cambios mientras estás por encima del presupuesto o por debajo del presupuesto. Entonces ese es un ejemplo. Estándar diario si estás ejecutando proyecto ágil, entonces obviamente el standup diario es una necesidad. Entonces es entonces cuando se reunirían y discutieran lo que están planeando hacer para el día, qué han hecho ayer, y si hay algún impedimento que necesiten ayuda de ti como proyecto manager, ScrumMaster, otras opciones, Iteración, Planeación, revisión de iteración, esas podrían ser opcionales, puede que no esté sucediendo. El otro clave importante es la reunión de arranque, y eso sucede todo el tiempo. Entonces cada vez que se inicia un proyecto, entonces hay que tener una reunión de kickoff para establecer el equipo y anunciado al mundo en más pesado seguir adelante con esto. Y nos hemos comprometido con esto. Este es nuestro plan y aquí es donde nos van a entregar. Si tienes cosas adicionales, háganoslo saber ahora, una vez que empecemos, entonces se priorizará en consecuencia más adelante. Del lado derecho, hay cosas que suceden al final del proyecto, es decir, lecciones aprendidas. Pero si estás ejecutando proyecto de cascada o proyecto ágil, el momento puede ser diferente. Para cascada, las lecciones aprendidas sucedieron al final del proyecto. Y para los proyectos Agile, las lecciones aprendidas es la reunión retrospectiva después de cada sprint. Entonces al final del sprint o a fin de mes, si estás corriendo Kanban, te reunirías y discutiría con el equipo para entender qué salió bien, qué no salió bien, y qué cambios que el equipo tiene que hacer para hacer algunas mejoras y actualizar el progreso del proyecto y otras cosas que aquí hemos enumerado es la fase de cierre del proyecto. Obviamente al final del proyecto, no lo harías es hacia la fase de cierre. Se considera como una ejecución de proyecto. Y luego otras cosas son status y reunión del comité directivo. Por lo que podría haber algunos proyectos que son los cinco principales proyectos importantes para la organización. Y para este tipo de proyectos serán comité directivo y su proyecto necesita ser presentado mensualmente a ese comité directivo, quien sea el cuerpo de eso, será partes interesadas fuera de un proyecto, los que estén interesados en la finalización de su proyecto. Por lo que son una agenda más grande se puede cumplir o se pueden cumplir sus objetivos de programa más grandes. Por lo que esas son las otras reuniones que hay que prestar atención durante la ejecución del proyecto. Y los otros elementos que tienes que manejar de cerca aparte del plan del proyecto son tus registros y registrados. Existen diferentes registros en la fase de ejecución del proyecto los que se necesita para realizar un seguimiento. Ésos se enumeran aquí. Entonces el importante aquí se cambia log. Entonces cada vez que ocurre una gestión de cambios o una solicitud de cambio, entonces hay que registrar ese cambio. Por ejemplo, digamos que empezaste con un proyecto de sitio web en nuestro caso, para vender plantillas. Y ahora digamos que la parte interesada volvió y dijo, vale, por cierto, tenemos que agregar, además de plantilla, también necesitamos agregar tal vez un módulo de capacitación. Entonces ese es un producto nuevo en el que debes pensar. Entonces eso significa que hay un cambio en el alcance y eso es una solicitud de cambio. Por lo que hay que llenar el formulario de solicitud de cambio para solicitar cambio adicional de recursos en la línea de tiempo, presupuesto adicional si es necesario, todo eso. Entonces cuando ocurrió ese cambio, entonces hay que registrar ese cambio en el registro de cambios para que tenga un seguimiento de todos los cambios que ocurrieron después de que hayamos establecido la línea de base. El siguiente importante es obviamente el registro de temas. A medida que avanzamos en la ejecución del proyecto, siempre habrá temas. A veces en nuevo usuario tiene que ser unido y luego no tenemos licencias ni cosas así. Entonces después de que se une, no es capaz de hacer el trabajo, entonces eso se convierte en un tema. O en algunos casos, necesitamos enviar un archivo a ubicación FTP y no tenemos las credenciales, por lo que tenemos que trabajar con eso al equipo SFTP, asegurar equipo FTP para obtener las credenciales y establecer eso arriba para el proyecto. Entonces cualquier cosa que no hayamos planeado o no pensado durante la fase de planeación, esas cosas vamos a volver y mordernos durante las ejecuciones y la mayoría de las veces se convierte en un tema para el equipo del proyecto hasta que se resuelva en él. Para mantener eso en los registros de emisión y rastrear y asignar un propietario. Echaremos un vistazo al registro de temas y cómo recogemos el tema, cómo lo rastreamos, cómo monitoreamos el progreso y todo eso. En la siguiente lección cuando hablamos de auto de estado, entonces los otros registros que se usan comúnmente en proyecto es el registro de riesgos. En la fase inicial de planeación, hemos analizado la evaluación de riesgos para que pueda reutilizar ese registro de riesgos aquí. Y ahora tenemos más seguimiento del riesgo y vemos si el ítem de acción asignado al propietario que se ha completado o no. Todos los demás registros aquí son registros generales que puede o no usar en gestión de un proyecto cuando está gestionando su proyecto. Pero estos están aquí para su referencia. Y por supuesto, si estás ejecutando proyecto ágil, vas a usar el atraso porque eso, eso es una especie de tu alcance o requisito. En tanto que en el proyecto de cascada, no hay atraso. Es más el documento de requerimiento empresarial y el alcance y las cosas se rastrean y capturan en eso. Entonces el último es el registro de partes interesadas que depende del tipo de proyecto que pueda o no ser relevante. Pero la mayoría de las veces lo que hacemos es crear un array C, donde enumeramos a todas las diferentes partes interesadas y entendemos cuál es su papel en el proyecto. Racy es responsable, responsable , consultado e informado. Raci es donde sabríamos quién es responsable y quién es el responsable. Por ejemplo, si estás haciendo un proyecto de desarrollo de sitios web de desarrollo como gestor de proyectos, soy responsable, pero para hacer el trabajo real de diseñar la página web, el desarrollador, la página web sería responsable. Por lo que RACI es un lugar donde claramente trazamos quién es responsable, quién es responsable, y quién debe ser consultado e informado durante la ejecución del proyecto. Para que eso se pueda lograr a través del registro de partes interesadas. Pondré un enlace en la descripción a continuación donde se puede descargar una plantilla para registro de partes interesadas y todos estos diferentes registros aquí y también la matriz RACI y cómo se ve. Esa es la fase de ejecución del proyecto. Por lo que de nuevo, recuerda que hay que asegurarse en la fase de ejecución que lo que planeamos está progresando según lo planeado. Y si no, ¿cómo lo rastreamos y cómo lo denunciamos a las partes interesadas? Y si es necesario, invoca, cambia las solicitudes para obtener presupuesto adicional y ampliar la línea de tiempo y cosas por el estilo. Muy bien, por lo que eso resume la ejecución del proyecto. Esto tendrá más sentido cuando hagamos la práctica y observemos el plan del proyecto y el registro de temas y riesgos en esta reunión de status. Por lo general, cuando se ejecuta la reunión de estado es cuando tienes el equipo, seguirás adelante y comenzarás a actualizar el plan del proyecto, el porcentaje de finalización, actualizar el tema y el riesgo y todo eso cosa. Hablaremos de todos estos en detalle donde obtendrás más comprensión de cómo rastrear y cómo identificas problemas y retrasos durante la llamada de estado o stand-up diario? Muy bien, nos vemos en la siguiente clase. 26. Llamamientos e informes de estado: Muy bien, entonces en esta lección vamos a echar un vistazo a cómo hacer un seguimiento del progreso de su proyecto. Y la mayoría de las veces se hace ya sea en el stand up diario si estás ejecutando proyectos ágiles o en una llamada de estado semanal o quincenal cuando estás ejecutando proyectos ágiles. Una de las herramientas que vengo a amar recientemente es OneNote. Si estás utilizando productos de Microsoft en tu organización. Entonces tendrías un nodo seguro. Y la razón es que es muy simple y sin embargo muy poderosa. Y puedes organizar cosas, especialmente si estás ejecutando varios proyectos. Así que déjame compartir mi pantalla y mostrarte lo que me gusta de este OneNote y cómo puedes organizarla. Y luego echaremos un vistazo a cómo típicamente ejecuta un informe de estado y ¿cuál es el beneficio de correr de esta manera? Para que como se puede ver aquí, de forma predeterminada, tiene automáticamente secciones y páginas. Para que puedas organizar las cosas de una mejor manera. Entonces si tienes uno-a-uno con tus partes interesadas y directivos, de nuevo, añádelo como sección y di Encuentros uno-a-uno. Y cualquier cosa relacionada con eso, puedes agregar esas páginas aquí. Por lo que a veces es posible que quieras reunirte con solo el equipo. Y digamos que en este caso, te encuentras con Sam para entender si hay alguna dificultad en lo que está haciendo. En ocasiones hay que reunirse con el CIO o con alguien más para entender lo que necesitan del proyecto. Entonces no se mete entonces en otras cosas que tienes otras secciones. Por lo que se queda dentro de esa reunión uno-a-uno. Lo que vamos a hacer es aquí tenemos proyecto hacia, tenemos aquí es que vamos a agregar una sección para la página web de plantillas de proyecto. Entonces de esa manera ese es nuestro proyecto. Y lo que podemos hacer es que podamos tener una página aquí y por defecto hay una página sin título. Así que voy a hacer uso de eso y lo llamaremos como estado semanal. Y puedes usar cualquier David que vaya a pasar todos los viernes o todos los lunes, cuales sean los días que puedas escoger ese día. Entonces en este caso, va a pasar todos los lunes. Entonces voy a decir que esto sucede el tercero de Ene si tienes reuniones, por lo que siempre puedes insertar aquí los detalles de una reunión. Entonces si hay calendario que sale al equipo cuando en cambio los detalles de la reunión. En este momento no tengo ninguna reunión, así que por eso no lo verás. De lo contrario, cualesquiera que sean los participantes que tengamos en esa reunión invitan a esos. Subiremos aquí automáticamente. Si no lo hace, entonces siempre hay una manera. Si ese no es el caso, entonces siempre se pueden agregar algunas casillas de verificación aquí. Entonces la mejor manera de hacerlo es en lugar de balas, solo se puede decir que hacer. Y puedes sumar cuello San Joe, quien sea parte de un equipo, solo podemos añadir eso. Y cuando Jain entonces puedes hacerlo. Marca de verificación aquí. Esa es la lista de participantes. Para que puedas llamar a eso como participante. Sube y elimínalo, y digamos participantes. Y si lo quieres, solo puedes negrita para que sepas que es una sección. Y la siguiente es la agenda. Desea revisar riesgos y cuestiones, revisar cualquier solicitud de cambio de cambio. Y lo primero que siempre hago cuando tengo estatus es el flujo de comunicación, nuestras comunicaciones desde aguas arriba o aguas abajo. Entonces esa es la agenda. Y luego a continuación vamos a hacer son temas, temas acción, discusiones generales. Les haré saber por qué estas secciones son importantes. Porque solo tienes que crear los y luego puedes reutilizarlo cada semana. En temas siempre inserto una tabla. Entonces puedes copiar pegar en el excel o cosas así con bastante facilidad. Por lo que tendrás número de serie, emisión, nombre, detalles de emisión, propietario, fecha de vencimiento. Y probablemente la otra cosa es que quieres agregar el estatus. Entonces si es estado abierto, eso son temas. Riesgo. Puedes volver a tener lo mismo aquí. Ahora he llenado todo el asunto, así que esta va a ser mi plantilla. Cada vez. Lo que pasa es que solo guardo esto como plantilla para que sólo pueda copiar y decir copiar esto y agregar una página. Y puedo llamarla plantilla de estado S que nosotros, cada vez que hemos estado reuniendo cada semana, solo puedes actualizar o copiar esta plantilla y luego cambiarla a otra cosa. Por lo que tengo aquí una plantilla de estado, así que eso va en la cima. Entonces tengo una reunión semanal sobre. Tercero, tengo una reunión semanal en pluma. Digamos que estoy en la tercera reunión de Ene que tengo que hacer es cuando haga la pantalla-compartir, lo haré como pantalla completa. Y luego. No se distrae por ninguna otra sección ni ningún otro proyecto. Todos los participantes ven aquí es esta página. Y lo mejor aquí es como la gente se unió entonces puedo decir, Ok, Hi Nick gigante, Sam Jain. Y a medida que la gente se une, puedo actualizar eso en la agenda. así como lo estructuré porque una vez que la gente comienza a unirse y como gerente de proyecto, es gente comienza a unirse y como gerente de proyecto, posible que tenga más información que el miembro del equipo no lo hizo. Por lo que hay que comunicar ese flujo aguas abajo de lo que tuvieras desde tu liderazgo hasta el equipo del proyecto. Entonces comenzaría con ese flujo de comunicación y agradeceré a todos por sumarse a la convocatoria y luego comenzar la reunión de esa manera. Y el siguiente ítem aquí es la revisión de estado del proyecto. Antes de meternos en eso, preguntaré si hay alguna actualización o algo que dijera que el equipo quería sacarlo antes de saltar a los detalles. Y si hay algo que sea crítico, entonces lo agregaré a las discusiones del tema y agregaré los detalles. Entonces eso va bajo discusión general y de esa manera se está comunicando todo. Y la parte buena es porque está en una página y tienes una sola página para cada reunión. A lo largo del proyecto, siempre se puede volver atrás y mirar qué acción, qué riesgo, qué decisiones se tomaron, y en qué reunión. Entonces algo que es realmente fácil de rastrear con la herramienta OneNote. Ahora echemos un vistazo a la revisión del estado del proyecto aquí. Estamos revisando el estado. Entonces la mejor manera de hacerlo es típicamente, voy a tener los puntos con balas son las cosas que hay que completar esta semana. Y luego preguntaré sobre el estado en la reunión. No voy a plantear el plan del proyecto. Te haré saber cómo lo hago típicamente. Por lo que voy al proyecto que creamos durante la fase de planeación, entonces cualquier cosa que se deba para esa semana. Y necesito actualizar eso con la información del proyecto. Entonces así es como lo rastreas. Así es como sabes si estás corriendo por delante o atrasado. Entonces digamos que tenemos la reunión está en el OneNote. Si vuelvo aquí, esta es la reunión para el VQ de 13, lo que significa que después de que finalice esa semana, eso ha estado acogiendo esta reunión. Entonces cualquier cosa que esté pendiente para ese 13 al 107, ahí es donde quiero conseguir la información. Entonces obviamente voy a agregar una columna aquí y llamarla como columna de inserción. Y persona-días completos. Cuando el equipo pase por la reunión de estado del proyecto, les preguntaré sobre el estado y así es como lo rastreo. Al igual que estoy de vuelta y pregunte, hemos finalizado el alcance, qué es el gasto? ¿Está hecho? Entonces D podría volver y decir, Sí, casi está hecho. Estamos 90% ahí. Necesitas finalizar ciertas cosas. Así que obviamente entonces puedo venir aquí y decir, está bien, estamos 90% terminados. Entonces, ¿cómo sabemos que este 90% es bueno o malo? Digamos que estamos en el viernes y yo entrega debería tener al 100%. Entonces ahí es donde entra el seguimiento. Para que puedas agregar una columna aquí llamada status. Verás indicadores de estado. Entonces cualquier cosa que esté en rojo, esas son las que están corriendo atrás porque está comprobando contra la fecha actual. Por lo que a partir de ahora, todos estos en Jan está marcando como retrasado. Esto no está terminado, dice que marca de garrapata se dice que está en horario. El proyecto está asumiendo que está a tiempo debido a que la fecha de finalización es en la Fed y no en enero. Así que cualquier cosa en Ene, lo está marcando como tarde. Entonces una forma de ver eso con precisión, Es bueno proyectar información y fijar la fecha actual como, digamos séptimo. Entonces si estás mirando el proyecto a partir del séptimo, entonces solo mirará las cosas que se van a completar antes de la séptima y resaltar las como hilo. Esta es una manera fácil de entender visualmente porque si se trata de un proyecto grande, es difícil pasar por cada fecha y ver ¿estamos por delante o atrasado? Project lo hará automáticamente haciendo indicador de estado. Se trata de un indicador de estado incorporado en el proyecto MS. Pero lo que me resulta difícil es a veces quiero incluso saber que algunas cosas como aquí donde dice que esto está en camino porque el séptimo no se hace porque actualizamos los datos del proyecto siete. Por lo que literalmente proyecto está pensando en fin de día viernes para completar esto, el 90% es bueno. Y si fue del 80%, entonces todavía dice que es bueno. Aquí hay algún umbral. Entonces cuando es 70% sólo entonces me muestra como rojo o un no lo hace en pista. Entonces, en lugar de que el proyecto determine si está en marcha o no, típicamente tengo una fórmula manual incorporada que puedo usar aquí. Y puedo tener estado de columnas indicadas que quiero hacer. Entonces por ejemplo. Si quisiera saber algo que se avecina en las próximas dos semanas, mostró todas esas tareas como semáforo amarillo en esta columna. Yo puedo hacer eso. Por lo que he cubierto eso manera detallada en mi blog y mi página web de YouTube. Entonces pondré ese enlace en la descripción aquí, porque solo puedes seguir eso si alguna vez quieres hacer eso. Pero esto es solo un ejemplo de cómo rastreamos en base a lo que reporta el equipo del proyecto. Dijeron que está 90% completo. Y si confían en que a finales del viernes que puedan completar el 10% restante. O para el lunes, al menos han tomado completo un 100%, entonces eso es bastante bueno. No tienes que denunciar eso como un tema. Pero vamos a salvar al equipo del proyecto en el estatus llamado ASA que golpeó, por cierto, no hemos terminado. Sólo se ha completado el 40%. Y la razón por la que no pudimos completar esto, porque sea cual sea el tema XYZ, porque sea cual sea el tema XYZ,es cuando entras aquí y dices, vale, entonces tenemos un tema ahora porque un alcance, así que ese es el tema, alcance indefinido. Vamos a decir que el alcance está indefinido y detalles de emisión es que la BA no está disponible para completar el requisito y de ahí que el alcance no se finalice. Ese es un tema que alguien tiene que tomar una acción. Entonces en este caso, obviamente, como gestor de proyectos, debes tomar esa acción. Y usted tiene tal vez dos o tres días para completar esto porque de lo contrario el proyecto va fuera de pista. Por lo que se asigna una fecha de vencimiento fuera, sea lo que sea factible. Entonces voy a sumar tal vez 13. Y luego veremos que el estatus está abierto. Entonces una vez que tienes eso, entonces ahí tenías el tema. Entonces así es como haces la llamada de status o el estándar e identifica qué temas enfrenta el equipo del proyecto. Y en base a lo que están reportando los Nuevos entienden que hay un tema o no. De igual manera, hay algo, digamos, una tarea próxima en el plan del proyecto. Y digamos que no es ahora, pero existe el riesgo de que para la próxima semana del día 14, si los BAs no están disponibles, entonces potencialmente lo mismo, bueno, aún más descarrilar el proyecto. Puedes agregar que como el riesgo BA puede no estar disponible para trabajar en el proyecto y propietario, puedes asignarlo y necesitas hacerlo bastante rapidez antes del 14, antes de esa fecha de vencimiento, tienes un riesgo y un tema. Este es solo un ejemplo sencillo para mostrarte cómo se construyen estas cosas durante la fase de ejecución. Y el ítem de acción estaría sobre ti decir que se reúnen con bonos o para conseguir recursos adicionales hechos con el patrocinador antes de tiempo para discutir sobre esto y luego tener alguna resolución. lo que este es un ejemplo sencillo solo para que comprendas cómo manejas el seguimiento, recopilación de información, reportas un riesgo y temas a tu liderazgo o a tu patrocinador y todo eso. Entonces esta es una forma muy efectiva. Y OneNote realmente lo ayuda porque todos tienen acceso a un nodo. Y al final de la llamada solo puedes Controlar, seleccionar y Controlar C. Poner los elementos de acción en una tabla, en un correo electrónico o puedes enviar toda esta página. O si tienes equipo y cosas así, tienes una opción para copiar link de esto. Entonces déjame mostrarte cómo hacer eso. Salgan de la pantalla completa. Simplemente se puede decir aquí compartido y se generará un enlace. En este caso, no he iniciado sesión en MS Team. Por eso me está dando un error. Pero de lo contrario obtendrías un enlace que puedes compartirlo. Y luego solo puedes copiar pegar solo los elementos de acción de las personas que han identificado que tiene una acción y luego enviarlo. Cuando hagas la próxima reunión de la semana. Si todavía hay elementos abiertos desde aquí, entonces obviamente puedes copiar pegar y poner eso en los ítems hay tablas aquí. Y puedes empezar a preguntar sobre el estado en eso. Entonces ese es un proceso continuo en curso hasta que cierres todos los temas o desconexión. Entonces eso es todo sobre la captura de datos. Y ahora tenemos que mirar cómo denunciamos el estado final a su alta dirección, su patrocinador, u otros. Entonces para eso, es un simple PowerPoint de una página. Y típicamente lo que hacemos es tener un PowerPoint creado. Ok. Ahora hemos recabado todos los detalles durante el reporte de estado llamada estándar si es una ágil dondequiera y ahora es el momento de enviar el estatus hasta el patrocinador superior de la gerencia o otras personas en el proyecto. Entonces este no es el mismo ejemplo, sino solo para darte cómo se ve la plantilla de estado en la parte superior, es bueno tener un resumen del proyecto porque cuando envías el estado, no todos preguntan cerca del proyecto. Entonces el resumen del proyecto es un ejemplo rápido o forma de control de calidad para recordarles de qué se trata este proyecto. Entonces enumeras a todas las personas clave. Entonces en este caso, patrocinador, gerente de proyecto. Y si tienes que enumerar a algunos otros interesados, puedes agregar una columna y agregar eso. También se agrega la fecha de inicio y finalización del proyecto para que quien esté recibiendo esta plantilla, estén en un alto nivel cuál es la línea de tiempo del proyecto. Y luego si hay algún ID de proyecto asignado por la organización en eso. El presupuesto general, el gasto del año hasta la fecha y cuándo estás planeando ir a vivir. Por lo que estas son información realmente crítica que típicamente se asocia con el proyecto. Y si hay algo más que quieras agregar, siempre puedes personalizarlo. Nuevamente, el OneNote y el PowerPoint. Agregaré el enlace en la descripción a continuación para que puedas descargarlo si necesitas referirte o crear uno para ti mismo. Y típicamente lo que queremos hacer en un informe de estado es que se puede pensar en esto como un bloqueador completo que tiene cuatro secciones. En la primera sección de la esquina superior izquierda, tienes realizaciones. Entonces ahí es donde estás diciendo que lo que el equipo logró durante esta semana y enumerar todos los de esa sección. Y en los próximos hitos, puedes enumerar todas las cosas que va a pasar en las próximas dos semanas o cuatro semanas dependiendo qué información o cuán precisa puedas pronosticar eso. Pones eso aquí. Y cualquier tema y riesgo que necesites ayuda con este patrocinador o cualquier persona a la que estés enviando este reporte, luego resalta esos riesgos y temas para que sepan que qué riesgo son temas con los que necesitas ayuda y cómo pueden ayudar a resolverlo. Si hay elementos de acción del proyecto basados en la reunión de estado, entonces se agrega eso en los elementos de acción. Entonces cuando haces eso en el mismo formato de columna que teníamos en el OneNote al PowerPoint y se vuelve realmente fácil hacer eso. Esta página es lo suficientemente buena, pero si lo desea, siempre puede agregar una página adicional como hitos del proyecto. Para que así puedas enumerar la tarea diferente y dar al patrocinador o a quien estés enviando esto a una imagen completa. Y tal vez puedas agregar una línea en algún lugar aquí y mostrar que SLI hoy para que así lo sepan bien, hoy vía aquí. Y queremos terminar aquí, ¿verdad? Esa es una patada otra herramienta o plantilla que tienes que enviar al final del pico o de una base diaria o una vez cada mes dependiendo del requisito de tu proyecto. Entonces esas son las cosas clave que tenemos en esta convocatoria de status y el reporte de estado. Y espero que estas herramientas, puedas usarla exactamente así o puedes inspirarte en esto y desarrollar tus propias plantillas y herramientas para rastrear el progreso de tu proyecto. Lo clave es que durante la ejecución, pueden esperar temas y cómo abordan eso, cómo se obtiene la información sobre el tema y cómo lo resuelves, cómo se hace lluvia de ideas y abordarlo con el equipo. Ese es un componente clave que haces como gestor de proyectos. Y tendrías mucho éxito si estás organizado. Y puedes rastrear los temas y abrir ítems de una manera que he mostrado aquí. Y lo que haremos en la próxima lección. Echaremos un vistazo a las diferentes plantillas de Excel para rastrear el ítem de acción, registro de emisión y obstrución de riesgo. De esa manera si necesitas descargarlo y usarlo para tu proyecto, puedes hacerlo. Muy bien, lo veremos en la próxima lección. 27. Registro de decisiones de acción de temas peligrosos: Muy bien, por lo que en esta lección vamos a echar un vistazo a todos los registros y la acción de emisión de riesgos cambian todos los registros y log que necesitamos para rastrear aspecto de la ejecución del proyecto. Así que déjame saltar a la pantalla aquí. Por lo que tenemos primero un registro de acciones. Por lo que he combinado todos los diferentes registros en múltiples pestañas. Para que así te sea fácil descargar, pero si quieres mantenerlo como archivo separado, puedes hacerlo. Por lo que tenemos el registro de acciones, registro de emisión, registro de decisiones, registro de cambios, y luego registro de riesgos. Un registro de riesgos, si recuerdas, esto es exactamente lo que usamos durante la fase de planeación del proyecto, por lo que podemos seguir utilizándolo porque a medida que ejecutamos, podemos tener un riesgo adicional identificado y se puede empezar a capturar eso aquí. Registro de acciones de nuevo, es la misma herramienta simple que usamos. Y si recuerdas el ejemplo anterior o la lección anterior donde habíamos identificado temas y riesgos durante la reunión de estado del proyecto. Este Excel es básicamente copiar pegando esos elementos identificados en el registro respectivo. Cualquier cosa que identificáramos durante la reunión de estado del proyecto como temas que van bajo el registro de temas aquí. Entonces si voy a emitir ficha Log, hemos identificado un tema que tenemos alcance no definido porque la ba el analista de negocios que no estaba disponible para completarlo y quién tiene la acción y cuál es el status en Excel, tienen la opción de filtrarlo. Entonces eso es la ventaja de transferir de un nodo a excel porque puedes ejecutar informes que puedes rastrear, y puede tener datos, filtro de datos y todo eso. Para que puedas personalizar de una manera que sea fácil para ti gestionar eso. Entonces ese es el registro de temas aquí. Si salto hacia atrás, también hemos identificado un riesgo de recursos. Por lo que podemos añadir esto a nuestro registro de riesgos para que sólo pueda copiar esto. Volver al registro de riesgos y decir que tenemos lista adicional que identificamos. Y esto es por recurso. Y puedes empezar a escribir en toda la copia en los detalles aquí. Entonces diríamos recurso. Y la probabilidad de que eso suceda es tal vez por alta probabilidad. Y el impacto puede ser medio o bajo a medio. Y el dueño que aquí hemos identificado es Nick. Y podemos añadir eso y necesitamos mitigar eso e identificar a alguien del equipo que pueda completar el requisito. Y la fecha de vencimiento que tenemos aquí es 114. Por lo que se puede añadir eso y hasta que se cierre, todavía está abierto. Entonces es así como transfieres de una reunión de status a un registro. Entonces este es un ejemplo rápido por qué mantenemos diferentes bloqueos en el Excel, porque puedes agregar y eliminar y hacer un filtro y todas esas cosas buenas. Cambiar registro aquí es ahora necesitamos agregar un módulo de capacitación al proyecto que sea un alcance adicional. Entonces la acción aquí es conseguir financiamiento adicional. Por lo que asignas eso a patrocinar y lo mantengas abierto hasta que eso se resuelva. Una vez finalizado el proyecto, se puede ver el registro de cambios para ver cuál fue el alcance inicial de la línea base y qué cambió todo durante la ejecución. Si hay alguna decisión o en este caso, se tomó la decisión de sumar el módulo de capacitación que aquí se agrega y dos es confirmado por patrocinadores o posteriormente. Si estos bonos que nuestro CEO dejó la empresa y alguien miró la carta del proyecto donde no se mencionó esto y te cuestionan como gerente de proyecto en cuanto a, oye, por qué le preguntaron este módulo de capacitación, que no está en la carta ni en el caso comercial. Entonces, ¿de dónde viene esto? ¿ Entonces? Se puede demostrar que, oye, tuvimos esta decisión tomada en este día y fue hecha por el patrocinador y CIO. Y también habíamos iniciado un registro de cambios y este es el estado. Entonces es por eso que mantener todo este log y temas son muy críticos e importantes porque el equipo puede cambiar continuamente. Y como PM, necesitas hacer un seguimiento de las cosas, qué cambió, ¿en qué momento? Si es auditado o alguien más entra en la imagen, entonces tienes los detalles detrás de los cambios. Elementos de acción es cualquier cosa que sea un elemento abierto que alguien tiene una acción y necesita ser completado. Y puedes revisar todo esto durante la reunión de estado y puedes filtrar por la fecha de vencimiento y también por el estado abierto. Y puedes revisar eso con el equipo y decir, Estos son los ítems abiertos. ¿ Dónde estamos en eso? ¿ Qué ayuda necesitas y cuándo podemos esperar que se complete? Entonces ese es un buen ejemplo de cómo manejas diferentes registros y la importancia de cada log. Espero que hayas entendido la importancia de todos estos diferentes registros. Y si lo desea, puede descargar esto, la descripción del archivo a continuación, y puede mantener esto como archivos individuales o puede mantenerlo como un solo archivo con múltiples pestañas dependiendo de cuán grande va a crecer esto. Muy bien, para que concluya las cosas primarias que hacemos en la ejecución. Ahora es el momento de celebrar el proyecto go-live. Y en el próximo capítulo vamos a echar un vistazo al corte de planeación Go-live y cosas por el estilo. 28. PLANIFICación de CUTOVER GOLIVE: Ahora es la parte emocionante. Hemos completado el proyecto y estamos listos para entrar en vivo a la producción antes de hacer ese salto final producción y hacer que su servicio o proyecto o producto esté disponible para que los usuarios puedan consumir y usar. Tienes que asegurarte de planificar tu actividad de corte con mucho cuidado. Porque ese es el rompetrato. Si mueves algo a la producción que no va a funcionar bien, entonces va a ser un desastre. Entonces tenías que asegurarte de que tu plan de corte esté muy bien pensado. Y si hay algún problema, siempre se puede retroceder a un estado anterior. Veamos cómo se ve el recorte Actividades y qué debemos considerar a la hora de planificar el corte? Entonces lo primero es que tienes que clavar el tiempo exacto de corte. ¿ Cuándo exactamente estás planeando completar la migración a la producción? Por ejemplo, si está planeando mover los cambios en el sitio web, posible que desee considerar o identificar el momento en que el tráfico a ese sitio web es muy bajo para que el impacto de los clientes y usuarios sean muy bajo porque el corte no va a ser solo flip de un interruptor y hecho. Es una larga nuestra actividad y podría tomar tal vez un par de horas o medio día para completar todas las actividades de corte. Serán tiempo de inactividad donde los usuarios no podrían acceder al sitio web o cualquier proyecto, servicio o producto que esté planeando pasar a predicción si tiene su cuenta bancaria, acceder al sitio web o cualquier proyecto, servicio o producto que esté planeando pasar ala predicción si tiene su cuenta bancaria, podría haber visto a veces un mensaje saliendo que el mantenimiento es este domingo, así que esperen tiempo de inactividad durante el vuelo a las 07:00 PM Este o lo que sea ese marco de tiempo que se haga para asegurarse de que el sistema, se derriba el sistema de producción, todo el mantenimiento y los cambios hacia arriba, empujar hacia atrás, y luego ponerlos de nuevo en línea. Entonces tienes que hacer exactamente lo mismo por tu proyecto. Hay que ver cuándo es el mejor momento para bajar los sistemas de predicción. Empuja todos tus cambios, tu código, tus archivos de configuración, todo lo que necesites hacer para pasar a la producción, hazlo durante el tiempo de corte. Y una vez que todo se mueve a producción texturizado, entonces traes la predicción y mamá y respaldo. Así es típicamente como se hace. Entonces por eso es muy importante que planifiques la línea de tiempo de corte y también asegúrate de tener todos los recursos disponibles para hacer todo el trabajo que se planea para el corte. Digamos que tiene asistencia requerida para el momento de la base de datos. Y si usted no ha planeado para el corte, entonces ese recurso podría no estar disponible y podría impactar todo su proceso de corte si hay ubicaciones de oficinas o sitio que están recortando, por ejemplo, nos estamos moviendo de un lado a un nuevo sitio. Entonces tienes que asegurarte de tener acceso a esos sitios después del horario regular de oficina. Por lo que hay que asegurarse de que la seguridad y otros informaron al respecto y estén disponibles para asegurarse de que pueda entrar a la nueva oficina cuando haga el corte. Y también hay que pensar en el plan de reversión. Lo que eso significa es que si algo sale terriblemente mal, entonces deberías poder reincorporarte a un estado anterior donde funcionaba bien. Entonces hay que identificar qué pasa si algo sale mal y cómo se puede retroceder a un estado anterior o a su estado donde funcionará con algún impacto mínimo. Y si hay algún requisito legal o regulatorio de los que necesite obtener la aprobación, esos deben tomarse con mucha anticipación porque lo más probable es que el corte vaya a ser durante el fin de semana cuando el tráfico es bajo y conseguir aprobaciones en un fin de semana va a ser un reto. Por lo que hay que pensar todos estos diferentes aspectos y luego planear su corte. Yo diría que la mejor analogía que se te ocurra es cuando te mudas de un departamento para entrar al departamento, o estás mudando tu casa de, digamos, de una parte del país a la otra. No puedes simplemente decidirte un día y mudarte porque tienes que asegurarte de que sean empacadores y más peor y cuándo van a venir a tu casa y a qué hora completarías el mover y luego entregar la llave al propietario. Por lo que hay diferentes componentes que sucede como parte de este proceso MOOC. Entonces la cartografía es exactamente la misma. Hay que planificar hora a hora o a veces minuto a minuto qué acciones deben suceder para que se haga todo el proceso de corte. En este ejemplo de mudanza, es posible que tenga que planear anticipación tal vez dos o tres semanas antes de tiempo para asegurarse de que está disponible el servicio de mudanza y darles una ventana de tiempo que tienen para venir a las nueve de la mañana y empezar a moverse y hacerse con él a las cinco de la tarde. Y luego en la nueva ubicación, hay que asegurarse de que a las cinco de la tarde pueda mudarse y tenga electricidad, agua, todos esos servicios disponibles y cosas por el estilo. Por lo que hay que asegurarse de pasar tiempo suficiente para enumerar todas las cosas que necesitan pasar durante esa ventana de corte y tener un plan y recursos asignados a esas y tiempo exacto como a lo que tiene que pasar y quién lo hará. Por lo que de nuevo, es muy crítico que cualquier aprobación que necesites, tengas que adelantarte a tiempo porque lo más probable es que en el último minuto, no quisieras correr para ninguna aprobación. Si hay alguna comunicación que necesite salir por el corte o cualquier tiempo de inactividad donde los sistemas no sean accesibles. Cualquier requisito previo como capacitar los empleados sobre el nuevo producto o proyecto o servicio. Y todos esos necesitan planificarse con anticipación y comunicarse cuando eso deba completarse durante o antes del corte. También tienes que pensar en cuándo quieres tener sesiones de capacitación disponibles para los usuarios? Y hay que asegurarse de que el entrenamiento esté atrapado porque si los usuarios no están capacitados en este nuevo sistema o cómo utilizar este nuevo sistema, siempre habrá desafío después de la Entrarán las quejas de corte. Tienes que asegurarte de que estén equipados para entender este nuevo proceso, la nueva tecnología o nuevo producto que estamos empujando. Y se sienten cómodos usándolo porque lo contrario será un reto durante el tiempo de soporte de corte. Y por último pero no menos importante, hay que asegurarte también de tener algún puente llamado configuración para que la gente, si se encuentra con algún tema, puedan llamar a ese puente común. Y alguien que esté disponible para responder y aclarar y apoyar al usuario si se encuentra con algún problema. Entonces planee un puente abierto, una línea telefónica, o una computadora, un correo electrónico, sea lo que sea, asegúrese de que alguien esté monitoreando eso y brinde esa información de nuevo a los usuarios. Entonces si alguien después del corte entra en algunos temas y quieren ayudarlo, saben cómo ponerse en contacto y a quién ponerse en contacto. Por lo que es muy crítico que apoye al usuario proporcionando todos estos detalles con anticipación. Entonces, en general, el go-live es un proceso muy nervioso. Pero si planeas tu corte y vas a vivir, muy por delante y enumerar todas las cosas que necesitas cuidar, entonces las cosas irán sin problemas y estarás bien. Es un esfuerzo de equipo. Se asegura de discutir con el equipo todos los artículos que hay que cuidar, cualquier plan de reversión que deba discutirse y documentar todo eso para que cuando algo salga mal, sabrías exactamente lo que hay que hacer en ese momento. Entonces es por eso que la planeación de corte es tan crítica porque de lo contrario te puede dar problemas y dolor de cabeza para tu proyecto en el último minuto. Por lo que en la sección de recursos, puedes encontrar alguna lista de verificación de corte que puedes usar para cualquier proyecto de TI para verificar si tienes que hacer todas estas cosas y siempre puedes contarle la lista de verificación a sus necesidades. Pero hábitos, listas de verificación listas para su corte para asegurarse de que las cosas vayan más fluidas. Y en la siguiente lección vamos a echar un vistazo al soporte hiper caso. Este es el soporte de garantía. Entonces después de nosotros con éxito recortar y ahora estás en vivo en producción, pero todo es nuevo para el usuario. Por lo que hay que asegurarse de que el equipo del proyecto esté disponible para apoyar a los usuarios que llamen al menos durante una semana, si no dos semanas, y esos se cubrirán en la siguiente lección. 29. Soporte en Hypercare: Muy bien, entonces ahora nos hemos ido en vivo con éxito y ahora es el momento de apoyar los usos para responder cualquier pregunta que pueda tener retos que estén enfrentando después del go-live. Por lo que HyperCools soporta este es tu periodo de garantía. Después de ir a vivir. Es necesario apoyar al equipo y los usos para los próximos días o hasta dos semanas si es posible. Idealmente, se puede pensar este activo 247 de apoyo posible. Entonces ese es alguien a quien atender la causa dependiendo de dónde llamen los usuarios. Si eres un equipo global, entonces obviamente podrías esperar llamadas de diferentes países durante todo el día. Entonces es buena idea tener a alguien que apoye los puentes. Nada más que una línea abierta donde la gente pueda marcar para que las preguntas se aclaren o respondan. Entonces eso es lo que hay que pensar sobre Penn instalando el puente de hiper cuidado. Por lo que típicamente se puede escuchar como salón de baile o puente abierto dedicado. Entonces cualquiera puede llamar. Esta información sería algo que avisarías a los usuarios con anticipación mucho antes del go-live para que estén al tanto de que hay una llamada de soporte o puente de soporte disponible en caso de que se ejecuten en un tema para que puedan obtener el apoyo que necesitan con el nuevo sistema después Go-live para hacer que la Hypercard llamara de apoyo a alguien y menos desafiante es que tengas varias personas en la habitación en lugar de una sola persona. Y mientras mantengas los usos con documentos de conocimiento, videos de capacitación, y sesiones de entrenamiento antes de la Go-live, entonces tus llamadas Hypercard serían muy menores porque los usuarios ya saben usar el nuevo sistema, por lo que no necesitarían mucha ayuda. Pero seguirían siendo usos que se han perdido las sesiones de entrenamiento y aún lo llamarían. Por lo que en ese momento, se pueden compartir las sesiones grabadas o cualquier otro recurso de capacitación que se los pueda dar para que puedan ver qué hacer con el nuevo sistema. Y eso podría resolver su problema, por qué están llamando. Por lo que estas son algunas de las cosas en las que hay que pensar al configurar la sala de pared o el soporte en mayúsculas, o un puente abierto donde la gente pueda llamar si tienen preguntas después del Go-live. Y dependiendo del tamaño y el ancho de banda, puedes tenerlo a un equipo global más grande o solo puedes tener una o dos personas apoyando esto. Esto es previo a la transición del proyecto a equipo de apoyo. Es una buena idea involucrar a una o dos personas del equipo de soporte para que entiendan qué tipo de llamadas esperar y qué respuestas estás brindando y dónde se ubican los recursos para que sepan apoyarlo después del periodo de garantía, después de dos semanas. Eso es todo por esta lección. Es una lección corta de cocinero y solo dar una idea de cómo se ve el soporte hiper caso. ¿ Qué significa y en qué hay que pensar antes de configurar una llamada de Hypercard. 30. Lecciones de cierre de proyectos aprenden: Muy bien, ahora ya hemos completado el proyecto y es hora de cerrar el proyecto, pero no te apresures y no cierres tan pronto como termines con la última tarea, aún tienes que hacer ciertas cosas para cerrar adecuadamente el proyecto. Entonces una de las cosas que recomiendo mucho hacer es una sesión de Lecciones Aprendidas con todo el equipo. Si bien tienes el equipo, esta es la oportunidad perfecta para entender ciertas cosas en los proyectos para que puedas mejorar la ejecución de tu proyecto y los proyectos posteriores. Entonces, antes que nada, revisemos como equipo lo que salió bien. Entonces antes de saltar a esto, lo que quieres hacer es mandar una junta retrospectiva o cualquier tablero donde puedan pensar en lo que salió bien para que puedan capturar esas cosas antes de reunirse. Si tienes un proyecto de un año de duración, es altamente imposible que todos lo recuerden. ¿ Cuáles son las cosas que salieron bien para darle al equipo una o dos semanas para pensar en lo que salió bien. Para hacer eso, cuando recuerdan algo antes de entrar en lecciones aprendidas, tienen un lugar donde anotarlo. Por lo que uso un tablero llamado fondo retrospectivo IN.com. Pondré el enlace en la descripción a continuación, pero puedes usar cualquier otro método como MS Planner o cualquier producto de Google. Entonces lo que estás buscando aquí es identificar las cosas que tuvieron éxito para que puedas repetir esas cosas en tu próximo proyecto, todo caso, que hayas hecho bien, entonces ¿por qué no utilizar los próximos proyectos o algún otro proyecto que se avecina? Lo siguiente en lo que quieres pensar como equipo es en qué se pueden mejorar las cosas. ¿ Hay alguna lección aprendida de la ejecución del proyecto? Entonces estas son cosas donde lo hemos hecho, pero podríamos haber cambiado ligeramente algo para hacerlo mejor la próxima vez. Entonces esas cosas tienen que ser capturadas y es bueno tener la perspectiva del equipo, no solo desde el punto de vista del director del proyecto. Es un buen momento para documentar eso. Y cuando mandas el enlace a la junta retrospectiva, quieres al menos capturar lo que salió bien, ¿qué se puede mejorar? Y por último pero no menos importante, y esto es quizás lo más importante. ¿ Qué se debe detener? ¿ Qué no está funcionando bien? Si algo no está funcionando bien, entonces no tiene sentido continuar eso en los proyectos posteriores o ejecución del proyecto. Entonces esas cosas son críticas para entender estas tres cosas como mínimo, debes capturar en la sesión Lecciones Aprendidas, o puedes llamarla como una sesión retrospectiva. Esta es una información valiosa que puedes recabar del equipo antes desmantelar al equipo y dejarlos sueltos. Entonces como ejemplo, la junta se vería algo así. El método de tres L le gustó, aprendido, carecía, cualquiera que sea la forma en que quieras nombrar los encabezados del tablero, puedes hacer eso. Las formas más fáciles de ir con lo que salió bien, ¿qué debemos mejorar y qué debemos dejar de hacer? Por lo que mientras recogemos eso y mejoremos con respecto a la próxima ejecución del proyecto, lo harías, como gerente de proyecto y como equipo mejoraría continuamente tus entregables y ejecución de proyectos. Eso es una sesión rápida de 30 minutos a una hora que puede hacer con el equipo. Y al final de la sesión de lecciones aprendidas, se puede agradecer a todos por la aportación y también por el trabajo de proyecto que han apoyado hasta el momento. 31. Transición al equipo de operaciones: De acuerdo, hemos completado el Go-live, y en esta lección vamos a echar un vistazo a cuál es el proceso para entregar al soporte de producción o a las operaciones. Cuando el proyecto se hace ahora se convierte en parte del equipo de operaciones. Son completamente nuevos. No tienen idea de lo que hizo DO como parte del proyecto, qué nuevas características agregaste, y cuál es el producto. Por lo que hay que hacerlos conocedores para que puedan apoyar cuando los clientes los llamen. Lo primero es, como parte del proyecto, si hay alguna documentación que puedas entregar al equipo de apoyo o al equipo de operaciones, entonces querrás hacer eso. La base de conocimiento podría ser cualquier arquitectura de sistema de alto nivel, el flujo de trabajo, o cualquier preguntas frecuentes que usted considere que podría ser útil para ellos. Entonces cuando el cliente les cuesta, pueden manejarlo apropiadamente. Esto es muy crítico para el personal de operación porque es cuando se pondrían de pie por primera vez, dicen el proyecto y los detalles y funciones del producto. Por lo que cualquier detalle que pueda proporcionar al equipo de operaciones que sería beneficioso para ellos. A continuación, si es posible, capacitar a las operaciones o al equipo de atención al cliente. Entonces si estás lanzando un nuevo producto, entonces obviamente una vez que esté en vivo, gente va a llamar no al equipo del proyecto, sino a la operación y soporte a todo el equipo de atención al cliente. Por lo que hay que asegurarse de que los está entrenando y que estén bien versados en el producto o en los nuevos servicios con los que se dobla en vivo para que cuando se llame al cliente, puedan responderlo apropiadamente porque lo último que quieres es que tengas un proyecto exitoso y es un desastre tras go-live, tan difícil asegurarte de que el impulso continúe incluso después de que de la mano fuera de su servicio de producto o cualquier otra cosa que saliera en vivo como parte del proyecto al equipo de operaciones. Y luego el último pero no menos importante, también hay que asegurarse de que le diga al atención al cliente o al equipo de operaciones cómo manejar y reportar cuestiones en base a la documentación que proporcionó. Si conoces la mayoría de las preguntas comunes que pueden obtener, nuevo, da las respuestas o cómo abordar esos temas. Y de esa manera el equipo de operaciones no tiene que ponerse en contacto con el equipo del proyecto. Y obviamente una vez que el proyecto está cerrado, puede que no sean un equipo de proyecto en absoluto. Por lo que se convierte en responsabilidad de la operación abordar los temas. Si hay algún miembro del equipo del proyecto que pueda hacer la transición a operaciones, eso sería mejor para que al menos haya un recurso conocedor moviéndose del proyecto o la transición, la mayor parte del diamante no es posible y el equipo del proyecto continúa y pasa a algún otro proyecto. Y luego entra algo crítico y el personal de operación puede ponerse en contacto con esa persona y pueden encontrar algún tiempo de espera para apoyarlos. Pero idealmente, lo que quieres es que si hay algún problema o cosas nuevas que se avecinan, quieres rastrearlo y luego manejarlo como parte del proyecto porque podrías tener un hiper tiempo de soporte de casos de dos semanas o un mes, entonces si se trata de problemas menores o mejora de procesos de lo que puede manejarlo como parte de la próxima versión. Por lo que quieres definir un proceso donde las operaciones puedan soportar y si hay nuevas características o bugs que necesitan ser atendidos, cómo puedes manejar eso como parte del soporte continuo desde el equipo del proyecto o para el próximo lanzamiento. Solo recuerda que a un alto nivel, lo que estamos tratando de hacer aquí es traspasar el producto o el servicio en el que trabajaste y dárselo a un equipo que va a apoyarlo en el futuro. Tienes que asegurarte de que ese equipo esté bien equipado para apoyar y servir nuevo producto o servicio para el cliente para que los clientes estén contentos al final del día. En la siguiente lección, echaremos un vistazo a cómo cerrar finalmente la limpieza del proyecto, realizar cualquier actividad de desmantelamiento, y cómo archivar los documentos del proyecto. 32. Documentos de documentos de proyecto de archivo: Muy bien, entonces ahora estamos en la etapa final. Ahora estamos listos para cerrar un proyecto. Hemos completado el apoyo de hiper atención, hemos hecho la transición a las operaciones. Ahora, podemos desmantelar el equipo del proyecto. Entonces antes de hacer eso, tenemos que asegurarnos de que archivamos todos los documentos del proyecto. Lo primero es si has recibido todas las aprobaciones, correos electrónicos, o de cualquier manera recibas las aprobaciones, Dave, ellos porque cuando te auditen y una auditoría va a pasar de una manera otro si tu proyecto es auditado que las cosas que buscarían es documentación con respecto a tus requisitos, tus aprobaciones, tu gestión de cambios y aprobadores de solicitud de cambio, todo eso. Por lo que cualquier aprobación que hayas recibido de la dirigencia para proceder con el proyecto, ya sea cambios escolares o de presupuesto o de horario, sean cuales sean las aprobaciones que tuvieras que obtener durante la ejecución. Ahora es el momento de recoger todo eso, guardarlo. Idealmente, quieres guardarlo a lo largo de la ejecución, pero si no lo has hecho, ahora digo buen momento para pasar por eso, encontrar todas las aprobaciones requeridas, y conseguir que se guarde en algún lugar para que siempre puedas acceder él. Lo siguiente es la documentación del proyecto. Esto es muy crítico porque una vez que desmantelas el equipo, entonces nadie sabe cómo se hizo y vas a perder a los expertos. Entonces antes de desmantelar el equipo, asegura de que hayan compartido toda la documentación, cómo se hacen las cosas, cuál fue su enfoque si hay alguna arquitectura o diagramas de flujo del sistema, guarde todo eso en la carpeta donde se pueda acceder a ella. Y estos documentos ya están ahí o guardados durante la ejecución del proyecto. Ahora sólo nos estamos asegurando de que esté todo ahí y se pueda acceder a él si es necesario. Y una vez que tengas las aprobaciones y la documentación del proyecto, entonces te aseguras de que hayas trasladado eso a una ubicación segura para que no lo vas a perder. Si tienes un lado específico del proyecto que se va a cerrar y no tendrías acceso que quieras guardar ahí, pero también quieres guardar una copia de alguna manera siempre puedes obtener acceso porque la auditoría y cualquier otra cosa que venga después, podría suceder después de seis meses o un año. Por lo que querrás acceder a todos estos documentos del proyecto incluso después de que el proyecto esté cerrado. Una vez que todo eso se hace, ahora eres libre. Estás listo para desmantelar a tu equipo y hacerle saber al mundo que tu proyecto se hace aquí, moviéndote y envíales una nota de agradecimiento por todos los esfuerzos y colaboración que todo el equipo extendido ha hecho por usted y el equipo del proyecto. Y entonces todos están listos para pasar a nuestro próximo proyecto.