Saltar al contenido

Un método claro en cada fase

Cada proyecto se organiza en cuatro fases con entregables definidos. El modelo de trabajo y la frecuencia de seguimiento se acuerdan con cada cliente según su organización.

Cuatro fases, un mismo equipo

Cada fase concluye con un entregable concreto, de modo que el cliente conoce en todo momento el estado del proyecto y el coste asociado.

  1. Fase 1: Análisis

    Estudio de la empresa desde dentro: cómo trabaja, qué sistemas utiliza y qué necesita resolver. Los requisitos se recogen con las personas responsables de cada proceso.

    EntregableUn análisis de procesos y sistemas, con los requisitos priorizados.

  2. Fase 2: Propuesta técnica

    Definición de la solución y la tecnología adecuadas, y elección conjunta del modelo de trabajo que mejor se ajusta al proyecto.

    EntregableUna propuesta técnica con alcance, arquitectura, modelo de trabajo y presupuesto.

  3. Fase 3: Desarrollo

    Construcción de la solución según el modelo acordado. El cliente sigue el avance y valida cada entrega antes de continuar.

    EntregableEntregas funcionales, listas para probar y validar.

  4. Fase 4: Puesta en marcha

    Despliegue de la solución, formación del equipo y acompañamiento posterior con soporte y mantenimiento.

    EntregableLa solución en producción, el equipo formado y la documentación de uso.

¿Cómo se organizaría su proyecto?

Cada proyecto es distinto. Tres preguntas permiten orientar cómo podría organizarse el suyo.

  1. ¿Cuenta su empresa con equipo informático propio?
  2. ¿Qué nivel de seguimiento prefiere?
  3. ¿Qué grado de definición tiene la necesidad?
  4. Resultado

Organización orientativa del proyecto

Responda a las preguntas para ver el resultado.

Seguimiento

Depende de las dos primeras preguntas.

Modelo de trabajo

Depende de la tercera pregunta.

Presupuesto

Depende del modelo de trabajo.

Se trata de una orientación, no de un compromiso: el modelo de trabajo y la frecuencia de seguimiento se acuerdan en la propuesta técnica y pueden ajustarse durante el proyecto.

Decisiones informadas

Ante cada decisión relevante, presentamos las alternativas con sus ventajas e inconvenientes, en términos comprensibles. La decisión corresponde al cliente, con toda la información necesaria.

Tres modelos de trabajo

Ninguno es mejor en abstracto. En la propuesta técnica se elige, junto con el cliente, el que mejor se ajusta al proyecto y a su forma de presupuestarlo.

Alcance cerrado

Los requisitos se definen y documentan al principio. Con el alcance y los plazos cerrados, el desarrollo avanza fase a fase hasta la entrega.

Indicado cuando
La necesidad está definida con precisión, el alcance no va a variar o existen requisitos contractuales que cumplir.
Presupuesto
Precio cerrado.

Mixto

Se cierra y documenta la base del proyecto (requisitos principales, arquitectura e integraciones críticas) y el resto se desarrolla de forma iterativa.

Indicado cuando
Una parte del proyecto está definida y otra se concretará con el uso.
Presupuesto
Precio cerrado para la base y por horas para la parte iterativa.

Por etapas

El proyecto arranca con una primera versión que cubre lo esencial y se amplía en ciclos cortos. Al final de cada ciclo, el cliente dispone de software operativo y decide las prioridades siguientes.

Indicado cuando
El alcance evolucionará, conviene disponer pronto de una primera versión o el equipo del cliente quiere participar de forma continua.
Presupuesto
Por horas, según el trabajo de cada ciclo.

Qué necesitamos de su empresa

Un proyecto funciona cuando ambas partes trabajan como una sola. Esto es lo que solicitaremos.

Un interlocutor
Una persona que conozca el negocio y tenga capacidad de decisión, o acceso a quien la tenga.
Accesos y datos
Acceso a los sistemas, los datos y la documentación relevantes para el proyecto en el momento en que se necesiten.
Validación de entregas
Revisión de cada entrega y respuesta en los plazos acordados, para no avanzar sobre supuestos.
Disponibilidad del equipo
Participación de los futuros usuarios en la toma de requisitos y en la formación.

Prácticas de ingeniería

La calidad técnica no se aprecia en una demostración, pero es determinante cuando el software debe crecer. Estas prácticas forman parte de cada proyecto.

Control de versiones
Todo el código se gestiona en Git, con el historial completo de cada cambio.
Revisión de código
Cada cambio se revisa antes de integrarse.
Pruebas automatizadas
Pruebas que verifican, tras cada cambio, que la funcionalidad existente sigue operativa.
Entornos separados
Cada cambio se valida en un entorno de pruebas antes de llegar a producción. Las incidencias se reproducen sobre una copia de producción.
Documentación
Documentación de la arquitectura, las integraciones y el uso, para que la solución no dependa de una sola persona.