Ver Mensaje Individual
  #10  
Antiguo 31-07-2007
Avatar de Delphius
[Delphius] Delphius is offline
Miembro Premium
 
Registrado: jul 2004
Ubicación: Salta, Argentina
Posts: 5.582
Reputación: 28
Delphius Va camino a la fama
Hola david_uh,
Escapando un poco el lado tecnológico de tu proyecto. Y yo siendo defensor de los principios y buenas prácticas de la ingeniería, te aconsejo.

1. Hacer reconocimiento de campo y del negocio. Empapate de la magnitud de la empresa. Conoce al personal que hará uso del sistema y no simplemente al jefe.
2. Una vez dimensionado el ambiente, haz no sólo charlas informales y formales con cada persona que intervenga, preguntale cosas directas. Si es posible busca encontrar alguna restricción tecnico/operativa (hasta legal). A veces, una pregunta del tipo ¿Usted es el más capacitado para responderme? puede salvarte el proyecto. Hablar con la persona más adónea sobre cada parte "sencible" es muy aconsejable. Son quienes dicen: "Esto es así. Esto NO. Esto me gusta... esto no me gusta"
3. Estima el tamaño del proyecto sabiendo ya de antenamo los requisitos. Este es todo un mundo... Es común ver que el cliente se imagina pantallas... que "hace esto, y aquello" y al momento de decirtelo no saben darlo a conocer. Es bueno en ocasiones dirigir al cliente hacia preguntas más específicas. Yo en una oportunidad (que quisiera olvidar. Mi primer "cliente" y no aceptó el precio. Cuidado con este punto) tuve que ir trayendo al usuario que estaba en las nubes. ¡Se me fue de las ramas! En cuanto el usuario pierde la noción de lo que habla es porque NO SABE LO QUE QUIERE, no es la persona adecuada para evacuar tus dudas (y a quien le "encajaron" el mando y dirección del proyecto).

Análisis, y análisis... Pon mucho esfuerzo en el análisis (1). Con aquella primera visión del "mundo" hazte unos diagramas (ya sea UML si trabajas en OO, o estructurado... el que gustes). La idea es que tengas algo visual que te diga ya, en una primera etapa, donde pueden haber problemas.

(1) Mamx, si... ya se.... existen otras posturas EXTREMAS. Pero yo defiendo el análisis

Ha sabiendas del tamaño y de algunos requisitos, recién arma un plan de trabajo:
1. Cronograma de actividades. Debe reflejar la relación inversión/beneficios, la capacidad de la mano de obra y la misma presión del mercado (puede incluso que la fecha sea inamovible!). Y por supuesto, todo montado en un esquema de trabajo que sea acorde a tu experiencia y la capacidad de absorción de los riesgos.

Por lo general:
USDP/RUP: para proyectos grandes. Muy sencible a los riesgos tecnológicos y para fechas cercanas e innamovibles. Tiene una conducta agresiva frente a al riesgo: trabaja amoldandose a los riesgos. Los enfrenta de menor a mayor.
Espiral: Para aquellos proyectos del tipo "actualización" y moderadamente sencibles a los riesgos y restricciones. Por lo general se para el trabajo en cuanto los riesgos superan a la capacidad de trabajo.
Prototipados: para proyectos sencillos. Y que requieren llevarse en corto o mediano plazo. Util cuando el cliente no sabe totalmente lo que quiere.
Cascada. El clásico: proyectos del tipo "habitual". Para aquellos requisitos ya impuestos o que se saben que no van a cambiar (o muy poco probables que cambien).

Aunque, puede ser útil en algunos casos (el mio por ejemplo) que hacen un "mix" (mexcla) de estos paradigmas.

2. Listado de aquellos riesgos más importantes y restricciones técnicas. Imponer dentro del cronograma de actividades, un tiempo para el control y chequeo de avances. Esto debería indicarte que tan próximo o lejano están los riesgos de producirse.
3. Armar un plan de contingencia. Recordar que estos planes están fuera del alcance del programa. Un error común (a mi me pasó) es contemplar este plan dentro del marco de trabajo habitual. Cuando un riesgo se produce, se sale el proyecto de su cauce (y esto lo estoy viviendo ahora con mi tesis ) normal. Un cronograma de actividades no debe incluir el tiempo "por si las". Debe ser un esquema de EXITO.
4. Imponer un marco de trabajo: Control de cambios. ¡Por favor Nunca dejar de documentar! (este si dentro del plan común de trabajo). Tanto la que te sirva a vos como la que le puede ser útil al cliente (Según el contrato, puede que tu debas dar informes de avance del proyecto)

Bueno... eso es todo lo que recuerdo... se que se me están escapando algunas cosas. En cuanto las recuerde, las pongo.

EDITO Y AGREGO.
Con el tema de costos, creo que otros ya te dieron una respuesta más profesional. Yo al menos la vengo haciendo de esta forma.

Saludos,
__________________
Delphius
[Guia de estilo][Buscar]

Última edición por Delphius fecha: 31-07-2007 a las 02:54:44.
Responder Con Cita