Este documento presenta una introducción a la administración de proyectos de comercio electrónico. Cubre temas como la estrategia para el desarrollo de proyectos, errores clásicos, aspectos fundamentales en el desarrollo, riesgos en el desarrollo y desarrollo rápido de proyectos. El documento ofrece una guía general para planificar, implementar y gestionar con éxito proyectos de comercio electrónico.

1. 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. 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. 3
ESTRATEGIA PARA EL
DESARROLLO DE
PROYECTOS

4. 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. 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. 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. 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. 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. 9
ERRORES CLÁSICOS

10. 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. 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. 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. 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. 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. 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. 16
Lista de errores clásicosErrores relacionados con
personas
Errores relacionados con
el proceso
Errores relacionados con
el producto
Errores relacionados con
la tecnología
1. Motivación débil
2. Personal mediocre
3. Empleados
problemáticos
incontrolables
4. Hazañas
5. Sumar más personal a
un proyecto
retrasado
6. Oficinas repletas y
ruidosas
7. Fricciones entre los
clientes y los
desarrolladores
8. Expectativas poco
realistas
9. Falta de un promotor
efectivo del proyecto
10. Falta de participación
de los implicados
11. Falta de participación
del usuario
12. Políticas antes que
desarrollo
13. Ilusiones
14. Planificación
excesivamente
optimista
15. Gestión de riesgos
insuficiente
16. Fallos de los
contratados
17. Planificación
insuficiente
18. Abandono de la
planificación bajo
presión
19. Perdida de tiempo
en la etapa de
definición
20. Escatimar en las
actividades iniciales
21. Diseño inadecuado
22. Escatimar en el
control de calidad
23. Control insuficiente
de la directiva
24. Convergencia
prematura o
excesivamente
frecuente
25. Omitir tareas
necesarias en la
estimación
26. Planificar ponerse al
día más adelante
27. Programación a
28. Exceso de
requerimientos
29. Cambio de
requerimientos
30. Desarrolladores
meticulosos
31. “Estira-y-afloja” en
la negociación
32. Desarrollo
orientado a la
investigación
33. Síndrome del
“puedelo-todo”
34. Sobrestimación de
las ventajas del
empleo de nuevas
herramientas o
métodos
35. Cambiar de
herramientas a
mitad del proyecto
36. Falta de control
automático del
código fuente

17. 17
Una reflexión

18. 18
ASPECTOS
FUNDAMENTALES EN EL
DESARROLLO DE
PROYECTOS

19. 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. 20
Aspectos técnicos
(continuación)
ORGANIZACIÓN
SISTEMA DE INFORMACIÓN
Input
Datose información
llana
Procesamiento
Clasifica, ordena, calcula
Output
Datos e
información
procesada
Realimentación
Clientes
Agencias regulardoras
Accionistas
Competidores
Proveedores
Control
Análisis, diseño, etc.
Almacenaje
Bases de datos

21. 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. 22
Aspectos de control de calidad
Especificación
de
requerimientos
Especificación
del diseño del
producto
Especificación
detallada del
diseño del
producto
Construcción Mantenimiento
Especificación
de
requerimientos
Especificación
del diseño del
producto
Especificación
detallada 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. 23
Aspectos de control de calidad
(continuación)
Tiempo de
desarrollo
Porcentaje de defectos suprimidos
95% 100%
Promedio de las
organizaciones
Mejor
planificación
(más rápida)

24. 24
RIESGOS EN EL
DESARROLLO DEL
PROYECTO

25. 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
Proyectospromedio
Proyectosabajodelpromedio Proyectos
de misión
crítica o
ineficientes
Enfoquededesarrollorápido
Proyectos
con
burocracia
excesiva

26. 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. 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. 28
DESARROLLO RÁPIDO DE
PROYECTOS

29. 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. 30
Una estrategia alternativa
Método tradicional Método del seminario
Ofrece mejoras instantaneas e
increibles
Mejoras modestas
Se require alta experiencia en
codificación y poca experiencia
tecnológica
Se require alta experiencia tanto en
codificación como en tecnología
Recursos humanos radicales y
dudosos
Recursos humanos conservadores,
aburridos y anticuados
Empleo de demasiados recursos
humanos
Uso de recursos humanos de forma
humana y eficiente
Ofrece poca visibilidad y control Ofrece tanta visibilidad y control como se
desee
Tan viejo como la humanidad Los puntos clave se han utilizado con
éxito desde hace 15 años

31. 31
Cuatro dimensiones para el
desarrollo de proyectos
Personas
Producto
Tecnología
Proceso

32. 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. 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. 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. 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. 36
4ª dimensión: tecnología
• Pasar de herramientas menos efectivas a
más efectivas
• Utilizar únicamente herramientas conocidas
y probadas
Esta herramienta CASE
es mágica, vale más de
10 de tus vacas
Aprender a
separar la
realidad de los
cuentos de
hadas

37. 37
¿Modelo único?
¡No existe un modelo único!

38. 38
SUPERVIVENCIA EN EL
DESARROLLO DEL
SOFTWARE

39. 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. 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. 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. 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. 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. 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. 45
Examen de supervivencia:
administración de riesgos
25.__¿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. 46
Examen de supervivencia:
personal
28.__¿ 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. 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. 48
Examen de supervivencia:
guías de puntaje
Puntaje Comentarios
90+
Sobresaliente
Un proyecto con este puntaje su éxito está virtualmente garantizado
en todos los aspectos
80-89
Excelente
Un proyecto en este nivel se desarrolla mucho mejor que el
promedio. Este proyecto tiene una alta probabilidad de entregarse
cercanamente a las fechas propuestas, a los presupuestos, y a la
calidad planeada
60-79
Bueno
Un proyecto con este promedio es mejor que el promedio en cuanto
a la efectividad del desarrollo de software. Tiene posibilidades de
entregarse 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ón
nerviosismo. El software será entregado con menor funcionalidad
que 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 es
cuándo se terminará del todo