Tecnologia para su PMO

En estos últimos años ha cobrado mayor fuerza para mas y mas empresas el concepto de entender porque es necesario tener una PMO. En este orden de ideas, hay que entender cuando y porque establecer una PMO y como la tecnología me puede ayudar a hacer una realidad la iniciativa de formalizar y estandarizar la manera como los proyectos son manejados. A partir de las mejores practicas la necesidad de establecer una PMO se justifica o no dentro de una organización. Si por el contrario su organización aun no tiene un volumen importante de proyectos, pero definitivamente el crecimiento proyectado apunta a manejar multiples proyectos, desde mi punto de vista se debería apoya la iniciativa de establecer una oficina de proyectos.
Por otro lado sin duda una herramienta que es menospreciada en el mercado es Project, esto porque siempre se evalúa Project como una herramienta aislada y no en su conjunto completo como Project Server y hoy en día Project Online. Gracias a estas herramientas de servidor es mucho mas fácil soportar la resistencia al cambio  de las empresas, puesto que la PMO al establecer formatos a seguir en cada area de gestión de los proyectos puede volver mas pesado el proceso de seguimiento, control y gestión de los proyectos. Gracias a la combinación de Project Server y Sharepoint se hace posible que por ejemplo los proyectos aprobados por la gerencia de una vez se generen con los formatos a tener en cuenta por las organizaciones y por la oficina de proyectos para la gestion efectiva del mismo, y parametrizando los proyectos de tal forma que sea facil consolidar los resultados de gestión de los proyectos.

Gracias a mi ultima experiencia junto a Simplifica he descubierto el gran potencial que tiene esta solucion en organizaciones que sin importar el tamaño ven en los proyectos su estrategia de eficiencia y efectividad.

Advertisements

Requirement process

Hola a todos, dentro del proceso de desarrollo de software una de las fases quizás más importantes del mismo es la captura de requerimientos. Hoy en día existen varias técnicas para hacerlo, sin embargo, muchas veces este proceso no se realiza de manera adecuada, pues se cree que solamente con una entrevista y una serie de preguntas se puede completar esta importante fase de construcción de software.

En muchas ocasiones se dan por sentadas una serie de suposiciones lo que siempre repercute en la construcción de requerimientos no pedidos o perdida de información importante que hace necesario una reconstrucción del software o hasta un nuevo proyecto para cumplir con lo pedido.

Por esto es importante hacer referencia a muchas técnicas que se tienen hoy en día para la recolección de requerimientos.

Algunas de las mas recomendadas para nuestro caso puntual (construcción de software) son:

  • Sombra (Shadowing): Básicamente es una técnica de observación sobre el desempeño de las tareas de los usuarios y la idea es hacer preguntas sobre el funcionamiento y la realización de dichas tareas. Este Shadowing se puede hacer de manera pasiva o activa, en la forma pasiva solamente el observador se limita a escuchar las explicaciones del usuario, en la parte activa la observación está guiada de preguntas por parte del observador.
  • Entrevistas: Generalmente son entrevistas uno a uno y su objetivo es preguntar de manera precisa sobre tareas a largo plazo y detalles puntuales sobre la solución que se desea. Dependiendo del nivel de abstracción y del nivel de detalle las entrevistas son necesarias con varios actores en el proceso o responsables de la solución que requieren.
  • Grupos de Foco (Focus Groups): Estas actividades sirven para discutir con grupos de usuarios funcionalidades específicas del sistema con la compañía de un facilitador que ayude a que el grupo fluya y se puedan obtener resultados más concretos sobre el concepto de solución. Los grupos suelen complementar la información de las entrevistas individuales.
  • Encuestas: Las encuestas se realizan basados en una serie de preguntas que ayuden a obtener detalles de un extenso grupo de personas que pueden ayudar a complementar la información.
  • Instrucciones de usuario: Esta técnica hace que un usuario del sistema entrene al observador en las tareas que realiza día a día, de esta forma es posible obtener detalles que normalmente son excluidos de la descripción de los requerimientos pues suelen ser asumidos como conocidos en la definición del problema.
  • Prototipos: Esta técnica ofrece la simulación del ambiente real en donde la solución será aplicada para obtener detalles del entorno y su interacción como solución.

Estos procesos son de gran utilidad cuando uno trata de capturar los requerimientos funcionales y no funcionales, como se ve no hay una restricción especifica a usar una metodología u otra, de hecho la combinación de todas puede aproximar la solución real e ideal de las peticiones del cliente.

La claridad tanto del cliente cuando describe su problema como la habilidad del observador para hacer énfasis en los detalles importantes o bien en minimizar las ambigüedades es algo totalmente deseable en este proceso y la realización de ejercicios internos dentro del equipo de trabajo para detectar las personas que pueden tener ese rol son de gran ayuda al momento de asignar responsabilidades al equipo de trabajo.

Saludos,

Roberto Erazo