Peter Roberts, Levinia Manfredini – Dermik; y Gustavo Zurita, UEjecutivos UCH.
Según Peter Roberts, Consultor del PNUD en proyectos informáticos, y Director informática, Levinia Manfredini – Dermik, quien expuso en el encuentro “Levantamiento de Requerimientos, ¿un Arte o una Técnica?”, existen al menos 20 tipos de requerimientos para un proyecto TI.
“La secuencia de un proyecto, que involucra la fase de alcance, planificación, lanzamiento, monitoreo y control y cierre, cuenta con distintos requerimientos, entre ellos aquellos asociados al tipo de proyecto, ámbito comunicacional, ambiental, recursos, plazo y negociación, entre otros”, sostuvo. Para el caso del desarrollo de productos o aplicaciones, añadió que “los requerimientos funcionales y no funcionales, que involucran la etapa de licitación de proyectos, diseño, codificación/construcción, prueba y despliegue, pueden afectar el proyecto, al plantear nuevos requerimientos o modificar los vigentes”.
“No siempre entendemos de la misma manera (cliente y empresa). Depende de las experiencias, los conocimientos y el modelo mental que tienen todos los actores involucrados, para comprender de manera precisa, real y objetiva los requerimientos de los clientes”, añadió Gustavo Zurita, Director Académico de programas de UEjecutivos, quien también participó como expositor del webinar organizado por la unidad de Educación Ejecutiva (UEjecutivos) de la FEN Universidad de Chile.
Tipos de requerimientos
Los requerimientos pueden ser operacionales, que involucran distintos escenarios y su factibilidad; funcionales, que tratan sobre lo que debe hacer el producto o aplicación; de desempeño, que consideran la velocidad, disponibilidad; y de interfase.
Otro de los requerimientos importantes, puede provenir de los recursos, entre ellos los humanos. Sobre estos, destacó que las disfunciones comunes tienen que ver con la “falta de compromiso, evasión de responsabilidades, temor al conflicto, falta de atención a los resultados y de confianza”. En este caso, señaló que el líder del proyecto debe eliminar ambigüedades, fijar metas, KPI y estándares, limpiar armonía artificial, dejar a un lado estatus y egos y romper fachada de invulnerabilidad.
Los requerimientos también pueden ser físicos; de verificación; de aceptación; de documentación, manuales, garantías y certificados; de software, ambiente/plataforma, compatibilidad y lenguaje; de seguridad física o del personal, prevención de accidentes y advertencias; medioambientales; de calidad; de diseño, cómo construir el producto (aplicación) y no construirlo; de embalaje y marcaje; legales, regulaciones, estándares y normas; de costos de ciclo de vida, costo anual y costos de actualización; y de evaluación, que tienen que ver con el ámbito económico, indicadores de homologación, TIR, VAN, ROI y métricas.
El último corresponde al requerimiento de negociación, contratación y relación con contratistas.
Sobre la negociación el profesional puso énfasis en que es preciso tener claro el punto de partida, que es la oferta inicial, así como el punto objetivo, que es el resultado que se espera tener, y el punto de retirada o desfavorable, que corresponde al límite de la negociación, pues sobrepasado este punto la negociación no es rentable.
Respecto a la contratación, sostuvo que se debe documentar y mantener evidencias de: solicitud, creación, confección, negociación, el modelo de contrato (depende si se usa metodología tradicional o técnica ágil), aprobación, firma, distribución, áreas involucradas, monitoreo, ejecución, gestión, ajustes, término y renovación.
Distintos puntos de vista
Para priorizar los requisitos/requerimientos del proyecto o producto que proporcionarán el mejor retorno de la inversión (ROI), Peter Roberts explicó que es posible utilizar el método Moscow, en el que se evalúan aquellos que deben estar, los que deberían, los que podrían y los que no estarán.
Gustavo Zurita, por su parte, aclaró que “los requerimientos del producto tienen una incidencia directa en cada uno de los 20 tipos de requerimientos”. Por lo mismo, agregó que si no se entiende qué es lo que exactamente se quiere hacer con el nuevo proyecto no se podrá desarrollar de manera correcta y lograr los objetivos trazados.
En ese aspecto, puntualizó que “un buen entendimiento de los requerimientos del producto depende del manejo adecuado de nuestros paradigmas que tenemos como seres humanos, y de cómo somos capaces de manejarlos para aproximarnos a una comprensión precisa y correcta de lo que se necesita. Se hace necesario ver el problema o requerimiento a resolver, desde distintos puntos de vista”.
Asimismo, Peter Roberts enfatizó que, en toda gestión exitosa de proyectos de TI, cuyo proceso consiste en planear, organizar y delimitar responsabilidades en la organización, se requiere tener una estrategia. Junto con ello, es preciso generar un análisis de contexto o entorno, y evaluar las condiciones y procedimientos, para que este funcione.
Otras exigencias para su buen desarrollo tienen que ver con la calidad, cumpliendo con los criterios planificados; así como también dar cumplimiento al presupuesto, el cronograma establecido en la carta Gantt, los requisitos del producto y los recursos planificados.
