Guideline de Project Manager

Roadmap del proyecto: En él se define el cronograma de ejecución de las tareas, las épicas, definición de entidades, budgets, cambios https://docs.google.com/spreadsheets/d/1_hmDOt-6vEqNDM8EEP8DdoWCbPXLyHKcj6oo7JsiZOU/edit?usp=sharing

Aprobación de tareas: En él se colocan las tareas ejecutadas (heredadas del Roadmap) para que sean aprobadas por el cliente https://docs.google.com/document/d/1axnpe2SJT_EauXhhOpPRMB0CcWtKL7fubfyAxYAcv54/edit?usp=sharing

Consultoría técnica: En el se especifica el detalle de la asesoría técnica para la ejecución de un proyecto https://docs.google.com/document/d/1JnRy0hNeiLY2H6v1TANhtDCGtJGGkXpwAkTeAmNY8Ik/edit?usp=sharing

Formato de certificado de conformidad y garantía: En él se definen los parámetros que rigen y que mantienen en vigencia la garantía de un proyecto de Rootstack (imprescindible la firma del cliente)

https://docs.google.com/document/d/1MdegVQDwcJ_hJHWh3FRslT3QgV7_B6K7SaDylKi3LhY/edit?usp=sharing

Cierre de proyecto: El cierre formal es consistente con las tareas y/o requisitos aprobados en el inicio del proyecto, este debe ser firmado por el cliente

https://docs.google.com/document/d/14oI4EPuR2_h630bkKE384nttdsWwZA_bEGXl24Bl5QE/edit?usp=sharing

Overview de la semana: Formato a enviar cada semana al cliente mostrando que se trabajo, en que se trabajará y enviando un copy paste del Roadmap del proyecto.

https://docs.google.com/document/d/1e0LXMmclF0O5bLUHe4tQKK4CroLoKIkl8yvaGkBnTHE/edit

===== OVERVIEW =====

Con este documento se busca explicar las competencias que debe tener un Project Manager para alcanzar con éxito el objetivo de un proyecto de cualquiera que sea su naturaleza

===== Metas =====

-Establecer las competencias, responsabilidades e importancia de este rol para Rootstack

-Definir ruta de procedimiento para una ejecución exitosa

-Definir los requerimientos y la planeación del proyecto

-Establecer los lineamientos del desarrollo

-Garantizar la calidad y seguridad del desarrollo

==== Project Manager ====

=== ¿Qué es un PM? ===

En Rootstack un PM no es solo quien ejecuta las labores de definición y gestión de un proyecto sino que también es aquel que mediante un conjunto de conocimientos técnicos, de mercado, de gestión humana y empresarial ejecuta exitosa mente un proyecto de cualquiera que sea su naturaleza , entre los puntos importantes a destacar “Qué es un PM”:

• No es un mensajero, es decir no es una persona que solo se dedica a enviar correos y organizar cosas en un proyecto, es un ser que debe de poder entender con claridad cada tarea del proyecto y saber como se hace el flujo a nivel visual del funcionamiento del software, conociendo al responsable de cada tarea.
• Es un ser que debe de entender, interpretar y tomar decisiones inteligentes ante circunstancias, es decir que al trabajar en el día a día con las tareas debe de saber que podría pasar con el equipo, saber que porque un blocker existe a nivel de forma y no porque el tech lead dijo “el esta bloqueado” o el desarrollador diga “estoy bloqueado” y al final del camino no es un blocker real.
• Es una persona visionaria que debe de estar anuente sobre circustancias a que a nivel de tiempo pueden afectar el proyecto, es decir al estar en una semana ejecutando un proyecto tiene claridad de temas como: cuando se deben de enviar los correos, como atacar situaciones para poder que todo fluya correctamente, llamar al cliente porque sabe que hay y/o puede haber una inconformidad, entre otras.
• Es una persona organizada por lo cual debe de estar claro con el orden secuencial y/o paralelo de la ejecución de las tareas de su equipo o por si mismo, unos ejemplo de relevancia: – Si se puede trabajar el manual antes que se cierre un proyecto debe de ejecutar dicha tarea. – Si el equipo puede realizar un entrenamiento y no es dependiente del deploy del proyecto que se haga. – Si a nivel de entregables necesita más recursos para seguir en linea con el proyecto debe de perdirlos en su momento pertinente – Si al final no tiene visibilidad del orden de cierre de tareas debe de hablar con su tech lead – Que su tech lead esté ejecutando bien el rol del mismo

-A parte de todos los atributos de cualquier integrante de Rootstack se espera de nuestros PM: Productividad

-Actualización constante de su base de conocimientos

-Cordialidad y educación para con todos sin distinción de jerarquía con desempeño

-Ser un buen comunicador en todos los niveles, claro y veraz

-Que siempre añade valor agregado a sus metas

-Estar a la expectativa de una nueva oportunidad de negocio

-Tiene que comunicarse con las opciones posibles; habladas, escritas y presenciales, con clientes, con su equipo o con cualquier persona que intervenga en el proyecto independientemente de la jerarquía que tenga

-Su capacidad de organización debe ser para sí mismo, para su proyecto y para su equipo

-Puede resolver de forma práctica y profesional todas las dificultades que se presenten dentro de su proyecto

-La capacidad de negociación debe ejercitarse de cara al cliente y de cara al equipo; siempre pensando en las prioridades, el bien común y las soluciones profesionales

-Debe lograr el objetivo del proyecto de forma exitosa, sabiendo que el principal motor de esto es su equipo de trabajo, en este sentido darle la importancia y directrices necesarias

-Ser claro y transparente evita daños mayores, si hay una situación debe ser conversada, quizá la solución a esa situación sea menos complicada de lo que parece

-Debe tener determinación para hacer lo posible hasta culminar las tareas y así mismo motivar a su equipo para lograr los objetivos

-Debe ser una persona sensible para detectar situaciones de riesgo, situaciones de potencial aprovechamiento entre otras

-Debe tener conocimientos amplios, mientras más áreas de conocimiento maneje más rango de acción y percepción, debe tener un aprendizaje constante

=== Responsabilidades ===

== Generales ==

-Definir y presentar el proyecto

-Planificar

-Establecer los objetivos

-Supervisar las tareas

-Implementación de soluciones o cambios

-Que la salud del proyecto a nivel de avances y monetariamente sea adecuada

-Comunicar y prever los problemas y/o dificultades

-Priorizar tareas durante el proyecto

-Respetar el budget del proyecto

-Que el roadmap del proyecto esté actualizado

-Planear los sprints semanales antes del scrum, se debe de revisar las tareas por integrantes del equipo, validando a nivel de percepción personal (si se tiene las experticias)

-Iniciar el sprint

-Cerrar el sprint

-Tiene la responsabilidad de tomar decisiones de contingencia -Tiene la responsabilidad de enviar el ”“Overview de la semana pasada” al cliente

== En el proyecto de cara al equipo ==

-Que el equipo esté contento

-Standup diarios

-Solicitud de actualizaciones de las herramientas de gestión cuando haya el cumplimiento de las tareas

-Verificar que las tareas hayan sido ejecutadas con calidad y a tiempo

-Siempre a la expectativa de solventar cualquier duda o necesidad que se presente y que ponga en riesgo la evolución del proyecto

-Evaluar que los demos de las tareas ejecutadas sean entregados en la fechas definidas

-En rootstack al inicio de la comunicación con el cliente le enviamos un documento de esbozo general de nuestras formas el cual permite al cliente conocer nuestra filosofía de trabajo (https://www.rootstack.com/data/meet-us-en.pdf). Es imprescindible que el PM en la primera reunión con el cliente se debe dejar claro que la comunicación debe ser cordial, grata y fluida, evitar los malos entendidos y tratos negativos. Si la comunicación con el cliente se torna incómoda o desagradable debe ser notificado de inmediato a Alejandro

-Se debe conocer al cliente de manera empática, comprendiendo su entorno, su filosofía de trabajo, la manera de percibir, comunicarse y relacionarse laboral y socialmente. Esto permite definir el protocolo de comunicación adecuado.

-Se busca que el cliente se sienta cómodo y confiado con nuestro trabajo

-Identificar a la persona autorizada para las aceptaciones, esto es un punto sensible ya que ella es la única autorizada para aprobar las tareas o pedir cambios de alcance. Si en el transcurso del proyecto es agregada otra persona esto debe ser notificado por escrito y anexado en el contrato

-Dejar claro al cliente que si hay algo incómodo o insatisfacción debe notificarlo de inmediato para no acarrear situaciones que pongan en riesgo la salud del proyecto

-Monitorear las aceptaciones y pagos de los clientes

-Las tareas fuera del alcance no serán ejecutadas sino que serán replanteadas para una segunda fase, sí es prioritaria debe ser redimensionado el alcance del proyecto y volver a pasar por las estimaciones de tiempo, costo y recursos.

-Al identificar el tipo de cliente se debe prever y tomar medidas frente a los siguientes casos:

• Si el cliente no tiene objetivos claros, hay que orientarlos de una forma práctica y eficiente, esto evitará pérdida de tiempo e inconsistencia en las tareas. Esto no debe pasar ya que en la consultoría técnica todos los objetivos deben estar claros sin embargo.
• El cliente en ocasiones al no tener claro qué tipo de soluciones rootstack está proporcionando, realiza llamadas y peticiones que están fuera del alcance de nuestra solución.
• El cliente tiene normativas de reportes y formalidades que deben ser respetadas o acordadas, si las formalidades implican inversión excesiva de tiempo llegar a acuerdos en esta fase del proyecto

-Ya definido el alcance del proyecto y esbozado mediante tareas y/o requerimientos debe estar el documento de Aceptación de tareas el cual debe de incluir el listado de tareas en función al contrato, si hay tareas nuevas aceptadas fuera del contrato debe de estar en este documento

-Cuando la situación del proyecto se torne complicada porque las tareas no se han concluido a tiempo o están defectuosas, el PM no debe aprehender de un sentimiento de culpa, esto dificultará la posibilidad de hallar una solución.

 -Debe conversar y tratar de conseguir la solución para la situación

 -Si el proyecto se encuentra lleno de defectos, debe idear una estrategia para subsanar la situación

-Si el cliente es agresivo, saber de qué forma comunicase haciendo valer el respeto y las normativas de comunicación (https://www.rootstack.com/data/meet-us-en.pdf)

-Las metas deben estar claras, se pueden establecer metas de lo micro a lo macro, es decir, diarias hasta finalización del proyecto para lograrlas se debe:

 -Si es proactivo
 
 -Si sabe dimensionar correctamente las tareas
 
 -Si tiene capacidad de resolución

 -Si está comprometido con el trabajo

 -Las metas deben estar bien definida procurando que sean entendidas por todos y en todos los niveles, hay personas con más capacidad de abstracción y otras con menos, pues estas deben estar claras para todos (para aquellas con más visión y también para aquellas con menos visión)

 -Si algo no está funcionando correctamente se debe:
 
      -Esperar un tiempo prudencial para la autocorrección
      
      -Se debe notificar
      
      -Se debe buscar las posibles soluciones

-Las tareas tienen un estado: Por hacer, En progreso y Listo. Estas tareas siempre deben ser actualizadas

-Las tareas deben ser comentadas en temas de importancia, soluciones, sugerencias del cliente, aclaratorias

-Si las tareas poseen condiciones o validaciones deben estar documentados todos sus casos

-La tarea debe ser analizada de tal manera que se pueda definir si se puede considerar como una tarea o si se debe subdividir considerando el tiempo de ejecución y las derivaciones. Por ejemplo; se tienen dos tareas que pueden ser mejor ejecutadas si se deriva una tercera tarea que mejorará el rendimiento de las dos definidas, Tarea 0: Crear plantilla de reportes

 Tarea 1: Generar un Reporte de personas según el género
 
 Tarea 2: Generar un Reporte de personas según la edad 

-Las tareas poseen la siguiente estructura:

 -Título: Por lo general el título es el mismo que se propuso o propuesto por el cliente. El título no es la descripción de la tarea

 -Estado: Por hacer, En proceso, Listo

 -Responsable: Si la tarea tiene dos responsables se deben crear dos tareas una para cada responsable

 -Etiqueta: Ayuda a definir si la tarea es de tipo Frontend,  Backend

 -Prioridad: Alta, media, baja

 -Comentarios: Se define un comentario principal como la explicación de la tarea, los comentarios subsiguientes como las aclaratorias, situaciones o soluciones de esas tareas. Si hay archivos relacionados es importante que sean mencionados o adjuntados

-Hacer el flujo de la tarea y comprobar que esté lista, cambiar su estado a listo

-Las tareas deben estar aprobadas por escrita, si se hizo una aprobación verbal, se debe realizar una confirmación mediante correo electrónico

-Demostrarle al cliente que la tarea está concluida para la firma de su aprobación (documento de aprobación de tareas)

-Si el cliente no queda satisfecho se debe conversar

-Si el cliente no quiere firmar la aprobación, Alejandro debe intervenir

El PM en una revisión preliminar del proyecto es capaz de prever cuales son las herramientas básicas de trabajo, sin embargo es indispensable que una vez realizado el Kickoff del proyecto en donde cada tarea y estrategias quedan lo más clara posible, reciba el feedback de parte del equipo con respecto a las herramientas que serán necesarias o propuestas para la consecución del proyecto. Existen herramientas básicas de la gestión del proyecto como los son:

Bitbucket ( manual básico de uso)

-Cada proyecto debe tener su repositorio

-Cada tarea debe tener un branch

-Cada tarea concluida debe generar un PR

Jira (manual básico de uso)

1. Creación del proyecto:
2. Configuración del proyecto:
3. Configuración de las columnas de ejecución de los sprints
4. Creación de las tareas del proyecto
5. Inciar - Cerrar Sprints

-Se debe crear el dashboard del proyecto

-Se debe incluir a todos los actores del proyecto

-Se debe agregar cada tarea con las descripciones básicas

-Se deben crear los sprint de las tareas

Catálogo de herramientas de software: En el guidelines de generalidades se han definido herramientas que pueden ser de utlidad para el desarrollo del proyecto. Es una opción que se debe tener a mano al momento de hacer el kickoff

Definición de ambientes

El Tech lead es el responsable de crear los tres ambientes básicos en el ciclo de vida de un desarrollo, sin embargo el PM debe velar porque esto se defina y se proporcione a las áreas de uso

a. Ambientes de desarrollo

b. Ambiente de pruebas

c. Ambiente de producción

-El PM hereda de la fase de negocio la siguiente información: (Documento de consultoría de negocio)

 -Tareas y/o requerimientos aprobados

 -Budget

 -Recursos necesarios

 -Estimación de tiempo

 -Información de contacto del cliente

-Toma del proyecto, se hace un pase del departamento de ventas hacia el PM estableciendo la comunicación con el cliente:

 -El departamento de ventas proporciona al PM el documento de tareas aprobadas o consultoría de negocios

 -Se proporciona la información de contactos del o los departamentos involucrados y la o las personas autorizada para las aprobaciones de las tareas

 -Se concerta una reunión con el cliente y el PM en donde se discutirá y aclarará todos los puntos pertinentes a las tareas a ser ejecutadas

-En la fase inicial debe crear el documento de Roadmap con el mayor detalle posible

-Debe definir las fechas y tareas para los diferentes demos internos que marcan la evolución del proyecto:

 -Demos internos

 -Demos externos

-Usando de insumo el Roadmap del proyecto se debe acondicionar la plataforma de gestión (JIRA) definiendo:

 -Configurar Jira para la gestión:

 -Tareas / Requerimientos

 -Recurso para ejecutar la tarea / requerimiento

 -Definir el cronograma de ejecución

-Debe reunir al equipo bien sea de forma presencial, remota o mixta para presentar los objetivos, desde lo general a lo específico describiendo cada una de las tareas, posible soluciones y observaciones (Kickoff):

 -El PM y el Tech Lead deben garantizar que todas las tareas queden claras y específicas para todos los miembros del equipo

 -El PM debe de comunicar claramente al equipo al iniciar un proyecto y/o durante un proyecto que no va a hacer micromanagement de los juniors, se debe de transmitir que si no comunica cae bajo su responsabilidad 

 -El PM debe de comunicar cuando hay problemas dentro del equipo para que sean tomadas las medidas, si esto no se corrige acarreará retrasos en el proyecto, insatisfacción con el cliente y agotamiento del Budget

 -El Pm debe de comunicar el tipo de actitud que se busca sobre cómo abordar los tickets, se ha visto que los juniors son muy pasivos ante situaciones y no preguntan nada, no dicen nada y al final se tiene la expectativa que entienden todo.

-El PM debe gestionar el recurso humano proporcionado para la ejecución del proyecto:

 -Proporcionar las herramientas tecnológicas para la ejecución del proyecto

 -Prever que el Tech Lead proporcione las plataformas de respaldo, pruebas y producción

 -Coordinar el horario de trabajo (sea in house o sea remoto)

 -Prever que el Tech Lead proporcione las credenciales necesarias según sea el caso

 -Proveer el acceso a las plataforma de gestión del proyecto (Jira) y/o software (Bitbucket)

 -Si el recurso está en conexiones remotas definir los servidores de prueba para esto. Dejar clara las reglas de trabajo para las diferentes prácticas de Rootstack definidas en el guideline de generalidades:

      -Prácticas locales

      -Prácticas remotas

      -Prácticas outsourcing

Ejecución diaria

1. Toma del sprint: Standup diarios donde por chat o personalmente mencionan. charlas técnicas de 15 min antes de hacer los scrums cuando se están aprendiendo las tecnologías, las charlas de 15 min deben de estar focalizadas a como hacer la tarea en drupal en el dia, no masticarlo sino explicar el contexto completo
2. Ejecución del stack: Verificación del inicio de la ejecución de las tareas
3. Seguimiento y control de las tareas finalizadas
4. Verificación de las metas diarias

   1. Asunto: EOD
   2. Contenido
    * Qué trabaje:
    * Qué terminé:
    * Cuales fueron los bloqueos:
    * Qué voy a trabajar:

Ejecución semanal

1. Planificar los tasks en el roadmap y en el sprint en Jira para cada integrante tenga sus tareas definidas
2. Explicar en conjunto con el tech lead la definición de las nuevas tareas
3. Definir cuál es el alcance y día del demo o los demo (de haber un demo)
4. Actualización diaria de las herramientas de seguimiento
5. Monitorear que todos los actores del proyecto actualicen diariamente la herramienta de gestión, presentando un estatus de tareas
6. Monitoreo de las tareas
7. Prueba del Demo, realizar una evaluación exhaustiva apuntado y discutiendo todas las incidencias o mejoras que surjan, así como también dar por cerradas aquellas tareas que hayan sido finalizadas con éxito
8. Prueba del demo con cliente (de haber un demo como entregable)

   a. Antes del demo se debe tener definido en un listado con un espacio de firma de aceptación con el cliente el alcance del demo, cuales son las tareas y funcionalidades que serán mostradas b. Cada tarea finalizada con éxito debe ser aprobada por el cliente c. Cada tarea con bugs debe ser reportado d. El formato puede ser entregado a más tardar 2 semanas luego del demo, después de él se podrán realizar las correcciones pertinentes para que haya una aceptación del cliente

9. Enviar cada lunes un el correo de “Overview de la semana pasada”
   Cierre

-Se genera un documento de PROY - CP (cierre del proyecto) el cual debe ser entregado en un periodo no mayor a dos semanas. Este documento debe ser firmado por ambas partes. La mayor parte de la información que incluye esta documentación ha sido desarrollada en el transcurso del proyecto por lo que no debe tomar más de dos horas en su redacción. Independientemente si hay bugs de cualquiera que sea su naturaleza serán reportados en otro documento https://docs.google.com/document/d/14oI4EPuR2_h630bkKE384nttdsWwZA_bEGXl24Bl5QE/edit?usp=sharing

-Al comunicar la entrega de proyecto, se debe de fijar una fecha tope de firma, se le debe de dar un monitoreo simple pero efectivo (google calendar) a esto ya que esta firma dependerá de iniciar la garantía y va atado a un proceso de cobros.

-Se genera un documento de PROY - CG certificado de conformidad y garantía. Este documento debe ser firmado por ambas partes en un período no mayor a dos semanas https://docs.google.com/document/d/1MdegVQDwcJ_hJHWh3FRslT3QgV7_B6K7SaDylKi3LhY/edit?usp=sharing

-Cierre de proyecto:

-El Documento de cierre debe ser proporcionado al departamento de ventas para su evaluación ya que de este se puede derivar una nueva posibilidad de venta

-e debe generar en la plataforma de Servicedesk los usuarios a partir de la entrega que permitirá el reporte de incidencias que se manejan para la garantía

Doc: https://www.rootstack.com/data/guideline-managed-services-espanol.pdf

1. Revisión del contrato de servicio
2. Asignación del SLA (según catálogo de SLA)
3. En conjunto con el TL hacer las estimaciones de tiempo ( Rootstack - Servicios manejados)
4. El PM debe enviar la propuesta al cliente para su aprobación
5. Posterior a la propuesta se calendariza y asigna el recurso para la ejecución
6. Asignación del recurso idóneo para la ejecución
7. Generar reportes mensuales:

   -Estado actual de la infraestructura
   -Incidencias del mes
   -Estado del consumo

1. El PM / Encargado de cuenta de Servicios Manejados es responsable de validar el tiempo invertido de su equipo semanalmente
2. Existe un ciclo de revisión de horas semanales, revisando a final de semana o al inicio de semana revisando los tiempos de la semana pasada, por lo cual si existe una queja / ambigüedad en el ingreso de horas de si mismo o del equipo debe de salir el feedback en este momento y no después.
3. Las horas ingresadas luego de la siguiente semana no son corregibles ya que existe el ciclo de revisión, la compañía no puede invertir tiempo revisando que paso muchas semanas atrás o meses atrás, por lo cual si un arreglo de hora no se hizo en su momento esto afecta el performance del proyecto, budget del proyecto y/o las horas de servicios manejados
4. Existe un flujo de envío de horas mensualmente al cliente, por lo cual el encargado de cuenta revisa las horas de Rootnet para enviarselo al cliente, por lo cual no existen arreglos de horas luego de un envío de reporte ya que se da por sentado una confirmación del cliente y estro traerá inconvenientes.
5. Con las cuentas de USA existe un flujo que esto es ley para administrar proyectos / bien correctamente, misma metodología la adoptamos nosotros.