project - trabajo - como presentar un proyecto pdf

¿Cómo entregar un proyecto sistemáticamente? (5)

Tenemos un proyecto entregado desde el equipo en tierra a nuestro equipo (en tierra) no hace mucho tiempo. Sin embargo estábamos teniendo dificultades para el proceso de entrega.

No pudimos pensar en ninguna pregunta que hacer durante su recorrido de diseño, porque estábamos abrumados por la gran cantidad de información. Queríamos preguntar, pero no sabíamos qué preguntar. Como no nos hicieron ninguna pregunta, la gerencia piensa que el proceso de entrega se realizó con éxito.
Intentamos revisar toda la documentación de la página wiki de nuestra compañía antes de asistir a la presentación de la entrega, pero hay demasiados documentos, ni siquiera sabemos por dónde empezar.

Me pregunto si existen reglas o mejores prácticas que podamos seguir para garantizar la entrega exitosa del proyecto, ya sea de nosotros o de nosotros.

Gracias.

Consulte "Requisitos de software" y Patrones de requisitos de software para obtener ideas sobre las preguntas que debe hacer al recopilar información sobre un proyecto. Creo que al igual que trabajarían para un nuevo desarrollo, también te ayudarían a llegar a un acuerdo con un proyecto existente.

En cuanto a la lectura de la documentación, personalmente iría por este pedido:

Obtenga una breve descripción general de la función básica de la aplicación: qué se pretende lograr. El caso de negocio es probablemente el mejor documento que ya existirá.
Luego la especificación funcional. En este punto, no estás tratando de entender ningún tipo de tecnología o cómo se hace la aplicación. Si es masivo, pregúnteles cuáles son los procesos comerciales clave y céntrese en ellos.
A continuación, la descripción técnica de alto nivel. Esto debería incluir un diagrama de arquitectura, plataformas requeridas, versiones, configuración, etc. Anote cualquier pregunta que tenga.
Luego, hojee cualquier otro documento técnico que parezca útil: sin duda, una pregunta frecuente, si la hay, los scripts de prueba también pueden ser buenos, ya que describen escenarios detallados de "cómo hacer" Tal vez sea solo yo pero encuentro que leer documentos técnicos antes de ver el sistema es un desperdicio, es demasiado académico y normalmente están escritos de manera sorprendente. Ciertamente es un área en la que limitaría el tiempo que pasaría si no sintiera que estaba obteniendo un rendimiento razonable por el tiempo que estaba gastando.

Si hay varios de ustedes, revise las revisiones estructuradas entre sí y discuta los documentos que ha leído, asegurándose de que tiene lo que necesita para salir de ella. Si el sistema es grande, entonces cada uno toma un área y se presenta a los demás, dense una razón para aprender lo más posible y saber que van a ser interrogados es un buen motivador. Haz una lista de preguntas donde no entiendas algo. Tener revisiones estructuradas entre usted enfocará su mente y la convertirá en una tarea más interactiva, en lugar de simplemente rastrear página tras página de un documento tedioso.

Una vez que te encuentres cara a cara con ellos:

Comience con una demostración del sistema completo. Haga preguntas a medida que surjan, no permita que lo engañen con respuestas confusas; si no pueden responder algo, escríbalo y pídales que obtengan la respuesta.
Ahora, compruebe y ejecute el código en sus máquinas. Haga esto en al menos dos máquinas: una que lideren, otra que usted dirija. Documentar todo el proceso - este es el paso más importante. Si no puedes poner en marcha el código estás jodido.
Ir a través del proceso de construcción. Asegúrese de que puede compilar la aplicación (incluidas las pruebas de creación y unidad automatizadas que puedan tener). Tenga en cuenta que todas las pruebas de unidad deberían pasar; si no lo hacen o si dicen "oh, ese siempre falla", entonces deben corregirlo antes de la aceptación final.
Ir a través del proceso de instalación. Haga esto por lo menos dos veces, una de ellas conducirá, una vez que usted dirija. Asegúrese de que está documentado.
Ahora cree un conjunto de funciones empresariales comunes realizadas con la aplicación. Usa esto para recorrer el código con ellos. El código base será demasiado grande para cubrir todo el asunto, pero asegúrese de cubrir una muestra representativa.
Si hay una base de datos o una API, haga un ejercicio similar. Cree algunos datos estándar que pueda necesitar extraer o algunas tareas básicas que necesite realizar utilizando la API y dedique un poco de tiempo a trabajar con ellos.
Pregúntales si hay algo que ellos piensen que debes saber.
Asegúrese de que todas las preguntas que haya escrito en cualquier otro lugar sean respondidas.
Puede considerar que vale la pena revisar la lista de errores (abierta y cerrada): comience con las de alta prioridad y comente cualquier aspecto particularmente preocupante. Incluso si lo han arreglado, puede apuntar a un poco de código que es problemático.
Y finalmente, si existe la oportunidad, si hay errores o cambios pendientes, vea si puede sincronizar un par de programas.

Finalmente, no acepte la aplicación a menos que esté 100% seguro de que puede:

Consigue el código para compilar
Obtener el código para construir (incluyendo la base de datos)
Instala la aplicación

No aceptar que la entrega esté completa hasta que tengan:

Documentó todo lo que recogió que no fue cubierto a su satisfacción
Respondió TODAS sus preguntas: una pregunta que no responderán después de que se le pregunte repetidamente grita algo que está ocultando

Y toma sus direcciones de correo electrónico y números de teléfono. Incluso si es solo informal, probablemente estarán dispuestos a ayudar si la mierda realmente golpea al fanático ...

Buena suerte.

La mayoría de las entregas, tal vez todas, harán que se pierda mucha información. La única forma efectiva de realizar una entrega que he visto es hacerlo gradualmente. Una forma de hacerlo es permitir que algunas personas clave de la Fase Uno permanezcan en el proyecto durante la Fase Dos.

La solución extrema es deshacerse de todos los traspasos y comenzar a utilizar una mentalidad ágil.

Mi proceso básico para recibir una entrega sería:

Obtenga una visión general de la aplicación, documéntela
Obtenga una lista de todos los trabajos futuros que el cliente espera
... todos los problemas conocidos
... cualquier especificacion de implementacion
Tanta documentación actualizada tienen
Si es posible, pídales que escriban algunas pruebas para los componentes críticos del sistema (o al menos que las documenten a fondo)

Si hay demasiada documentación (es posible), simplemente confirme que está todo actualizado y asegúrese de averiguar dónde comenzar, si no está claro.

Haga tantas preguntas como sea posible; cualquier cosa que se te ocurra, porque quizás no vuelvas a tener la oportunidad.

Para empezar, defina los criterios de salida para el traspaso. Esto debe ser discutido, negociado y acordado con ambas partes y asegurarse de que la administración superior lo sepa. Luego, escriba una lista de verificación de todas las cosas necesarias para alcanzar los criterios de salida y cójala.