La gestión eficaz de un proyecto de software se centra en las cuatro P: 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.
El MMCGP es compañero del modelo de madurez de la capacidad software, que guía a las organizaciones en la creación de un proceso de software maduro. Más adelante en este capítulo se consideran aspectos asociados a la gestión de personal y estructuras para proyectos de software.
Los participantes
El proceso del software (y todos los proyectos de software) lo componen participantes que pueden clasificarse en una de estas cinco categorías:
Gestores superiores, que definen los aspectos de negocios que a menudo tienen una significativa influencia en el proyecto.
Gestores (técnicos) del proyecto, que deben planificar, motivar, organizar y controlar a los profesionales que realizan el trabajo de software.
Profesionales, que proporcionan las capacidades técnicas necesarias para la ingeniería de un producto o aplicación.
Clientes, que especifican los requisitos para la ingeniería del software y otros elementos que tienen menor influencia en el resultado.
Usuarios finales, que interaccionan con el software una vez que se 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
La gestión de un proyecto es una actividad intensamente humana, y por esta razón, los profesionales competentes del software a menudo no son buenos jefes de equipo.
Simplemente no tienen la mezcla adecuada de capacidades del personal. Y sin embargo, como dice
Edgemon: «Desafortunadamente y con demasiada frecuencia, hay individuos que terminan en la gestión de proyectos y se convierten en gestores de proyecto accidentales»
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. Para bien o para mal, el organigrama no puede cambiarse fácilmente. Las consecuencias prácticas y políticas de un cambio de organización no están dentro del alcance de las responsabilidades del gestor de un proyecto de software. Sin embargo, la organización del personal directamente involucrado en un nuevo proyecto de software está dentro del ámbito del gestor del proyecto.
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; la coordinación es responsabilidad del gestor del software que puede que tenga otros seis proyectos de los que preocuparse
2. n individuos son asignados a m diferentes tareas funcionales
(m<n) de manera que se establecen «equipos informales; se puede nombrar un líder al efecto; la coordinación entre los equipos es responsabilidad de un gestor del software.
3. n individuos se organizan en t equipos; a cada equipo se le asignan una o más tareas funcionales; cada equipo tiene una estructura específica que se define para todos los equipos que trabajan en el proyecto; la coordinación es controlada por el equipo y por el gestor del proyecto de software.
Aunque es posible encontrar argumentos en pro y en contra para cada uno de los enfoques anteriores, existe equipo formal (opción 3) es la más productiva.
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:
1. 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». Las decisiones sobre problemas y los enfoques se hacen por consenso del grupo. La comunicación entre los miembros del equipo es horizontal.
2. Descentralizado controlado (DC). Este equipo de ingeniería del software tiene un jefe definido que coordina tareas específicas y jefes secundarios que tienen responsabilidades sobre subtareas. La resolución de problemas sigue siendo una actividad del grupo, pero la implementación de soluciones se reparte entre subgrupos por el jefe de equipo. La comunicación entre subgrupos e individuos es horizontal. También hay comunicación vertical a lo largo de la jerarquía de control.
3. 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. La comunicación entre el jefe y los miembros del equipo es vertical.
Cargos
· Operador de PC
· Técnico de soporte y mantenimiento.
· Técnico de reparación de PC, Impresoras, monitores, celulares, laptops…
· Técnico en Programación.
· Técnico en redes de PC, Telefónicas y de Comunicación.
· Ingenieros en computación.
· Ingenieros en Sistemas de Información.
· Ingenieros en Telecomunicaciones.
· Ingenieros Electrónicos.
· Administrador de Bases de Datos
· Administrador de Redes.
· Administrador de Servidores.
· Administrador de Sistemas Informáticos.
· Analista.
· Diseñador de Sitios Web.
· Diseñador de interfaz.
· Desarrollador.
· Evaluador.
· Auditores.
Producto
Antes de poder planificar un proyecto, se deberían establecer los objetivos y el ámbito del producto, se deberían considerar soluciones alternativas e identificar las dificultades técnicas y de gestión. Sin esta información, es imposible definir unas estimaciones razonables (y exactas) del coste; una valoración efectiva del riesgo, una subdivisión realista de las tareas del proyecto o una planificación del proyecto asequible que proporcione una indicación fiable del progreso.
El desarrollador de software y el cliente deben reunirse para definir los objetivos del producto y su ámbito. En muchos casos, esta actividad empieza como parte del proceso de ingeniería del sistema o del negocio y continúa como el primer paso en el análisis de los requisitos del software. Los objetivos identifican las metas generales del proyecto sin considerar cómo se conseguirán (desde el punto de vista del cliente).
El ámbito identifica los datos primarios, funciones y comportamientos que caracterizan al producto, y, más importante, intenta abordar estas características de una manera cuantitativa.
Una vez que se han entendido los objetivos y el ámbito del producto, se consideran soluciones alternativas.
Proceso
Un proceso de software proporciona la estructura desde la que se puede establecer un detallado plan para el desarrollo del software. Un pequeño número de actividades estructurales se puede aplicar a todos los proyectos de software, sin tener en cuenta su tamaño o complejidad. Diferentes conjuntos de tareas, hitos, productos del trabajo y puntos de garantía de calidad permiten las actividades estructurales adaptarse a las características del proyecto de software y a los requisitos del equipo del proyecto. Finalmente, las actividades protectoras tales como garantía de calidad del software, gestión de la configuración del software y medición- cubren el modelo de proceso.
Las actividades protectoras son independientes de las estructurales y tienen lugar a lo largo del proceso.
Proyecto
Dirigimos los proyectos de software planificados y controlados por una razón principal es la Única manera conocida de gestionar la complejidad-. Y todavía seguimos esforzándonos. En 1998, los datos de la industria del software indicaron que el 26% de proyectos de software fallaron completamente y que el 46 % experimentaron un desbordamiento en la planificación y en el coste. Aunque la proporción de éxito para los proyectos de software ha mejorado un poco, nuestra proporción de fracaso de proyecto permanece más alto del que debería ser .Para evitar el fracaso del proyecto, un gestor de proyectos de software y los ingenieros de software que construyeron el producto deben eludir un conjunto de señales de peligro comunes; comprender los factores del éxito críticos que conducen a la gestión correcta del proyecto y desarrollar un enfoque de sentido común para planificar, supervisar y controlar el proyecto.
Practicas Críticas
El Concilio Airlie ha desarrollado una lista de «prácticas críticas de software para la gestión basada en el rendimiento». Estas prácticas son «utilizadas de un modo consistente por, y consideradas críticas por, organizaciones y proyectos de software de mucho éxito cuyo rendimiento “final” es más consistente que los promedios de la industria». En un esfuerzo por permitir a una organización de software determinar si un proyecto específico ha implementado prácticas críticas, el Concilio Airlie ha desarrollado un conjunto de preguntas de «Visión Rápida» para un proyecto:
Gestión formal del riesgo. ¿Cuáles son los diez riesgos principales para este proyecto? Para cada uno de los riesgos ¿cuál es la oportunidad de que el riesgo se convierta en un problema y cuál es el impacto si lo hace?
Coste empírico y estimación de la planificación.
¿Cuál es el tamaño actual estimado de la aplicación de software (sin incluir el software del sistema) que será entregada en la operación? ¿Cómo se obtuvo?
Gestión de proyectos basada en métricas. ¿Dispone de un programa de métricas para dar una primera indicación de los problemas del desarrollo? Si es así, ¿cuál es la volatilidad de los requisitos actualmente?
Seguimiento del valor ganado. ¿Informa mensualmente de las métricas del valor ganado...? Si es así, ¿están calculadas estas métricas desde una red de actividades de tareas para el esfuerzo total a la próxima entrega?
Seguimiento de defectos frente a objetivos de calidad.
¿Realiza el seguimiento e informa periódicamente del número de defectos encontrados en cada prueba de inspección [revisión técnica formal] y ejecución desde el principio del programa y del número de defectos que se corrigen y se producen en la actualidad?
Gestión del programa del personal. ¿Cuál es la media de rotación de la plantilla en los tres Últimos meses por cada uno de los distribuidores/desarrolladores involucrados en el desarrollo del software para este sistema? Si un equipo de proyectos de software no puede responder a estas preguntas, o las responde inadecuadamente, se debe realizar una revisión completa de las prácticas del proyecto. Cada una de las prácticas críticas señaladas anteriormente se trata con detalle
No hay comentarios:
Publicar un comentario