Alcance

¿Cuándo deben estar listas las especificaciones de una tarea?

• Las especificaciones se realizan en paralelo al desarrollo y se tienen justo a tiempo para dar inicio a cada hito del proyecto.

• Las especificaciones se realizan en conjunto con el desarrollador una vez que ha comenzado el proyecto.

• Las especificaciones deben realizarse antes de comenzar el desarrollo proyecto, para que puedan ser revisadas por el equipo anticipadamente.

• Las especificaciones se deben realizar desde el primer contacto comercial con el cliente.

Las especificaciones incluyen:

• La forma en la que el equipo de desarrollo debe trabajar y los criterios de aceptación del cliente.
• Las necesidades del cliente y como administra la funcionalidad o requerimiento.
• El contexto, los requerimientos funcionales y no funcionales, los criterios de aceptación
• Los requerimientos del cliente, los casos de uso, el cronograma.

Los requerimientos en una especificacion deben indicar:

• Lo que se espera que haga el desarrollo, el porqué debe realizarse de esa forma, los criterios de aceptación y como pueden validarse.

• El comportamiento esperado para los usuarios del sitio o aplicación.

• El presupuesto estimado para cubrir la necesidad del cliente.

• Los casos de prueba asociados a la necesidad y los costos del desarrollo.

Entendiendo el alcance del proyecto como el conjunto de procesos necesarios para dar por finalizado un proyecto con las funcionalidades y caracteristicas esperadas. El project manager para entender el alcance del proyecto debe:

• Distribuir los recursos adecuadamente y garantizar que se responde a la necesidad del cliente.
• Garantizar que los resultados responden a los requerimientos del cliente. Definir hitos y tiempos de entrega. Determinar los mínimos de calidad para garantizar la satisfacción del cliente.
• Definir los limites y restricciones del proyecto, y completar las especificaciones.
• Establecer el cronograma, garantizar que el diseño se ajusta a las especificaciones y controlar los costos.

¿Que se debe hacer cuando los recursos no pueden soportar la carga de un proyecto?

• Solicitar a la PMO un desarrollador de apoyo adicional para comprimir el planning.
• Escribir al director de proyectos para que consiga recursos extras que pueden ayudar a ir más rapido y entregar el proyecto a tiempo.
• Detener el desarrollo y alertar al cliente que no podremos continuar porque no hay recursos.
• Hacer uso eficiente de los recursos disponibles, hacer un analisis de costo y recursos disponibles y solicitados, presentarlos a la PMO y mostrar el plan de gestion del cronograma, ya sea nivelación, compresión o fast tracking.

Es inevitable en todo proyecto que surjan cambios en el curso del desarrollo ¿Cómo controla usted la gestión de cambios del alcance de un proyecto?

• Siempre que haya un cambio en el curso de desarrollo usted solicita un desarrollador adicional para poder responder a los cambios sin afectar su cronograma.

• Realiza una revisión de requisitos que están incluidos en el proyecto y que fueron planificados y si el cambio que el cliente solicita no se encuentra dentro de estos limites, informa al cliente que no podrá realizarlo.

• Realiza una revisión de las especificaciones iniciales y de los desarrolladores disponibles, y si tiene el tiempo realiza todos los cambios que el cliente solicite.

• Revisa los requisitos que pueden estar incluidos en el proyecto, y para aquellos requisitos no contemplados en el inicio usted analiza cuales son necesarios para la primera entrega, y para aquello que no sea necesario lo propone al cliente como mejora para fases posteriores.

Para garantizar la calidad del entregable final al cliente se requiere:

• a) Garantizar la planeacion de lotes/tareas que responder a la funcionalidad esperada. b) Verficacion de loter/tareas por el PM. c) Verificacion de lotes/tareas por el QA. d) Revalidacion final de QA sobre los bugs inicialmente encontrados.
• a) Garantizar los recursos necesarios para cubrir el planning. b) Verificar accesos a aplicaciones o servidores. c) Verificar el entregable. d) Enviar demos al cliente en diferentes hitos del proyecto.
• a) Garantizar la planeacion de lotes/tareas que respondan a la funcionalidad. b) Garantizar que el tiempo consumido respeta la planeacion inicial. c) Hacer análisis de costos. d) Validación del PM y QA.
• a) Garantizar que el tiempo consumido respeta la planeacion inicial. b) Informar de los movimientos de planning al cliente cuando es necesario. c) Realizar compresiones del planning para lograr entregables más rápido. d) Enviar demos al cliente. e) Validaciones de QA.

Los casos de prueba que realiza QA:

• Deben estar acordes al alcance delimitado en las especificaciones, pero si el equipo encuentra elementos o funcionalidades que pueden ser mejor para el cliente, a pesar de que aumente el tiempo inicialmente estimado, deben añadirse.
• Deben contener el conjunto de acciones ejecutadas para autenticar la funcionalidad, diseño, configuración de una aplicación de software, y estan basadas en las especificaciones y requerimientos del cliente.
• Deben construirse en conjunto entre PM y QA una vez que el desarrollador reporta que a terminado el trabajo y el LT ha revisado el código.
• Deben ser construidos con anticipacion a la entrega del desarrollo y estan basados en el devis inicial y la revision de wireframes, una vez que el PM confirma que tiene los elementos e informacion completa para realizar especificaciones finales.

Si usted realiza el entregable final del proyecto o tarea al cliente, y el cliente le reporta bugs que no estan definidos en el diseño pero que a simple vista afectan el flujo de compra del sitio, usted:

• Considera que como no esta escrito en la especificacion entonces no es algo que deba corregir el equipo, puesto que el cliente le validó la especificacion por correo o slack o monday.
• Considera que aunque no este explicito en la especificacion si el flujo de compra se ve afectado y el sitio no es funcional, es algo que el equipo debe corregir para garantizar la satisfacción del cliente, y entregables de calidad.
• Le informa al cliente que puede corregirlo pero que eso implica cobrarle una evolucion adicional.
• Revisa con el equipo de QA para validar que falló en las pruebas, deja feedback a todo el equipo y procede a programar las correcciones necesarias aunque no este explicito en la especificación, pues el sitio debe como mínimo ser funcional en todo el flujo de compra.

¿Cómo debe el PM organizar las tareas para poder iniciar el desarrollo? Desde la confirmación comercial del lanzamiento del proyecto hasta el inicio del desarrollo.

• a) Revisar los documentos iniciales entregados por el comercial (letra de mision, brief, devis incial). b) Dar inicio al planning en Monday (creacion de actividades y subactividades). c) Enviar elementos graficos al diseñador para iniciar Wireframes d) Hacer especificaciones. e) Hacer el kick off con el equipo de trabajo. f) Realizar reunion de lanzamiento con el cliente.

• a) Revisar los documentos iniciales entregados por el comercial (letra de mision, brief, devis incial). b) Revision de riesgos y entendimiento del scope. c) Organizar la planeación en Monday (creacion de actividades y subactividades). d) Completar especificaciones posibles y solicitar estimaciones al LT. e) En paralelo trabajar con el diseñador para iniciar Wireframes y diseño. f) Garantizar que el diseño se alinea con las especificaciones. g) Refinar especificaciones y estimaciones. h) Organizar el cronograma, definir fechas para los entregables de cada hito del proyecto. i) Hacer el kick off con el equipo de trabajo.

• a) Revisar los documentos iniciales entregados por el comercial (letra de mision, brief, devis incial). b) Dar inicio al planning en Monday (creacion de actividades y subactividades). c) Estimar con el LT. d) Enviar elementos graficos al diseñador para iniciar Wireframes. e) Programar los dailys. f) Hacer kick off y seguimiento al desarrollador.

• a) Creacion del planning y cronograma en Monday (creacion de actividades y subactividades). b) Revision y entendimiento del scope con la lectura de la letra de mision o devis inicial. c) Solicitar la realizacion de figma. d) Empezar a documentar las especificaciones y requisitos funcionales. e) Garantizar que las especificaciones sean lo más claras posibles y refinar si es necesario. f) Programar los dailys y hacer el lanzamiento del proyecto con los desarrolladores.