¿Cuál es el Plan?

Como normalmente las cosas nunca salen como lo planeamos; sin embargo el plan nos da una idea de las tareas que tenemos que realizar y los tiempos que deberíamos de estar invirtiendo, con el plan podemos ir viendo cual es la desviación y nos puede ayudar a tener mejor visibilidad de los tiempos para aplicar alguna corrección, ya sea a nivel de recursos, tareas o tiempos.

¿Cuántos de nosotros hacemos cosa sin planear y cuantas veces salen bien?

Considerando desarrollos donde el nivel de calidad y efectividad es punto esencial, debemos de tener un plan que permita tener claro el esfuerzo y objetivo.

El plan para que tenga mayor efectividad y certidumbre debería de ser considerado por todas las partes (Cliente, stakeholders y equipo de trabajo) en función de los requerimientos y entregables establecidos con el cliente.

Desde mi perspectiva es mejor ir entregando parcialmente el producto (producto funcional), de tal manera que el cliente pueda saber cómo va creciendo y que permita tomar decisiones para corregir o adaptar el producto conforme a sus necesidades del negocio a diferencia de entregar hasta el último todo el sistema y tener un re-trabajo descomunal para hacer modificaciones.

Por ello conviene hacer para proyectos medianos a grandes un plan maestro (Road Map) y hacer un plan detallado, bajo demanda, por cada entregable (Por Iteración, ciclo o Sprint); cuando digo plan no me refiero solo a un documento tipo “mpp” sino a la actividad de asignar de tareas, tiempos y roles para cada miembro del equipo (Plan de trabajo y comunicación), esto se puede manejarse de manera verbal, escrito o visual dependiendo de la metodología implementada. Lo que es un hecho es que el líder es el responsable de dar a conocer el plan y darle seguimiento.

Es muy importante que desde el inicio se marquen los roles y responsabilidades de cada uno de los miembros del equipo de trabajo, para no dejar a supuestos o una mala interpretación de los mismos.


Un líder deberá de guiar, proveer soporte y facilitar el trabajo al equipo de trabajo (de manera planeada), por otro lado los programadores deberán de preguntar la existencia del plan (conocer el objetivo y alcance), conocer los requerimientos (Cliente y Sistema) además de conocer las responsabilidades de cada integrante en el equipo.

Las tareas que se ejecutan en paralelo en un desarrollo de software al crear el plan de actividades son:

  • Creación de ambientes de desarrollo (control de versiones docs. y código) - Actividad de CM
  • Proceso para Administración de Riesgos – Actividad de PM
  • Proceso para Administración de Controles de Cambio – Actividad de PM
  • Mecánica de monitoreo y reporte de avance – Actividad de PM
  • Proceso de comunicación entre las etapas de desarrollo (Análisis, Diseño, Codificación y Pruebas)
  • (Actividades mínimas)

    Estas actividades se sugieren ejecutarlas antes de que se comience las entregas de líneas bases
    Línea Base: grupo de artefactos (documentos, Modelos, código) congelados y aprobado, para enviarse a la siguiente etapa de desarrollo

Opciones de visualización de comentarios

Seleccione la forma que prefiera para mostrar los comentarios y haga clic en «Guardar las opciones» para activar los cambios.
Imagen de WinDoctor

Casi de acuerdo

Esta vez estoy casi de acuerdo con todo lo que nos compartes.

Una pregunta, podrías ilustrarnos con un ejemplo como se lleva a cabo la parte de:
- Proceso para Administración de Riesgos – Actividad de PM

Saludos!

Imagen de Israel-69

Administración de Riesgos

El objetivo principal es controlar de manera estratégica los eventos no previstos ( o no deseados), para lo cual se requiere la colaboración de todo el equipo e incluso de los stakeholders, notificando al líder de dicho riesgo (Personal, ambiente, comunicación, tecnológico, de negocio etc..) no importa si es bajo o no, eso lo decidirá el Líder lo importante es que documente y se le de un tratamiento.

Los riesgos básicamente se dividen en riesgos o problemas (risk & issues) donde el problema es aquel que te impide avanzar en tú proyecto, esté seguramente fue causa de un riesgo no manejado en tiempo y forma.

Para poder dar cierta prioridades a los riesgos ses deben de cuantificar en términos de su probabilidad de ocurrencia (%) y su criticidad dando como resultado el impacto al desarrollo del sistema, con ello tendrás visibilidad de cuales son los más importantes para ser atendidos.

El impacto puede darse por rangos (Critico, Alta, Media, Baja) por números ( del 0 al 1) donde el Crítico o el 1 nos darán un problema, algo que tenemos que resolver en este momento.

los riesgos contiene la siguiente información

  • fuente (quien lo detecto o donde se da)
  • fecha de registro
  • impacto (resultado de la ocurrencia por la criticidad)
  • plan de acción (o mitigación del riesgo)
  • fecha de ultima revisión
  • fecha de la siguiente revisión
  • descripción del riesgo
  • estatus del Riesgo (Abierto, Cerrado, Cancelado ...)
  • responsable
  • asignado a
  • entre otros .. que pueden servir para mediciones posteriores.

    Generalmente el Líder o PM deberá de llevar el seguimiento y monitoreo de los riesgos para apoyarse en las decisiones del proyecto, además es muy útil para poder negociar con el cliente cuando los riesgos que se identifican son externos al proyecto o están asociados al negocio.

    En el caso de los riesgos internos, que tendrán que ver con el equipamiento, habilidades de los recursos u situaciones laborales (vacaciones, descansa u otros) no tienen que ser ventilados al cliente, sin embargo deben de ser atendidos y canalizado debidamente.

    Todo proyecto tiene riesgos asociados, si un proyecto se dice que no tiene riesgo, es que entonces no se han identificados y que cuando ocurran estos serán problemas.

    Imagen de Shadonwk

    Que buena información,

    Que buena información, gracias @Israel