Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

El Factor Humano en Proyectos de Software

2,434 views

Published on

Presentacion creada originalmente por Hector Obregon Roa y presentada por Haaron Gonzalez para la comunidad Technet Mexicali

  • Be the first to comment

El Factor Humano en Proyectos de Software

  1. 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. 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. 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. 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. 5. Un Poco de Teoría Software y Personas
  6. 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. 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. 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. 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. 10. Acercamient o y Venta El Nacimiento de un Proyecto
  11. 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. 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. 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. 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. 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. 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. 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. 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. 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. 20. Análisis y Entendimiento Los Cimientos Fundamentales de un Proyecto Exitoso
  21. 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. 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. 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. 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. 25. Triángulo de Desarrollo de Software Recursos Tiempo Alcance
  26. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 36. Diseño y Construcción
  37. 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. 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. 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. 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. 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. 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. 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. 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. 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. 46. El Juego Final
  47. 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. 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. 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. 50. Otros Elementos
  51. 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. 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. 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. 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. 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. 56. Gracias

×