Embed Size (px)
Citation preview
1
ADMINISTRACIÓN DE
PROYECTOS DE
COMERCIO ELECTRÓNICO
ALEJANDRO DOMÍNGUEZ
Notas parciales de clase (abril de 2000) basadas en los libros:
McConnell, Steve. Rapid development. Microsoft Press. USA, 1996
McConnell, Steve. Software project survival guide. Microsoft Press. USA, 1998
2
CONTENIDO
• Estrategia para el desarrollo de proyectos
• Errores clásicos
• Aspectos fundamentales en el desarrollo de
proyectos
• Riesgos en el desarrollo de proyectos
• Desarrollo rápido de proyectos
• Supervivencia en el desarrollo de proyectos
3
ESTRATEGIA PARA EL
DESARROLLO DE
PROYECTOS
4
El desarrollo de proyectos
• Modelo conceptual
Conjunto de todos los métodos para desarrollar proyectos
Métodos eficaces
Métodos orientadas a la planificación
Conjunto de métodos utilizados en algún
proyecto determinado
Métodos ineficaces
5
Clases de métodos planificados
Métodos orientados a la planificación
Métodos orientados a la
velocidad
Métodos orientados a la planificación de
riesgos
Métodos orientados a la visibilidad
6
Estrategia para el desarrollo de
proyectos
• Evitar los errores clásicos
• Aplicar las métodos fundamentales para el
desarrollo de proyectos
• Manejo de riesgos
• Aplicar métodos orientados a la
planificación
7
Estrategia para el desarrollo de
proyectos (continuación)
Mejor planificación posible
Evitar errores clásicos
Bases del desarrollo
Gestión de riesgos
Métodos orientados a la planificación
Los cuatro pilares del desarrollo de proyectos
8
Estrategia para el desarrollo de
proyectos (continuación)
Bases del desarrollo
Gestión de
riesgos
Métodos orientados a la planificación
El efecto de tener errores clásicos
Evitar errores clásicos
Métodos orientados a la planificación
El efecto de no tener bases de desarrollo ni gestión de riesgos
9
ERRORES CLÁSICOS
10
Bajo control de calidad
• Bajo control de calidad: error accidental
Encuentre y corrija los defectos cuando aparezcan por vez primera y sean fáciles de
controlar
11
Requerimientos progresivos
• En promedio, los requerimientos cambian
mensualmente entre el 1% y 4%
• La velocidad del cambio de requerimientos
se controla de 3 formas
– Seleccione los requerimientos “reales”
– Limite el número de cambios
– Diseñe e implemente cada cambio
12
Síndrome del “puede-lo-todo”
• Problemas:
– Encuentran fascinante la nueva tecnología y los
nuevos métodos
– Quieren probar nuevas formas (aunque
dudosas) de crear proyectos
– Improvisan sobre la marcha
– No diseñan ni documentan sus técnicas
13
“Estira-y-afloja” en la etapa de
definición
• Perdida de tiempo al no tener definidos las
entradas y salidas del proyecto o sistema
• El líder aprueba los retrasos de desarrollo
(consecuencia de una mala planeación)
• Cuando sucede los anterior se vuelve a
repetir el mismo error
14
Planeación excesivamente
optimista y no realista
• Una planeación
optimista
– en promedio se retrasa el
220%
– no considera los tiempos
de coordinación ni de
corrección
– genera presión en el
personal al estar
desarrollando
No me interesa que los expertos digan que el proyecto no puede
ser realizado en menos de 6 meses. ¡Lo necesito en 4!
15
Resumen de errores clásicos
• Crear una lista de <<malos hábitos>>
• Iniciar con la lista que aparece en seguida
• Incrementar la lista según la terminación de
proyectos
• Aprender de los errores cometidos por el equipo
de trabajo
• Intercambiar experiencias con colegas
• Exhibir la lista en un lugar visible
16
Lista de errores clásicosErrores relacionados con
personasErrores relacionados con
el procesoErrores relacionados con
el productoErrores relacionados con
la tecnología
1. Motivación débil2. Personal mediocre3. Empleados
problemáticosincontrolables
4. Hazañas5. Sumar más personal a
un proyectoretrasado
6. Oficinas repletas yruidosas
7. Fricciones entre losclientes y losdesarrolladores
8. Expectativas pocorealistas
9. Falta de un promotorefectivo del proyecto
10. Falta de participaciónde los implicados
11. Falta de participacióndel usuario
12. Políticas antes quedesarrollo
13. Ilusiones
14. Planificaciónexcesivamenteoptimista
15. Gestión de riesgosinsuficiente
16. Fallos de loscontratados
17. Planificacióninsuficiente
18. Abandono de laplanificación bajopresión
19. Perdida de tiempoen la etapa dedefinición
20. Escatimar en lasactividades iniciales
21. Diseño inadecuado22. Escatimar en el
control de calidad23. Control insuficiente
de la directiva24. Convergencia
prematura oexcesivamentefrecuente
25. Omitir tareasnecesarias en laestimación
26. Planificar ponerse aldía más adelante
27. Programación a
28. Exceso derequerimientos
29. Cambio derequerimientos
30. Desarrolladoresmeticulosos
31. “Estira-y-afloja” enla negociación
32. Desarrolloorientado a lainvestigación
33. Síndrome del“puedelo-todo”
34. Sobrestimación delas ventajas delempleo de nuevasherramientas ométodos
35. Cambiar deherramientas amitad del proyecto
36. Falta de controlautomático delcódigo fuente
17
Una reflexión
18
ASPECTOS
FUNDAMENTALES EN EL
DESARROLLO DE
PROYECTOS
19
Aspectos técnicos• Problematización, la
situación vista como un
sistema (aplicando la
Teoría General de
Sistemas):
– Entradas (inputs): datos
e información llana
– Salidas (outputs): datos
e información procesada
– Proceso (process):
clasifica, ordena,
calcula, etc.
– Control: análisis, diseño,
implantación, pruebas,
mantenimiento, métricas,
calidad, etc.
– Almacenaje (storage):
bases de datos
– Realimentación
(feedback)
– Entorno (environment):
organización
– Fronteras (boundaries):
variables (dependen del
sistema)
20
Aspectos técnicos
(continuación)
ORGANIZACIÓNSISTEMA DE INFORMACIÓN
InputDatose información
llana
ProcesamientoClasifica, ordena, calcula
OutputDatos e
información procesada
Realimentación
Clientes
Agencias regulardoras
Accionistas
Competidores
Proveedores
ControlAnálisis, diseño, etc.
AlmacenajeBases de datos
21
Aspectos de gestión
• Dimensionar el proyecto (sistema)
• Estimar costos y tiempo
• Planear el desarrollo del proyecto (sistema)
• Seguimiento del proyecto (sistema)
• Medir las evoluciones del proyecto
(sistema)
22
Aspectos de control de calidad
Especificaciónde
requerimientos
Especificacióndel diseño del
producto
Especificacióndetallada del
diseño del producto
Construcción Mantenimiento
Especificaciónde
requerimientosEspecificacióndel diseño del
productoEspecificacióndetallada del
diseño del producto
Construcción
Fase en la que se detecta un defecto
Fase en la que se introduce un defecto
Costo/tiempo para corregir• Planeación del control de calidad
• Pruebas• Revisiones
23
Aspectos de control de calidad
(continuación)
Tiempo de desarrollo
Porcentaje de defectos suprimidos95% 100%
Promedio de las organizaciones
Mejor planificación (más rápida)
24
RIESGOS EN EL
DESARROLLO DEL
PROYECTO
25
Riesgos en el proyecto
Oportunidad de cumplir la
planeación y el presupuesto
100%
0%5% 25% 50%
Proporción del presupuesto destinado a la administración de riesgos
Proy
ect
os p
romedio
Proy
ect
os a
bajo
del pr
omedio
Proyectos de misión crítica o
ineficientes
Enf
oque
de d
esa
rrollo r
ápido
Proyectos con
burocracia excesiva
26
Administración de riesgos
• Planear para administrar riesgos
• Existencia de un responsable de
identificación de riesgos
• Utilizar la lista de los 10 riegos mas
comunes
• Crear un plan de ataque para cada
riesgo
• Crear un canal anónimo de reporte
de riesgos
27
Mapa de riesgos
Gestión de riesgos
Estimación de riesgos
Identificación de riesgos
Análisis de riesgos
Identificación de riesgos
Control de riesgos
Planificación de riesgos
Resolución de riesgos
Monitorización de riesgos
28
DESARROLLO RÁPIDO DE
PROYECTOS
29
Desarrollo eficiente
Mejor planificación posible
Evitar errores clásicos
Bases del desarrollo
Gestión de riesgos
Métodos orientados a la planificación
30
Una estrategia alternativa
Método tradicional Método del seminario
Ofrece mejoras instantaneas eincreibles
Mejoras modestas
Se require alta experiencia encodificación y poca experienciatecnológica
Se require alta experiencia tanto encodificación como en tecnología
Recursos humanos radicales ydudosos
Recursos humanos conservadores,aburridos y anticuados
Empleo de demasiados recursoshumanos
Uso de recursos humanos de formahumana y eficiente
Ofrece poca visibilidad y control Ofrece tanta visibilidad y control como sedesee
Tan viejo como la humanidad Los puntos clave se han utilizado conéxito desde hace 15 años
31
Cuatro dimensiones para el
desarrollo de proyectosPersonas
Producto
Tecnología
Proceso
32
1ª dimensión: personas• Motivar y
tener ética
• Seleccionar buen personal
• Crear medio ambiente agradable
• Generar tiempos extras voluntarios
• Hacer equipo de trabajo
Bolígrafo de la empresa
El buen desarrollador de software
Carta de recomendación
Reloj de la empresa
Camiseta de la empresa
Entradas para las luchas
Recompensa por fin de proyecto
Gorra de la empresa
Mascota
Botones del proyecto
Refrescos gratis
Maleta de deporte con el logotipo
del proyecto
Póster para excursión de
fin de proyecto
33
2ª dimensión: proceso
• Evitar repetición del trabajo
• Controlar la calidad
• Crear bases para el desarrollo
• Gestionar riesgos
• Poner atención a los recursos
• Planificar el ciclo de vida
• Enfatizar la orientación al cliente
34
2ª dimensión: proceso
(continuación)Visibilidad de un proyecto ideal
Visibilidad de un proyecto eficiente
Visibilidad de un proyecto utilizando el
ciclo de vida en cascada
Visibilidad de un proyecto típico
Inicio Final
Progreso del
proyecto
Proceso orientado a la visibilidad
35
3ª dimensión: producto
• Dimensionar el tamaño del
producto
– Entrega a corto plazo
– Entrega a mediano plazo
– Entrega a largo plazo
• Definir las características
del producto
– Diseño de acuerdo a las
herramientas
– Diseño de acuerdo a la
planificación
Productos pequeños toman menos tiempo en construirse
36
4ª dimensión: tecnología• Pasar de herramientas menos efectivas a
más efectivas
• Utilizar únicamente herramientas conocidas y probadas
Esta herramienta CASEes mágica, vale más de
10 de tus vacas
Aprender a separar la
realidad de los cuentos de
hadas
37
¿Modelo único?
¡No existe un modelo único!
38
SUPERVIVENCIA EN EL
DESARROLLO DEL
SOFTWARE
39
Cómo tener éxito en el desarrollo del software
• Elaborar y seguir un plan de desarrollo
• Capacitar al personal del proyecto
• Minimizar la burocracia
• Definir las bases de los requerimientos, y administre los cambios
• Revisar periódicamente la salud y progreso del proyecto, y reconsiderar la planeación cuando sea necesario
• Reestimar el tamaño del proyecto, el esfuerzo, y la planeación periódicamente
• Definir y administrar las fases de transición
• Fomentar un espíritu de equipo
• Iniciar el proyecto con el personal experto necesario
40
Cómo no tener éxito en el
desarrollo del software• Permitir que el personal
trabaje de forma no sistemática
• Proponer objetivos irreales
• Implementar cambios sin evaluar su impacto y obtener la aprobación del comité de cambios
• Comprar y utilizar herramientas innecesarias
• Contratar personal innecesario, principalmente al inicio del proyecto
• Retrasar procesos definidos en la planeación
• Disminuir los estándares con el fin de acortar la planeación
• Suponer que documentación en demasía asegura el éxito
41
Examen de supervivencia:
instrucciones• 3 puntos para cada “si”
• 2 puntos para “probablemente”
• 1 punto para “casi, pero realmente no”
• Si el proyecto está en sus inicios, responda
las preguntas en base a los planes del
mismo
• Si el proyecto está desarrollandose,
responda en base lo que sucede actualmente
42
Examen de supervivencia: requerimientos
1.__ ¿El proyecto tiene una visión o
misión clara y no ambigua?
2.__ ¿Todos los miembros del equipo
creen que la visión es realista?
3.__ ¿El proyecto tiene un estudio de
financiero y de negocios que detalla
los beneficios de y como éstos serán
medidos?
4.__ ¿El proyecto tiene un prototipo de
interface con el usuario que
realmente y verídicamente
demuestre la funcionalidad que el
sistema real tendrá?
5.__ ¿El proyecto posee una
especificación detallada por escrito
de lo que se supone que hará el
software?
6.__ ¿El equipo entrevistó a las
personas que utilizaran el
software y éstos continúan
relacionados con el proyecto?
7.__ ¿El proyecto posee un plan
detallado de desarrollo del
software por escrito?
8.__ ¿El proyecto incluye la creación
de un programa de instalación,
conversión de datos provenientes
de versiones previas, integración
con otro software, reuniones con
los clientes, y otras tareas
menores?
9.__ Fueron la planeación y el
presupuesto oficialmente
actualizados al final de la fase
recién completada
43
Examen de supervivencia: requerimientos (continuación)
10.__¿El proyecto posee documentos detallados por escrito del diseño y la arquitectura?
11.__¿El proyecto posee por escrito un plan detallado de aseguramiento de la calidad que contenga revisiones de diseño y código, además de las pruebas del sistema?
12.__¿El plan del proyecto posee un plan de fases para el software, que describa las fases en el cual será entregado y liberado?
13.__¿El plan del proyecto incluye periodos vacacionales, días no laborables, y días perdidos por enfermedad o por cursos de capacitación?
14.__¿Fue el plan de desarrollo y de calendarización aprobado por el equipo de desarrollo, el equipo de aseguramiento de la calidad, y el equipo de reportes técnicos ( en otras palabras, por las personas responsables de realizar el proyecto)?
44
Examen de supervivencia: control del proyecto
15.__Existe un único ejecutivo clave
que tenga poder de decisión y que
pueda dar soporte al proyecto?
16.__¿Al responsable del proyecto se le
permite que dedique una cantidad
considerable de tiempo al mismo?
17.__¿El proyecto posee puntos clave
de tipo binario que permita decir
que está 100% realizado o 100%
no realizado?
18.__¿El tenedor del proyecto puede
detectar cuándo estos puntos clave
han sido completados?
19.__¿El proyecto posee un canal de
realimentación que permita de
forma anónima reportar
problemas a los superiores?
20.__¿El proyecto posee un plan por escrito
para controlar cambios en la
especificación del software?
21.__¿El proyecto posee un Comité de
Control de Cambios que tiene la
autoridad final para aceptar o rechazar
los cambios propuestos?
22.__¿Los materiales planeados y la
información del estado del proyecto
(avances, calendarización estimada,
tareas asignadas, y comparación con el
plan original) están disponibles?
23.__¿El código se revisa por controladores?
24.__¿El entorno del proyecto incluye
herramientas necesarias para completarlo
(software para administración de
proyectos, controladores de código,
etc.)?
45
Examen de supervivencia:
administración de riesgos25.__¿El plan del proyecto posee una lista de los
riesgos actuales del mismo? ¿La lista ha sido
actualizada recientemente?
26.__¿El proyecto posee un responsable de la
identificación de riesgos emergentes en el
mismo?
27.__Si el proyecto subcontrata, ¿posee un plan para
administrar cada organización subcontratada y
una única persona para cada una de ellas? (de el
máximo puntaje si no existen subcontrataciones)
46
Examen de supervivencia:
personal28.__¿ El equipo posee la
experiencia técnica necesaria para completar el proyecto?
29.__¿El equipo posee experiencia con el ambiente de negocios en el cual el software operará?
30.__¿El proyecto posee un líder técnico capaz de conducir el proyecto exitosamente?
31.__¿Existe el número suficiente de personas que el trabajo requiere?
32.__¿Todos trabajan de forma conjunta y en armonía?
33.__¿Está cada persona comprometida con el proyecto?
47
Examen de supervivencia:
totales
__ Puntaje preliminar. Sume los puntos de cada
respuesta
__ Multiplicador de tamaño. Escriba 1.5 si el equipo de
trabajo tiene 3 o menos personas de tiempo completo
(incluyendo desarrolladores, personal del
aseguramiento de la calidad, administradores de
primer nivel). Escriba 1.25 si tiene de 4 a 6 personas
de tiempo completo. De otra forma, escriba 1.0.
__ Puntaje final. Multiplique el puntaje preliminar por
el multiplicador de tamaño
48
Examen de supervivencia:
guías de puntajePuntaje Comentarios
90+
Sobresaliente
Un proyecto con este puntaje su éxito está virtualmente garantizadoen todos los aspectos
80-89
Excelente
Un proyecto en este nivel se desarrolla mucho mejor que elpromedio. Este proyecto tiene una alta probabilidad de entregarsecercanamente a las fechas propuestas, a los presupuestos, y a lacalidad planeada
60-79
Bueno
Un proyecto con este promedio es mejor que el promedio en cuantoa la efectividad del desarrollo de software. Tiene posibilidades deentregarse ya sea tiempo o cumpliendo el presupuesto planeado,pero probablemente no cumpla ambos
40-59
Débil
Este puntaje es típico. Un proyecto con este puntaje genera tensiónnerviosismo. El software será entregado con menor funcionalidadque la deseada,a un costo grande y con un gran retraso
< 40
En riesgo
Un proyecto con este puntaje tiene debilidades significativas en lasáreas de requerimientos, planeación, control del proyecto,administración de riesgos, y personal. La principal incógnita escuándo se terminará del todo
