Requerimiento, camino al despliegue del éxito.

Requerimiento, camino

al despliegue del éxito.

Los requerimientos son fundamentales ya que determinan el éxito o fracaso de una implementación. Un requerimiento es una de las partes esenciales en la implementación de un sistema que evoca un sentido de necesidad de un usuario o cliente, es la base de cada proyecto de lo que se quiere realizar, automatizar o mejorar, se trata de la capacidad que tiene un producto para satisfacer la necesidad o el objetivo de un consumidor sobre un servicio.

El análisis de los requerimientos operativos de la empresa es una de las fases más importantes para que un proyecto tenga éxito evitando incidencias no contempladas, por lo tanto, la preparación adecuada de un requerimiento reduce los costos y los riesgos en la implementación del ERP.

Las especificaciones por parte del cliente al consultor son un proceso de levantamiento y análisis de requerimientos para realizar el mapeo de procesos actuales con el fin de generar la transición de información al nuevo ERP abordando a detalle los diferentes módulos y desarrollos a implementar como una propuesta en un documento de diseño.

Pero ¿cómo saber que es un buen requerimiento?, ¿cuál es el requerimiento?, ¿el requerimiento es funcional?, lo que pide el cliente y lo que propone el consultor ¿es lo mismo?, ¿cómo definir que el requerimiento en una implementación realmente es lo que se necesita? Este tipo de preguntas las iremos contestando desde el punto de vista “consultor” el cual de acuerdo con su expertis apoyará al cliente a identificar y definir un buen requerimiento.

Requerimiento, camino al despliegue del éxito

INTRODUCCIÓN

Los requerimientos tendrán dos puntos a tomar en cuenta, el requerimiento principal y los requerimientos para mejorar o modificar los que ya se había pedido en las peticiones originales.

Uno de los principales retos que enfrenta el consultor al trabajar con cliente al inicio del proyecto es “resistencia al cambio” de procesos y procedimientos por lo que no aceptan el mínimo detalle de la modificación del flujo operativo actual y los usuarios muestran rechazo hacia la herramienta.

Estos requerimientos se utilizan para determinar que hará el Software, definiendo las relaciones de su operación y su implementación, sin olvidar que deben ser explícitos también en lo que el sistema no debe hacer y que validaciones se deben realizar, teniendo en cuenta cual será el comportamiento del sistema.

Es común que los requerimientos de un proyecto de software no se expresen de manera clara ni se documenten de manera apropiada. Esto es porque muchas veces los usuarios requieren que su sistema funcione como el anterior si se tratara de migrar un sistema, pero las nuevas tecnologías a la que se migrará no siempre tienen estas bondades es por ello que los requerimientos son cambiantes de acuerdo a cada proyecto-cliente y el nivel del consultor-experiencia.

Entendemos “requerimiento” como la necesidad de que un sistema funcione de acuerdo con las especificaciones y asegunes que dicte el cliente ya que con él se desarrollará la solución y tiene un ciclo entre “usuario-consultor (técnico y funcional)” durante diferentes etapas (diseño, prototipación, validación, transición y ejecución con la satisfacción que el cliente requiere).

Para realizar con éxito la definición de los requerimientos es importante conseguir que sean claramente definidos para minimizar la ambigüedad, para esto es importante tener en cuenta lo siguiente:

• Definir los requerimientos teniendo en cuenta la información identificada con la perspectiva del usuario

• Reutilizar requerimientos, revisando proyectos ya finalizados para ver si contienen material potencialmente reutilizable. La ventaja de esta reusabilidad es que, una vez que un requisito ha sido especificado satisfactoriamente para un producto y que el producto ha tenido éxito, el requerimiento no tendrá que volverse a inventar, podrá ser utilizado las veces que se desee teniendo en cuenta los derechos de autor.

• Se debe documentar los requerimientos de una forma clara y correcta. En la mayoría de los proyectos se observa que la documentación de los requerimientos puede parecer una tarea tediosa, pero es la única manera de asegurar que la esencia de los requisitos ha sido capturada correctamente, y que esto pueda ser probado.

REQUERIMIENTOS

Los Requerimientos funcionales son los requerimientos que no se refieren directamente a las funciones específicas que entrega el sistema, sino a las propiedades emergentes de éste como la fiabilidad, la respuesta en el tiempo y la capacidad de almacenamiento.

Los requerimientos no funcionales surgen de la necesidad del usuario, debido a las restricciones en el presupuesto, a las herramientas utilizadas, a las políticas de la organización, a la necesidad de interoperabilidad con otros sistemas de software o hardware o a factores externos como los reglamentos de seguridad, las políticas de privacidad, etcétera.

Los Requerimientos funcionales se pueden dividir en dos puntos de vista: el primero tiene relación con el usuario, donde se identifica la relación del usuario con el sistema desde el punto de vista del mismo; El segundo tiene relación con el sistema dando respuesta al usuario, es decir desde el punto de vista de lo que realiza el sistema. Para tener claridad de la necesidad del cliente se debe realizar un levantamiento de requerimientos el cual consiste en aplicar una seria de preguntas acerca del módulo, desarrollo o herramienta (tanto de la que se utilice actualmente como de la funcionalidad esperada) con la finalidad de recabar información y tener el mayor contexto posible o entendimiento del problema para elaborar una propuesta de solución satisfactoria con base al expertis del consultor funcional tomando en cuenta todos los elementos que interactúen en la ejecución de la misma.

Requerimiento, camino al despliegue del éxito

Dicha propuesta de solución estará sujeta a cambios que pueda solicitar el usuario para verificar que se cumpla con el requerimiento planteado y a la validación-aprobación de esta para realizar la prototipación con base en la propuesta generada.

Para la verificación de requisitos se deben añadir criterios de aceptación por cada requisito, es importante asegurarse de que cada requisito cumple con los criterios asignados, este criterio es una medida del requisito que lo hace entendible y con capacidad de ser probado y se debe validar lo siguiente:

• El requerimiento cumpla con las necesidades del cliente

• El requerimiento sea necesario para el sistema y le de valor al producto

• El requerimiento no se encuentren palabras ambiguas

• El requerimiento sea probable y la información sea coherente

• El requerimiento no use palabras que lleven a confusión al escribir como “debería” ya que da a entender que el requerimiento es opcional

• Confirmar que los involucrados en el negocio tengan el mismo entendimiento acerca de los requisitos especificados

DEFINICIÓN DEL REQUERIMIENTO

CON MEJORAS DEL FUNCIONAL

Un requerimiento para un desarrollador es como una receta de cocina puesto que el funcional y el usuario ya tomaron la decisión de cómo debe de funcionar, su comportamiento, a diferentes entradas y las reacciones que debe de tomar ante posibles datos no especificados en el desarrollo y es aquí donde muchas veces hay discrepancias puesto que los documento que se entregan a la parte técnica son unas y lo que desean es otra por parte del cliente o funcional y esto se debe a que en algunas ocasiones no se tomaron el tiempo necesario para validar todos los escenarios por disposición del usuario.

En algunas ocasiones esto cambia no porque se haya tomado mal la especificación si no por que los usuarios tienden a cambiar lo que pensaron al principio pues necesitan agregan funcionalidades extras que podría mejorar el rendimiento o funcionamiento del desarrollo.

Esto puede ser para bien o para mal del desarrollo y el producto final porque muchas veces ya se están desarrollando la versión inicial y cambia de repente y ahora necesita que haga algo totalmente diferente.

Por eso y de acuerdo a lo que se tenga planeado y el tiempo estimado, se recomienda que la primera versión de requerimiento y los cambios sean llevados en un historial y que se tenga las firmas de aprobación de cada parte hasta llegar a desarrollo, ya que lo que se entrega como requerimiento es como se desarrollará y si el requerimiento no está bien

definido, no se tendrá lo esperado como resultado final y se tendrá que re trabajar, aumentando tiempos para la entrega y finalización.

Por eso haremos hincapié para la parte de desarrollo y en general para toda la parte de requerimientos en que la versión inicial debe estar firmada, aprobada y los cambios de igual manera, teniendo esto en cuenta los cambios se deben de realizar o dar a conocer después desplego la primera versión o antes de que inicie la construcción.

Reiterar que el equipo de desarrollo deberá pedir firmados estos cambios para poder realizarlo o hacer cambios, la razón es que en algunas ocasiones no se recuerda por parte funcional, el cliente o del equipo de desarrollo cuando y como se pidieron los cambios y el equipo de desarrollo realizan el cambio y después se tiene problemas porque no está documentado el cambio o por qué y quien pidió el cambio, esto es como parte de la recomendación por parte de desarrollo para poder tener el mejor creación y solución de los desarrollos y esto a su vez da del lado de cliente/funcional un mayor control de lo que se va realizando.

REQUERIMIENTO A

DESARROLLO

Lograr una comunicación efectiva entre los usuarios y el equipo de trabajo con el objetivo de llegar a un entendimiento de lo que hay que hacer es la clave del éxito en un proyecto.

¿Hay una manera de considerar lo mejor de cada enfoque y crear una estrategia que tome completas ventajas del software ERP a implementar? ¿Qué pasaría si se pudieran traer diferentes enfoques para complementar y elaborar progresivamente las necesidades del negocio?

El objetivo del enfoque combinado es aprovechar diferentes técnicas de proceso que pueden generar el mayor valor para que el equipo de proyecto (negocio) reúna las necesidades empresariales desde diferentes perspectivas que le permitan crear un conjunto de definiciones de requisitos globales. Estudiar detenidamente los procesos actuales que se llevan a cabo en toda la compañía con el fin de identificar las fallas, los errores y los problemas que existen en las operaciones, al igual que aquellas que se realizan adecuadamente y las áreas de oportunidad que existen actualmente.

Nos hacen concientizar de la importancia de tomar medidas necesarias sobre las fallas que se presentan en la implementación. El tamaño de este tipo de proyectos es muy grande, por lo que no se debe descuidar ningún punto, y es necesario proponer alguna metodología que ayude a controlar todos los aspectos de la implementación.

Requerimiento, camino al despliegue del éxito

• Realizar entrevistas y sesiones de trabajo con usuarios clave para estudiar los procesos actuales que se llevan a cabo en la compañía y los sistemas que los apoyan.

• Detectar junto con los usuarios clave las fallas tanto operacionales como de sistemas que existen en los procesos actuales.

• Detectar los síntomas de pobre desempeño que se presentan en los procesos actuales.

• Recopilar los requerimientos que tienen actualmente los usuarios al llevar a cabo sus tareas diarias.

• Identificar las áreas de oportunidad que existen en los procesos actuales.

Consecuencias por falta de ejecución de tareas clave:

• Fallas en el sistema integral por una mala ejecución de las pruebas.

• Errores en la generación de la información. • Falta de una completa ejecución de las pruebas ya que éstas no alcanzaron a realizarse dentro de los tiempos establecidos.

• Fracaso en la aceptación de los resultados de las pruebas por parte de los usuarios clave.

CÓMO FUNCIONA UN

REQUERIMIENTO

Se considera un cambio todo aquello que modifique las limitaciones iniciales del proyecto, las cuales deben estar claramente definidas en el plan del proyecto o en el contrato de proyectos, siendo lo más habitual la modificación del alcance o de costo (reducir el costo final por limitación del presupuesto).

En el caso de proyectos ejecutados de forma progresiva o por fases, también se considera un cambio una modificación en los puntos aceptados al final de la fase anterior, los cuales son el punto de partida y definen el trabajo a ser ejecutado durante la fase en curso, aunque teóricamente cualquier modificación de este tipo se consideraría un cambio, en la práctica solo se suelen tratar como tal aquellas modificaciones que impliquen un trabajo adicional significativo. Estos son debido a que en la práctica el director de proyectos también debe velar por la relación con el cliente más allá del proyecto, y tener un cierto criterio “comercial”.

La gestión de cambios en los proyectos debe ser una coordinación planificada de las actividades para lograr los objetivos, este proceso tiene una secuencia de pasos a seguir para poder definir cuáles serán los cambios que aplicarán al desarrollo o configuración del sistema como: análisis de la solicitud, valoración del cambio, análisis de modificaciones, documentación y aprobación de cambios.

Es importante realizar cada una de las actividades, la documentación deber ser clara, concisa y debe ser validada por las dos partes, el cliente y la empresa de desarrollo o configuración de software.

CAMBIOS DE REQUERIMIENTO

Y MANEJO

PUBLICADO EN 2020

Requerimiento, camino al despliegue del éxito

Si bien todos los pasos de un desarrollo de software son importantes, la definición de requerimientos debe ser uno de los pilares de cada proyecto y no importando el tiempo que se tome en definir estos, ya que este tiempo será de calidad para los pasos siguientes, entonces aquí es donde se debe dar más tiempo.

Entonces lo que debemos hacer es dedicarle tiempo, si bien en un principio pareciera tiempo perdido o poner demasiado tiempo en algo tan simple, cuando no es así, no debemos menospreciar esto, aunque el usuario sea el usuario clave y se sepa todo el flujo puede que omita pasos y se verá reflejado en el avance del proyecto, evitando trabajar doble, retrasos o volver a replantear los requerimientos.

Pero somos humanos y podemos tener errores y por eso el manejo de los cambios debe tener un orden establecido y que se debe cumplir de forma cabal para poder llevar a buen término el proyecto. Sabemos que será difícil el proceso de pasar por ciertos pasos burocráticos el cambio de un requerimiento o mejora, pero debemos tener en cuenta que este debe ser por el bien. En el paso de los requerimientos todos los involucrados deben poder tomar las mejores decisiones y apoyarse en este caso las 3 partes cliente, funcional y desarrollador.

La mejor forma de terminar de manera oportuna un proyecto es poder llevar a buen puerto la culminación de este con la satisfacción de que todos los requerimientos son lo que se esperaba y no se tuvieron tantos cambios y si hubo sean lo más claros y asertivos posibles. Por eso también debemos tener en cuenta la reunión de los involucrados todos los días para poder validar los requerimientos y si por alguna causa cambiaran, se trabajen en menor tiempo y no hasta que se culmine el desarrollo ya que así se podrá tomar las mejores decisiones para el proyecto y los requerimientos. Con base en lo anterior podemos concluir que llevar un seguimiento y tener clara la información que se necesite ayuda a que podamos cumplir con lo que se necesita y tener uno de los mejores resultados posibles.