Revisión de Cambios con cliente
Justificación
Antes de realizar algún cambio solicitado por el cliente es muy importante conocer si cumple realmente con el alcance esperado por el cliente, si cubre en su totalidad la necesidad presente, en función de esto se debe implementar un método que permita evitar ambigüedad en la solicitud, pese a la nimiedad del cambio se convierte en una prioridad primaria la transparencia de la actividad por realizar.
Visto de otra forma, el objetivo preciso inicialmente no es otra cosa que definir de forma clara e inequívoca el objetivo perseguido en ambas partes con el desarrollo y teniendo claro que las consecuencias marcarán la finalización con éxito de este y así mismo la satisfacción de las partes involucradas.
¿Qué se debe hacer antes de realizar la solicitud?
Aún cuando el cambio sea de urgencia es importante tomar tiempo para definir de forma escrita la actividad a realizar previo a su desarrollo, este método evitará pérdidas en el objetivo inicial durante el desarrollo.
En función de lo anteriormente expuesto, se establece el siguiente procedimiento que le ayudará a determinar el alcance de la solicitud:
Definición del Cliente
Definición de la Solicitud
Consiste en la información proporcionada por el cliente la misma debe ser sólida, consistente y exenta de subjetividades, es decir, ir en busca de la transparencia es la finalidad de esta fase que se convierte en un elemento nuclear para la preparación y la iniciación del desarrollo, en ella se deben recabar los siguientes datos:
Justificación: Basta con una breve descripción de la problemática presente, y en relación con las motivaciones que impulsan la causa del desarrollo.
Descripción del alcance de los entregables: Consiste en exponer las características de los resultados esperados del desarrollo, reportes, ventanas, validaciones y todo producto esperado posterior al desarrollo, adicional a ello se espera en esta etapa la precisión de los casos de usos presentes en el requerimiento, con la finalidad de cubrir la necesidad, la omisión de los mismo ocasionará desconocimiento al momento de plantear la solución propuesta y por consiguiente la ambigüedad en el desarrollo.
Asignación de tarea
Consiste en la asignación y notificación de la creación de la tarea a un supervisor de ERPyA para informar que la solicitud fue creada en el gestor de proyecto OpenProject, previo a este paso se asume un desconocimiento por parte de ERPyA de la definición del requerimiento.
Definición de la Solución de E.R.P. Consultores y Asociados, C.A
Verificación de Definición de la Solicitud
Para definir un desarrollo inicialmente es escencial conocer el alcance, esto dependerá de la optima Definición del Cliente, recordando que es el equivalente al objetivo del desarrollo, por lo que es necesario en esta etapa evaluar si la definición sigue el método SMART.
Ahora bien, ¿Qué significa esto?
S (Specific) – Específico: Tiene que estar claramente definida la solución sin ambigüedades
M (measurable) – Medible: Debe ser medible cuantificablemete en horas,permitiendo evaluar el avance y el tiempo estimado de entrega.
A (Achievable) – Alcanzable: La ambición de un desarrollo no debe ser mayor a la realidad existente, debe contemplar una forma que posibilite alcanzar el objetivo, alineado con una estrategia motivadora.
R (Relevant) – Relevante: Debe ser factible y razonable el logro con respecto a los recursos invertidos y plazos estimados.
T (Time-related) – A Tiempo: La estimación de tiempo debe ser limitada, con base en los resultados esperados, establecer una fecha límite permite evaluar el cumplimiento.
Para el cumpliento de la metodología y definición de objetivos inteligentes,se deben plantear las siguientes interrogantes para cada una de las cinco caracteristicas:
S (Specific) – Específico: ¿Qué quieres conseguir con el desarrollo?
M (measurable) – Medible: ¿Qué indicadores se pueden utilizar para medir su eficiencia?
A (Achievable) – Alcanzable: ¿Es razonable la meta?
R (Relevant) – Relevante: ¿Por qué le interesa al cliente?
T (Time-related) – A Tiempo: ¿Cuándo se tiene que conseguir esta meta?
Asignación de Responsabilidades
Posterior a la verificación del requerimiento, Verificación de la solicitud, es necesario asignar responsables para el seguimiento,modelado, ejecución y cumplimiento del desarrollo, para ello hemos pensado en una matriz RASCI ejecutada en el gestor de proyecto OpenProject, esta matríz asigna responsable del seguimiento del desarrollo, de esta forma se distribuirá responsabilidades entre los participantes del desarrollo, adicionalmente definiremos límites en el alcance.
R (Responsible) – Responsable: Persona responsable de su ejecución por parte de ERPyA, directamente, conjuntamente o supervisando al equipo.
A (Accountable) – Aprobador: Persona confirma la solución planteada para dar inicio al desarrollo, aprueba el resultado posterior al desarrollo y da por concluida la tarea una vez considera que los objetivos han sido alcanzados.
S (Support) – Soporte: Persona que da soporte durante la ejecución de la tarea aunque no necesariamente es responsable de ella.
C (Consulted) – Consultor: Persona que orienta en el modelado durante la ejecución de la tarea aunque no necesariamente participa en la ejecución.
I (Informed) – Informado: Persona que debe estar informada de los avances y ejecución de la tarea, aunque no necesariamente participa en la ejecución.
Cambiar el estado de la tarea
Cuando el cliente realiza un requerimiento en el gestor de proyecto OpenProject, por defecto el estado de la tarea previamente definida es creada con el estado inicial “En Espera”, sin embargo, el estado que indica al cliente que su requerimiento se encuentra en una siguiente fase dependerá del consultor que atiende el requerimiento, para ello el consultor de ERPyA está obligado a cambiar el estado actual, En Espera al estado Por Definir.
El estado en cuestión denota al cliente que su solicitud se encuentra en la fase de modelado que le brindará posteriormente una solución estimada, este proceso de definición por parte de ERPyA tiene una duración no mayor de 32 horas hábiles, previendo la definición de un proceso complejo y tomando en cuenta las prioridades o urgencias del cliente.
Es importante acotar, el estado Por Definir se mantendrá durante el proceso de aprobación del cliente, el tiempo que demore el cliente en dar respuesta de aprobación ó rechazo de la propuesta no será imputada en la demora de la entrega.
Asignación de tarea
El responsable de ERPyA, gestor del proyecto debe asignar la tarea al departamento pertinente, para transferir la tarea a la siguiente etapa, en la cual se procederá a modelar la solución del requerimiento.
Definición de la Solución
Esta etapa como lo indica su nombre consiste en definir con una redacción clara, específica y entendible para el cliente el alcance de la solución desde la perspectiva de ERPyA.
Este es el método que utilizamos cuando redactamos una oferta, la misma se encuentra muy vinculada a una RFQ (Request For Quotation), que no es más que una solicitud de información, proceso empresarial estándar donde el propósito es recabar información escrita referente a una cotización.
Es importante describir el alcance del desarrollo mediante palabras concisas y directas, asegurándose que el documento generado contenga todos los puntos para que el objetivo pueda ser considerado SMART.
Al realizar la redacción es importante incluir lo que forma parte del alcance con bases en el requerimiento del cliente, esto dependerá de la optima Definición del Cliente, los puntos no considerados en la redacción no serán contemplados en el desarrollo de la solución.
Explicar la funcionalidad a Desarrollar
Describa la funcionalidad a desarrollar incluyendo cualquier información de interés como:
Sistema Operativo donde funcionará.
Cómo se puede visualizar el cambio después de aplicarlo.
Aspectos importantes que se deben considerar: Si es algo estrictamente necesario o si solo es una mejora de baja prioridad.
Aclarar las implicaciones que tendrá el cambio
Debe ser específico en este punto ya que es muy importante que el cliente entienda qué implicaciones tendrá el cambio solicitado. Un ejemplo de esto puede ser la solicitud de una funcionalidad específica en la que sólo aplicará para un cliente y no se podrá escalar.
Solicitud de confirmación del cliente
Posterior a la definición de la propuesta por parte de Soporte, Definición de la Solución por parte del responsable de ERPyA, la tarea debe ser asignada al aprobador por parte del cliente, esperando del mismo la aprobación de la solución planteada ó rechazo de la misma:
Aprobación
Soporte: El Soporte solicitará en un comentario la aprobación de la tarea mediante un comentario realizando una pregunta concreta:
¿Está de acuerdo con el cambio propuesto?
Asigna la tarea al Aprobador.
Aprobador: El aprobador responderá la tarea aprobando la solución planteada con una respuesta concreta:
Estoy de acuerdo con el cambio propuesto
Caso contrario, no será válida la aprobación del cambio, en consecuencia no iniciará el desarrollo hasta no aprobar siguiendo el protocolo.
Rechazo
Soporte: El Soporte solicitará en un comentario la aprobación de la tarea mediante un comentario realizando una pregunta concreta:
¿Está de acuerdo con el cambio propuesto?
Asigna la tarea al Aprobador.
Aprobador: El aprobador responderá la tarea rechazando la solución planteada, indicando la causa por la cual no es válida, en tal sentido será necesaria la especificación o de ser necesaria la redefinición del requerimiento, preveendo la transparencia del mismo, este caso conlleva a la re-definición de la propuesta por parte de Soporte, Definición de la Solución, volviendo a iterar en el proceso de definición hasta conseguir la aprobación que da paso a la siguiente etapa.
Inicio del desarrollo
Definición de fecha de inicio
Únicamente despúes de tener la aprobación del cliente Aprobación comienza la etapa en la cual se estiman tiempos a partir del objetivo y de los recursos necesarios y disponibles, estableciendo una duración a cada tarea, pautando una fecha de inicio y fecha de vencimiento, este proceso al igual que todos los anterior dependen en gran manera del detalle y la calidad de la información de la que se disponga.
Cambiar el estado de la tarea
Cuando el cliente haya aprobado la solución planteada en el gestor de proyecto OpenProject y posteriormente la tarea se encuentra en la fase previa al desarrollo, Inicio del desarrollo, el responsable de ERPyA está obligado a cambiar el estado actual, Por Definir al estado En Espera (Técnico).