Los requisitos ideales están volviendo

En partes pasadas

En la primera parte, anuncié una serie de artículos sobre el trabajo del analista en el anteproyecto. Enumeró los problemas, las soluciones y los principios que debe recordar al comenzar un proyecto de TI.

En la segunda parte, hablé sobre los problemas frecuentes del anteproyecto.

En la última publicación, discutimos la primera parte de los principios básicos:

• El diseño de sistemas informáticos y la clasificación de productos informáticos.
• Niveles del modelo V y ciclo de vida del sistema.
• Una mirada al sistema como un activo financiero.

En esta nota, terminaremos con una descripción de "cómo", para discutir más a fondo qué hacer si no funciona correctamente.

Lo que aprenderá de esta nota:

• En el cono de incertidumbre y fases de diseño.
• Sobre cómo funciona la evaluación.
• Sobre el alcance completo de las tareas de la fase previa al proyecto y los valores realizados al mismo tiempo.
• Acerca de cómo obtener suficientes recursos para un anteproyecto.

Si no desea esperar las siguientes partes del ciclo, puede ver el video de mi informe, sobre la base de la cual se escribe esta serie de artículos.

Ciclo de vida del sistema y cono de incertidumbre

El Cono de Incertidumbre es uno de los conceptos centrales del diseño y la gestión moderna de proyectos. La esencia del concepto: cuanta menos información tengamos, mayor será la incertidumbre que se puede expresar en forma de una extensión en los términos y el costo del proyecto.



Cada fase de la construcción de un sistema elimina parte de la incertidumbre. Al pasar por las fases típicas de un proyecto, la incertidumbre cae exponencialmente:

• Cuando tenemos una idea expresada en un resumen de media página, la distribución del costo y la rentabilidad puede alcanzar varios órdenes de magnitud.

• Cuando existen requisitos comerciales, mientras se desarrolla el plan comercial o el modelo comercial, reducimos el diferencial en el costo / retorno del pedido.

• Para reducir aún más la propagación, debe tomar decisiones clave sobre la apariencia y el diseño del sistema. Este estudio reduce la propagación a medio orden. A pesar del hecho de que la dispersión aún es grande, un análisis de la relación entre los retornos y los costos da la decisión principal: si construiremos un sistema o buscaremos algo más rentable.

• Al especificar las condiciones bajo las cuales se construirá el sistema (quién lo hará y en qué período de tiempo), podemos reducir la distribución de costos a valores con los que se pueden trabajar mediante métodos de gestión de proyectos, reservas y manejo de riesgos. Las condiciones especificadas se registran en la declaración de trabajo.

• Solo el diseño técnico proporciona una estimación casi precisa con un error aceptable para la empresa.

Lo que sigue de esto:

• Desde el punto de vista de la asignación de recursos, debemos tener tiempo para reducir el proyecto antes de gastar una parte significativa del costo si ha dejado de ser rentable. Las fases desde el resumen hasta el diseño técnico deben ocupar una pequeña fracción del costo total del sistema.

• También debe comprender que no se le ocurre una idea e inmediatamente establece el costo. Cuando te dicen que hay 20 millones aquí y eso es seguro, tener solo un breve informe, no lo creas, no lo hace.

• Los requisitos comerciales y el desarrollo conceptual deben hacerse, ya que eliminan la incertidumbre, pero esto puede no defenderse si el proyecto no comienza. Como resultado, las fases deberían ser lo más baratas posible, pero aliviar la incertidumbre de una manera de calidad.

¿Cómo funciona la evaluación?

Existe una idea errónea común que impide el lanzamiento normal del trabajo previo al proyecto: si no podemos proporcionar rápidamente una evaluación precisa, entonces no deberíamos molestarnos en absoluto con los requisitos. Esto no es verdad La suma de estimaciones inexactas, más precisamente, es un hecho de la teoría de la probabilidad.



En este caso, el estudio previo al diseño debe dividir el sistema y el plan de trabajo en varias docenas de partes comparables, y la evaluación de cada parte debe hacerse por analogía o por un método más preciso. La suma de las calificaciones tendrá un margen menor que cada calificación individual.
Si la calidad del estudio conceptual no nos permite obtener una división del sistema en partes aceptables para la evaluación, entonces no reducimos la dispersión de la evaluación y no tiene sentido conectarse con dicho estudio.

Las fases del proyecto desde el punto de vista del modo de evaluación son las siguientes:

• Cuando hay una idea expresada en un resumen de media página, podemos evaluar por analogía.

• Cuando hemos resuelto los requisitos comerciales, el plan comercial o el modelo comercial, podemos resaltar los parámetros clave del sistema y realizar una evaluación por analogía utilizando un factor a gran escala.

• El concepto se divide en varias docenas de partes y trabajos, lo que le permite resumir las estimaciones realizadas por analogía y calcular el plan de gestión de riesgos clave.

• Los términos de referencia reemplazan la evaluación de partes del sistema por analogía con las obligaciones de los proveedores por tipo de trabajo. Las estimaciones de las piezas realizadas por analogía se convierten en estimaciones de expertos. Los riesgos de error en la evaluación se transmiten a los proveedores.

• El diseño técnico permite dividir el sistema en cientos y miles de partes, cada una de las cuales se evalúa de manera experta o con el uso de estadísticas sobre la implementación de proyectos anteriores.

Si la esencia descrita anteriormente no se encuentra en el trabajo de diseño previo, es mejor no hacerlo. Para lograr una reducción real de la incertidumbre, es necesario no solo aumentar el grosor del paquete de documentación para el sistema, sino también garantizar que se establezcan requisitos y soluciones medibles y factibles.

Otra idea común es: "Los requisitos comerciales no deben ser medibles". Recuerda, ¡esto es una mentira!

Lo que necesitas lograr en el anteproyecto

En las partes anteriores, esto se mencionó en términos de problemas. Ahora repita brevemente qué tareas deben establecerse y completarse en cualquier anteproyecto:

1. Comprenda el tiempo y el costo para planificar los costos y tomar una decisión de ir / no ir. Es aconsejable predecir el efecto y volver a acelerar esta decisión.
2. Para vender el sistema:
   
   
   • Mostrar al cliente una comprensión de sus objetivos.
   • Mostrar a los usuarios la solución a sus problemas.
   • Complete con éxito la oferta para el presupuesto (siempre está ahí).
3. Para crear una base para la aceptación (un contrato para el volumen y la calidad del resultado es una tarea técnica), no olvide incluir en el plan la validación del sistema resultante desde el punto de vista de la justificación práctica de las expectativas de todas las partes.
4. Decida los recursos: tipos, etapas, cronogramas, volúmenes de trabajo y fuentes de recursos para confirmar las estimaciones de los artistas intérpretes o ejecutantes y fijar el costo del sistema.

Si tales tareas no se establecen explícitamente y su solución no está planificada, es mejor no perder el tiempo: este proyecto puede tener éxito solo por accidente.

Por qué no puede (o incluso no puede) funcionar

Como resultado de todas las consideraciones anteriores, tenemos 3 condiciones conflictivas:

1. El análisis previo al diseño debe hacerse rápidamente.
2. El análisis previo al diseño debe hacerse a bajo costo.
3. El análisis previo al diseño debe hacerse cualitativamente.

Aquellos que están familiarizados con la regla del triángulo de diseño entienden que esto no sucede.

Hay algunas dificultades adicionales:

1. El análisis previo al proyecto puede mostrar un bajo rendimiento de la solución propuesta, y esto no será interesante para el cliente y el patrocinador.
2. Un análisis previo al proyecto puede aumentar el volumen del proyecto o el costo total de propiedad en relación con los supuestos iniciales, y esto volverá a ser poco interesante para el cliente y el patrocinador.
3. El análisis previo al proyecto puede reducir el volumen del proyecto con respecto a los supuestos iniciales, y esto a menudo no es interesante para el contratista externo.

En relación con todas estas dificultades, quiero que usted y yo comprendamos una cosa: los problemas del anteproyecto son insolubles si no nos ponemos del lado del patrocinador y no consideramos el proyecto de TI como un activo financiero.

En los comentarios al artículo anterior, se expresó la opinión: “El anteproyecto debe abrirse lo antes posible, pero debe tenerse en cuenta que el alcance del anteproyecto está limitado por su efectividad. Dicho anteproyecto se considera efectivo, luego de lo cual se lanzará el proyecto. Este es el principal indicador clave de la efectividad del anteproyecto ". (c) WizardryIB

Este es un punto de vista bastante común entre los gerentes de proyecto, porque si se le confía algo, debe suicidarse, exprimir a un equipo hasta el final, girar los brazos de sus proveedores antes de las fracturas, violar al cliente, pero lograr el objetivo.

Por otro lado, si el gerente del proyecto cierra su propio proyecto, reducirá su propio lugar de trabajo.

El enfoque correcto es deshacerse de un activo malo lo antes posible. La tarea del analista y gerente en el anteproyecto es hacer esto.

Cómo obtener un presupuesto para un anteproyecto

Para recorrer el camino hacia una eliminación constructiva y consistente de la incertidumbre en torno a un proyecto de TI, es necesario aclarar con el cliente y el patrocinador la posición general con respecto a la actitud hacia el proyecto como un activo financiero.

La imagen muestra la relación normal de incertidumbre, inversión y rendimiento.



Mientras la incertidumbre sea grande, debemos invertir poco y reducirla.

Una vez que la incertidumbre con la proporción de inversiones y beneficios se convierte en un nivel aceptable, puede invertir la mayor parte de los recursos para obtener un rendimiento. Al final de cada fase, se debe tomar una decisión honesta: trabajar o cerrar el proyecto.

Para hacer esto, al final de cada fase debe haber una evaluación de la proporción de inversiones y rendimientos al nivel de precisión que es natural para la fase actual.

El cliente necesita mostrar el nivel actual de incertidumbre, la evaluación razonable actual de los beneficios y costos. Si los beneficios exceden el costo, tiene sentido discutir la eliminación de la incertidumbre.

La retórica puede ser la siguiente: "Vemos un pronóstico de beneficios que excede significativamente el costo del sistema, gastemos una pequeña fracción del valor o los beneficios pronosticados para refinar las estimaciones y decidir sobre el inicio del sistema".

Mis recomendaciones (muy promedio) sobre la relación del costo de partes del anteproyecto:

• Todo lo que sucede antes de la construcción no debería costar más del 10-30% del proyecto.

• Un anteproyecto debería costar un orden de magnitud menor: esto es 1-3% del costo proyectado del sistema.

• En las primeras etapas, siempre y cuando no existan requisitos comerciales, puede que no haya un valor pronosticado y deba ser repelido a partir del rendimiento calculado; puede tomar 0.1-0.2% durante la vida del sistema en el presupuesto para crear requisitos comerciales (dado que no se inicia cada proyecto propuesto).

Por ejemplo, si vendemos un sistema que cuesta ~ 100 millones (por analogía). Esto tiene sentido si el rendimiento de su operación es de al menos ~ 300-500 millones, dada la baja precisión de todas las estimaciones.

En este caso, los siguientes costos pueden considerarse normales:

• Requisitos comerciales: 0.5-1 millones de rublos.

• El concepto es de 1-3 millones de rublos.

• Proyecto técnico - 10-30 millones de rublos.

Las desviaciones en cualquier dirección son posibles aquí. Pero el principio general es el siguiente: los recursos invertidos deben estar correlacionados con el beneficio previsto y la probabilidad de su recepción, dependiendo del nivel actual de incertidumbre.

Resumen breve

Aquí completamos la revisión del anteproyecto correcto y repetimos lo más importante:

1. El proyecto debe considerarse como un activo financiero arriesgado.
2. El nivel de incertidumbre debe ser conocido por todos y discutido entre todas las partes interesadas.
3. Los costos de análisis deben estar relacionados con el beneficio previsto y la probabilidad de que se reciba.
4. En el curso del desarrollo, es necesario lograr la calidad de los requisitos suficientes para evaluar el costo y los términos con la precisión inherente a la fase actual.
5. En particular, los requisitos comerciales ya deberían ser medibles.
6. Es necesario recordar la lista completa de tareas de la fase previa al proyecto, la omisión de cada una de ellas aumenta la probabilidad de falla del proyecto en órdenes de magnitud.

La vida muestra que por varias razones no siempre es posible observar estos principios. En algunos casos, un proyecto dañado antes del lanzamiento se puede guardar, o al menos mejorar ligeramente. Hablaremos de esto en las siguientes partes de la serie.