Problemas al planificar un proyecto

0
28000

¿Por qué cuesta tanto planificar proyectos informáticos?

Cuando se desarrolla un proyecto informático, independientemente de la
metodología de desarrollo utilizada, hay que realizar multitud de actividades,
documentos, procedimientos, programas, etc..

En la siguiente tabla expongo (de mi cosecha) una lista de las tareas a
realizar de un modo genérico en cualquier proyecto. Obviamente es una plantilla
pobre pero nos puede valer para realizar nuestro planteamiento, al tratar de
entender por qué los proyectos informáticos son tan impredecibles ….

 

Tarea
Preparación
Definición del comité de dirección
Definición del ámbito del proyecto
Identificación de recursos corporativos
Identificación de disponibilidad de recursos humanos
Análisis de la competencia
Definición prioridades de negocio
Selección de productos y proveedores
Definición del plan de comunicación

……

Análisis Requerimientos
Definición de metodología y criterios de calidad
Primera rueda de entrevistas negocio
Definición de casos de uso de contexto (requerimientos)
Definición de diagramas de actividad principales
Segunda rueda entrevistas negocio
Refinamiento de casos de uso
Definición del modelo de negocio
Entrevista personal de seguridad
Análisis de políticas de seguridad
Entrevista con personal tecnología
Definición arquitectura candidata
Verificación de arquitectura
Análisis de la imagen de marca
Análisis Riesgos del sistema
Construcción del glosario de términos
Primera entrega del documento requisitos
Instalación del entorno de desarrollo
Redefinición de alcance y entregas
Definición de textos legales y condiciones de uso

……

Análisis Funcional
Entrevistas con áreas especificas
Refinamiento de requisitos funcionales
Definición del modelo de análisis
Diagramas de secuencia fundamentales
Definición de estados fundamentales
Análisis de interfaces con otros sistemas
Definición de origen de datos
Definición de procedimientos automáticos
Definición de procedimientos manuales
Definición de prioridades
Análisis de Usabilidad
Definición guía de estilo (diseño gráfico)
Preparación de propuesta l&f
Selección de la propuesta de l&f
Desarrollo maqueta
Definición pruebas funcionales automáticas
Definición de las pruebas de aceptación
Diseño de procedimiento operacionales de salvaguarda de negocio

……

Diseño detallado
Refinamiento requisitos técnicos
Análisis de aplicaciones y componentes existentes
Construcción de pruebas de validación estructural
Construcción del modelo de diseño
Definición del modelo de presentación
Definición del modelo de persistencia
Definición de patrones generales
Definición de modelo de procesos batch
Refinamiento del modelo de clases (asignación de responsabilidades)
Definición modelo de gestión de errores y excepciones
Definición del modelo de empaquetamiento
Definición de entornos (desarrollo, preproducción, etc.)
Definición de estrategia de paso entre entornos
Revisión de Seguridad
Revisión Arquitectura
Definición del modelo lógico de datos
Definición de estándares de calidad
Adquisición de licencias de software
Asignación de Hardware (adquisición o reciclaje)
Revisión de calidad

……

Construcción
Formación a desarrolladores (Guía de desarrollo)
Definición pruebas unitarias e integración
Identificación de patrones
Desarrollo aplicación
Construcción de paquetes de servicio
Construcción de paquetes de solución
Refinamiento del interfaz de usuario
Construcción del modelo físico de datos
Carga inicial de base de datos
Construcción de rutinas de migración de datos
Pruebas
Ejecución de pruebas unitarias
Ejecución de pruebas integradas
Análisis de viabilidad de pruebas en producción
Pruebas de estabilidad y sincronización de accesos
Desarrollo de rutinas empaquetamiento
Documentación
Desarrollo guía de usuario
Desarrollo guía Help-Desk
Desarrollo guía instalación
Desarrollo guía de operaciones y contingencia operativa
Ejecución de pruebas de aceptación
Asignación de prioridades a deficiencias
Corrección de deficiencias
Definición de nuevos requerimientos
Empaquetamiento y verificación de integridad

……

Despliegue
Plan de Formación administradores y help-desk
Definición de estrategia de backup
Formalización de estrategia de instalación de parches y nuevas versiones
Definición de procedimientos de monitorización
Pruebas de Rendimiento y Usabilidad
Generación informe pruebas Rendimiento y Usabilidad
Reingeniería y optimización de código
Optimización base de datos
Revisión de documentación
Definición de la política de cambios y gestión incidencias



Planificación de la siguiente iteración

……

Como podéis comprobar, antes de empezar a detallar más actividades
particulares del proyecto concreto, tenemos más de 100 líneas.

Cualquiera de ellas, hasta las más triviales, nos llevarán más de un día así
que cualquier proyecto, por muy pequeño que sea, nos costaría más de 3 meses
para una persona (si cuentas los días laborables). Pero hay que tener en cuenta:

  • No es muy  normal que una persona pueda realizar todas las labores
    descritas (y mucho menos hacerlas todas bien) por lo que necesitaremos
    distintos perfiles especializados. Definir la participación correcta de cada
    perfil es difícil…. lo que implica infrautilización.
  • Cuando hay varias personas en un proyecto hay que coordinar, reunirse y
    priorizar. Estas labores ocupan días…..
  • Las relaciones humanas provocan conflictos (profesionales y personales)…
    y resolver los conflictos requiere tiempo.
  • Las personas cometemos errores. Con poca experiencia (y formación) esos
    errores pueden ser críticos y requerir rehacer multitud de trabajo.
  • No es fácil definir cuanto tiempo debería tardar una persona en realizar
    una tareas. Hacer programas no es como poner ladrillos (la tecnología de
    instalación del ladrillo supongo que no cambia tan a menudo) por lo que los
    cálculos no cuadran.
  • Las personas no somos máquinas por lo que estar 100 por 100 centrados 8
    horas al día (ojalá solo 8) es casi imposible por lo que las jornadas no son
    demasiado productivas. La poca motivación de los equipos puede ser fatal.
  • Los equipos de proyecto tienden a relajarse al principio y a agobiarse al
    final . Normalmente hay que sacrificar tareas o meter más gente a última hora
    (que además no es seguro que aportar más gente ayude al proyecto).
  • Un plan es solo un plan….. y cuando planificas las actividades a
    realizar durante meses (más aún con requerimientos pobres o incompletos),
    seguro que te olvidas de algunas ….
  • Nos negocios están vivos… las necesidades cambian….. la interpretación
    de los requisitos cambian.
  • Muchas de la tareas planificadas como sencillas se complican (la
    complicadas normalmente no se simplifican)
  • En los proyectos, normalmente dependemos de personas ajenas a nuestros
    equipos de desarrollo…. predecir su involucración y constancia es imposible.
  • Las tecnologías no son estables por lo que todos los proyectos parecen de
    I+D… los problemas pueden aparecer cuando ya estamos en producción.

La verdad es que así pintado puede parecer deprimente … aunque, la realidad
nos dice que lo más deprimente …. son la cantidad de horas que estamos
acostumbrados a invertir en los proyectos para corregir las desviaciones en la
planificación…..

El único modo de mejorar en la planificación del proyecto (y su cumplimiento)
es una combinación de elementos:

  • Conocimiento del negocio (de los analistas)
  • Contar con arquitectos experimentados (y maduros)
  • Formación adecuada de los equipos de desarrollo
  • Trabajar metodológicamente
  • Mantener a un equipo motivado (no siempre es cuestión de dinero) y no en
    continuo periodo de crisis.
  • Respetar las jornadas de trabajo asegurándose que todo el mundo entienda y
    asuma su responsabilidad.
  • Un poquito de buena voluntad de todos …….
  • ……….y como siempre ….. suerte.

 Sobre el
Autor ..

Dejar respuesta

Please enter your comment!
Please enter your name here