Limitar la cobertura funcional con los objetivos operacionales
Los proyectos deben identificar grupos, cuestiones básicas e indicadores de éxito. Cada demanda debe ser capaz de demostrar su contribución al objetivo, de lo contrario es fácil añadir la función “por los escenarios” a la discusión.
En la primera fase se da prioridad a cubrir el proceso básico completo en lugar de al gran número de funciones marginales.
Establecer una base de referencia común de las necesidades
Las necesidades de archivos, diagramas de flujo, prototipos, reglas de campo y condiciones de aceptación constituyen bases de referencia. Es difícil apoyar proyectos complejos simplemente grabando minutos o chats.
La base de referencia no requiere que todos los detalles permanezcan invariables, sino que ambas partes saben cuál es la versión confirmada actualmente.
Detección temprana de las desviaciones mediante demostraciones de ciclo corto
Los resultados de la ejecución se demuestran cada dos semanas para permitir que el personal operacional proporcione información sobre los procesos reales, más eficaz que la aceptación centralizada al final del proyecto. Los principales actores deben participar en un examen constante y confirmar las conclusiones oportunamente.
Los comentarios iniciales pueden corregir las desviaciones en la comprensión y ayudar a las empresas a recalificar sus necesidades.
Mostrar el efecto completo de cada cambio.
La solicitud de cambio debe indicar las razones, el alcance y la prioridad, y el equipo del proyecto debe evaluar el impacto en el diseño, los datos, la interfaz, las pruebas, la periodicidad y el presupuesto, y decidir si aceptar, reemplazar o extender.
Los cambios en los registros pueden proteger a ambas partes y permitir que la administración entienda por qué se producen ajustes en los proyectos.
- Las necesidades adicionales podrían sustituir las necesidades de baja prioridad del volumen de trabajo equivalente
- Principales cambios en los hitos y costos de la reconfirmación
- Los no esenciales están en la lista para versiones posteriores.
Cambio de la gestión de las necesidades de software desde las conclusiones de la lectura hasta la entrada de proyectos
El problema más probable después de leer artículos metodológicos es la aceptación de principios, que no se traducen en el siguiente paso. Se propone que el jefe de operaciones organice un mini-taller de 60-90 minutos, eligiendo sólo un proceso real y no apresurarse a discutir la plataforma completa.
Paso 1: Establecimiento de una situación actual y una base de referencia de la muestra
Los datos no se utilizan para registrar la cantidad de tareas normales, inusuales y fronterizas que se están realizando actualmente, el tiempo de espera, el tiempo de procesamiento real, la tasa de trabajo posterior, el contacto manual, las consecuencias de error y la herramienta actual.
Paso 2: Aclarar el cierre inicial y la inacción
La primera fase está diseñada para permitir que una cadena funcione y sea retracable, en lugar de apilar la gestión de proyectos subcontratados, el cambio de demanda, el alcance de proyecto de software en la misma versión.
Paso 3: Coincide con los resultados técnicos a la evidencia de ingeniería
El proyecto subcontratado debe incluir la misma base en términos de alcance, hipótesis, exclusiones, hitos, atribución de fuentes, patrones de despliegue y pruebas de aceptación. El cambio de demanda debe evaluarse por su impacto en el ciclo, coste y pruebas, sin un compromiso oral para reemplazar el registro de cambio. La demostración del proveedor debe utilizar una muestra confirmada por ambas partes; datos de producción no identificados que no pueden ser puestos a disposición pública, pero no pueden ser reemplazados por datos de prueba idealizados.
Paso 4: Recepción, inspección y disco con el mismo calibre
Suponiendo que el proceso original se encargue de 600 tareas mensuales, una media de 20 minutos y una tasa de retorno del 10%, el objetivo puede describirse como “seis semanas después de que la línea haya sido levantada, con un promedio de 25% menos tiempo que la base original, dado el grado de complejidad de la tarea”. Este conjunto sólo demuestra el método de medición y no representa los resultados de ningún cliente; los indicadores formales deben ser identificados por la empresa sobre la base de su propia.
- Material operacional: diagrama de flujo, función, misión de muestra, cuestiones actuales y datos de referencia
- Material técnico: inventario del sistema, interfaz, acceso a datos, entorno de despliegue y necesidades de seguridad
- Material del proyecto: alcance de primera fase, exclusiones, matriz de responsabilidad, hitos y mecanismos de cambio
- Material de recepción e inspección: conjunto de pruebas, registros de ejecución, lista de deficiencias, consultas de indicadores y documentos de entrega
Cuando estos materiales son identificados conjuntamente por los partidos operativos y técnicos, el método del artículo se introduce en el proyecto. Si los datos clave, la autorización de interfaz o la persona responsable no están en su lugar, el siguiente paso lógico es generalmente un diagnóstico limitado o PoC, en lugar de un compromiso inmediato para completar el período de trabajo y el precio total fijo.
Aplicar metodología para la acción de proyectos
- Controlar la primera fase con objetivos y procesos básicos
- Base de referencia de los requisitos de documentación, prototipo y aceptación
- El cambio debe evaluar el impacto en el tiempo, el costo y la calidad
Continuando conciliando las cuestiones comunes en la adopción de decisiones de proyectos
¿Cómo se firman los contratos de contratación externa de software y qué términos deben ser acordados?
El contrato para el software contratante debe especificar al menos el alcance de la demanda, los hitos, los pagos, la aceptación, el cambio, los derechos de propiedad intelectual, la confidencialidad, la garantía de calidad y la terminación de la entrega. La lista funcional no sólo debe incluir el nombre del módulo, sino también se relaciona con los requisitos de la versión, interfaz, datos y requisitos no funcionales. La responsabilidad de las partes, la cooperación cliente y la dependencia de terceros también debe ser incluido en el objetivo de hacer cumplir todos los riesgos.
Ver respuesta completaContratos, pagos, cambios y ejecución de proyectos¿Quién es el titular de los derechos de propiedad intelectual, código fuente y derechos de propiedad intelectual?
El proyecto debe distinguir entre la información original del cliente, los resultados personalizados, los componentes genéricos del proveedor, el software de código abierto y las licencias comerciales de terceros. El mismo concepto no es verdadero de la entrega de fuentes, derechos de acceso, derechos de modificación, registro de derechos de autor y derechos de re-licencia.
Ver respuesta completaContratos, pagos, cambios y ejecución de proyectos¿Cómo calcula los costos y la duración del proceso de desarrollo aumentando la demanda?
Los requisitos adicionales deben documentarse y efectuarse cambios específicos antes de evaluar el producto, el diseño, el desarrollo, las pruebas, los datos y los efectos. El tiempo de codificación para la nueva página no puede calcularse sólo porque el rango de estructura, interfaz y regresión puede cambiar. El volumen de trabajo, los costos y la programación son confirmados por ambas partes antes de que esté disponible o posterior.
Ver respuesta completaContratos, pagos, cambios y ejecución de proyectos¿Qué información se necesita para la aceptación e inspección del proyecto de software?
El objetivo de la información es demostrar que el sistema cumple con las normas acordadas y que el cliente puede seguir operando y asumiendo el control.
Ver respuesta completa¿Necesitas más análisis en el contexto del estado actual de la empresa?
Proporcionamos asesoramiento técnico en TI, construcción de información empresarial, Outlook de proyecto de software, diseño de productos, servicios de entrega R & D y entrega de sistemas.