1.9: Planeación de Alcance
- Page ID
- 68524
\( \newcommand{\vecs}[1]{\overset { \scriptstyle \rightharpoonup} {\mathbf{#1}} } \)
\( \newcommand{\vecd}[1]{\overset{-\!-\!\rightharpoonup}{\vphantom{a}\smash {#1}}} \)
\( \newcommand{\id}{\mathrm{id}}\) \( \newcommand{\Span}{\mathrm{span}}\)
( \newcommand{\kernel}{\mathrm{null}\,}\) \( \newcommand{\range}{\mathrm{range}\,}\)
\( \newcommand{\RealPart}{\mathrm{Re}}\) \( \newcommand{\ImaginaryPart}{\mathrm{Im}}\)
\( \newcommand{\Argument}{\mathrm{Arg}}\) \( \newcommand{\norm}[1]{\| #1 \|}\)
\( \newcommand{\inner}[2]{\langle #1, #2 \rangle}\)
\( \newcommand{\Span}{\mathrm{span}}\)
\( \newcommand{\id}{\mathrm{id}}\)
\( \newcommand{\Span}{\mathrm{span}}\)
\( \newcommand{\kernel}{\mathrm{null}\,}\)
\( \newcommand{\range}{\mathrm{range}\,}\)
\( \newcommand{\RealPart}{\mathrm{Re}}\)
\( \newcommand{\ImaginaryPart}{\mathrm{Im}}\)
\( \newcommand{\Argument}{\mathrm{Arg}}\)
\( \newcommand{\norm}[1]{\| #1 \|}\)
\( \newcommand{\inner}[2]{\langle #1, #2 \rangle}\)
\( \newcommand{\Span}{\mathrm{span}}\) \( \newcommand{\AA}{\unicode[.8,0]{x212B}}\)
\( \newcommand{\vectorA}[1]{\vec{#1}} % arrow\)
\( \newcommand{\vectorAt}[1]{\vec{\text{#1}}} % arrow\)
\( \newcommand{\vectorB}[1]{\overset { \scriptstyle \rightharpoonup} {\mathbf{#1}} } \)
\( \newcommand{\vectorC}[1]{\textbf{#1}} \)
\( \newcommand{\vectorD}[1]{\overrightarrow{#1}} \)
\( \newcommand{\vectorDt}[1]{\overrightarrow{\text{#1}}} \)
\( \newcommand{\vectE}[1]{\overset{-\!-\!\rightharpoonup}{\vphantom{a}\smash{\mathbf {#1}}}} \)
\( \newcommand{\vecs}[1]{\overset { \scriptstyle \rightharpoonup} {\mathbf{#1}} } \)
\( \newcommand{\vecd}[1]{\overset{-\!-\!\rightharpoonup}{\vphantom{a}\smash {#1}}} \)
\(\newcommand{\avec}{\mathbf a}\) \(\newcommand{\bvec}{\mathbf b}\) \(\newcommand{\cvec}{\mathbf c}\) \(\newcommand{\dvec}{\mathbf d}\) \(\newcommand{\dtil}{\widetilde{\mathbf d}}\) \(\newcommand{\evec}{\mathbf e}\) \(\newcommand{\fvec}{\mathbf f}\) \(\newcommand{\nvec}{\mathbf n}\) \(\newcommand{\pvec}{\mathbf p}\) \(\newcommand{\qvec}{\mathbf q}\) \(\newcommand{\svec}{\mathbf s}\) \(\newcommand{\tvec}{\mathbf t}\) \(\newcommand{\uvec}{\mathbf u}\) \(\newcommand{\vvec}{\mathbf v}\) \(\newcommand{\wvec}{\mathbf w}\) \(\newcommand{\xvec}{\mathbf x}\) \(\newcommand{\yvec}{\mathbf y}\) \(\newcommand{\zvec}{\mathbf z}\) \(\newcommand{\rvec}{\mathbf r}\) \(\newcommand{\mvec}{\mathbf m}\) \(\newcommand{\zerovec}{\mathbf 0}\) \(\newcommand{\onevec}{\mathbf 1}\) \(\newcommand{\real}{\mathbb R}\) \(\newcommand{\twovec}[2]{\left[\begin{array}{r}#1 \\ #2 \end{array}\right]}\) \(\newcommand{\ctwovec}[2]{\left[\begin{array}{c}#1 \\ #2 \end{array}\right]}\) \(\newcommand{\threevec}[3]{\left[\begin{array}{r}#1 \\ #2 \\ #3 \end{array}\right]}\) \(\newcommand{\cthreevec}[3]{\left[\begin{array}{c}#1 \\ #2 \\ #3 \end{array}\right]}\) \(\newcommand{\fourvec}[4]{\left[\begin{array}{r}#1 \\ #2 \\ #3 \\ #4 \end{array}\right]}\) \(\newcommand{\cfourvec}[4]{\left[\begin{array}{c}#1 \\ #2 \\ #3 \\ #4 \end{array}\right]}\) \(\newcommand{\fivevec}[5]{\left[\begin{array}{r}#1 \\ #2 \\ #3 \\ #4 \\ #5 \\ \end{array}\right]}\) \(\newcommand{\cfivevec}[5]{\left[\begin{array}{c}#1 \\ #2 \\ #3 \\ #4 \\ #5 \\ \end{array}\right]}\) \(\newcommand{\mattwo}[4]{\left[\begin{array}{rr}#1 \amp #2 \\ #3 \amp #4 \\ \end{array}\right]}\) \(\newcommand{\laspan}[1]{\text{Span}\{#1\}}\) \(\newcommand{\bcal}{\cal B}\) \(\newcommand{\ccal}{\cal C}\) \(\newcommand{\scal}{\cal S}\) \(\newcommand{\wcal}{\cal W}\) \(\newcommand{\ecal}{\cal E}\) \(\newcommand{\coords}[2]{\left\{#1\right\}_{#2}}\) \(\newcommand{\gray}[1]{\color{gray}{#1}}\) \(\newcommand{\lgray}[1]{\color{lightgray}{#1}}\) \(\newcommand{\rank}{\operatorname{rank}}\) \(\newcommand{\row}{\text{Row}}\) \(\newcommand{\col}{\text{Col}}\) \(\renewcommand{\row}{\text{Row}}\) \(\newcommand{\nul}{\text{Nul}}\) \(\newcommand{\var}{\text{Var}}\) \(\newcommand{\corr}{\text{corr}}\) \(\newcommand{\len}[1]{\left|#1\right|}\) \(\newcommand{\bbar}{\overline{\bvec}}\) \(\newcommand{\bhat}{\widehat{\bvec}}\) \(\newcommand{\bperp}{\bvec^\perp}\) \(\newcommand{\xhat}{\widehat{\xvec}}\) \(\newcommand{\vhat}{\widehat{\vvec}}\) \(\newcommand{\uhat}{\widehat{\uvec}}\) \(\newcommand{\what}{\widehat{\wvec}}\) \(\newcommand{\Sighat}{\widehat{\Sigma}}\) \(\newcommand{\lt}{<}\) \(\newcommand{\gt}{>}\) \(\newcommand{\amp}{&}\) \(\definecolor{fillinmathshade}{gray}{0.9}\)Siempre quieres saber exactamente qué trabajo hay que hacer antes de iniciarlo. Tienes una colección de miembros del equipo, y necesitas saber exactamente qué van a hacer para cumplir con los objetivos del proyecto. El proceso de planeación de alcances es lo primero que haces para administrar tu alcance. La planeación del alcance del proyecto se refiere a la definición de todo el trabajo necesario para cumplir con éxito los objetivos del proyecto. La idea aquí es que cuando comienzas el proyecto, necesitas tener una idea clara de todo el trabajo que debe suceder en tu proyecto, y a medida que avanza el proyecto, debes mantener ese alcance actualizado y anotado en el plan de gestión de alcances del proyecto.
Definición del Alcance
Ya tienes una ventaja para refinar los objetivos del proyecto en términos cuantificables, pero ahora necesitas planificar más y anotar todos los entregables intermedios y finales que tú y tu equipo producirán a lo largo del proyecto. Los entregables incluyen todo lo que usted y su equipo producen para el proyecto (es decir, cualquier cosa que su proyecto entregará). Los entregables para su proyecto incluyen todos los productos o servicios que usted y su equipo están realizando para el cliente, cliente o patrocinador. Incluyen todos los documentos intermedios, plan, cronograma, presupuesto, plano y cualquier otra cosa que se haga en el camino, incluidos todos los documentos de gestión de proyectos que haya reunido. Los entregables del proyecto son resultados tangibles, resultados medibles o elementos específicos que deben producirse para considerar el proyecto o la fase del proyecto completada. Los entregables intermedios, al igual que los objetivos, deben ser específicos y verificables.
Todos los entregables deben describirse con un nivel de detalle suficiente para que puedan diferenciarse de los entregables relacionados. Por ejemplo:
- Un plano de doble motor versus un plano de motor único
- Un marcador rojo versus un marcador verde
- Un reporte diario versus un reporte semanal
- Una solución departamental frente a una solución empresarial
Una de las funciones principales del gerente de proyecto es documentar con precisión los entregables del proyecto y luego administrar el proyecto para que se produzcan de acuerdo con los criterios acordados. Los entregables son los resultados de cada fase de desarrollo, descritos de manera cuantificable.
Requerimientos del Proyecto
Después de identificar todos los entregables, el gerente del proyecto necesita documentar todos los requisitos del proyecto. Los requisitos describen las características del entregable final, ya sea un producto o un servicio. Describen la funcionalidad requerida que debe tener el entregable final o las condiciones específicas que debe cumplir el entregable final para satisfacer los objetivos del proyecto. Un requisito es un objetivo que debe cumplirse. Los requisitos del proyecto, definidos en el plan de alcance, describen lo que se supone que debe lograr un proyecto y cómo se supone que se debe crear e implementar el proyecto. Requisitos responder a las siguientes preguntas con respecto a los estados como están y futuros del negocio: ¿quién, qué, dónde, cuándo, cuánto y cómo funciona un proceso de negocio?
Los requisitos pueden incluir atributos como dimensiones, facilidad de uso, color, ingredientes específicos, etc. Si volvemos al ejemplo de la empresa productora de ponche de huevo navideño, uno de los principales entregables son los cartones que contienen el ponche de huevo. Los requisitos para ese entregable pueden incluir diseño de cajas, fotografías que aparecerán en la caja, opciones de color, etc.
Los requisitos especifican cómo debe ser el entregable final del proyecto y qué debe hacer. Los requisitos deben ser medibles, comprobables, relacionados con las necesidades u oportunidades de negocio identificadas y definidos con un nivel de detalle suficiente para el diseño del sistema. Se pueden dividir en seis categorías básicas: funcional, no funcional, técnico, empresarial, usuario y requisitos reglamentarios.
Requerimientos Funcionales
Los requisitos funcionales describen las características del entregable final en lenguaje ordinario no técnico. Deben ser comprensibles para los clientes, y los clientes deben desempeñar un papel directo en su desarrollo. Los requisitos funcionales son lo que desea que haga el entregable.
Ejemplo de Vehículo
Si estabas comprando vehículos para un negocio, tu requisito funcional podría ser: “Los vehículos deberían poder llevar hasta una tonelada de carga de un almacén a una tienda”.
Ejemplo de sistema informático
Para un sistema informático se puede definir qué va a hacer el sistema: “El sistema debe almacenar todos los detalles del pedido de un cliente”.
El punto importante a tener en cuenta es que se especifica lo que se quiere y no cómo se entregará.
Requerimientos no funcionales
Los requisitos no funcionales especifican criterios que se pueden utilizar para juzgar el producto o servicio final que entrega su proyecto. Son restricciones o restricciones que se deben colocar en el entregable y cómo construirlo. Su propósito es restringir el número de soluciones que satisfagan un conjunto de requisitos. Usando el ejemplo del vehículo, el requisito funcional es que un vehículo lleve una carga de un almacén a un taller. Sin ninguna restricción, las soluciones que se ofrecen podrían resultar en cualquier cosa, desde un camión pequeño hasta uno grande. Los requisitos no funcionales se pueden dividir en dos tipos: rendimiento y desarrollo.
Para restringir los tipos de soluciones, puede incluir estas restricciones de rendimiento:
- Los camiones comprados deberían ser camiones fabricados en Estados Unidos debido a los incentivos gubernamentales.
- El área de carga debe estar cubierta.
- El área de carga debe tener una altura de al menos 10 pies.
Del mismo modo, para el ejemplo del sistema informático, puede especificar valores para los tipos genéricos de restricciones de rendimiento:
- El tiempo de respuesta para la información se muestra en la pantalla para el usuario.
- El número de horas que un sistema debe estar disponible.
- El número de registros que un sistema debe ser capaz de mantener.
- Se debe incorporar la capacidad de crecimiento del sistema.
- El tiempo que se debe mantener un registro para fines de auditoría.
Para el ejemplo de registros de clientes, las restricciones pueden ser:
- El sistema deberá estar disponible de 9 a.m. a 5 p.m.de lunes a viernes.
- El sistema debería ser capaz de mantener 100,000 registros de clientes inicialmente.
- El sistema debería poder agregar 10 mil registros al año durante 10 años.
- Un registro debe estar completamente disponible en el sistema durante al menos siete años.
Un punto importante con estos ejemplos es que restringen el número de opciones de solución que te ofrece el desarrollador. Además de las restricciones de rendimiento, puede incluir algunas restricciones de desarrollo.
Hay tres tipos generales de limitaciones de desarrollo no funcionales:
- Tiempo: Cuándo se debe entregar un entregable
- Recurso: Cuánto dinero hay disponible para desarrollar el entregable
- Calidad: Cualquier estándar que se utilice para desarrollar el entregable, métodos de desarrollo, etc.
Requerimientos Técnicos
Los requisitos técnicos emergen de los requisitos funcionales para responder a las preguntas: ¿cómo se resolverá el problema en esta ocasión y se resolverá tecnológica y/o procesalmente? Especifican cómo se debe diseñar e implementar el sistema para proporcionar la funcionalidad requerida y cumplir con las características operativas requeridas.
Por ejemplo, en un proyecto de software, los requisitos funcionales pueden estipular que se desarrollará un sistema de base de datos para permitir el acceso a datos financieros a través de un terminal remoto. Los requisitos técnicos correspondientes detallarían los elementos de datos requeridos, el lenguaje en el que se escribirá el sistema de gestión de la base de datos (debido al conocimiento existente internamente), el hardware en el que se ejecutará el sistema (debido a la infraestructura existente), los protocolos de telecomunicación que deberían ser usado, y así sucesivamente.
Requerimientos del Negocio
Los requerimientos del negocio son las necesidades de la organización patrocinadora, siempre desde una perspectiva gerencial. Los requisitos del negocio son declaraciones de la justificación del negocio para el proyecto. Por lo general, se expresan en resultados amplios, satisfaciendo las necesidades del negocio, en lugar de funciones específicas que el sistema debe realizar. Estos requisitos surgen de la visión del producto que, a su vez, es impulsado por metas y objetivos de misión (o negocio).
Requerimientos del Usuario
Los requisitos del usuario describen lo que los usuarios deben hacer con el sistema o producto. El foco está en la experiencia del usuario con el sistema bajo todos los escenarios. Estos requisitos son la entrada para las siguientes fases de desarrollo: diseño de interfaz de usuario y diseño de casos de prueba del sistema.
Requerimientos reglamentarios
Los requisitos reglamentarios pueden ser internos o externos y generalmente no son negociables. Son las restricciones, licencias y leyes aplicables a un producto o negocio que son impuestas por el gobierno.
Un Ejemplo de Requerimientos
Los cajeros automáticos (ATM) se pueden utilizar para ilustrar una amplia gama de requisitos (Figura 9.1). ¿Cuáles son algunas de las características físicas de estas máquinas y qué tipo de funciones realizan para los clientes del banco? ¿Por qué los bancos pusieron en marcha estos sistemas? ¿Cuáles son los requerimientos del negocio de alto nivel?
A continuación se presenta un posible ejemplo de cada tipo de requerimiento, ya que se aplicarían al cajero automático externo de un banco.
- Requisito funcional ATM: El sistema permitirá al usuario seleccionar si producir o no un recibo de transacción en papel antes de completar una transacción.
- Requisito no funcional de ATM: Todas las pantallas serán en blanco, texto Arial de 14 puntos sobre fondo negro.
- Requisito técnico ATM: El sistema ATM se conectará sin problemas a la base de datos existente del cliente.
- Requisito de usuario de cajero automático: El sistema completará un retiro estándar de una cuenta personal, desde el inicio de sesión hasta el efectivo, en menos de dos minutos.
- Requisito comercial de ATM: Al brindar un servicio superior a nuestros clientes minoristas, la red de cajeros automáticos de Monumental Bank nos permitirá aumentar los ingresos por tarifas de servicios asociados en un 10% anual de forma continua.
- Requisito regulatorio de ATM: Todos los cajeros automáticos se conectarán a fuentes de energía de servicios públicos estándar dentro de su jurisdicción cívica y se les suministrará una fuente de alimentación ininterrumpida aprobada por la compañía.
La especificación efectiva de requisitos es una de las empresas más desafiantes a las que se enfrentan los gerentes de proyectos. Los requisitos inadecuadamente especificados garantizarán malos resultados del proyecto.
Documentar los requisitos es mucho más que solo el proceso de anotar los requisitos tal y como los ve el usuario; debe abarcar no sólo qué decisiones se han tomado, sino también por qué se han tomado. Comprender el razonamiento que se utilizó para llegar a una decisión es fundamental para evitar la repetición. Por ejemplo, el hecho de que una característica particular haya sido excluida, porque simplemente no es factible, necesita ser registrada. Si no lo es, entonces el proyecto corre el riesgo de desperdiciar trabajo y repetición, cuando un stakeholder solicita que la característica sea restablecida durante el desarrollo o las pruebas.
Una vez documentados los requisitos, haga que los interesados firmen sus requisitos como confirmación de lo que desean.
Si bien el gerente del proyecto es responsable de asegurarse de que los requisitos estén documentados, no significa que el gerente del proyecto realice esta tarea. El gerente del proyecto cuenta con la ayuda de todos los grupos de interés (analistas de negocios, analistas de requisitos, propietarios de procesos de negocio, clientes y otros miembros del equipo) para llevar a cabo las discusiones, lluvia de ideas y entrevistas, y para documentar y firmar los requisitos. El gerente del proyecto es responsable únicamente de habilitar el proceso y facilitarlo. Si el director del proyecto considera que la calidad del documento es cuestionable, su deber es detener el proceso de desarrollo.
El director del proyecto revisa los requisitos, los incorpora a la biblioteca de documentación del proyecto y los utiliza como insumo para el plan del proyecto.
Fundamentos de los requisitos de software
Esta sección se refiere a los requisitos de “software” porque se refiere a problemas a ser atendidos por el software. Un requisito de software es una propiedad que debe ser exhibida por software desarrollado o adaptado para resolver un problema en particular. El problema puede ser automatizar parte de una tarea de alguien que va a utilizar el software, apoyar los procesos de negocio de la organización que ha encargado el software, corregir deficiencias del software existente, controlar un dispositivo, etc. El funcionamiento de los usuarios, procesos de negocio, y dispositivos es típicamente complejo. Por lo tanto, los requisitos de software particular suelen ser una combinación compleja de requisitos de diferentes personas en diferentes niveles de una organización y del entorno en el que operará el software.
Una propiedad esencial de todos los requisitos de software es que sean verificables. Puede ser difícil o costoso verificar ciertos requisitos de software. Por ejemplo, la verificación del requisito de rendimiento en un centro de llamadas puede requerir el desarrollo de software de simulación. Tanto los requisitos de software como el personal de calidad del software deben garantizar que los requisitos puedan verificarse dentro de las limitaciones de recursos disponibles.
Los requisitos tienen otros atributos además de las propiedades conductuales que expresan. Los ejemplos comunes incluyen una calificación de prioridad para permitir compensaciones frente a recursos finitos y un valor de estado para permitir monitorear el progreso del proyecto. Por lo general, los requisitos de software se identifican de manera única para que puedan monitorearse durante todo el ciclo de vida del software.
Requerimientos de Medición
Como cuestión práctica, suele ser útil tener algún concepto del volumen de los requisitos para un producto de software en particular. Este número es útil para evaluar el tamaño de un cambio en los requisitos, para estimar el costo de una tarea de desarrollo o mantenimiento, o simplemente para usarlo como denominador en otras mediciones (ver Tabla 9.1).
| Propiedad | Medir |
|---|---|
| Velocidad |
|
| Tamaño |
|
| Facilidad de uso |
|
| Confiabilidad |
|
| Robustez |
|
| Portabilidad |
|
Entradas de alcance
El gerente del proyecto recopila datos iniciales del proyecto a partir de la carta del proyecto. Además, la información de antecedentes sobre el lugar de trabajo del actor, el modelo de negocio y las reglas existentes, etc., ayudan a crear la visión del producto/servicio final y, en consecuencia, el alcance del proyecto (ver Figura 9.2).
Técnicas
Sin duda, ser un gerente de proyectos experimentado amplía el repertorio de las técnicas de planificación del alcance de uno. Un gerente de proyecto experimentado puede aprovechar experiencias pasadas con proyectos similares para determinar el trabajo que es realista realizable, dadas las limitaciones de tiempo y costos, para un proyecto actual. Las habilidades de comunicación y negociación también son “imprescindibles”. Los gerentes de proyectos necesitan educar a las partes interesadas sobre los impactos del proyecto de algunos requisitos. Agregar complejidad a un proyecto puede requerir más personal, tiempo y/o dinero. También puede tener un impacto en la calidad del proyecto. Algunos aspectos del proyecto pueden ser inviables; los interesados necesitan saber esto para que puedan ajustar su visión o prepararse para futuros desafíos.
La recolección de requisitos es parte de la definición del alcance, y se puede hacer usando una o más de las siguientes técnicas:
- Entrevistas
- Grupos focales
- Grupos facilitados como JAD (desarrollo de aplicaciones conjuntas)
- Técnicas de creatividad grupal: brainstorming, grupos nominales, delphi, mapa mental, diagnóstico de afinidad
- Prototipado
- Observación
- Preguntas y encuestas
- Técnicas de toma de decisiones grupales: unanimidad, mayoría, pluralidad, dictadura
Matriz de trazabilidad de requisitos
La matriz de trazabilidad de requisitos es una tabla que vincula los requisitos con su origen y los rastrea a lo largo del ciclo de vida del proyecto. La implementación de una matriz de trazabilidad de requisitos ayuda a garantizar que cada requisito agregue valor comercial al vincularlo con los objetivos del negocio y del proyecto. Proporciona un medio para rastrear los requisitos a lo largo del ciclo de vida del proyecto, ayudando a garantizar que los requisitos aprobados en la documentación de requisitos se entreguen al final del proyecto. Finalmente, proporciona una estructura para gestionar los cambios en el alcance del producto. Este proceso incluye, pero no se limita a, el seguimiento de:
- Requisitos para las necesidades, oportunidades, metas y objetivos del negocio
- Requisitos para los objetivos del proyecto
- Requisitos para los entregables del alcance/estructura de desglose del trabajo
- Requisitos para el diseño del producto
- Requisitos para el desarrollo de productos
- Requisitos para probar la estrategia y los escenarios de prueba
- Requerimientos de alto nivel para requisitos más detallados
Los atributos asociados a cada requerimiento se pueden registrar en la matriz de trazabilidad de requisitos. Estos atributos ayudan a definir información clave sobre el requisito. Los atributos típicos utilizados en la matriz de trazabilidad de requisitos pueden incluir un identificador único, una descripción textual del requisito, la razón de inclusión, propietario, fuente, prioridad, versión, estado actual (como activo, cancelado, diferido, agregado, aprobado) y fecha de finalización. Los atributos adicionales para asegurar que el requisito ha cumplido con la satisfacción de las partes interesadas pueden incluir criterios de estabilidad, complejidad y aceptación.
Campos de Matriz
Estas son solo sugerencias y variarán en función de los requisitos organizativos y del proyecto.
- Un número de identificación único que contiene la categoría general del requisito (por ejemplo, SYSADM) y un número asignado en orden ascendente (por ejemplo, 1.0, 1.1, 1.2)
- Declaración de requisitos
- Fuente de requisitos (conferencia, placa de control de configuración, asignación de tareas, etc.)
- Especificación de requisitos de software/requisitos funcionales número de párrafo del documento que contiene el requisito
- Número de párrafo de especificación de diseño que contiene el requisito
- Módulo de programa que contiene el requisito
- Especificación de prueba que contiene la prueba de requisito
- Número (s) de caso de prueba donde se debe probar el requisito (opcional)
- Verificación de pruebas exitosas de requisitos
- Campo de modificación (Si un requisito fue cambiado, eliminado o reemplazado, indique disposición y autoridad para la modificación).
- Observaciones
Estructura de desglose del trabajo
Ahora que tenemos los entregables y requisitos bien definidos, comienza el proceso de desglose del trabajo del proyecto a través de una estructura de desglose del trabajo (EDT). La EDT define el alcance del proyecto y divide el trabajo en componentes que pueden programarse, estimarse y monitorearse y controlarse fácilmente. La idea detrás de la EDT es simple: subdivides una tarea complicada en tareas más pequeñas, hasta llegar a un nivel que no se puede subdividir más. Cualquier persona familiarizada con los arreglos de carpetas y archivos en la memoria de una computadora o que haya investigado su árbol genealógico ancestral debe estar familiarizado con esta idea. Dejas de desglosar el trabajo cuando alcanzas un nivel lo suficientemente bajo como para realizar una estimación de la precisión deseada. En ese punto, suele ser más fácil estimar cuánto tardará la tarea pequeña y cuánto costará realizarla de lo que habría sido estimar estos factores en los niveles superiores. Cada nivel descendente de la EDT representa un mayor nivel de definición detallada del trabajo del proyecto.
WBS describe los productos o servicios a entregar por el proyecto y cómo se descomponen y relacionan. Es una descomposición orientada a entregables de un proyecto en componentes más pequeños. Define y agrupa los elementos de trabajo discretos de un proyecto de manera que ayude a organizar y definir el alcance total de trabajo del proyecto.
Una EDT también proporciona el marco necesario para la estimación y control de costos detallados, además de proporcionar orientación para el desarrollo y control de horarios.
Visión general
EDT es una descomposición jerárquica del proyecto en fases, entregables y paquetes de trabajo. Es una estructura de árbol, que muestra una subdivisión del esfuerzo requerido para lograr un objetivo (por ejemplo, un programa, proyecto y contrato). En un proyecto o contrato, la EDT se desarrolla comenzando con el objetivo final y subdividiéndolo sucesivamente en componentes manejables en términos de tamaño, duración y responsabilidad (por ejemplo, sistemas, subsistemas, componentes, tareas, subtareas y paquetes de trabajo), que incluyen todos los pasos necesarios para lograr el objetivo.
La creación de EDT implica:
- Listado de todos los resultados del proyecto (entregables y otros resultados directos)
- Identificar todas las actividades necesarias para entregar los resultados
- Subdividir estas actividades en subactividades y tareas
- Identificar los entregables y los hitos de cada tarea
- Identificar el uso del tiempo de todos los recursos (personal y material) necesarios para completar cada tarea
El propósito de desarrollar una EDT es:
- Permite una gestión más sencilla de cada componente
- Permitir una estimación precisa de los requisitos de tiempo, costo y recursos
- Facilitar la asignación de recursos humanos
- Permitir una asignación más fácil de responsabilidad por las actividades
Ejemplo de una EDT
Si quiero limpiar una habitación, podría comenzar por recoger ropa, juguetes y otras cosas que se han caído al suelo. Me vendría bien una aspiradora para sacar suciedad de la alfombra. Podría bajar las cortinas y llevarlas a la tintorería, y luego desempolvar los muebles. Todas estas tareas son subtareas realizadas para limpiar la habitación. En cuanto a aspirar la habitación, podría tener que sacar la aspiradora del armario, conectar la manguera, vaciar la bolsa y volver a poner la máquina en el armario. Se trata de tareas más pequeñas a realizar en el logro de la subtarea llamada aspiración. La Figura 9.3 muestra cómo esto podría ser retratado en formato EDT.
Es muy importante señalar que no nos preocupamos por la secuencia en la que se realiza el trabajo ni por cualquier dependencia entre las tareas cuando hacemos una EDT. Eso se resolverá cuando desarrollemos el horario. Por ejemplo, bajo 3.0 Vacuum, sería obvio que 3.3 La alfombra de vacío se realizaría después de 3.4 ¡Conecta la manguera y el enchufe! No obstante, probablemente te encontrarás pensando secuencialmente, ya que parece ser la naturaleza humana hacerlo. La idea principal de crear una EDT es capturar todas las tareas, independientemente de su orden. Entonces, si te encuentras a ti mismo y a otros miembros de tu equipo pensando secuencialmente, no te preocupes demasiado, pero no te molestes al intentar trazar la secuencia o ralentizarás el proceso de identificación de tareas. Una EDT se puede estructurar de cualquier manera que tenga sentido para usted y su proyecto. En la práctica, la estructura gráfica se utiliza con bastante frecuencia pero también se puede componer en forma de esquema (Figura 9.4).
Notarás que a cada elemento en cada nivel de la EDT en ambas figuras se le asigna un identificador único. Este identificador único suele ser un número, y se utiliza para sumar y realizar un seguimiento de costos, horarios y recursos asociados con elementos EDT. Estos números suelen estar asociados con el plan de cuentas de la corporación, el cual se utiliza para realizar un seguimiento de los costos por categoría. Colectivamente, estos identificadores numéricos se conocen como el código de cuentas.
También hay muchas formas de organizar la EDT. Por ejemplo, puede organizarse ya sea por entregable o por fase. Los principales entregables del proyecto se utilizan como primer nivel en la EDT. Por ejemplo, si está realizando un proyecto multimedia, los entregables podrían incluir la producción de un libro, un CD y un DVD (Figura 9.5).
Muchos proyectos están estructurados u organizados por fases del proyecto (Figura 9.6). Cada fase representaría el primer nivel de la EDT y sus entregables serían el siguiente nivel y así sucesivamente.
El gerente del proyecto es libre de determinar el número de niveles en la EDT en función de la complejidad del proyecto. Debe incluir suficientes niveles para estimar con precisión el tiempo y los costos del proyecto, pero no tantos niveles que sean difíciles de distinguir entre componentes. Independientemente del número de niveles en una EDT, el nivel más bajo se llama paquete de trabajo.
Los paquetes de trabajo son los componentes que se pueden asignar fácilmente a una persona o a un equipo de personas, con una clara rendición de cuentas y responsabilidad para completar la tarea. El nivel de paquete de trabajo es donde se determinan las estimaciones de tiempo, las estimaciones de costos y las estimaciones de recursos.
Regla del 100 por ciento
La regla del 100 por ciento es el criterio más importante en el desarrollo y evaluación de la EDT. La regla establece que cada nivel descompuesto (hijo) debe representar el 100 por ciento del trabajo aplicable al siguiente elemento superior (padre). Es decir, si cada nivel de la EDT sigue la regla del 100 por ciento hasta las actividades, entonces estamos seguros de que el 100 por ciento de las actividades habrán sido identificadas cuando desarrollemos el cronograma del proyecto. Cuando creamos el presupuesto para nuestro proyecto, se identificará el 100 por ciento de los costos o recursos requeridos.
Declaración de alcance
Las declaraciones de alcance pueden tomar muchas formas dependiendo del tipo de proyecto que se esté implementando y la naturaleza de la organización. La declaración de alcance detalla los entregables del proyecto y describe los principales objetivos. Los objetivos deben incluir criterios de éxito medibles para el proyecto.
Una declaración de alcance captura, en términos muy amplios, el producto del proyecto: por ejemplo, “el desarrollo de un sistema basado en software para capturar y rastrear pedidos de software”. Una declaración de alcance también debe incluir la lista de usuarios que utilizan el producto, así como las características del producto resultante.
Como referencia, las declaraciones de alcance deben contener:
- El nombre del proyecto
- La carta del proyecto
- El propietario del proyecto, los patrocinadores y los grupos de interés
- La declaración del problema
- Las metas y objetivos del proyecto
- Los requisitos del proyecto
- Los entregables del proyecto
- Los no-objetivos del proyecto (lo que está fuera de alcance)
- Hitos
- Estimaciones de costos
En organizaciones más orientadas a proyectos, la declaración de alcance también puede contener estas y otras secciones:
- Plan de gestión del alcance del proyecto
- Solicitudes de cambio aprobadas
- Supuestos y riesgos del proyecto
- Criterio de aceptación del proyecto
Descripciones de las imágenes
Descripción de la imagen de la Figura 9.2: Un gerente de proyecto desarrolla un Plan de Gestión de Alcance tomando la carta del proyecto, la memoria organizacional y el plan del proyecto y aplicando las siguientes técnicas y herramientas:
- Pide experiencia en proyectos pasados
- Utiliza plantillas de gestión de alcance (SOS, EDT, Plan de Gestión de Alcance)
- Utiliza habilidades de comunicación (para negociar y educar a los clientes)
Figura 9.3 Descripción de la imagen:
0.0 Cuarto Limpio
- 1.0 Piso de fregona.
- 1.1 Saca la fregona y el cubo.
- 1.2 Mezclar limpiador con agua en cubo.
- 1.3 Enjuaga el cubo y la fregona.
- 2.0 Polvo
- 2.1 Mesa de centro
- 2.2 Persianas
- 3.0 Vacío
- 3.1 Saca la aspiradora del clóset
- 3.2 Alfombra de vacío
- 3.3 Bolsa vacía
- 3.4 Conecte la manguera y el enchufe
- 4.0 Piso de recogida
- 4.1 Juguetes
- 4.1.1 Poner juguetes en caja
- 4.2 Ropa
- 4.2.1 Cuelga en el clóset
- 4.1 Juguetes
- 5.0 Cortinas limpias
- 5.1 Quitar cortinas
- 5.2 Llevar a limpiadores
- 5.3 Colgar cortinas
Atribuciones de texto
Este capítulo de Gestión de Proyectos es un derivado de los siguientes textos:
- Gestión de proyectos por Merrie Barron y Andrew Barron. © CC BY (Atribución).
- Gestión de proyectos/PMBOK/Scope Management and Development Cooperation Handbook/Diseñar y ejecutar proyectos/Planeación detallada o etapa de diseño por Wikibooks. © CC BY-SA (Attribution-ShareAlike).
- Requisitos Matriz de Trazabilidad por DHWiki. © CC BY-NC-ND (Atribución-NoComercial-SinDerivadas)
- Estructura de desglose del trabajo por Wikipedia. © CC BY-SA (Reconocimiento-CompartirIgual).
- Regla del 100 por ciento por Pabipedia. © CC BY-SA (Atribución-CompartirIgual).
Atribuciones de medios
- Cajeros automáticos por megawatts86 © CC BY-SA (Atribución CompartirIgual)
- Gestión de alcances IO de Flaming Sevens adaptado por Josie Gray © Public Domain
- WBS Cleaning Room by Barron & Barron Project Management for Scientists and Engineers © CC BY (Atribución)
- Esquema EDT — Sala limpia de Barron & Barron Gestión de proyectos para científicos e ingenieros © CC BY (Atribución)
- EDT de proyectos multimedia por Barron & Barron Gestión de proyectos para científicos e ingenieros © CC BY (Atribución)
- Fases del Proyecto WBS por Barron & Barron Gestión de Proyectos para Científicos e Ingenieros © CC BY (Atribución)