Conocimiento del cliente

El PM debe planear, seguir y controlar sus proyectos, para ello debe:

• Revisar los costos de su proyecto (Garantizar la rentabilidad del proyecto), gestionar el cronograma del proyecto (definir tiempos, actualizar y hacer sgeuimiento), validar el alcance (entender y garantizar la planeación basada en el alcance del proyecto), seguimiento de recursos (hacer seguimiento a recursos y tomar decisiones cuando considerada que hay riesgos de no cumplimiento del proyecto), accountability (reportar informes de rendimiento y planes de accion para mejorar procesos).
• Revisar los costos de su proyecto (Garantizar la rentabilidad del proyecto), gestionar el cronograma del proyecto (definir tiempos, actualizar y hacer sgeuimiento), validar especificaciones técnicas (entender y garantizar especificaciones con todo el detalle tecnico para el equipo), seguimiento de recursos (hacer seguimiento a recursos y tomar decisiones cuando considerada que hay riesgos de no cumplimiento del proyecto).
• Revisar los costos de su proyecto (Garantizar la rentabilidad del proyecto), gestionar el cronograma del proyecto (definir tiempos, actualizar y hacer sgeuimiento), validar el alcance (entender y garantizar la planeación de su cronograma basado en el alcance inicial definido en el proyecto).
• Gestionar el relacionamiento comercial (Tener el primer contacto con el cliente y realizar negociaciones). Revisar los costos de su proyecto (Garantizar la rentabilidad del proyecto), gestionar el cronograma del proyecto (definir tiempos, actualizar y hacer sgeuimiento), validar el alcance (entender y garantizar la planeación basada en el alcance del proyecto), seguimiento de recursos (hacer seguimiento a recursos y tomar decisiones cuando considerada que hay riesgos de no cumplimiento del proyecto), accountability (reportar informes de rendimiento y planes de accion para mejorar procesos).

La facturación debe ser:

• Reportada al area de facturación por el PM y facturación valida y envía al cliente.
• Reportada y cobrada directamente por el PM.
• Reportada al DP por el PM y DP valida y envía al cliente.
• Reportada a Loic por el PM y Loic valida y envía al cliente.

¿Cómo debe ser la comunicación con QA?

• La comunicación entre QA y el resto del equipo se hace en canales privados para no saturar los canales de cliente. Y si se requiere se comunica en el canal general para que todo el equipo sepa las decisiones, restricciones o alertas del proyecto.
• La comunicación entre QA y el resto del equipo se hace en el canal de pruebas QA, allí se dejan las solicitudes de revision de cada día.
• La comunicación entre QA y el resto del equipo se hace desde los canales cliente de cada proyecto.
• La comunicación entre QA y el resto del equipo se hace desde los canales generales de cada proyecto, es mejor que todo el equipo sepa las decisiones, restricciones o alertas del proyecto.

¿Como debe gestionarse el paso de un proyecto desde el equipo de proyectos largos, a grantías o al equipo ágil?

• El PM de proyectos largos una vez llega al final del proyecto debe preparar todos los entregables para Garantías, todos los bugs que estén dentro del scope del proyecto van a ser tratados por el equipo de soporte-Garantía, es posible que en algunos casos se requieran evoluciones fuera del scope, en cuyo caso debe informar al cliente y al comercial para que se haga la negociación del contrato con el equipo ágil y se preparen todos los entregables al equipo ágil.
• El PM de proyectos largos una vez llega al 70% de avance del total del proyecto, debe comunicar al cliente que las evoluciones las hace el equipo ágil y pasar todos los posibles bugs directamente al tablero de agiles. Una vez se termina el proyecto se pasa a garantías tanto los bugs del scope inicial, como los bugs derivados de las evoluciones tratadas en agiles.
• El PM de proyectos largos una vez llega al final del proyecto debe preparar todos los entregables para Garantías, todos los bugs y evoluciones para ser tratados por el equipo de soporte-Garantía, se debe negociar el paquete de horas que el cliente va a tomar con el equipo de garantías.
• El PM de proyectos largos una vez llega al final del proyecto debe preparar todos los entregables para Garantías, todos los bugs que estén dentro del scope del proyecto van a ser tratados por el equipo de soporte-Garantía, es posible que en algunos casos se requieran evoluciones fuera del scope, en cuyo caso se debe redirigir al cliente con el equipo ágil que empezará a trabajar inmediatamente en las evoluciones.

¿Que tener en cuenta para una puesta en línea?

• a) Que se tenga la validación de QA. b) Que se hagan en un horario adecuado, en el caso de proyectos largos en un horario de 6 a 9 am, en el caso de proyectos ágiles que no sea los viernes en la tarde.
• a) Que se tenga la validación de QA. b) Que se tenga la validacion del DP y de Loic. c) Que se hagan en un horario adecuado, en el caso de proyectos largos en un horario de 6 a 9 am, en el caso de proyectos ágiles que no sea los viernes en la tarde.
• a) Que se tenga la validación del LT. b) Que se hagan en un horario adecuado, en el caso de proyectos largos en un horario de 6 a 9 am, en el caso de proyectos ágiles que no sea los viernes en la tarde.
• a) Que se tenga la validación de QA. b) Que se hagan en un horario adecuado, en el caso de proyectos largos en un horario de 6 a 9 am, en el caso de proyectos ágiles que no sea los viernes en la tarde. c) Que haya aprobación de Benoit en el caso de proyectos largos y que tenga aprobación del cliente en el caso de ágiles.

¿A que hace referencia un sprint de investigación o la investigación en el contexto de Gradiweb?

• Son periodos de tiempo en el que el equipo comercial hace el análisis de los prospectos, definen una propuesta comercial y fechas de posibles entradas de nuevos proyectos a los equipos.
• Análisis previo al desarrollo en el que se hace una revisión exhaustiva de los requerimientos, riesgos y restricciones del proyecto y/o tarea para entender su complejidad. Aquí se definen los flujos de solución
• Periodo en el que el PM realiza una revision de la tareas planeadas para hacer análisis de riesgos respecto a costos del proyecto.
• Es un periodo en el que el equipo directivo se reune para proponer mejoras en los diferentes procesos de cada área de la empresa.

Cuando un nuevo proyecto entra en un equipo es importante:

• Realizar un análisis previo a todos los documentos e informacion comunicada por el área comercial (brief, devis, lettre de mision y/o especificaciones iniciales), gestionar el planning en Monday y preparar la reunion de lanzamiento con el cliente donde se debe explicar el funcionamiento del equipo, herramientas usadas diariamente y el planning.
• Realizar un análisis previo a todos los documentos e informacion comunicada por el área comercial (brief, devis, lettre de mision y/o especificaciones iniciales), gestionar el planning en Monday y enviar un mensaje al cliente con la explicacion del funcionamiento del equipo, herramientas usadas diariamente y el planning.
• Realizar un análisis previo a todos los documentos e informacion comunicada por el área comercial (brief, devis, lettre de mision y/o especificaciones iniciales), definir las primeras tareas a realizar, adelantar WF y diseñor y preparar una reunion inicial con el cliente para mostrar los avances.
• Realizar un análisis previo a todos los documentos e informacion comunicada por el área comercial (brief, devis, lettre de mision y/o especificaciones iniciales), gestionar el planning en Monday y preparar la reunion de lanzamiento con el cliente, en esta reunión se debe presentar a todo el equipo incluidos devs y qa.

¿Como se debe gestionar el seguimiento de tareas con el cliente?

• La herramienta por defecto para realizar el seguimiento del proyecto es Monday, toda la planeación debe estar en el board del cliente y los respectivos boards internos, y el cliente debe interactuar con el board cliente para mantenerse informado del avance del proyecto.
• La herramienta por defecto para realizar el seguimiento del proyecto es Slack, aunque la planeación está en monday, el PM debe informar todos los días por slack el avance del proyecto al cliente.
• La herramienta por defecto para realizar el seguimiento del proyecto es Monday, toda la planeación debe estar en el tablero interno y el cliente debe interactuar con el tablero interno en una vista asignada para él.
• La herramienta por defecto para realizar el seguimiento del proyecto es gmail, aunque la planeación está en monday, el cliente no tiene acceso porque es solo una herramienta interna, el PM debe informar semanalmente el avance del proyecto en curso.

¿Que es el business model del cliente?

• Se refiere a la estrategia de marketing que el cliente va a serguir para captar nuevos clientes y fidelizar clientes antiguos.
• Se refiere al objetivo que persigue una cliente / empresa: el tipo de producto o servicio que ofrece o lanzará al mercado, el público al que se dirige, las vías / canales que utilizará para comercializar, sus reglas de negocio y recursos o asignacion de presupuestos.
• Se refiere a la estructura interna de su negocio, como están organizados, y cuales son los canales de comunicacion que usan.
• Se refiere al tipo de relacionamiento que quieren tener con sus clientes, si tienen segmentación o no de clientes, y que canales usaran para comunicarse con sus clientes.

A que hace referencia la plantilla de esencial settings y porqué es importante?

• Es una plantilla que permite reunir la informacion de como se administra el sitio de cada proyecto. Con el objetivo de que el cliente pueda consultarlo y tener información precisa de como hacer cambios en el theme settings o en los metafields de producto.
• Es una plantilla que permite reunir la informacion del análisis de stakeholders del lado del cliente y definir el tipo de comunicación que se debe tener con cada uno para asegurar la satisfacción del cliente.
• Es una plantilla que permite reunir la informacion de configuraciones esenciales de cada proyecto. Con el objetivo de que el PM tenga claridad y pueda aconsejar y orientar al cliente para que elija la configuración más adecuada para su negocio.
• Es una plantilla que permite reunir la informacion de todas las especificaciones funcionales para los desarrollos del sitio y le permitirá al PM validar con el cliente sus necesidades y restricciones.