2010-06-24 24 views
10

Somos una empresa pequeña (15 personas) de desarrollo web/diseño con alrededor de 8 desarrolladores LAMP a tiempo completo. Para reducir la cantidad de errores que cometemos y evitar que nuestros presupuestos superen nuestras estimaciones, introduje algún tipo de análisis técnico de nuestros proyectos antes de que comience el desarrollo. Esto no es pan comido para un desarrollador de aplicaciones, pero en nuestro sector (webdev) parece ser una práctica menos común. Hasta ahora solo recibimos un pequeño resumen de nuestro gerente de proyecto ensamblado (a menudo menos de una página) y saltamos de cabeza al desarrollo con algunas fallas presupuestarias catastróficas como resultado.Cómo escribir un proyecto ¿Análisis o resumen del proyecto?

Para abordar este problema, comencé a leer sobre el tema, leí CodeComplete2, Programador Pragmático y The Mythical Man-month. Creo que aproveché los conceptos que hay detrás de la preparación y el análisis de un nuevo proyecto, pero me faltan ejemplos prácticos. ¿Alguien sabe de un ejemplo de análisis técnico o un extenso resumen del proyecto que puedo ver para poner mejor las cosas que he leído para practicar? Soy un gran admirador de aprender-por-ejemplo, no es necesario decir eso :)

Respuesta

17

Desafortunadamente, la mayoría de los documentos de alcance del proyecto están protegidos comercialmente por lo que no se pueden publicar, sin embargo, me complace acumular mi experiencia de lo que hace una buena y he incluido el tipo de cosas que espero ver.

Lo principal que debe recordar es lo que está tratando de lograr: está tratando de lograr un entendimiento común entre usted y el cliente sobre lo que está sucediendo. Las estimaciones erróneas no solo se refieren a la diferencia entre lo que creía que iba a tomar y lo que realmente implicaba, sino también sobre lo que pensaba que iba a entregar y lo que el cliente pensó que iba a ofrecer.

Una forma de ver documentar todo esto es que esté cubierto y si el cliente regresa y dice "¿dónde está el módulo de informes?", Puede señalar la frase que dice "no habrá módulo de informes" pero eso no es realmente así. Se trata de tener esa conversación al principio (donde puede ser constructiva) en lugar de al final (donde es probable que sea de confrontación). Recuerde esto si su proyecto o gerente de cuenta comienza a quedarse, ya que demasiados detalles suenan negativos.

Así que, ¿qué debe incluir:

  • descripción de alto nivel de lo que se está haciendo - sólo un par de párrafos. Realmente no va a proporcionar ningún detalle, pero establece la escena.En esta sección, dice que está creando un sitio de comercio electrónico para vender widgets, que es un sitio B2C en lugar de B2B, que el proyecto abarca el diseño y la construcción completos del sitio, y así sucesivamente. Un par de párrafos como máximo.

  • Requisitos funcionales de alto nivel: viñetas que describen las principales características que se construirán/diseñarán. Para cada entidad de datos incluida, ya sea crear, leer, actualizar y eliminar, esto le ayudará a comprender mejor la tarea. Incluya la capacidad de crear/leer/actualizar/eliminar usuarios, la capacidad de crear, leer y actualizar pedidos, la capacidad de crear/leer/actualizar/eliminar categorías de productos, la capacidad de crear/leer/actualizar/eliminar productos, incluido el texto , imágenes y video.

  • Requisitos no funcionales: otra área donde se pierden muchas cosas. Los requisitos no funcionales incluyen aspectos como rendimiento, carga del usuario, auditoría, archivo, seguridad, etc. Los informes pueden encajar aquí; aunque es realmente funcional, es algo que se olvida, ya que a menudo es algo que respalda el uso del sistema en lugar de ser una parte central de él. Si no está haciendo algo en un área dada (p. Ej., No habrá pistas de auditoría), explíquelo con claridad, quizás en otra sección llamada ...

  • Fuera de alcance: las cosas surgirán durante las discusiones sobre si algo (un poco de funcionalidad, una interfaz a otro sistema) está o no incluido. ¡Escribe esto! Una de las áreas clave donde el alcance falla en mi experiencia es que los diferentes recuerdos de estas conversaciones y obtenerlo en papel por adelantado se deshace o mucho de eso. Esta es otra área donde los informes pueden llegar (sabrán que quieren informes, pero no por lo que se mueve y entregará y preguntan dónde están), sino también la administración de usuarios (¿restablecimiento de contraseña?) Y la seguridad.

  • Suposiciones: en este punto del proyecto, no tendrá la información suficiente para llegar a una estimación realmente precisa. Está bien, puedes llenar los vacíos, siempre y cuando dejas en claro que esto es lo que has hecho. Entonces, si está asumiendo que le están entregando plantillas corporativas para diseñar las cosas, anótelas. Si crees que están proporcionando la copia y las imágenes para todo, de nuevo escríbelo.

Otras secciones que consideraría incluyendo:

  • plataforma técnico - si usted piensa que es importante describir la plataforma técnica en un nivel alto (en este caso lámpara, además de los otros bits). En mi experiencia, este no es un área donde realmente existe el credo de alcance, pero suele durar dos minutos, por lo que no puede perjudicar.

  • Interfaces con otros sistemas - En mi experiencia, una de las cosas que agrega complejidad a cualquier proyecto son cosas sobre las cuales no tiene control total, y una de las áreas clave que esto sucede son las interfaces con otros sistemas. Cuando se trata de estos, siempre es mejor enumerar los sistemas, el tipo de interfaz y las interacciones que se llevarán a cabo. Por lo tanto, si está actualizando su sistema de stock, digamos que es así, digamos que es un servicio web, diga que va a disparar consultas de stock, actualizar los niveles de stock, etc.

  • Dependencias - Nuevamente, esto es parte de lo que está fuera de su control. Si hay otras partes que contribuyen al proyecto (incluido el cliente), puede ser mejor enumerar lo que está esperando de ellos. ¿Quién proporciona la copia, en qué formato (es un archivo de Excel bien estructurado que se puede importar fácilmente o un millón de documentos de Word)? ¿Qué tal un sistema de prueba para la aplicación de terceros con la que se espera que interactúes? ¿Cuándo necesitas estas cosas?

Espero que esto ayude.

Editar: He desenterrado y ligeramente anonimizado un par de plantillas que utilicé en mi último trabajo. Son internos (es decir, éramos un equipo interno que hacía un trabajo dentro de la empresa en lugar de un equipo que trabajaba para otras organizaciones), pero la estructura y los principios son los mismos.

He incluido una plantilla mandato proyecto que está bastante cerca de la clase de documento que desea:

http://seventeensix.tumblr.com/post/749062608/a-sample-project-mandate-template

y una plantilla de especificación que también podría tener algunos bits usted encontrará útil:

http://seventeensix.tumblr.com/post/749077647/a-sample-specification-template

El mandato proyecto uno contiene algunas muestras reales de uno de los proyectos allí (un paquete de conciliación sistemas financieros muy tedioso), tanto contiene estructura y puntero en cuanto a qué va con el extraño ejemplo.

+0

Muy útil, de hecho enumera muchas de mis suposiciones y agrega alguna información útil que incluiré en mi próximo análisis/resumen. Era consciente de que probablemente la mayoría de los análisis están protegidos/privados, pero esperaba que alguien fuera tan amigable para compartir los suyos :) De todos modos ... esta publicación es ciertamente útil y un paso en la dirección correcta. ¿Quizás tengas un esquema de muestra o una tabla de contenido de un informe/análisis, que también podría ser útil :) ¿O estoy pidiendo demasiado? – ChrisR

+1

He pegado un par de plantillas que he usado en el pasado en Tumblr (enlaces en la respuesta principal). Lo siento, el formato se ha torcido un poco, pero espero que sea útil. –

+0

Hola John, ¿aún tienes las dos descargas que publicaste en tu respuesta todavía disponible en línea en alguna parte? Los enlaces parecen estar muertos. – ChrisR

1

Esos son buenos libros. También podría sugerir agregar "Requisitos de software 2" y "Peopleware: Proyectos productivos y equipos" (todavía no he leído Peopleware; está en mi lista de tareas todo el tiempo, me temo)

Pero yo Me temo que no hay sustituto para la experiencia; si prestas atención a lo que tu equipo ha citado en el pasado, lo que realmente se necesita para entregar, y tratas de encontrar las razones por las que estabas en lo correcto o incorrecto para las piezas en las que tenías razón o equivocas, aprenderás a ser mejor.

En mi experiencia, nunca está de más intentar descomponer el gran problema en problemas más pequeños. Iterar. Cuando piensas que finalmente tienes piezas que te llevarán de .5 a 1 programador por día, entonces estás llegando al punto en el que he tenido el mejor éxito al estimar el tiempo.

Por supuesto, debe tener en cuenta los programadores que trabajan para usted: Alice podría codificar una solución que se pueda enviar en medio día, Bob podría tomar un día, y Charlie podría tardar dos días en llegar, con una hora desde Bob para la revisión del código. Conocer las fortalezas y debilidades de su programador también le llevará experiencia.

+1

Peopleware es un buen libro, pero no ayudará con esto. De hecho, iría con Rapid Development de Steve McConnell; piense en Code Complete para Project Managers. –

Cuestiones relacionadas