A lo largo del ciclo de vida del proyecto, los usuarios deberían poder probar todos los resultados intermedios. #
Se insta a los clientes a definir sus necesidades con la mayor precisión posible a lo largo de las fases de definición y diseño. Esto es un desafío por dos razones. Para empezar, los consumidores tienen una comprensión limitada del potencial y las imposibilidades de la tecnología de la información. No tienen noción de lo que es o debería ser factible, ni saben lo que deberían o no deberían desear. En segundo lugar, los consumidores a menudo carecen de un conocimiento profundo de sus propios procesos comerciales.
Numerosas iniciativas de TI incluyen la informatización de los procesos comerciales actuales de una organización. Aunque los consumidores han trabajado con procesos durante un largo período de tiempo, a menudo carecen de la capacidad para diseñar sus propios procesos comerciales. Pueden funcionar bien a su manera, pero no pueden especificar cuál es esa manera. Se requiere una definición exacta del proceso antes de desarrollar el software que impulsará la informatización. La complejidad de los clientes aumenta como resultado de tener que explicar los procedimientos actuales.
Criterios determinantes #
Con frecuencia, la lista de criterios elaborada durante la fase de definición está incompleta. Los programadores crean software de acuerdo con esta lista parcial durante la fase de implementación. Cuando los consumidores encuentran versiones beta de software nuevo, se hacen evidentes necesidades adicionales. «Se ve bien, pero ¿podrías arreglarlo para que no tenga que ingresar constantemente mi contraseña?» Los programadores a menudo lamentan que los clientes no estén seguros de lo que quieren. Los clientes afirman que, como expertos, los desarrolladores de software deberían haber identificado lo que los clientes quieren antes en el proceso.
Se creó un diseño funcional integral para un proyecto de software que incluía el procesamiento automatizado de aplicaciones para un servicio basado en web. Se recopilaron numerosas necesidades de los clientes. Después de agregar algunos diseños de pantalla y dibujos de flujo, los programadores pudieron comenzar.
Gestión de clientes y restricciones #
Posiblemente como resultado de las severas limitaciones de tiempo del proyecto o posiblemente como resultado de la organización bastante caótica del cliente, los diseñadores se habían olvidado de incluir un componente crítico: la administración manual. El programa procesó las solicitudes. Debido a que las aplicaciones debían procesarse automáticamente, los programadores razonaron que no sería necesaria una administración humana. Este criterio también se omitió del diseño funcional.
Cuando se proporcionó el programa para probarlo, el cliente descubrió que muchas aplicaciones tenían excepciones. Estas solicitudes no se pueden procesar automáticamente y deben tratarse manualmente. Sin embargo, el programa funcionó de forma totalmente automática.
los gestión de proyectos en cascada requiere probar el resultado real del proyecto al final de la fase de implementación. Esto es tarde etapa de desarrollo . Entre la fase de definición, la fase de diseño y la fase de implementación, pueden pasar meses o incluso más de un año. Si se encuentran fallas de diseño en una etapa tardía del proyecto, puede ser costoso, si no imposible, modificar el programa sin comenzar un nuevo proyecto por completo. Dado que es prácticamente imposible definir todos los criterios por adelantado, es deseable un enfoque de trabajo que permita probar los resultados (intermedios).
Análisis de requisitos #
Al comparar varias empresas de software potenciales, un cliente preguntó acerca de las posibilidades. Una de las partes dudaba y cuestionaba la viabilidad de muchas de las demandas del cliente. El bando contrario estuvo representado por un agresivo agente de ventas.
Cuando un cliente preguntó sobre la viabilidad de una solicitud específica, el vendedor llamó a sus codificadores. ‘¿Podemos crear una función que haga X?’ El programador, que pensaba principalmente en términos técnicos, dijo que cualquier cosa era concebible teóricamente. Ni el programador ni el vendedor estaban preocupados por gestión de proyectos viabilidad (por ejemplo, tiempo, dinero, complejidad y riesgo).
El entusiasmo del representante de ventas superó el comportamiento moderado de la otra parte. El cliente seleccionó la oferta agresiva del representante de ventas. El proyecto recién adquirido se entregó luego a un gerente de proyecto y un equipo de programadores.
Después de un tiempo, quedó claro que el proyecto no estaba a la altura de las expectativas del cliente. Esto se debió en parte al hecho de que los procedimientos eran mucho más complejos para el cliente de lo que parecían inicialmente. Durante un acalorado intercambio entre las dos partes, el cliente dijo que el vendedor ‘había declarado que la funcionalidad X no sería un problema.
