1. DESARROLLO DE PROYECTOS INFORMATICOS
ORGANIZACIÓN DE PROYECTOS INFORMATICOS
Ing. John Toasa Espinoza
0
2. El desarrollo de los proyectos informáticos
suele requerir:
◦ un equipo pequeño, por lo que las estructuras
clásicas sólo nos sirven de marco de referencia.
◦ especialistas en diferentes áreas:
conocimiento técnico informático
conocimiento en el área del S.I. en estudio.
(Equipos Multifuncionales).
GPI-3A. Organización en Proyectos
Informáticos . 1
3. Se han clasificado las estructuras de los
equipos en tres tipos diferentes:
◦ Equipo no egoísta (Weinberg)
◦ Equipo de Programador Jefe.
◦ Equipo Controlado Descentralizado.
Marilyn Mantei (1981)
2
4. Son equipos pequeños (< 10 personas)
Las personas del equipo comparten el código
desarrollado. Examinando mutuamente lo
desarrollado.
Las metas se marcan por consenso.
El liderazgo del grupo es una función
rotativa, tratando de pasársela al individuo
más apropiado en cada momento.
3
5. Las personas están en diferentes áreas de
conocimientos y niveles de experiencia.
4
6. Todo el mundo puede comunicarse con todo
el mundo.
GPI-3A. Organización en Proyectos
Informáticos . 5
7. Se trata de equipos pequeños.
Hay un Jefe Técnico (el
programador jefe) que:
◦ Reparte las tareas a realizar. El se
queda con las más complejas.
◦ Recibe información del trabajo
realizado por cada miembro del
equipo.
◦ Toma todas las decisiones
importantes.
6
8. Es una estructura autocrática y centralizada
Programador Jefe
Programadores Especialistas Consultores
Bases de Datos
7
9. Todas las comunicaciones pasan
necesariamente por el programador jefe.
8
10. Los equipos pueden ser grandes.
Del líder del proyecto dependen una serie de
programadores expertos y estos a su vez
gestionan cada uno un grupo de
programadores.
Trata de nutrirse de las mejores
características de los equipos anteriores.
9
11. La responsabilidad es del líder y los
programadores expertos.
Líder del Proyecto
Programador
Experto
Programador
10
12. Los grupos formados por
personas a un mismo
nivel y su superiores se
comunican de forma
descentralizada
11
13. Dific Tam Dura Mod Fiabi Dura Soci
ultad año ción ulari lidad ción abili
dad dad
Estructura del equipo A B G P C L A B A B E L A B
l a r e o a l a l a s a l a
t j a q r r t j t j t x t j
a a n u t g a a a a r a a a
d e a a i
e ñ c
o .
No Egoísta X X X X X X X
Controlado X X X X X X X
Descentralizado
Programador Jefe X X X X X X X
12
14. Comunicación en Armonía
La incapacidad de la gente para comunicarse
de forma efectiva es uno de los obstáculos
más comunes para la obtención de productos
de calidad así como para la productividad.
13
16. Comprender las causas de problema.
Poner en marcha acciones correctivas.
Forzar hacia un entorno de trabajo
comunicativo.
15
17. Cuando estas equivocado admítelo.
Ejercita la tolerancia.
Habla con la gente.
Ayuda a los demás.
Pide ayuda a los demás.
Utiliza el tacto; haz tus comentarios desde
una perspectiva correcta.
16
18. Mantén informados a los demás; No
Sorprendas.
Cierra los problemas.
Muestra aprecio.
Escucha con atención.
Saluda a la gente; Recuerda sus nombres.
Alcanza compromisos.
17
19. Debes estar deseoso de romper la tradición.
Ten claro lo que debes esperar de los demás.
Respetar a las personas.
18
20. No existe mejor recomendación para trabajar
en grupo que la de tratar a los otros como te
gustaría que te tratasen a ti.
La gente tiende a tratarte del mismo modo en
que la tratas.
19
21. Admitir que estas equivocado puede cambiar
el modo desde la confrontación a la
cooperación.
Si sabes que te has equivocado, no
construyas muros a tu alrededor.
No es cierto el dicho: “Admitir que estas
equivocado es signo de debilidad”
Aumentaras el respeto hacia ti.
La tensión tiende a desaparecer.
20
22. La tolerancia con que trates a los demás
enseñara a los otros a ser tolerante cuando
lo requieran tus acciones.
De forma especial cuando alguien esta
aprendiendo.
Recuerda las veces en que te has equivocado.
◦ En un caso en el que no fueron tolerantes
◦ En un caso en que lo fueron
21
23. La comunicación interactiva todavía es la
mejor.
Es mas fácil criticar a las espaldas de uno,
sobre todo cuando no lo conoces.
Sal de tu puesto para hablar con tus
superiores, inferiores y compañeros.
Habla por teléfono, en lugar de enviar
notas.
Cuando tengas una reunión, plantéate
quienes se podrían beneficiar.
22
24. Ayuda a los demás cuando puedas.
Cuida de no hacer el trabajo de los demás.
(Se te mide por tu trabajo).
No crees dependencias.
Enseña como hacerlo. Sugiere caminos para
aprender.
Se respeta a los que ayudan.
23
25. Acudiendo al potencial de otros lleva a los
dos a ganar de la experiencia.
Todo el mundo tiene cosas que aportar.
Te sorprenderás no solo de la respuesta, sino
que también de la mejora en tus resultados.
Las personas a las que se les pide ayuda se
sienten bien.
Busca al combinación “Ganar-Ganar”
24
26. Tacto, es el arte de hacer una
puntualización sin hacer un enemigo.
Ponte en la piel de los demás:
◦ ¿Como reaccionaria si me dijeran esto?
Deja claro que quieres trabajar con los
demás y añadir valor al proyecto.
Los mensajes que envías no se escuchan
por lo alto que lo envíes.
Deja las emociones aparte :-( | :-) | ;-)
25
27. Esfuérzate por no sorprender con noticias
malas.
Las noticias malas son como la basura;
cuando mas tardes en actuar sobre ellas,
mayor será el mal olor.
26
28. Los problemas prolongados entre personas o
grupos tienen efectos negativos para la
comunicación.
Ojo si escuchas:
◦ Veremos que pasa,
◦ No se que es lo que voy ha hacer
◦ Trabajare en esto más adelante
◦ Todavía no he entrado a este asunto
◦ No me he olvidado de esto, pero...
27
29. Una de las frases más importantes que
puedes pronunciar es “Gracias”
Cuando la gente haga algo por ti, muestra
tu aprecio.(aceptación)
Estará deseoso de ayudarte otra vez.
Si muestras tu gratitud en publico, será
mayor la percepción.
◦ Recuerda situaciones en las que tras hacer un
buen trabajo fuiste elogiado o no.
28
30. Escuchar beneficia a ambas partes.
En la comunicación se envía y recibe
información.
◦ Escuchar es la parte fundamental de la recepción.
◦ El emisor rara vez tiene problemas de
concentración
◦ El receptor puede estar distraído por otros
pensamientos.
Preparando la respuesta a lo dicho hace 2 minutos.
Contando los segundos hasta que termine de hablar para
irse.
29
31. Técnicas para aumentar la atención.
◦ Hacer preguntas sobre el tema,
◦ Reafirmar lo dicho
Ganaras en conocimientos, y ganara el
proyecto.
30
32. Es una forma importante de implicarse con
los demás.
Recordar situaciones en las que algún
superior se dirigiera a vosotros por
nombre.
Recordar otra situación en la que algún
superior se cruzase con vosotros, pero
que no os saludara.
Los 30 segundos del ascensor
¿Que situación hace que trabajéis mas
duro?
31
33. Una solución de compromiso, es
frecuentemente la mejor.
Es fácil que dos partes se encuentren en
desacuerdo.
◦ Es posible que las dos partes tengan la razón.
◦ Si todos tienen que trabajar para el tema lo mejor
será ponerse de acuerdo
(Unir los objetivos por los que se trabajara)
32
34. Es un signo de fuerza el concentrarse en los
aspectos que uno cree mas importantes,
dando menos importancia a los otros.
33
35. No permitas que los hábitos pasados impidan
el progreso positivo.
Mucha gente utiliza los hábitos como razones
de peso para no mejorar.
Vivimos en un mundo muy cambiante.
◦ Debemos estar abiertos a nuevas ideas y formas de
pensar.
◦ Lucha por hace las cosas que tienen más sentido.
34
36. Si queremos que se forme un equipo efectivo,
los miembros de un proyecto deben entender
el papel de los demás.
Las expectativas que tenemos de los demás
pueden causar problemas.
Esperamos ciertas cosas de la gente con la
que trabajamos.
35
37. Asumimos que los demás saben lo que
esperamos.
Las expectativas han de estar documentadas:
◦ Documentadas, Aprobadas y ser Medibles (para
medir el cumplimiento)
36
38. de Cos Castillo, M. Teoría General del Proyecto.
Síntesis 1995.
Mantei, M. “The effect of Programming Team
Structures on Programming Task”. CACM Marzo
1981. Reimpreso en “Tutorial: Software Engineering
Project Management de R. Thayer, IEEE Computer
Society Prees, 1988.
Whitten, N., Managing Software Development
Projects - 2nd de.. John Whiley & Sons Inc. 1995.
37