La ruta corta a proyectos exitosos

www.sgcampus.com.mxflabordep@hotmail.com
Síguenos ...
La Ruta Corta Hacia un Proyecto Exitoso
pág. 1

 Todos los miércoles de 2 a 4 pm
 Webinars de julio
 ¿Qué hacer para dominar el arte
del levantamiento de
requerimientos?
 La ruta corta a los proyectos
exitosos (Modelo 4CE)
 HTML5 Avanzado. El poder de
Javascript
 Home Office "Mito o Realidad"
 ¿Quieres saber más?
 http://www.sgcampus.com.mx/we
b/guest/eventos
Lunch & Learn
página 2

 Maestro en Diseño Industrial en
Fukuoka, Japón (1985)
 Sigtao Software Factory
 Inicio del programa en 2000
 CMM 5 en 2004
 CMMi ML5 en 2006
 ITESM campus Querétaro
 SQA y pruebas, desde 2007
 Adm. Proyectos en 2010
 Free lance (actual)
 Mejora de procesos
 Administración de proyectos
 Formación de equipos
¿Quién es Francisco Laborde?
página 3

 SoftwareGuru:
talento.sg.com.mx/perfil/a/flabordep
 Linkedin: linkedin.com/in/flabordep
 Facebook: flabordep
 Twitter: @flabordep
 www.fungusdice.wordpress.com
 www.flabordep.wordpress.com
¿Dónde encuentro a Francisco Laborde?
página 4

 Si tienen problemas con el
audio cierren las ventanas. Si
el problema persiste, usen la
señal “más”.
 Pongan sus preguntas y
comentarios en el chat. Yo las
contestaré al final.
 Si no alcanzamos a revisar
todas las preguntas, las iré
contestando en mi blog.
Housekeeping
página5

 Al final de este webinar, el
participante podrá describir ...
 Los principales elementos
que determinan la calidad
de un producto de software
y
 Las prácticas que le
permiten asegurar la entrega
oportuna de productos de
calidad.
¿A qué le tiramos?
página6

 Elementos que determinan la calidad
 Prácticas que aseguran la entrega oportuna con calidad.
Objetivo
Sistema (prácticas)
describir
determinan
?
principales
elementos
calidad
producto de
software
?
entrega
segura
Cubre las
necesidades y
expectativas ...
página 7

 Mejorar la competitividad y
productividad de empresas de
desarrollo.
 Promover un modelo de
calidad que balancea eficacia
con sencillez (80, 20)
 Compartir mi experiencia en
la implantación de modelos de
calidad en México.
 ¿Qué vendo?
Expectativas
página 8

 De cada veinte proyectos, sólo
uno se entrega con toda la
funcionalidad prometida, a
tiempo y dentro del
presupuesto autorizado.
 Trece son mediocres, porque
se entregan:
 incompletos,
 tarde o
 exceden el presupuesto.
 Seis son pérdida total.
Proyectos fallidos
página9

Explicaciones
página 11

 Resolví el problema que no
era, porque ...
 No entendí cómo se crea el
valor en este negocio
 Me distraje con retos
técnicos
 Se me olvidó el objetivo de
negocio
 El negocio cambió y no me
di cuenta
No entendí los requisitos
página 12

 Se me hizo fácil ...
 No conseguí los recursos a
tiempo
 No conseguí gente con
experiencia y no supe cómo
capacitarlos
 No supe cómo coordinar al
equipo
No controlé los recursos
página13

 Actuar sin entender el sistema
es mala estrategia.
Y ahora ¿qué?
Perdone ...
¿el camino al
éxito?
página14

 American Society for Quality (ASQ Glossary)
 Un grupo de personas y
procesos interdependientes
que en conjunto desempeñan
una misión común.
Sistema
System: A group of interdependent
processes and people that together
perform a common mission.
página16
Conocer el estado
deseado
Controlar el sistema

Cliente
Usuario
ProveedorProd
¿Cumple?
RequisitosNecesidades y
expectativas
Uso
basado en: IEEE-STD-610
 Grado en que un sistema, componente o proceso cumple con las
necesidades o expectativas del cliente o del usuario.
Calidad
página 18

La Comunidad
Clientes, usuarios
y otros
interesados
La Comunidad
Clientes, usuarios
y otros
interesados
Control de documentos y registros
Gestión de
recursos
Responsabilidad
de la dirección
Medición y
análisis
Realización de productos y servicios
Satisfacción
Productos
y servicios
Mejora
continua
Necesidades y
expectativas
• Planeación • Compras
Recursos
humanos y
materiales
PruebasProvisiónDiseñoRequisitos
 Modelo basado en ISO 9004, enfocado a desarrollo de software
Sistema de gestión de la calidad
página 20

La Comunidad
Clientes, usuarios
y otros
interesados
La Comunidad
Clientes, usuarios
y otros
interesados
Gestión de
recursos
Responsabilidad
de la dirección
Medición y
análisis
Satisfacción
Productos
y servicios
Mejora
continua
Necesidades y
expectativas
Recursos
humanos y
materiales
 Modelo basado en ISO 9004, enfocado a desarrollo de software
Sistema de gestión de la calidad
página 21

CMMi DEV®
página 23

CMMi DEV®
página 24

Áreas de proceso CMMi DEV®
página 26

Planeación, seguimiento y
control
Gestión de la calidad
Requisitos
Gestión de la
configuración
Externa Interna
Investigar y
entender ...
Entregar lo
prometido
Aprendizaje e inicio de un
nuevo ciclo
Controlar los recursos disponibles para ejecutar las
actividades y preparar los productos.
Calcular la situación del proyecto con base en mediciones y
modelos formales (no en intuición).
Comunicar el estado del proyecto correcta y oportunamente
a todos los responsables de tomar decisiones.
Conocer las necesidades y expectativas de clientes,
usuarios y otros interesados.
Proceso
Modelo de solución
página 27

 Conocer las necesidades
 Controlar los recursos
 Calcular el avance
 Comunicar el estado
 Establecer mejora continua
Molino
página 28

Conocer las necesidades
 Conocer las necesidades y
expectativas de clientes,
usuarios y otros interesados.
pág. 29

 Joe Marasco [http://joemarasco.syscon.com/]
[http://www.ibm.com/developerworks/rational/library/feb06/marasco/]
 Cerca de la mitad del retrabajo
en un proyecto típico se debe
a que faltan algunos requisitos
o a que están mal definidos.
 Esto representa un desperdicio
de entre el 15% y el 20% del
costo de un proyecto de
software.
Desperdicio
página 30

La Comunidad
Clientes, usuarios
y otros
interesados
La Comunidad
Clientes, usuarios
y otros
interesados
Gestión de
recursos
Responsabilidad
de la dirección
Medición y
análisis
Satisfacción
Productos
y servicios
Mejora
continua
Necesidades y
expectativas
Recursos
humanos y
materiales
 Basado en la norma ISO 9000
Conocer las necesidades
página 31

 Empieza aunque no tengas todos los requisitos ...
 una lista larga en la que identifiques casi todos los requisitos sin
detallarlos
 una lista corta con las necesidades más importantes (técnicas y
de negocio) ... no empieces con las más fáciles
 Prepárate a seguir un blanco móvil, porque ...
 el entendimiento del negocio evoluciona
 nuevas oportunidades aparecen.
 las reglas del juego cambian
 la tecnología cambia.
Piensa en los requisitos
página 32

 Peter Drucker, “Innovation and Entrepreneurship: Practice and Principles”.
 Calidad no es lo que el
proveedor entrega, sino lo que
el cliente recibe.
 El cliente sólo quiere pagar
por lo que es útil y valioso.
 Calidad no es lo mismo que
difícil de hacer o caro.
Calidad
página33

 http://profs.etsmtl.ca/cfuhrman/OpenUPBasic/Publish/openup_basic/guidances/concepts
/requirements,_0Wh-sMlgEdmt3adZL5Dmdw.html
 Requisito es la declaración formal de:
 un atributo que un producto debe tener o una función que un
producto debe desempeñar (resultado esperado)
 el estándar de desempeño del atributo o función y
 el procedimiento de medición que se usará para determinar si el
estándar ha sido cubierto.
Requisito
página 34

No empieces la construcción de una
iteración con requisitos incompletos o
confusos.
http://profs.etsmtl.ca/cfuhrman/OpenUPBasic/Publish/openup_basic/guidances/concepts/requirements,_0Wh-sMlgEdmt3adZL5Dmdw.html
 Requisito es la declaración formal de:
 un atributo que un producto debe tener o una función que un
producto debe desempeñar (resultado esperado)
 el estándar de desempeño del atributo o función y
 el procedimiento de medición que se usará para determinar si el
estándar ha sido cubierto.
Requisito
página 35

 Hace lo que se espera que haga
 Cubre las necesidades del cliente
 Es fácil de entender y usar
 Está ahí cuando lo necesitas
 Puede adaptarse a cambios en las necesidades
 Vale lo que cuesta
 Reduce el riesgo por error, uso mal intencionado o fallas
 Con pocos defectos (tolerable tomando en cuenta costo y tiempo)
Requisitos típicos del producto
página 36

 Respuesta rápida
 Sabe lo que tiene que hacer y lo hace bien
 Se toma el tiempo para entender los problemas del cliente (se pone
en sus zapatos)
 Explica las cosas en términos que el cliente entiende
 Conoce el negocio del cliente
 Cumple lo que promete
Requisitos típicos del servicio
página 37

 Based on Tom Mochal at TechRepublic.com
 Sin criterios de validación, no hay requisitos.
 Cuando tenemos referencias vagas, hay que preguntar hasta
entender con precisión qué se requiere y cómo se va a probar.
 ... para facilitar (o simplificar) el trabajo
 ... algo útil y práctico
 ... que haga lo mismo que el sistema anterior.
Cuidado con ... descripciones vagas
página 38

 Las mejoras esperadas deben estar ligadas a los objetivos de
negocio y deben ser medibles con base en datos reales en plazos
razonables.
 ... el fondo me gusta rojo con letra amarilla.
 ... reducir el consumo de papel en 25%
 ... reducir la carga de trabajo en 10%
 ... el proyecto es demasiado caro.
 ... debe estar listo para la fecha de mi cumpleaños.
 Hay opiniones que si representan requisitos, pero no todas.
Cuidado con ... opiniones
página 39

 Para evitar que el entrevistado se salga del alcance del proyecto es
importante aclarar desde el principio con el promotor del proyecto
qué aspectos quedarán dentro y fuera del alcance.
 Por ejemplo, en una entrevista, el cliente puede
 ... tener ideas para mejorar los procesos, la organización o el
programa de capacitación, aún cuando eso no esté dentro del
alcance del proyecto.
 ... declarar, sin aportar evidencia, que necesita una impresora
laser a color tamaño doble carta.
Cuidado con ... la tangente
página 40

 Algunos requerimientos son más bien frases comerciales o simples
exageraciones.
 ... que refresque mejor
 ... que la huella de carbón sea verde
 ... que sea el número uno en el mercado
 ... que resista todas las pruebas
 ... que vuele bajo el radar
 En estos casos hay que investigar para qué quieren eso (beneficio
para el usuario y la comunidad) y cómo lo van a medir.
Cuidado con ... sueños guajiros
página 41

Controlar los recursos
 Controlar los recursos
disponibles para ejecutar las
actividades y preparar los
productos.
pág. 42

 Donald Firesmith, Software Engineering Institute, 2003
 Dos de cada tres proyectos de
software iniciados este año no
alcanzarán a satisfacer las
expectativas de sus clientes
por:
 entregas tardías,
 presupuestos excedidos,
 funcionalidad incompleta, y
 cancelación.
Falta de control
página 43

La Comunidad
Clientes, usuarios
y otros
interesados
La Comunidad
Clientes, usuarios
y otros
interesados
Gestión de
recursos
Responsabilidad
de la dirección
Medición y
análisis
Satisfacción
Productos
y servicios
Mejora
continua
Necesidades y
expectativas
Recursos
humanos y
materiales
Controlar los recursos
página 44

 (En cualquier proyecto ...) antes de dar el sí, determina qué
recursos necesitas y cómo vas a obtenerlos.
 Ya dentro, prepara un plan que esté
 alineado con los requisitos que conoces
 basado en tus mejores procesos ... y
 actualízalo frecuentemente.
 Asegúrate de que todos sepan qué pueden esperar de ti en cuanto a
responsabilidad y compromiso ...
 y averigua qué puedes esperar de los demás.
 Prepárate para reaccionar rápido (mantente informado).
 Aprende sobre la marcha.
Piensa en los recursos
página 45

Planeación
1 2 3 4 5
Plan
• Esfuerzo
• Inicio y fin
• Ejecutante
• Recursos
• V&V
• Defectos
• Retrabajo
• etcétera...
Planeación
Proceso
• Rol
• Actividad
• Secuencia
• Insumos
• Producto
Actividad específica
(instancia)
1
2
3
4
5
página 46

Calcular el avance
 Calcular la situación del
proyecto con base en
mediciones y modelos
formales (no en intuición).
pág. 47

La Comunidad
Clientes, usuarios
y otros
interesados
La Comunidad
Clientes, usuarios
y otros
interesados
Gestión de
recursos
Responsabilidad
de la dirección
Medición y
análisis
Satisfacción
Productos
y servicios
Mejora
continua
Necesidades y
expectativas
Recursos
humanos y
materiales
Calcular el avance
página 48

 Distingue entre producto y basura.
 El retrabajo es costo, no beneficio.
 El esfuerzo sólo es útil si añade valor
 Valida los resultados intermedios contra los requisitos:
 expectativas,
 supuestos y
 restricciones
 Haz evaluaciones formales para saber si ya acabaste:
 Inspecciones
 Auditorías
 Pruebas
Piensa en las mediciones
página 49

Validación
SGC
?
página 50

 Comprobar que un producto o componente cumple con la intención
de uso en el ambiente en que se usará.
 Seleccionar los productos que se validarán (por ejemplo)
 código ejecutable, software de terceros, prototipos, manuales,
material de entrenamiento.
 Establecer un ambiente apropiado para la validación
 Establecer procedimientos y criterios alineados con las
características de los productos que se validan, restricciones en
los métodos que se pueden usar y el ambiente de validación
 Ejecutar las actividades de validación
 analizar los resultados y tomar acción.
Validación
página 51

Verificación
SGC
?
página 52

 Asegurar que los productos seleccionados cumplen con los
requisitos documentados.
 Seleccionar los productos que serán verificados
 Establecer el ambiente para la verificación
 Establecer procedimientos y criterios de verificación
 Ejecutar procedimientos de verificación
 inspecciones entre colegas (peer review)
 otros métodos de verificación (análisis de cobertura, pruebas
de carga y desempeño, árboles y tablas de decisión)
 Analizar los resultados y tomar acción
Verificación
página 53

Auditoría
SGC
?
página 54

 Aportar visibilidad para el personal del proyecto, el cliente y otros
interesados acerca de los procesos que se usan y los resultados que
se obtienen.
 Comparándolos con el proceso definido
 Señalando las diferencias
 Sin hacer juicios de valor
Auditoría
página 55

 Registrar todos los defectos,
hallazgos y fallas y darles
seguimiento hasta su
resolución.
 Usar la información obtenida
acerca de los defectos
recurrentes para mejorar el
sistema.
Corregir y prevenir
página 56

 Adaptado de "A Discipline of Software Engineering"
Sospechosos comunes
Las causas más frecuentes Humphrey
Educación No entendiste cómo hacer algo.
Comunicación No fuiste informado de que tenías que hacer algo.
Descuido Olvidaste hacer algo: “después lo arreglo”
Transcripción Sabías qué hacer, pero te equivocaste.
Proceso De algún modo, el proceso te dirigió mal.
página 57

Actividades (uso de recursos)
página 58

Ejemplo de reporte
Número Esfuerzo
Artefactos Defectos Esfuerzo total Base Evaluación Prevención Retrabajo
Iteración Semana Ppto Real % Plan Real % Ppto Real % Plan Real % Plan Real % Plan Real % Plan Real %
It1 1
It1 2
It1 3
It2 4
It2 5
It3 6
It3 7
It4 8
It4 9
It4 10
It4 11
It4 12
It5 13
It5 14
It5 15
It5 16
página 59

Comunicar el estado
 Comunicar el estado del
proyecto correcta y
oportunamente a todos los
responsables de tomar
decisiones.
pág. 60

La Comunidad
Clientes, usuarios
y otros
interesados
La Comunidad
Clientes, usuarios
y otros
interesados
Gestión de
recursos
Responsabilidad
de la dirección
Medición y
análisis
Satisfacción
Productos
y servicios
Mejora
continua
Necesidades y
expectativas
Recursos
humanos y
materiales
Comunicar el estado
página 61

 Identifica a todos los interesados relevantes
 ¿Qué información necesitan, cómo y cuándo?
 No te conformes con enviar la información.
 Confirma que la recibieron y entendieron
 Asegúrate de que todos trabajan con la versión correcta de …
 documentos
 registros
 Asegúrate de incorporar los cambios correctos.
 todos los cambios autorizados
 sólo los cambios autorizados.
Piensa en la comunicación
página 62

Gestión de documentos
página 63

Establecer mejora continua
 Identificar las causas de
defectos y otros problemas
para erradicarlas y evitar su
recurrencia.
 Identificar oportunidades de
mejora e incorporarlas al
proceso para mejorar el
desempeño.
pág. 64

 Enfócate en la prevención.
 Aprende a oler los problemas (diagnosticar las causas de
defectos recurrentes). No esperes a que aparezcan.
 Asegúrate de que tus procesos tienen sentido
 que todos los participantes los entienden
 que los siguen puntualmente
 que miden los resultados (capacidad del proceso) y que tienen
autoridad y competencia para mejorarlos cuando hace falta.
Piensa en la mejora continua
página 65

La Comunidad
Clientes, usuarios
y otros
interesados
La Comunidad
Clientes, usuarios
y otros
interesados
Gestión de
recursos
Responsabilidad
de la dirección
Medición y
análisis
Satisfacción
Productos
y servicios
Mejora
continua
Necesidades y
expectativas
Recursos
humanos y
materiales
Establecer mejora continua
página 66

 Mejorar un proceso es modificarlo para que el producto
correspondiente se produzca:
 más rápido,
 de manera más económica o
 con mejor calidad.
Mejora de procesos
página 67

• Establecer
prácticas que
reduzcan los
errores y
defectos, como el
uso de procesos y
herramientas.
• Medir la
conformidad de
procesos y
productos con los
estándares
relevantes.
• Encontrar y
corregir los
defectos antes de
usar los productos
intermedios.
• Encontrar las
fallas y corregir
los defectos antes
de entregar al
cliente.
• Corregir fallas con
rapidez y al menor
costo posible.
• Contener el daño
por efecto de
fallas.
• Conservar al
cliente.
Prevención Falla internaEvaluación Falla externa
1
2
3
página 68

Resolver problemas por sus causas
Causa
Acción
Problema
Resultado
• El sistema no tiene el
resultado esperado
(costo y beneficio)
• Situación
deseada medible
• Situación actual
conocida
• Brecha medible
• Comunicaciones
• Entrenamiento
• Proceso mal definido
• Falta de atención al
detalle
• Error manual (typo)
Cambiar el sistema:
• Comunicaciones
• Entrenamiento
• Proceso
• Productos
• Métodos
• Herramientas
• Mejora medible en los
resultados (reducción
de la brecha).
• Registro útil para otros
proyectos,
• Mejoras al SGC.
página 69

Ciclo de Shewhart
Especificación InspecciónProducción
Paso I Paso IIIPaso II
Antes
Ahora (1939)
Especificación
(corregida)
Producción
Inspección
Hipótesis EvaluaciónExperimentos
Manufactura
Método científico
página 70

Ciclo Deming PDCA
Do
Plan
Check
1. Prepara un
plan
2. Ejecuta un
piloto
3. Verifica el
resultado
4. Toma las
acciones
necesarias
Act
página 71

Mejora de procesos
D
Define
Definir las metas de la actividad de mejora
Ciclo de mejora de procesos six sigma
M
Measure
Medir el desempeño del sistema actual
A
Analyze
Analizar el sistema para identificar las oportunidades
I
Improve
Implantar mejoras al proceso de manera creativa
C
Control
Controlar el nuevo sistema hasta que esté institucionalizado
página 72

A I C
El método
• Identificar el problema
• Medir el efecto (pérdida
social) en costo o esfuerzo
= “la Y”)
• Medir efectos del problema
en indicadores secundarios
(x)
• Con base en las
mediciones obtenidas,
describir la relación entre
las x y la Y.
• Describir la situación
deseada en términos
medibles (x, Y)
• Describir el grupo de
actividades que se analiza
(alcance).
• Identificar los puntos clave
(habilidades,
comunicaciones, detalle,
etc.).
• Identificar dónde se
manifiesta el problema.
• Generar listas de causas y
factores (a favor y en
contra).
• Confirmar o corregir las
hipótesis acerca de la
relación x, Y
• Estimar el efecto de cada
causa (x) o grupo de
causas en “la Y”
• Identificar acciones que
puedan impactar las
principales causas y su
efecto probable en “la Y”
• Seleccionar las acciones
que sean factibles y
ofrezcan mejor relación
costo:beneficio.
• Para cada acción,
identificar un objetivo
“SMART” y negociarlo con
el responsable de
ejecutarlo.
• Definir un calendario de
seguimiento.
• En las fechas acordadas
revisar el avance.
• Verificar y registrar el
cierre (todos los objetivos
alcanzados).
• Definir “siguientes pasos”.
Al menos, calendario de
medición de resultados.
• Registrar acciones
exitosas y definir cómo y
cuándo se incorporarán al
sistema para beneficio de
otros.
• Registrar acciones fallidas
y diseñar actividades para
evitar su recurrencia.
D/M
página 73

Resumen
pág. 74

HERE is Edward Bear, coming
downstairs now, bump, bump, bump, on
the back of his head, behind
Christopher Robin.
It is, as far as he knows, the only way of
coming downstairs, but sometimes he
feels that there really is another way, if
only he could stop bumping for a
moment and think of it.
And then he feels that perhaps there
isn't.
A. A. Milne
Winnie the Pooh
página 75

La Ruta Corta Hacia un Proyecto Exitoso
Gracias
(vamos a las preguntas)
Si no acabamos, publicaré
las respuestas en el blog.
pág. 76

La ruta corta a proyectos exitosos

Recomendados

Recomendados

Más contenido relacionado

La actualidad más candente

La actualidad más candente (10)

Destacado

Destacado (13)

Similar a La ruta corta a proyectos exitosos

Similar a La ruta corta a proyectos exitosos (20)

Último

Último (20)

La ruta corta a proyectos exitosos