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

¿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

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

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

Un Poco de

Teoría Software y Personas

¿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

¿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

¿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

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.

Acercamient

o y Venta El Nacimiento de un

Proyecto

¿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

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

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

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

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

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

¿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

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

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?

Análisis y

Entendimiento Los Cimientos

Fundamentales de un

Proyecto Exitoso

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

Roles y Responsabilidades

Metodologías modernas recomiendan

usar “Cartas de Derechos”

También es indispensable presentar el

“triángulo de desarrollo de software”

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

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

Triángulo de Desarrollo de

Software

Recursos Tiempo

Alcance

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”

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

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

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

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

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

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

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

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

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

Diseño y

Construcción

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

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

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í

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

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

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

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

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

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

El Juego Final

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

¿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?

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

Otros

Elementos

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

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

Arriba o Afuera

Práctica común en consultoras

internacionales

Evita el estancamiento

Contribuye a una mentalidad dinámica

en el equipo de trabajo

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

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

Gracias