Este documento presenta una discusión sobre el factor humano en proyectos de software. Se discuten varios temas clave como la importancia de entender a los diferentes clientes de un proyecto (la organización, los patrocinadores y los usuarios), la necesidad de establecer expectativas realistas, gestionar riesgos de manera efectiva y fomentar la comunicación y participación en el equipo. El documento enfatiza que el desarrollo de software involucra aspectos técnicos pero también humanos que son fundamentales para el éxito de cualquier proyecto.

1. El Factor
Humano en
Proyectos de
Software
Presentada por:
Haarón Gonzalez
http://www.harongonzalez.com.mx
Preparada por:
Héctor M Obregón
Director de Emlink
www.emlink.com.mx

2. ¿De dónde salió esta plática?
 Experiencia de más de 15 años
desarrollando software en diferentes
roles
 La tecnología no es el principal factor de
éxito en proyectos de software
 Sin embargo, es el aspecto más analizado
 Como técnicos es lo que más nos gusta
 Sentido común poco común

3. Formato de la Platica
 Se vale preguntar en cualquier momento
 Esta plática se basa en experiencias y no
pretende representar la verdad final en
cuanto al tema
 Objetivo es lograr que pensemos en
nuestro trabajo de manera diferente

4. Estructura de los Temas
1. Un Poco de Teoría
2. Acercamiento y Venta
3. Análisis y Entendimiento
4. Diseño y Construcción
5. El Juego Final
6. Elementos Generales

5. Un Poco de
Teoría
Software y Personas

6. ¿Cómo desarrollamos
software?
 El software es creado por personas
 Normalmente, el software es utilizado por
personas
 El software afecta la vida de las personas
 En la mayoría de los casos es el resultado
de un trabajo en equipo

7. ¿Qué habilidades necesitamos
para crear software?
 La postura más común es que se requiere
de un gran conocimiento técnico
 A esto se enfocan la mayor parte de las
instituciones educativas
 Un punto de vista es el conocimiento
técnico, aunque necesario, no es lo más
importante
 De “eso otro” hablaremos hoy

8. ¿Qué es lo más importante?
 LAS PERSONAS
 Porque es para ellas
 Porque normalmente no resulta de un
esfuerzo individual
 Porque son el principal obstáculo (ó el
mejor facilitador) para el éxito de un
proyecto

9. Aspectos Relevantes en
Software
 No podemos esperar que las personas
actúen siempre racionalmente
 Cada persona es un individuo diferente
 Su motivación es distinta
 Sus preocupaciones son diferentes
 El desarrollo de software es una actividad
altamente personal y creativa
 Es sencillo que nos identifiquemos con nuestro
trabajo….
 ….y que nuestro trabajo sea un reflejo de nosotros.

10. Acercamient
o y Venta
El Nacimiento de un
Proyecto

11. ¿Quién es el cliente?
 ¿La empresa?
 ¿El patrocinador?
 ¿El usuario?
 La respuesta correcta es: todos
 Es fundamental construir una visión
común para tener éxito

12. El Cliente Organización
 Si no generamos resultados para la
organización que provee los recursos
 Probablemente no generemos oportunidades
futuras
 En la mayoría de los casos el objetivo
organizacional es fácil de identificar
 Pero no es fácil de llevar a cabo

13. El Cliente Patrocinador(es)
 Los objetivos individuales de cada persona
involucrada en el proyecto afectan a este
 Objetivos políticos
 Objetivos personales
 No es necesario alinear el proyecto a
objetivos personales, pero siempre es
importante tomarlos en cuenta
 O el proyecto corre un alto riesgo de fracasar

14. El Cliente Usuario
 Tiene el poder de hacer del proyecto un éxito
o un fracaso
 Por lo tanto también debemos de conocer
sus objetivos
 Aprovecharlos para lograr el éxito del proyecto

15. El Mensaje de Venta
 No existe un único mensaje de venta
 Los intereses de cada tomador de
decisión y su mecanismo de
convencimiento pueden ser diferentes
 Por lo tanto, para una venta efectiva
debemos adaptar el mensaje a la
audiencia objetivo

16. El Desarrollo de la Confianza
 La confianza es el elemento más importante
en la construcción de ventas exitosas en el
largo plazo
 Construir la confianza puede implicar
sacrificios de corto plazo, pero genera
beneficios permanentes
 La confianza es el principal motor en generar
relaciones de negocio duraderas y exitosas

17. ¿Cómo formar un experto
reconocido?
 En primer lugar, una disposición a ayudar
 En segundo lugar, un entendimiento de los
límites de nuestro conocimiento
 Pero acceso a las fuentes de información
complementaria cuando se requieren
 Por último, una pasión compartida por el
área de conocimiento individual
 Si no lo harías sin cobrar, olvídalo
 Busca otra área de conocimiento

18. Elementos de una Venta
Efectiva
 Conocimiento de la persona
 Franqueza y ética en el trato
 Así puedes vender siempre
 Propuesta de valor
 Me preocupo por como ayudarte
 Escuchar las necesidades
 ¿Realmente estoy atacando el problema
real?
 Disponibilidad a invertir tiempo

19. Definir que Hacemos y que No
 Saber decir que no crea confianza
 Probablemente es más difícil definir lo
que no hacemos
 Intentar cubrir todos los aspectos puede
transmitir inseguridad y desconfianza en
el cliente
 ¿Realmente pueden hacer todo lo que
quiero?

20. Análisis y
Entendimiento
Los Cimientos
Fundamentales de un
Proyecto Exitoso

21. La Reunión de Arranque
 Elemento fundamental para establecer
una buena comunicación inicial entre los
involucrados en el proyecto
 Debe incluir al equipo técnico, usuarios y
patrocinadores
 Debe definir claramente una misión común y los
parámetros de éxito del proyecto
 Debe definir con claridad roles y
responsabilidades
 Debe educar en el proceso de software a los
participantes no técnicos

22. Roles y Responsabilidades
 Metodologías modernas recomiendan
usar “Cartas de Derechos”
 También es indispensable presentar el
“triángulo de desarrollo de software”

23. Carta de Derechos del Cliente
1. Fijar objetivos para el proyecto que se cumplan
2. Saber cuanto va a costar y cuanto tiempo tomará el
proyecto
3. Decidir que funciones entran y cuales no en el
software
4. Hacer cambios razonables a los requerimientos
durante el proyecto y saber el costo de esos cambios
5. Saber el estado del proyecto clara y completamente
6. Ser informado regularmente de los riesgos que
pueden afectar tiempo, costo ó calidad y recibir
opciones de solución a problemas
7. Tener acceso continuo a los entregables del
proyecto

24. Carta de Derechos del Equipo
Técnico
1. Saber los objetivos del proyecto
2. Contar con objetivos claramente priorizados
3. Conocer en detalle el producto a construir y
aclarar cualquier duda
4. Acceso oportuno al cliente, gerente, u otra
persona responsable para decidir sobre la
funcionalidad
5. Aprobar programas de trabajo para cualquier
trabajo a realizar. Incluye el derecho a estimar
costo y tiempo alcanzable, tener tiempo para
estimar y revisar estimaciones de tiempo y costos
cuando cambian los requerimientos
6. Un ambiente de trabajo productivo, libre de
interrupciones y distracciones

25. Triángulo de Desarrollo de
Software
Recursos Tiempo
Alcance

26. Complejidad vs. Resultados
 Mientras más compleja sea una iniciativa
de TI, menos probable es que cambie el
comportamiento de las personas
 KISS ó “Keep it Simple, Stupid”

27. Zapatero a tus Zapatos
 Como expertos técnicos, el equipo debe
focalizarse en el entendimiento del área
de problema a resolver
 En muchos casos el problema a resolver
real no es el técnico
 Si no entendemos el problema, no
podemos aportar valor real como equipo
 Y estaremos condenados a “maquilar”
software

28. Compromiso
 El compromiso hace sentido en relación
con nuestra aportación a resolver el
problema identificado
 Hay que construir un entendimiento claro
de la responsabilidad de cada integrante
del equipo

29. Manejo de Expectativas
 Subpromete, sobrecumple en la medida
de lo posible siempre
 Es difícil cuando el entusiasmo por la
tecnología nos gana
 La tendencia natural de muchas personas
es buscar agradar para obtener
aprobación
 En otros casos el miedo a la incertidumbre
provoca demasiado pesimismo
 Es difícil buscar el balance adecuado

30. Ser Como Doctores
 “Bueno señora, todo procedimiento
tiene un riesgo.”
 “En la mayoría de los casos esta
operación da resultados.”
 La medicina tiene 2,000 años y no hace
promesas firmes
 Sin embargo, los programadores
pensamos que si tenemos certeza sobre
sistemas que son cada vez más
complejos
 Pronto más complejos que la anatomía humana

31. La Negación de los Riesgos
 Los humanos tenemos dificultades para
actuar ante el riesgo
 Por eso es difícil vender seguros
 “La verdad no creo que haya problema.”
 Ignorar los riesgos en un proyecto
prácticamente garantiza problemas con
este

32. Estrategias de Manejo de
Riesgo
 Ordenar los riesgos con base en
probabilidad e impacto
 Documentar las acciones para mitigar
cada riesgo y dar seguimiento al nivel de
riesgo en el plan del proyecto
 Pruebas de concepto para riesgos
tecnológicos
 Compartir la información de los riesgos
con todos los miembros del equipo

33. Aprender a Escuchar
 Naturalmente abordamos casi cualquier
análisis con prejuicios y/o ideas anteriores
 Esto dificulta el entendimiento
 Particularmente los problemas o las
críticas son difíciles de escuchar
 Nos identificamos con nuestro trabajo y
con nuestras ideas

34. Significados Encontrados
 Aun dentro de la misma organización,
términos comunes de negocio pueden
significar algo diferente para cada
persona
 Mientras más ligado es el concepto al
área central de negocios, más variantes
pueden existir

35. El Poder de la Información
 Información es poder. Por lo tanto,
 la mayoría de las personas encuentran
difícil compartirla.
 Es más fácil obtenerla si tomamos en
cuenta los objetivos individuales del
poseedor de información

36. Diseño y
Construcción

37. Valor de Negocio y
Prioridades
 El criterio de priorización de actividades
en la construcción debe reflejar el valor
de negocio de cada función
 Ordenar con criterios técnicos disminuye
el valor del software ante cualquier
problema que se presente

38. Construyendo la Confianza
 Los problemas deben comunicarse en
cuanto se presentan
 Acompañados de ideas de solución
cuando sea posible
 Si no tenemos la solución, hay que informar de
cualquier forma y pedir ayuda
 Pocas cosas afectan la confianza tanto
como un problema no comunicado y no
resuelto
 El ambiente de trabajo debe facilitar la
comunicación de los errores

39. Diferentes Percepciones
 Cuando se presentan diferentes puntos
de vista debemos buscar un consenso
común documentado
 La fragmentación de la percepción del
proyecto en cualquier aspecto pone en
riesgo al proyecto en sí

40. Optimismo Forzado
 Es cuando “yo creo que si nos
recuperamos para la próxima semana”
 Cuando se presentan problemas se
deben tomar acciones
 Si una orquesta no funciona, el director
no lo resuelve diciendo “que le echen
más ganas”
 Sin acciones ante un proyecto
atrasados, no hay razones para esperar
que esto mejore después

41. Crecer como Programador
 Un programa es un trabajo intensamente
personal
 En algunos casos el proceso de
programación es similar a la creación
artística
 Sin embargo, esto dificulta la aceptación
crítica
 Francamente, la programación es
demasiado compleja como para que haya
una forma correcta de hacer las cosas
 Reconocer las ideas de los demás es factor
de liderazgo y confianza

42. El Hombre en un Cuarto
 Se da cuando descargamos un
problema en un experto solitario
 El riesgo de una desviación es
enorme
 La capacidad de solución debe
estar en el equipo

43. La Computadora es Difícil de
Usar - ¿O no?
 Estamos en el único negocio donde la
gente asume que las computadoras
son complicadas
 Y además está dispuesta a aceptar
esto:
 Capacitarse, reiniciar la máquina, respaldar,
etc.
 Esto es una señal de la falta de calidad
de nuestro trabajo
 Es posible hacer sistemas fáciles de usar

44. Elementos Humanos de la
Interfaz de Usuario
 El elemento humano es particularmente
crítico en el diseño de la interfaz de
usuario
 La lógica de desarrollo es distinta de la
lógica de uso
 Esto dificulta al diseñador crear la interfaz
ideal
 Es recomendable que un miembro del
equipo se concentre en este tema
 Ignorando en lo posible restricciones internas

45. Problemas Comunes en la
Interfaz
 Iconitis
 Mensajes de Error Inútiles
 Pasos Innecesarios
 Presentación Inadecuada de la
Información
 Interrupciones Innecesarias del Flujo de
Trabajo
 Los humanos somos no-líneales

46. El Juego Final

47. Listos para Liberar
 Las pruebas independientes por personal
independiente y especializado son
indispensables
 Someter al usuario a pruebas de calidad
genera desgaste, no es necesario y pone
en riesgo al proyecto
 El usuario sólo debe validar
responsabilidad de negocio

48. ¿Cúando Terminamos?
 Increíblemente este punto genera mucha
controversia
 Como en otros diferendos, es necesario
generar y documentar un consenso
común cuando esta situación se da
 Un buen criterio es: ¿podemos generar el
valor de negocio prometido?

49. Mover la Gelatina
 Agregar funcionalidad a un proyecto a
punto de terminar es de alto riesgo
 Se parece a “mover la gelatina” cuando
está cerca de cuajar
 Es necesario “congelar” la funcionalidad
en esta etapa
 Foco en el valor de negocio

50. Otros
Elementos

51. Menso = True
 Sucede cuando no escuchamos las
aportaciones y críticas de los demás
 …o cuando nos hartamos de que no nos
escuchen y dejamos de aportar.
 Esta situación degrada la labor de
equipo
 Es fundamental favorecer la participación
de todos los miembros

52. Estímulos y Reconocimientos
 Liderazgo por jerarquía no funciona en
ningún lado, pero menos aún en un
proyecto de software
 El líder puede hacer mucho para motivar
al equipo mostrando su reconocimiento
al trabajo
 Igualmente importante es exigir
responsabilidad a cualquier miembro que
afecte al equipo

53. Arriba o Afuera
 Práctica común en consultoras
internacionales
 Evita el estancamiento
 Contribuye a una mentalidad dinámica
en el equipo de trabajo

54. Efectos de TI en las Personas
 Fascina a algunos e intimida a otros
 Es muchas veces sobrevalorada como
instrumento del cambio organizacional
 Las TI no generan cambio humano
 De hecho, generan resistencia y amenaza
 Por lo tanto, la generación de valor de
negocio es únicamente apoyada por las
TI

55. Momentos para Tomar
Decisiones
 Nunca en momentos de celebración o
de molestia, enojo o preocupación
 Probablemente el peor momento sea
cuando estamos emocionados
 Olvidamos los riesgos
 Es mejor esperar y posponer la decisión

56. Gracias