...
- Si la tarificación es basal, tras poner fechas, la tarea pasa al estado PDTE. COMENZAR RESOLUCIÓN. En este estado es factible por parte del Responsable de proyecto poder modificar esas fechas una vez que se tenga una foto de todo el trabajo a planificar.
- Si la tarificación es Valor añadido, al hacer esa acción la tarea pasa a estado CALENDARIZADA donde el Responsable del Contrato aprobará o no la estimación de la tarea. Si no aprueba la estimación, la tarea deberá ser de nuevo estimada por el Proveedor. Una vez aprobada, pasará a estado PDTE. COMENZAR RESOLUCIÓN.
Cuando la tarea está en PDTE. COMENZAR RESOLUCIÓN en en ese estado está planificada en fechas y en teoría no deberían modificarse éstas. Ahora bien, en ese estado el Responsable de Sistemas, el de Puesto Usuario o el del proyecto concreto podrán modificar esas fechas consensuándolas con el Proveedor, fundamentalmente porque puede haber cambio en las prioridades y sea necesario una replanificación del trabajo pendiente.
Cuando el Proveedor comienza a resolver la tarea, puede asignar un técnico que será visible (selección a través de un desplegable con los miembros del proyecto que el Proveedor hayan configurado),
la tarea pasa al estado EN RESOLUCIÓN. En este estado, el Proveedor podrá incurrir esfuerzo, indicando el restante. Si durante este estado, hay algún motivo que bloquee la tarea pasará a estado PARALIZADA.
Si una tarea que se está ejecutando tiene que ser cancelada por parte del Responsable del proyecto, entra en un circuito en el que se intenta que el Proveedor liquide el esfuerzo que llevara hasta ese momento y el grado de avance técnico (estado PDTE. CANCELACIÓN). Esta liquidación que hace el Proveedor debe ser validada por el Responsable del proyecto. Dicha acción se realiza cuando la tarea está en estado PDTE. REVISIÓN CANCELACIÓN
...
indicar el técnico o los técnicos que van a hacerse cargo del trabajo. La lista de técnicos del proveedor se configura en la opción "Miembros del proyecto". Es importante indicar los técnico fundamentalmente porque de esta forma garantizamos que si la tarea tiene alguna modificación (se cambia algún campo, se pone un comentario, se edita un comentario, se adjunta un archivo, etc. ) el técnico indicado recibirá una notificación en su correo electrónico.
Cuando el proveedor está resolviendo la tarea pueden darse cuatro casos:
- Que la tarea se desarrolle como se había planificado. El proveedor incurre el esfuerzo (si es de tarificación basal) o el coste (si es de tarificación valor añadido) y resuelve la tarea. Puede ocurrir que exista una desviación (positiva o negativa) respecto a la fecha fin indicada. El proveedor al resolver debería justificar esa desviación.
- Que la tarea se bloquee y no pueda seguir su curso hasta que ese motivo que la bloquea desaparezca. En ese caso, la tarea deberá paralizarse e informarse una fecha prevista de reanudación de la misma.
- Que la tarea cambie las condiciones en las que se había planificado, bien porque pueda haber un cambio de prioridades y que haya algo más urgente o bien porque la tarea se haya complicado más de los previsto. En cualquier caso, el proveedor sabe que no va a poder cumplir con la fecha fin indicada. En estos casos accediendo a la acción Seguimiento podrá indicar en el momento en el que la planificación de la tarea cambia, cuál es la Fecha Fin Actualizada y el grado de avance técnico que lleva n la tarea en ese momento. A partir de ahí será esa fecha la que marque la posible desviación respecto a la fecha real en la que el proveedor resuelva la tarea.
- Que la tarea tenga que cancelarse por cualquier motivo. Siempre será cancelada por el Responsable del proyecto. En estos casos la tarea entra en un circuito en el que se intenta que el Proveedor liquide el esfuerzo que llevara hasta ese momento y el grado de avance técnico (estado PDTE. CANCELACIÓN). Esta liquidación que hace el Proveedor debe ser validada por el Responsable del proyecto. Dicha acción se realiza cuando la tarea está en estado PDTE. REVISIÓN CANCELACIÓN
Una vez que el Proveedor ha terminado su trabajo, la tarea pasa al estado PDTE. REVISIÓN TÉCNICA donde el peticionario de la misma si es quien la ha creado o quien indique el Proveedor si es quien a crea, debe aceptar o no la solución
- Si el peticionario no acepta la solución, la tarea pasará al estado NO ACEPTADA con objeto de que el Proveedor vuelva a trabajar en ella y, una vez que la haya acabado pase a PDTE. REVISIÓN TÉCNICA de nuevo. Destacar que la fecha que se marca como de resolución de la tarea por parte del proveedor es la fecha en la que ha hecho las correcciones que se le han indicado al no aceptar la solución técnica.
- Si el peticionario acepta la solución, la tarea pasará a estado CERRADA si su tarificación es basal. Si la tarificación es valor añadido pasará a la revisión de costes, donde el Responsable del contrato deberá comparar los costes en HBS incurridos con los registrados en la estimación aprobada de la tarea. En el caso en que no aprobara los costes, la tarea volvería a NO ACEPTADA para que el Proveedor corrigiera los costes. Una vez corregidos, pasaría de nuevo directamente a que se revisaran los costes por parte del Responsable del contrato.
Si el peticionario no acepta la solución, la tarea pasará al estado NO ACEPTADA con objeto de que el Proveedor vuelva a trabajar en ella y, una vez que la haya acabado pase a PDTE. REVISIÓN TÉCNICA de nuevo
...
Las tareas de seguridad se detallan en el proceso de evaluación de seguridad.
Hay que indicar que hay veces en las que ciertas implantaciones no tienen entidad suficiente ni recorrido para ser un proyectos. En estos casos se crean tareas generales o con validación para la implantación y subtareas de seguridad que funcionan como una especie de asesoría para estos casos.
...