La gestión eficaz de un proyecto de software se centra en las cuatro P’s: personal, producto, proceso y proyecto. El orden no es arbitrario. El gestor que se olvida de que el trabajo de ingeniería del software es un esfuerzo humano intenso nunca tendrá éxito en la gestión de proyectos. Un gestor que no fomenta una minuciosa comunicación con el cliente al principio de la evolución del proyecto se arriesga a construir una elegante solución para un problema equivocado. El administrador que presta poca atención al proceso corre el riesgo de arrojar métodos técnicos y herramientas eficaces al vacío. El gestor que emprende un proyecto sin un plan sólido arriesga el éxito del producto.
PERSONAL: La necesidad de contar con personal para el desarrollo del software altamente preparado y motivado se viene discutiendo desde los años 60. De hecho, el «factor humano» es tan importante que el Instituto de Ingeniería del Software ha desarrollado un Modelo de madurez de la capacidad de gestión de personal (MMCGP) «para aumentar la preparación de organizaciones del software para llevar a cabo las cada vez más complicadas aplicaciones ayudando a atraer, aumentar, motivar, desplegar y retener el talento necesario para mejorar su capacidad de desarrollo de software».
El modelo de madurez de gestión de personal define las siguientes áreas clave prácticas para el personal que desarrolla software: reclutamiento, selección, gestión de rendimiento, entrenamiento, retribución, desarrollo de la carrera, diseño de la organización y del trabajo y desarrollo cultural y de espíritu de equipo.
- Los participantes.
1.- Gestores superiores, que definen los aspectos de negocios que a menudo tienen una significativa influencia en el proyecto.
2.- Gestores (técnicos) del proyecto, que deben planificar, motivar, organizar y controlar a los profesionales que realizan el trabajo de software.
3.- Profesionales, que proporcionan las capacidades técnicas necesarias para la ingeniería de un producto o aplicación.
4.- Clientes, que especifican los requisitos para la ingeniería del software y otros elementos que tienen menor influencia en el resultado.
5.- Usuarios finales, que interaccionan con el software una vez que ha entregado para la producción.
Para ser eficaz, el equipo del proyecto debe organizarse de manera que maximice las habilidades y capacidades de cada persona. Y este es el trabajo del jefe del equipo.
- Los jefes de equipo.
Weinberg sugiere que el éxito de los gestores de proyecto se basa en aplicar un estilo de gestión en la resolución de problemas. Es decir, un gestor de proyectos de software debería concentrarse en entender el problema que hay que resolver, gestionando el flujo de ideas y, al mismo tiempo, haciendo saber a todos los miembros del equipo (mediante palabras y, mucho más importante, con hechos) que la calidad es importante y que no debe verse comprometida.
Motivación. La habilidad para motivar (con un «tira y afloja») al personal técnico para que produzca conforme a sus mejores capacidades.
Organización. La habilidad para amoldar procesos existentes (o inventar unos nuevos) que permita al concepto inicial transformarse en un producto final.
Ideas o innovación. La habilidad para motivar al personal para crear y sentirse creativos incluso cuando deban de trabajar dentro de los límites establecidos para un producto o aplicación de software particular.
Incentivos por logros. Para optimizar la productividad de un equipo de proyecto, un gestor debe recompensar la iniciativa y los logros, y demostrar a través de sus propias acciones que no se penalizará si se corren riesgos controlados.
Influencia y construcción de espíritu de equipo. Un gestor de proyecto eficiente debe ser capaz de «leer» a la gente; debe ser capaz de entender señales verbales y no verbales y reaccionar ante las necesidades de las personas que mandan esas señales. El gestor debe mantener el control en situaciones de gran estrés.
Motivación. La habilidad para motivar (con un «tira y afloja») al personal técnico para que produzca conforme a sus mejores capacidades.
Organización. La habilidad para amoldar procesos existentes (o inventar unos nuevos) que permita al concepto inicial transformarse en un producto final.
Ideas o innovación. La habilidad para motivar al personal para crear y sentirse creativos incluso cuando deban de trabajar dentro de los límites establecidos para un producto o aplicación de software particular.
Incentivos por logros. Para optimizar la productividad de un equipo de proyecto, un gestor debe recompensar la iniciativa y los logros, y demostrar a través de sus propias acciones que no se penalizará si se corren riesgos controlados.
Influencia y construcción de espíritu de equipo. Un gestor de proyecto eficiente debe ser capaz de «leer» a la gente; debe ser capaz de entender señales verbales y no verbales y reaccionar ante las necesidades de las personas que mandan esas señales. El gestor debe mantener el control en situaciones de gran estrés.
- El equipo de software.
Existen casi tantas estructuras de organización de personal para el desarrollo de software como organizaciones que se dedican a ello.
Las siguientes opciones pueden aplicarse a los recursos humanos de un proyecto que requiere n personas trabajando durante k años:
1. n individuos son asignados a m diferentes tareas funcionales, tiene lugar relativamente poco trabajo conjunto.
2. n individuos son asignados a m diferentes tareas funcionales (m<n) de manera que se establecen <<equipos>> informales.
3. n individuos se organizan en t equipos; a cada equipo se le asignan una o más tareas funcionales.
La <<mejor>> estructura de equipo depende del estilo de gestión de una organización, el número de personas que compondrá el equipo, sus niveles de preparación y la dificultad general del problema. Mantei sugiere tres organigramas de equipo genéricos:
Descentralizado democrático (DD). Este equipo de ingeniería del software no tiene un jefe permanente. Más bien, <<se nombran coordinadores de tareas a corto plazo y se sustituyen por otros para diferentes tareas>>.
Descentralizado controlado (DC). Este equipo de ingeniería de software tiene un jefe definido que coordina tareas específicas y jefes secundarios que tienen responsabilidades sobre subtareas.
Centralizado controlado (CC). El jefe del equipo se encarga de la resolución de problemas a alto nivel y la coordinación interna del equipo.
Mantei describe siete factores de un proyecto que deberían considerarse cuando se planifica el organigrama de equipos de ingeniería del software:
· La dificultad del problema que hay que resolver.
· El tamaño del programa(s) resultante(s) en líneas de código o puntos de función.
· El tiempo que el equipo estará junto (tiempo de vida del equipo).
· El grado en que el problema puede ser modularizado.
· La calidad requerida y fiabilidad del sistema que se va a construir.
· La rigidez de la fecha de entrega.
· El grado de sociabilidad (comunicación) requerido para el proyecto.
Los equipos CC y DC producen menos defectos que los equipos DD, pero estos datos tienen mucho que ver con las actividades específicas de garantía de calidad que aplica el equipo. Los equipos descentralizados requieren generalmente más tiempo para completar un proyecto que un organigrama centralizado y al mismo tiempo son mejores cuando se precisa una gran cantidad de comunicación.
Constantine sugiere cuatro <<paradigmas de organización>> para equipos de ingeniería del software:
1.- Un paradigma cerrado estructura a un equipo con una jerarquía tradicional de autoridad (similar al equipo CC).
2.- El paradigma aleatorio estructura al equipo libremente y depende de la iniciativa individual de los miembros del equipo.
3.- El paradigma abierto intenta estructurar a un equipo de manera que consiga algunos de los controles asociados con el paradigma cerrado, pero también utiliza el paradigma aleatorio.
4.- El paradigma sincronizado se basa en la compartimentación natural de un problema y organiza los miembros del equipo para trabajar en partes del problema con poca comunicación activa entre ellos.
Constantine propone una variación en el equipo descentralizado democrático defendiendo a los equipos con independencia creativa cuyo enfoque de trabajo podría ser mejor llamado <<anarquía innovadora>>. Para conseguir un equipo de alto rendimiento:
· Los miembros del equipo deben confiar unos en otros.
· La distribución de habilidades debe adecuarse al problema.
· Para mantener la unión del equipo, los inconformistas tienen que ser excluidos del mismo.
- Aspectos sobre la coordinación y la comunicación.
Hay muchos motivos por los que los proyectos de software pueden tener problemas. La escala (tamaño) de muchos esfuerzos de desarrollo es grande, conduciendo a complejidades, confusión y dificultades significativas para coordinar a los miembros del equipo. La incertidumbre es corriente, dando como resultado un continuo flujo de cambios que impactan al equipo del proyecto. La interoperatividad se ha convertido en una característica clave de muchos sistemas. El software nuevo debe comunicarse con el anterior y ajustarse a restricciones predefinidas impuestas por el sistema o el producto.
Estas características del software moderno, son aspectos de la vida. Para enfrentarse a ellos eficazmente, un equipo de ingeniería del software debe establecer métodos efectivos para coordinar a la gente que realiza el trabajo. Para lograr esto se deben establecer mecanismos de comunicación formales e informales entre los miembros del equipo y entre múltiples equipos.
PRODUCTO: El gestor de un proyecto de software se enfrenta a un dilema al inicio de un proyecto de ingeniería del software. Se requieren estimaciones cuantitativas y un plan organizado, pero no se dispone de información sólida.
- Ámbito del software.
El ámbito se define respondiendo a las siguientes cuestiones:
Contexto. ¿Cómo encaja el software a construir en un sistema, producto o contexto de negocios mayor y qué limitaciones se imponen como resultados del contexto?
Objetivos de información. ¿Qué objetos de datos visibles al cliente se obtienen del software? ¿Qué objetos de datos son requeridos de entrada?
Función y rendimiento. ¿Qué función realiza el software para transformar la información de entrada en una salida? ¿Hay características de rendimiento especiales que abordar?
- Descomposición del problema.
La descomposición del problema, denominado a veces particionado o elaboración del problema, es una actividad que se asienta en el núcleo del análisis de requisitos del software. Durante la actividad de exposición del ámbito no se intenta descomponer el problema totalmente. Más bien, la descomposición se aplica en dos áreas principales: (1) la funcionalidad que debe entregarse y (2) el proceso que se empleará para entregarlo.
PROCESO: El gestor del proyecto debe decidir qué modelo de proceso es el más adecuado para (1) los clientes que han solicitado el producto y la gente que realizará el trabajo; (2) las características del producto en sí, y (3) el entorno del proyecto en el que trabaja el equipo de software.
· Comunicación con el cliente: tareas requeridas para establecer la obtención de requisitos eficiente entre el desarrollador y el cliente.
· Planificación: tareas requeridas para definir los recursos, la planificación temporal del proyecto y cualquier información relativa a él.
· Análisis del riesgo: tareas requeridas para valorar los riesgos técnicos y de gestión.
· Ingeniería: tareas requeridas para construir una o más representaciones de la aplicación.
· Construcción y entrega: tareas requeridas para construir, probar, instalar y proporcionar asistencia la usuario.
· Evaluación del cliente: tareas requeridas para obtener información de la opinión de cliente basadas en la evaluación de las representaciones de software creadas durante la fase de ingeniería e implementas durante la fase de instalación.
Una vez que se ha elegido el modelo de proceso, la estructura común de proceso (ECP) se adapta a él. En todos los casos, el ECP estudiado anteriormente puede adaptarse al paradigma. El ECP es invariable y sirve como base para todo el trabajo de software realizado por una organización.
- Maduración del producto y del proceso.
· Comunicación con el cliente: tareas requeridas para establecer la obtención de requisitos eficiente entre el desarrollador y el cliente.
· Planificación: tareas requeridas para definir los recursos, la planificación temporal del proyecto y cualquier información relativa a él.
· Análisis del riesgo: tareas requeridas para valorar los riesgos técnicos y de gestión.
· Ingeniería: tareas requeridas para construir una o más representaciones de la aplicación.
· Construcción y entrega: tareas requeridas para construir, probar, instalar y proporcionar asistencia la usuario.
· Evaluación del cliente: tareas requeridas para obtener información de la opinión de cliente basadas en la evaluación de las representaciones de software creadas durante la fase de ingeniería e implementas durante la fase de instalación.
- Descomposición del proceso
Una vez que se ha elegido el modelo de proceso, la estructura común de proceso (ECP) se adapta a él. En todos los casos, el ECP estudiado anteriormente puede adaptarse al paradigma. El ECP es invariable y sirve como base para todo el trabajo de software realizado por una organización.
PROYECTO: Para gestionar un proyecto de software con éxito, debemos comprender qué puede ir mal (para evitar esos problemas) y cómo hacerlo bien. En un excelente documento sobre proyectos de software, John Reel define diez señales que indican que un proyecto de sistemas de información está en peligro:
1.- La gente del software no comprende las necesidades de los clientes.
2.- El ámbito del producto está definido pobremente.
3.- Los cambios están mal realizados.
4.- La tecnología elegida cambia.
5.- Las necesidades del negocio cambian (o están mal definidas)
6.- Las fechas de entrega no son realistas.
7.- Los usuarios se resisten.
8.- Se pierden los patrocinadores (o nunca se obtuvieron adecuadamente)
9.- El equipo del proyecto carece del personal con las habilidades apropiadas.
10.- Los gestores (y los desarrolladores) evitan buenas prácticas y sabias lecciones.
1.- La gente del software no comprende las necesidades de los clientes.
2.- El ámbito del producto está definido pobremente.
3.- Los cambios están mal realizados.
4.- La tecnología elegida cambia.
5.- Las necesidades del negocio cambian (o están mal definidas)
6.- Las fechas de entrega no son realistas.
7.- Los usuarios se resisten.
8.- Se pierden los patrocinadores (o nunca se obtuvieron adecuadamente)
9.- El equipo del proyecto carece del personal con las habilidades apropiadas.
10.- Los gestores (y los desarrolladores) evitan buenas prácticas y sabias lecciones.
No hay comentarios:
Publicar un comentario