1 # Planificación de Proyectos 2 3 \tableofcontents 4 5 ## Proceso de Diseño 6 7 El diseño de ingeniería se vincula con la concepción de sistemas, equipos, 8 componentes o procesos con el fin de satisfacer una necesidad 9 10 Un proyecto de ingeniería es definido como: "Un proceso único consistente en un 11 conjunto de actividades coordinadas y controladas, con fechas establecidas de 12 inicio y finalización, desarrolladas con el fin de alcanzar un objetivo para 13 conformar requerimientos específicos, incluyendo restricciones de tiempo, costo 14 y recursos". 15 16 Las tareas involucradas y su desarrollo reúnan las siguientes condiciones: 17 18 * Ser único 19 * Ser complejo 20 * Cumplir con una organización temporaria/un plan preestablecido 21 * Tener objetivos relacionados con la satisfacción de las necesidades 22 * Satisfacer requerimientos específicos: 23 - Tiempo 24 - Presupuesto 25 - Beneficio 26 - Recursos 27 28 La salida debe resultar de un proceso de optimización del diseño, buscando 29 simplificar, mejorar, innovar, y reducir desperdicios, valiéndose de 30 herramientas específicas tales como: 31 32 * La función de despliegue de la calidad (QFD) 33 * Análisis de los modos de falla (FMEAs) 34 * Análisis del árbol de fallas (FTA) 35 * Diseño de experimentos (DOE) 36 * Análisis de ingeniería del valor (VE) 37 * Análisis de tolerancias (DOT) 38 * Análisis de costo/desempeño/riesgo 39 40  41 42 ### Determinación de la necesidad 43 44 El proceso de diseño parte del reconocimiento de una necesidad insatisfecha, mal 45 satisfecha, o susceptible de mejorar en algún sentido. Las necesidades resultan 46 o surgen por motivaciones muy variadas: 47 * Investigaciones de mercado, que muestran que los productos actuales han 48 quedado obsoletos, o fuera de competencia 49 * Aparición de nuevas legislaciones, normativas o demandas. 50 * Complementos de productos, por análisis de un mercado ya existente. 51 * Nuevas posibilidades que surgen durante la ejecución de otro proyecto 52 * Pedidos formales, donde el cliente formula directamente el requerimiento 53 * Pedidos informales, en donde un potencial cliente sugiere que una determinada 54 propuesta, en un área de interés particular, tendría gran aceptación o grandes 55 posibilidades futuras. 56 * Nichos de mercado insatisfechos de productos existentes. 57 58 ### Definición de producto 59 60 Los requerimientos son las necesidades, funcionalidades o condiciones que un 61 sistema, producto o proyecto debe cumplir para satisfacer los objetivos. Los 62 requerimientos se pueden dividir en funcionales y no funcionales, los 63 funcionales describen qué debe hacer el sistema, por ejemplo: "El sistema debe 64 permitir al usuario crear una cuenta", mientras que los no funcionales 65 describen como se debe comportar el sistema, o que características de calidad 66 debe tener, por ejemplo "El sistema debe responder en menos de 2 segundos". 67 68 Los requerimientos son la base de las especificaciones, la cual es una 69 descripción detallada, clara y precisa de cómo debe ser el producto, sistema o 70 componente para cumplir con los requerimientos definidos. 71 72  73 74 #### Especificaciones técnicas 75 76 Detallan los aspectos funcionales, mecánicos, eléctricos, de software, etc. 77 Ejemplo: "El sistema debe usar una base de datos PostgreSQL y soportar hasta 78 1000 usuarios concurrentes." 79 80 #### Especificaciones funcionales 81 82 Describen lo que el sistema debe hacer. Ejemplo: "El sistema debe permitir 83 registrar nuevos usuarios mediante un formulario web." 84 85 #### Especificaciones de diseño 86 87 Incluyen planos, diagramas, prototipos o interfaces. Ejemplo: un wireframe de 88 una aplicación móvil. 89 90 #### Especificaciones de producto o fabricación 91 92 Usadas en ingeniería o industria. Ejemplo: materiales, dimensiones, tolerancias, 93 procesos. 94 95 ### Diseño detallado 96 97 El propósito de esta etapa del proyecto es: 98 99 * Seleccionar los circuitos 100 * Establecer modelos para el cálculo de los elementos, a fin de determinar la 101 carga a la que se ven sometidos 102 * Seleccionar los componentes estándar en función de la carga a la que están 103 sometidos, indicando fabricante y número de parte correspondiente 104 * Establecer las especificaciones que deben ser satisfechas por los componente a 105 medida 106 * Realizar análisis de valor de cada elemento 107 * Documentar los problemas detectados en las etapas de verificación, y las 108 acciones de corrección correspondientes 109 * Documentar los resultados de los ensayos de validación efectuados sobre 110 prototipos 111 * Generar la documentación y las especificaciones que describan completamente el 112 diseño, etc 113 114 ## Pensamiento de Diseño (Design Thinking) 115 116 El pensamiento de diseño es una metodología que se aplica en el diseño de 117 productos, esta metodología esta centrada en las personas, ya que se basa en 118 entender las necesidades del usuario, generando ideas, prototipando soluciones y 119 probándolas corrigiéndolas y volviendo a empezar, esto ultimo notando el 120 comportamiento iterativo de la metodología. 121 122 ### Etapas del pensamiento de diseño 123 124 Principalmente, el pensamiento de diseño se estructura en 5 fases 125 126 1. Empatizar 127 2. Definir 128 3. Idear 129 4. Prototipar 130 5. Evaluar 131 132 #### Empatizar 133 134 Durante esta etapa se busca comprender al usuario, para esto se puede seguir la 135 regla *observar-escuchar-involucrarse*. 136 137 ##### Mapas de Empatía 138 139 Es una herramienta que ayuda a sintetizar la información obtenida del usuario 140 (en etapas previas, como entrevistas, o mediante observación, etc) de manera tal 141 que resulte mas fácil identificar descubrimientos claves (insights) que no se 142 obtienen solo con datos. 143 144 La estructura típica de un mapa de empatía es: 145 146 1. Dice 147 2. Piensa 148 3. Siente 149 4. Hace 150 5. Esfuerzos 151 6. Necesidades 152 153 #### Definir 154 155 Se sintetiza la información para formular un problema claro y bien enfocado, 156 basado en las necesidades detectadas en etapas anteriores. 157 158 ##### POV Statement 159 160 Un POV Statement (Point of View Statement) es una declaración clara del problema 161 desde la perspectiva del usuario, que ayuda a enfocar la ideación en una 162 necesidad humana específica. 163 164 La estructura tipica de un POV Statement es `<usuario> necesita <necesidad> 165 porque <insight>`, por ejemplo en el contexto del sistema de acceso al 166 estacionamiento desde el punto de vista del operador de sistema: "el operador 167 **necesita** registrar vehículos de forma rápida y sin cometer errores, 168 **porque** debe atender a varios usuarios en poco tiempo y asegurarse de que la 169 información esté bien cargada**. 170 171 #### Idear 172 173 El propósito principal de la etapa de idear es generar soluciones creativas al 174 problema definido a partir de los hallazgos de las fases anteriores, existen 175 muchas dinámicas para generar ideas, como por ejemplo brainstorming, SCAMPER, 176 entre otras 177 178 ##### Brainstorming 179 180 El brainstorming es una herramienta dinámica grupal (o individual) para 181 generar una gran cantidad de ideas sin juzgarlas, con el fin de explorar todas 182 las posibles soluciones a un reto o necesidad del usuario. 183 184 #### Prototipar 185 186 Durante esta etapa se convierten las ideas seleccionadas de la etapa anterior en 187 soluciones tangibles y experimentales con las cuales el usuario pueda 188 interactuar, de esta forma detectando posibles fallas, oportunidades o 189 malentendidos. 190 191 Algunas formas de prototipar incluyen realizar bocetos, maquetas, videos 192 simulados, entre otras. 193 194 #### Evaluar 195 196 Durante la etapa de testeo o evaluación se ponen a prueba las soluciones 197 prototipadas con los usuarios para ver si realmente satisfacen sus necesidades, 198 resuelven sus problemas y generan valor. 199 200 Con la información obtenida durante esta etapa se puede decidir si volver a 201 etapas anteriores, o rediseñar el prototipo de alguna manera, y en caso de hacer 202 cambios importante repetir la etapa de evaluación. 203 204 ## Work Breakdown Structure (WBS) 205 206 Se debe tener definido el propósito, el objetivo y el alcance del proyecto. El 207 propósito, es la razón de ser o el significado más profundo del proyecto. El 208 objetivo es la meta concreta y tangible que se busca alcanzar, basada en el 209 propósito y el alcance se define los límites y fronteras del proyecto, es la 210 suma de todos los requerimientos y las restricciones. 211 212 En un WBS o EDT (Estructura de Desglose del Trabajo, en español) se plasma el 213 alcance y los requerimientos del proyecto, para esto se divide la totalidad del 214 proyecto en actividades intermedias únicas. 215 216 Los niveles del WBS representan el grado de detalle o descomposición del 217 proyecto en partes más manejables, cuanto mayor sea el nivel mayor será la 218 especificidad de la tarea o actividad. Por lo general las actividades de un WBS 219 se eligen de manera tal que no ocupan mas de 80 horas de trabajo por persona 220 221  222 223 ## Activity on Node (AON) 224 225 En el AON se muestran todas las actividades necesarias para completar el 226 proyecto en un diagrama de nodos y flechas, de manera que se pueda ver las 227 dependencias de cada actividad y se pueda estimar tiempos. 228 229 Para estimar tiempos en un diagrama AON, se asigna una duración estimada a cada 230 actividad representada por los nodos, esto puede ser mediante expertos en el 231 area o si se ha realizado proyectos similares antiguamente o bien mediante la 232 técnica PERT (la cual es similar a un promedio ponderado); luego de la 233 estimación de tiempos se analiza la secuencia de actividades para calcular la 234 duración total del proyecto, así como identificar el camino crítico. 235 236 El camino critico es el camino de actividades que de retrasarse, se retrasa todo 237 el proyecto, es el de mayor duración, o de holgura nula. La holgura es el tiempo 238 que puede retrasarse (en iniciar o finalizar) sin que se retrasen otras 239 actividades dependientes de esa. 240 241 ### Técnica CPM 242 243 La técnica Critical Path Method (CPM) es un método de estimación y gestión de 244 tiempos que se utiliza para planificar, programar y controlar proyectos. Es 245 útil cuando se tiene la duración estimada de cada actividad y se necesita 246 encontrar la secuencia de tareas críticas para completar el proyecto en el menor 247 tiempo posible. Se realiza un gráfico de nodos y flechas con cada una de las 248 actividades del proyecto contemplando las dependencias jerárquicas y temporales 249 250 El tiempo mas temprano de un nodo es el instante más inmediato en el cual puede 251 ocurrir el evento correspondiente a dicho nodo. El tiempo más tarde para un nodo 252 es el último instante en el cual puede ocurrir el evento correspondiente al nodo 253 sin retrasar la duración total del proyecto. 254 255 La diferencia entre el tiempo más tardío y el tiempo más temprano se define 256 como holgura. 257 258 Una actividad crítica es una actividad que no puede retrasarse. Si se retrasa 259 afecta a la duración total del proyecto. En otras palabras, el tiempo más 260 temprano y el tiempo más tarde de inicio de la actividad son idénticos, es 261 decir, tiene tiempo de holgura nulo. 262 263 ### Técnica de estimación de tiempos PERT 264 265 La técnica PERT (Program Evaluation and Review Technique) es una herramienta de 266 planificación utilizada para estimar la duración de actividades en proyectos, 267 especialmente cuando hay incertidumbre en los tiempos, esto puede ocurrir cuando 268 no se conoce con certeza cuánto tiempo tomará la actividad, por ejemplo en 269 investigaciones o desarrollos nuevos. 270 271 Es una formula probabilística que permite obtener una estimación de tiempo mas 272 real a partir de 3 tiempos estimados de una actividad: el tiempo optimista 273 ($O$), el mas probable ($M$) y el tiempo pesimista ($P$). 274 275 $$T_{e} = \frac{O + 4*M + P}{6}$$ 276 277 El calculo de la varianza de cada actividad se utiliza para determinar la 278 incertidumbre de que se termine el proyecto de acuerdo al programa. 279 280 $$Varianza = {\sigma}^2 = \left({\frac{P - O}{6}}\right) ^2$$ 281 282 ## Metodologías Ágiles 283 284 La metodología ágil es un enfoque flexible para la gestión de proyectos que se 285 centra en la colaboración, la comunicación y la entrega de valor de manera 286 iterativa y continua. En lugar de planificar exhaustivamente al inicio, las 287 metodologías ágiles permiten adaptarse a los cambios en los requisitos y 288 prioridades a lo largo del proyecto 289 290 ### Metodología Scrum 291 292 Es una forma de organizar el trabajo en equipo en ciclos cortos y repetitivos 293 llamados Sprints, con el objetivo de entregar valor rápidamente, adaptarse a 294 cambios y mejorar continuamente. 295 296 #### Roles en Scrum 297 298 * Product Owner (Dueño del Producto): Representa al cliente y prioriza el 299 trabajo (Product Backlog). 300 * Scrum Master: Facilita el proceso Scrum, elimina obstáculos y guía al equipo. 301 Hace de intermediario entre el Product Owner y el equipo de desarrollo, 302 facilitando la comunicación. 303 * Equipo de desarrollo: Grupo auto-organizado que lleva a cabo el trabajo 304 técnico y el desarrollo concreto y tangible del proyecto. 305 306 #### Product Backlog 307 308 El Product Backlog es una lista ordenada de todo lo que se necesita hacer para 309 desarrollar el producto. Es la fuente única de requisitos para cualquier cambio 310 que se necesite en el producto. El Product Owner se encarga de crear y 311 mantenerlo, de asignar las prioridades a cada item en funciona del valor de 312 negocio y de asegurarse de que este bien claro y comprendido. El product backlog 313 se actualiza de manera continua, por ejemplo al terminar un sprint o cuando 314 cambian las necesidades de los usuarios. 315 316 Los items pueden ser historias de usuario, los cuales son una forma ágil y 317 centrada en el usuario de describir requisitos funcionales. 318 319 #### Historias de Usuario 320 321 Las historias de usuario son una forma de describir lo que el usuario 322 necesita de manera simple, clara y centrada en el valor que aportará esa 323 funcionalidad o característica. 324 325 El formato mas común de historia de usuario es `Como <usuario> quiero <lo que 326 desea> para <beneficio o valor>`. Por ejemplo en el sistema de acceso al 327 estacionamiento: "**Como** operador del sistema, **quiero** poder registrar los 328 datos del vehículo al ingresar, **para** llevar un control preciso de los 329 accesos." 330 331 Para crear historias de usuario de manera efectiva se puede seguir la regla de 332 las 3 Cs: Card-Conversation-Confirmation (tarjeta, conversación, confirmación) 333 334 * Card: cada historia de usuario se reduce hasta hacerla fácil de memorizar y de 335 sintetizar en una tarjeta. La tarjeta sirve como recordatorio y promesa de una 336 conversación posterior y no debe ser un documento completo. 337 * Conversation: el equipo de desarrollo y el propietario del producto añaden 338 criterios de aceptación a cada historia poco antes de su implementación. Los 339 cambios son bienvenidos en agilidad, por lo que no tiene sentido profundizar 340 en estos detalles antes. La situación puede variar mucho desde el momento en 341 el que se sintetiza la funcionalidad en la tarjeta hasta que se implementa. 342 * Confirmation: el product owner o usuario de negocio confirma que el equipo de 343 desarrollo ha entendido y aplicado correctamente sus requisitos revisando los 344 criterios de aceptación. A veces se pueden presentar transformados en 345 escenarios de pruebas. 346 347 #### Temas, Épicas y Tareas 348 349 * Epic: es una historia de usuario de gran tamaño o alta granularidad, y que 350 tiene por tanto un mayor grado de incertidumbre. Marcar una historia como epic 351 implica que no puede completarse de una sola vez o en un único sprint. Lo 352 normal es que el equipo de desarrollo lo descomponga cuando se acerque el 353 momento de su implementación. Las historias de usuario resultantes estarán 354 íntimamente relacionadas y su menor tamaño permitirá gestionarlas de forma 355 ágil, estimando mejor el tiempo requerido para completarlas y siguiendo su 356 avance con detalle. 357 * Tema: una colección de epics e historias de usuario relacionadas que describen 358 un sistema o subsistema. Se trata de un elemento que forma parte de la visión 359 del producto, más que una funcionalidad. Por ejemplo: en un sistema de 360 software para gestión contable, el conjunto de epics «altas, bajas y 361 mantenimiento de clientes», «facturaciones puntuales y recurrentes», 362 «consultas de navegación y acciones de fidelización», «pedidos» 363 y«devoluciones» se podrían denominar como el tema de la «gestión de clientes». 364 * Tareas: están por debajo de las historias de usuario. Describen cómo construir 365 en lugar de qué. Resultan de la descomposición de las historias de usuario en 366 unidades de trabajo adecuadas pare gestionar y seguir el avance de su 367 ejecución. 368 369 #### Sprint Backlog 370 371 El sprint backlog lo crea el equipo de desarrollo previo a la ejecución de un 372 sprint (sprint planning) teniendo en cuenta las prioridades del product backlog 373 y es el conjunto de item a desarrollar durante el sprint siguiente. 374 375 #### Incremento 376 377 Producto potencialmente entregable al final de cada Sprint. 378 379 ### Riesgos 380 381 Los riesgos son cualquier "evento" que altera la planificación original de 382 objetivos y planes del proyecto. 383 384 #### Gestión de riesgos 385 386 La gestión de riesgo implica identificar los riesgos, sus efectos y tratar de 387 reducir sus consecuencias. Esto **no elimina** los riesgos, pero maximiza la 388 chance de éxito a pesar de los problemas. 389 390 Establecer planes de contingencia para todos los riesgos implica el incremento 391 de costos. Debemos decidir cuáles riesgos serán mitigados en base a distintos 392 criterios los cuales deben ser correctamente explicados y conocidos por todos 393 los interesados e involucrados en el proyecto. 394 395 Para definir si se debe contar con un plan de mitigación de un riesgo se lo 396 puede; 397 - Clasificar de acuerdo a la probabilidad de ocurrencia; utilizando una métrica 398 de 0 a 100% y la etiqueta agrupadora de "siempre", "frecuentemente", 399 "ocasionalmente", "raramente", "nunca". 400 - Clasificar de forma ordinal: esto es; primero el riesgo más probable, luego el 401 segundo, y así sucesivamente. 402 - Clasificar en forma relativa; por ejemplo, "el riesgo A es dos veces más 403 probable que el riesgo B" "Siempre se debe entender el impacto del riesgo en 404 el proyecto y el impacto en la calidad del proyecto" 405 406 1. Identificar los riesgos: determinar que aspectos del plan o del proyecto 407 podrían cambiar. 408 2. Estimar las consecuencias de esos riesgos: evaluar qué podría pasar si esos 409 aspectos cambian. 410 3. Elaborar planes para mitigar sus efectos: determinar cómo se puede proteger 411 el proyecto ante los riesgos. 412 4. Seguir el estado de los riesgos: su probabilidad de ocurrencia, la aparición 413 de nuevos riesgos, etc. 414 5. Informar a todos los interesados sobre los riesgos. 415 416 Para detectar cuál riesgo conviene mitigar primero se puede utilizar el "RPN"; 417 en inglés, "Risk Priority Number". 418 419 $$ RPN = Prob. de Ocurrencia * Factor de Severidad * (1 – Prob. de Detección)$$ 420 421 Siendo "Prob. de Ocurrencia": Probabilidad que ocurra ese evento; Factor de 422 Severidad: Indicador del daño potencial que podría generar. (Valoración 423 subjetiva de 0 a 1) y Probabilidad de Detección: la probabilidad de detectar la 424 ocurrencia del evento con anticipación. 425 426 ## Gestión Económica 427 428 La gestión económica de un proyecto busca garantizar el uso eficiente de los 429 recursos disponibles para cumplir con los objetivos dentro del alcance, tiempo y 430 costo definidos. Es parte fundamental de la triple restricción: 431 tiempo–alcance–costo. 432 433 La elaboración de presupuestos es una de las actividades claves en la 434 planificación de proyectos, ya que permite anticipar recursos, justificar 435 decisiones y evaluar la viabilidad. 436 437 Los costos se pueden clasificar en directo e indirectos 438 439 ### Costos directos 440 441 Los costos directos son aquellos que se pueden asociar directamente con un 442 producto, servicio o entregable del proyecto. Por ejemplo el hardware, las 443 licencias de uso, los materiales para la instalación, etc. 444 445 ### Costos indirectos 446 447 Los costos indirectos no se pueden asociar directamente a un entregable 448 particular, pero son necesarios para que el proyecto se lleve a cabo. Por 449 ejemplo, la mano de obra (programadores, instaladores), el mantenimiento 450 preventivo, los costos de gestión o administración, etc. 451 452 ### Cost Breakdown Structure (CBS) 453 454 El Cost Breakdown Structure (CBS) es la organización jerárquica de los costos 455 del proyecto, alineada a los entregables y actividades del Work Breakdown 456 Structure (WBS).
