viernes, 24 de marzo de 2017

Gestión de Proyectos y Metodología de Desarrollo de Software

Panorama General

Además de las metodologías comercialmente disponibles como Prince 2 y Rational Unified Process (RUP), existen muchas metodologías desarrolladas a la medida para organizaciones individuales. Este artículo trata de proveer un mejor entendimiento de las metodologías y cómo éstas se pueden desarrollar e implementar.

Metodología de Gestión de Proyectos & Metodología de Desarrollo de Aplicaciones

Es importante diferenciar entre una metodología de gestión de proyectos y una metodología de desarrollo de aplicaciones o metodología de desarrollo de software. Una metodología de gestión de proyectos cubre todas las cosas que un gerente de proyectos necesita hacer independientemente de si se trata de un desarrollo de software, una selección de paquetes, o una mudanza de su departamento de proyectos.

La Guía del PMBOK® (Project Management Body of Knowledge – Biblia del PMI) cubre nueve áreas de la gestión de proyectos, siendo éstas las siguientes:

Gestión del Costo
Gestión del Riesgo
Gestión del Alcance
Gestión de los Recursos
Gestión de las Comunicaciones
Gestión de la Calidad
Gestión del Tiempo
Gestión de las Adquisiciones
Gestión de la Integración
Como se podrá ver, no se menciona nada acerca de requerimientos, pruebas, o selección de vendedores. Eso es parte de una metodología de desarrollo de aplicaciones o metodología de desarrollo de software.

Diferencias entre Metodologías

· Una metodología de gestión de proyectos dice que los proyectos deben descomponerse en fases y debe existir un plan definido para cada fase antes de que empiecen. Una metodología de desarrollo de aplicaciones define que fases serán y que actividades deben de ejecutarse en cada una.

· Una metodología de gestión de proyectos dice que hay que definir roles y responsabilidades. Una metodología de desarrollo de aplicaciones define que roles y responsabilidades habrán en la fase de desarrollo.

· Una metodología de gestión de proyectos dice que se debe establecer un presupuesto y que debe ser gestionado adecuadamente. Una metodología de desarrollo de aplicaciones define cuales deberían ser los códigos de cuenta para un desarrollo en su organización.

La metodología de gestión de proyectos es la estructura de trabajo. Una metodología de desarrollo de aplicaciones es la carne que colocamos sobre los huesos.
La prueba auténtica para diferenciar una metodología de gestión de proyectos es hacer la
pregunta:

“¿Podría colocar otra carne sobre los mismos huesos?”

Por ejemplo, podría tener una metodología de selección de paquetes que podría encajar a
la perfección en una metodología de gestión de proyectos. La diferencia está en que contiene un conjunto diferentes de actividades, roles, responsabilidades, riesgos, etc.


¿Por qué es importante conocer la distinción?

Es importante porque cualquier organización debe tener una metodología de gestión de proyectos consistente, la cual sea de uso común para cualquier tipo de proyecto. De esta manera, el personal puede moverse confortablemente de desarrollo de aplicaciones, a despliegue de infraestructura, a selección de software, o incluso mudanzas a nuevos edificios, usando la misma metodología.

Entrenar al personal en gestión de proyectos tiene prioridad antes de que aprendan a desarrollar, seleccionar software, o incluso antes de hacer algún proyecto que no tenga una metodología definida. Las personas necesitan saber que deben administrar el alcance, y deben saber como hacerlo. Deben saber como elaborar un presupuesto y como gestionarlo. Deben saber como hacer una evaluación de riesgos y como gestionar los riesgos.

Una Metodología no es una Plantilla

Otra área de confusión es que las personas entreveran plantillas y metodologías. Cuando se pregunta a la gente si poseen una metodología, responden “Si, tenemos algunas plantillas.”

Una evolución típica para una organización que no tiene un modo definido de hacer las cosas es empezar desarrollando plantillas para ganar algo de consistencia en la manera en que se presentan las cosas. En esta fase lo que en realidad se está expresando es: “Aquí tienes una lista de cosas que necesitas considerar”. La siguiente fase es adicionar algunas instrucciones en la plantilla que expliquen que significa cada sección. Alternativamente se puede crear una guía de usuario de la plantilla. Finalmente se podría desarrollar un proceso o metodología que indique a las personas como obtener la información que termina en la plantilla.

Existen frecuentes confusiones entre plantillas y procesos:

· Un proceso es un modo de hacer las cosas, ejecutando algunas actividades en una cierta secuencia.
· Las plantillas se usan para recolectar las salidas de los procesos.


Solo porque se tenga plantillas, no significa que la gente conozca como recolectar la información que va en ellas. Por ejemplo una plantilla podría tener una sección con un encabezado llamado “Seguridad”. El proceso correspondiente podría ser algo como esto:

· Discutir el proyecto con el gerente de seguridad de aplicaciones e identificar que acciones se requerirán para satisfacer los estándares corporativos.
· Revisar cómo el proyecto será afectado por los nuevos estándares de seguridad a ser introducidos por la arquitectura. Esto se debe hacer en un taller con las siguientes personas…
· Conversar con la administración de redes e identificar cualquier implicación de seguridad de la red.
· Reunirse con Microsoft y discutir cualquier parche de seguridad que pueda necesitar ser distribuido con el software.
· Etc.

Si sólo tenemos disponible una plantilla y no un proceso, la persona que llenará la plantilla quizás no sepa nada de las actividades mencionadas arriba, y al final la sección “Seguridad” podría llevar sólo la anotación “No aplicable a este proyecto”. Esta es la diferencia entre una plantilla y un proceso o metodología.

¿Qué debe de cubrir una metodología?

Cualquier metodología debería cubrir los siguientes tópicos:


Usando una Metodología

Una metodología no podrá ser usada por todos los proyectos que se llevarán a cabo. Habrá que hacer ajustes por muy buenas razones. Esto no significa que la metodología variará según el antojo de cada equipo. Se necesitará tener guías específicas sobre un enfoque pragmático y razonable para cada proyecto.

Una investigación de Gartner Group encontró que una metodología aplicada con holgura podría mejorar la productividad en un 30%. Aplicarla rígidamente mejoraría el producto en solamente 10%. La metodología debe ser una ayuda para el proyecto, no un obstáculo. Si se desea que nuestra organización use una metodología, se necesitará tener algunos expertos a quienes puedan recurrir las personas por ayuda.

Objeciones para Usar una Metodología

A continuación hay algunas objeciones comunes y la forma en que pueden ser manejadas:

¿Reprime mi creatividad?

· La creatividad no significa “Lo haré conforme avanzo”. Debe significar “Poseo un mecanismo de reconocimiento de problemas y uso mi creatividad para resolverlos”. En un proyecto la creatividad necesita realizarse dentro un ambiente controlado. A menos que exista una estructura establecida, los cientos de detalles y problemas no podrán ser controlados.

Poseo mi propia metodología

· Cualquiera de nosotros, que haya trabajado en organizaciones, posee usualmente una metodología. La razón para usar la metodología de la compañía es que alguien más esta operando dentro de esa metodología. Por lo tanto causará confusión a todos si cada uno usa sus propios procesos.

Mi metodología es mejor

· Una compañía debe tener un área responsable para revisar y mejorar metodologías.
Ese es el lugar donde se debe promover una nueva metodología.

La metodología no es aplicable a mi proyecto

· Si no es así ¿Porqué no? Qué componentes son aplicables, y cómo se pueden incluir otros procesos para unirse a éstos. Revise la metodología de gestión de proyectos, ¿Qué nuevas actividades, roles, etc. necesitan ser desarrollados?

La metodología (o plantilla) tiene mucha información

· Trátela como un checklist. Si algo no es aplicable, justifique porqué y haga un comentario. Podría ser una situación como el tema de seguridad mencionado anteriormente, donde la persona no entiende el proceso en forma apropiada.

Existe mucho papeleo

· Un par de puntos: Primero, pregunté qué información está. A veces un pequeño rearreglo de información puede resultar en una solución tipo “refiérase al documento X”, o a un cortar y pegar párrafos. Segundo, es más barato y fácil desechar papel que código. Los programadores adoran tener sus manos en el teclado, pero es más eficiente construir algo en papel antes de hacerlo en código. Tercero, examine cada documento y vea si es realmente necesario. Hice este ejercicio con un CFO (Chief Financial Officer) quien hizo un comentario acerca de la cantidad de papel que estábamos generando. Después de revisar cerca de diez documentos que tenía sobre su escritorio, encontró al menos una razón para recibir cada uno de ellos. Todo se debía simplemente a que no estaba acostumbrado a ver agendas, actas o reportes semanales.

Implementando una Metodología

Una metodología no es una serie de plantillas. Es un proceso que necesita ser adaptado a la medida de cada situación. Para esto se necesita de alguien con quien el equipo se pueda comunicar, el cual será el mentor de los equipos en el uso de la metodología.
Una de las implantaciones más exitosas de una metodología en la cual he participado, fue la de un departamento de gobierno. Ellos tienen un coordinador de la metodología a tiempo completo, quien entrena, trabajaba con los equipos, e integra la retroalimentación dentro de la metodología.

La retroalimentación es muy importante. La metodología no permanecerá inmóvil. Evolucionará volviéndose más aplicable en la organización. En este sentido se necesitará un mecanismo establecido que se ocupe del “aprendizaje a partir de la experiencia”.

Proceda de manera gradual. Un cambio radical en el modo en que la gente trabaja no tendrá probablemente tanto éxito como un cambio progresivo. Si la meta es tener personas elaborando un plan para cada fase, lo mejor será que empiecen por un solo plan estándar para todo el proyecto. Si decide introducir tres puntos de control para la aprobación de recursos, introdúzcalos uno a la vez. Probablemente encontrará, después de haber establecido el primer punto de control, que tendrá que cambiar tan sólo ligeramente su proceso para establecer los otros dos puntos de control.

La disponibilidad es otro asunto a tratar. Pedir a las personas que lean 400 hojas de un manual, no funciona. Proporcionarles un entrenamiento de alto nivel, y presentándoles la información en un formato donde puedan encontrar fácilmente la parte que es relevante para la labor que están realizando, tiene muchas más probabilidades de éxito.
Una bien estructurada presentación vía Web, es una condición indispensable. Las personas necesitan ser capaces de profundizar rápidamente a través de unos cuantos clicks, para encontrar lo que es relevante para ellos en ese momento. Entrenarlos en el layout del website de la metodología probablemente tendrá mayor impacto que entrenarlos en el detalle de la metodología.

Resumen

Colocar algunas plantillas es un buen primer paso, pero no es una metodología. Asegúrese de entender la diferencia entre las plantillas y los procesos. También entienda la diferencia entre una metodología de gestión de proyectos y otras metodologías.
Para muchas personas la metodología es una palabra sucia. Significa burocracia, papeleo, y restricciones. Se necesita superar esto proveyendo soporte y flexibilidad en la manera de aplicar la metodología. Todavía no he visto una metodología que tenga éxito con tan solo presentar a las personas una serie de libros y plantillas.

Finalmente, aprenda a caminar antes de correr. Primero implante pasos simples en la metodología, dejando lo más complicado para el final. Comprenda que está tratando de cambiar el modo de pensar y trabajar de las personas. Hay una resistencia al cambio. Aborde el asunto lentamente o se encontrará obteniendo pocos resultados o ninguno.

Neville Turbit tiene más de 15 años de experiencia como Consultor TI y casi el mismo tiempo en Negocios. Es el director principal de Project Perfect. Project Perfect es una organización de consultoría y entrenamiento localizada en Sydney, Australia. Su foco es proveer soluciones creativas aunque pragmáticas para los problemas dela Gestiónde Proyectos.

Project Perfect vende el software “Project Administrator”, el cual es una herramienta que ayuda a las organizaciones a gestionar mejor los riesgos del proyecto, problemas, presupuestos, alcance, documentación del planeamiento, y programación de actividades. También ha creado una técnica para levantar información llamada “Method H”, y vende software para soportar dicha técnica. Para mayor información sobre Herramientas para Proyectos o Gestión de Proyectos visite www.projectperfect.com.au

CRÉDITOS

Autor: Neville Turbit

E-mail: project@projectperfect.com.au

Fuente: Project Perfect

Enlace artículo original: http://www.projectperfect.com.au/downloads/Info/info_methodology_implementation.pdf

No hay comentarios:

Publicar un comentario