domingo, octubre 21, 2012

Proyecto Oxígeno de Google - ¿cómo ser mejores líderes/gerentes/jefes de proyecto?


A principios del 2009, los investigadores de Google, se embarcaron en un proyecto al que llamaron Oxígeno. Su objetivo era construir mejores jefes. Se analizaron las revisiones de desempeño, las encuestas de opinión y nominaciones para los premios de alto gerente. Se correlacionaron frases, palabras, elogios y quejas.


Y se encontraron con los mísmos resultados de siempre pero dejan grandes enseñanzas:


  1. Sea un buen coach.
  2. Faculte a su equipo y evite la micro gerencia.
  3. Exprese interés en el éxito y el bienestar de los miembros del equipo.
  4. No sea tímido: Sea productivo y este orientado a los resultados.
  5.  Sea un buen comunicador y escuche a su equipo.
  6. Ayude a sus empleados con el desarrollo de sus trayectorias profesionales.
  7. Establezca una estrategia y visión claras para el equipo.
  8. Tenga habilidades Técnicas clave para poder aconsejar al equipo.




  • Ver artículo original en el New York Times - clic aquí
  • Ver presentación realizada por la estudiante del curso de Planeación y Gestión de Proyectos Informáticos (el cual imparto) de la Especialización en Ingeniería de Software de la Universidad de Medellín. - clic aquí

Proyectos a la medida de las pymes

Presentó el trabajo realizado por uno de mis alumnos Enrique Arango Lyons de la materia Gestión de Proyectos informáticos que dicto en el pregrado de Ingeniería de Sistemas en la Universidad Eafit en Medellín.

Para ver el artículo haga clic aquí.

Lean Thinking, Dirección de Proyectos usando PMBOK y aportes a la gestión de proyectos informáticos

Hola a todos

Presentó el trabajo realizado por uno de mis alumnos (Juan Felipe Arango Aguirre) de la materia Gestión de Proyectos informáticos que dicto en la Universidad Eafit en Medellín.

Para ver el artículo haga clic aquí

Técnicas de negociación según el cliente y su personalidad

Hola a todos

Presentó el trabajo realizado por uno de mis alumnos (Daniel Camilo Vergara Marin) de la materia Gestión de Proyectos informáticos que dicto en la Universidad Eafit en Medellín.

Para ver haga clic aquí: Técnicas de Negociación según el Cliente


sábado, octubre 20, 2012

Frases para no olvidar en gerencia de proyectos


  • “Foco muchachos... foco.. ”  (tener siempre presente el objetivo del proyecto e impedir que tanto desarrollos clientes, como el equipo de trabajo.. pierdan el foco por fuera de los objetivos)

  • Respecto al perfeccionismo:“Lo perfecto es enemigo de lo bueno” /  En inglés “perfect is the enemy of good.” / en francés  “le mieux est l’ennemi du bien”.

  • “Se gestionan acuerdos no personas”. Sobre un acuerdo usted puede negociar y lograr compromisos, en cambio las personas no se les puede comprometer si no existen acuerdos previos.

  • “Ataque los riesgos activamente o ellos lo atacarán a usted”. - “Attack the risks actively or they will attack you.” (Tom Gilb) 

  • “El gerente de proyecto es un integrador”. - Insisten en ella el PMBoK y todos los libros de gerencia de proyectos y otra muy asociada a esta: "El gerente de proyecto remueve objeciones" trabaja en pro de que no hayan elementos u obstáculos que atrasen o afecten negativamente el proyecto.

  • El software de nada sirve en manos del equipo de desarrollo, el software solo tiene valor cuando es visto, palpado y sentido por el cliente, por lo tanto, genere software usable lo antes posible para mostrar avance y mostrar valor.

  • “La buena gestión no puede garantizar el éxito del proyecto. Sin embargo, la mala gestión usualmente lleva al fracaso del proyecto” (Sommerville, 2005).


martes, octubre 16, 2012

Reflexiones sobre la planeación



  • Planear no garantiza que las cosas no salgan mal, pero NO-PLANEAR, sí. (Similar al pensamiento: PENSAR es gratis, pero no pensar puede salir muy caro)

  • Los planes deben trabajar para el proyecto, no  el gerente de proyecto para los planes. 

  • Hacer los planes necesarios y suficientes para que tu proyecto este controlado, revisa de los siguientes planes cuales realizar:
    • alcance
    • tiempo 
    • costo
    • recursos humanos
    • calidad
    • comunicaciones
    • riesgos
    • adquisiciones  
    • (es decir, identificar si requieres cubrir las áreas de conocimiento del pmbok, o más, o menos necesidades en tu proyecto).



domingo, octubre 07, 2012

Recomendaciones sobre el sobre-esfuerzo del equipo en un proyecto

Si por alguna circunstancia el equipo se debe sobre-esforzar, trabajar horas extras, trabajar de más, etc (ojalá esto no sucediera, pero pasa), ya sea por:

  • Mala planeación
  • Premura del proyecto por algún requisito del cliente, externo o interno.
  • Imprevistos
  • etc

considere las siguientes sugerencias para el equipo o miembro del equipo:
  • Sea humano...
  • Por lo general aplazar el almuerzo no genera valor. Permita que su equipo o miembro del equipo almuerce con tranquilidad y calma, de forma que regrese de nuevo a las labores críticas que tiene encomendadas.
  • No permitir que se trabaje de forma sobre-esforzada por más de dos semanas pues al final, aunque su equipo sea comprometido, después el agotamiento se volverá en su contra impidiendo concentración, y éxito en las tareas encomendadas. Descanse una semana (horario normal) y retome el sobre-esfuerzo en caso de ser necesario.
  • Cuando comprometas un sobre-esfuerzo que sea hasta un máximo de horas adicionales, ejemplo: 2 horas más, 3 horas más al día, durante un periodo, pero:
    • Que se descanse los domingos
    • Y si se se trasnocha que sea una sola noche. dos seguidas o más veces seguidas el agotamiento se vendrá en contra del equipo y el rendimiento bajará.
  • Acompañe a su equipo no lo deje solo sobre-esforzándose. En caso de no poder estar presente, esté disponible para resolver cualquier inquietud.
  • Si alguien del equipo durante el sobre-esfuerzo requiere un permiso, concédalo, no tiene sentido que el sacrifique su tiempo pero cuando se le pida un permiso usted no lo autorice.
  • Mantenga esta regla: PRIMERO LAS PERSONAS QUE EL PROYECTO. Si pasa algo grave, o alguien se enferma, etc, primero es la persona que el proyecto, no sea inhumano con su equipo.




Dice Sun Tzu en el arte de la guerra:
"Las armas son instrumentos de mala suerte; emplearlas por mucho tiempo producirá calamidades. Como se ha dicho:"Los que a hierro matan, a hierro mueren." Cuando tus tropas están desanimadas, tu espada embotada, agotadas tus fuerzas y tus suministros son escasos, hasta los tuyos se aprovecharán de tu debilidad para sublevarse. Entonces,aunque tengas consejeros sabios,al final no podrás hacer que las cosas salgan bien."


sábado, septiembre 29, 2012

Mi experiencia con SCRUM

Hay que reconocer que el desarrollo iterativo no fue inventado por la metodologías ágiles pero si fue reforzado por ellas.

Esta es la historia...


Antecedentes
Hace tres meses (hoy es 29 de septiembre de 2012) vengo liderando un proyecto móvil con las siguientes características:
  • Dispositivo IPADs, (aunque se quiere que tambien funcione en web)
  • PhoneGap como framework de implementación de la interfaz gráfica
  • Arquitectura: SOA - Consulta a la capa de datos a través de mediaciones sobre Websphere ESB
  • Motor de reglas de negocio: DROOLS.
  • Duración del proyecto: 8 meses aproximadamente
  • Fecha de inicio: Mayo de 2012
  • Ciclo de vida cascada
  • Reporte en Project Server
  • Horas de equipo de 5 personas con 45 horas diarias laborales de trabajo.
Cuando recibí  el proyecto ya se encontraba 2 meses avanzado y el entregable para pruebas del cliente era para mediados de noviembre. Por lo tanto solo hasta 3 semanas antes de esa DEADLINE (nombre muy bien puesto.. si seguiamos asi.. sería la muerte) podría hacer clic en el sistema.


Nudo
Decidí implementar todo lo que había leído y recopilado de SCRUM (ver diapositivas) y defendido en las cursos de gerencia de proyectos informáticos que dicto en el un pregrado (Ingeniería de sistemas - Universidad Eafit - Medellín) y un posgrado (Especialización en Ingeniería de Software - Universidad de Medellin)

Elementos adoptados de SCRUM:
  • Product Backlog
  • Sprint Backlog  (reporte de avance en google docs)
  • 3 Sprints de 1 mes (concertado con el equipo)
  • Burndown Chart (reporte de avance en google docs)
  • Velocidad  (reporte de avance en google docs)
  • Standup meeting 
  • Sprint review
  • Sprint retrospective
No se adoptaron:
  • Un el backlog de tareas sin dueño y cada cual va y "selecciona" la tarea que quiere.
  • El cliente inmerso en el equipo
  • Escritura de historias de usuario.
Se conservó:
  • Artefactos requeridos por la metodología de la empresa:
    • Casos de uso
    • Documento de arquitectura
    • Casos de prueba
    • Manual de instalación y despliegue
    • Manual de usuario
    • Prototipo navegable
  • Gestión de proyectos basada en el PMBoK

Y se tenían los siguientes problemas
  • El único que conocía el avance era el gerente de proyecto
  • Los ingenieros tenía un listado de tareas que realizaban según disponibilidad de los insumos sin un objetivo común
  • Los ingenieros percibían que no iban a alcanzar a realizar la entrega pero no lo habian comunicado.

Desenlace
Luego de implantar Scrum estas son algunas de las conclusiones.
  • El seguimiento es propiedad del equipo, no solo del gerente del proyecto. Siendo el burndown chart una propiedad del equipo y un compromiso de todos tenerla actualizada.(a todos nos da felicidad de la gráfica baje!!!)
  • Las reuniones de seguimiento diario han mejorado comunicación y dinámica del equipo (más detalle acá)
  • Se resolvieron problemas de salida a pruebas mucho tiempo antes de enfrentarnos con ellos en 
  • El cliente tiene un lugar donde hacer  "clic" y percibir el avance.
  • El equipo se encuentra altamente motivado.
  • Mitigación temprana de riesgos de desarrollo, y pruebas.
  • Equipo enfocado en un objetivo común: EL SPRINT!!.
  • Obtencion de una velocidad del equipo que permite predecir entregas (de 25 a 33 horas por día - similar a lo que dice PSP, que solo es efectiva la mitad de nuestro tiempo laboral).
  • Menos presión sobre el cronograma
  • Un enfoque a los objetivos
Burndown Chart - Iteración 1

Velocidad - Iteración 1



martes, agosto 28, 2012

Standup meeting - ventajas y observaciones

Responder siempre:

  • qué se hizo ayer
  • qué se va a hacer hoy
  • existe algún impedimento
  • [adición 2013-01-24] (una buena cuarta pregunta) que nivel de confianza tiene de que vamos alcanzar el objetivo.
  • [adición 2013-01-24] (otras dos preguntas) 
  • ------ que aprendí
  • ------ que me tiene inconforme y que me molesta
Consejos
  • enfocarse en responder las tres preguntas
  • no extenderse en explicaciones que no corresponden al contexto
  • mantener el foco 
  • SE PUEDE HACER SENTADO..  :) [corrección 2013-01-27] Aunque se puede hacer sentado, definitivamente estar de pie hace que no divaguemos tanto, y contestemos rápidamente las tres preguntas. 
  • Se puede llevar una lista (hoja de cálculo de google docs, excel publico) donde todos observen que se va  haciendo
  • lo que se respondió ayer en " qué se va a hacer hoy" para una persona sirve para iniciar la lista de " qué se hizo ayer" de una persona
  • Controlar el tiempo
  • No es una reunión para reportar tiempos.. existen otros espacios para eso
Ventajas
  • todo el equipo mantiene el contexto
  • el equipo sabe que están haciendo sus miembros y buscan como ayudar y hacer más eficiente el día.
  • Se identifica en equipo el foco del día.

miércoles, julio 25, 2012

Si la entrega esta enredada - planear al detalle

Llevas tratando de entregar el proyecto hace un buen tiempo y siempre incumples la fecha de entrega.

Realiza:

  • un plan detallado con tu equipo de trabajo
  • identifica todas las dependencias externas e internas
  • plásmalas en el cronograma
  • identifica riesgos y priorizalos de forma que no hayan más sorpresas.
  • no presiones a tu equipo para que te dé fechas irreales

Equilibrio en en el seguimiento

No realizar micro-seguimiento
y cada semana es demasiado lejos

Lograr un equilibrio 

martes, julio 03, 2012

Proporcionalidad entre la Presión y Estimados Irreales


A mayor presión sobre el equipo de trabajo en realizar estimados se logrará un estimado más irrealista.

El equipo se comprometerá con fechas no factibles para satisfacer los compromisos irreales.


Conclusiones:

  • No presione por tiempos y compromisos irrealistas. 
  • Respete los tiempos que dice el equipo y logre un compromiso sobre ese tiempo de proyecto
  • Defienda el tiempo proporcionado por el equipo ante las diferentes instancias



__

jueves, junio 28, 2012

Ley de la inestabilidad temporal de los requisitos


Un mismo requisito de software cambiará varios meses después, aunque este sea indagado a la misma persona.




Conclusión:

  • Logre la firma y acuerdo sobre los requisitos cuando los levante




__


miércoles, junio 27, 2012

La suficiencia de las metricas y métricas básicas

Siempre que crees una métrica piensa:

  • ¿es realmente necesaria?
  • ¿quien la va a utilizar?
  • ¿cuantas cada cuanto las va a usar?
  • ¿es muy fácil o difícil obtenerla?
  • ¿proporciona información de valor?
  • e insisto... ¿es realmente necesaria?
Un listado básico de metricas es:
  • SPI
  • CPI
  • Número de defectos post-producción
  • % de desviación en plazo
  •  % de desviación en esfuerzo
  • Número de cambios
  • Número de no-conformidades

Ley de las métricas

Sino lo mides

  • no lo puedes controlar
  • no lo conoces

Continuidad en la evaluación de los riesgos

¿ya identificaste todos los riesgos con su impacto?

en serio..¿ya identificaste todos los riesgos con su impacto

insisto ¿ya identificaste todos los riesgos con su impacto?  

-


---
¿y le hiciste seguimiento a los identificados?




_

Ley de la palabra escrita y la memoria selectiva



Sino esta escrito no existe.



En una discusión el cliente recordará del pasado lo que le convenía y tu también (sin ni siquiera tener mala intención)

Si es importante, escríbelo y que quede en el acta, mail o documento respectivo.


___

La eficacia de las metodologías

No todas las metodologías de desarrollo son para solucionar todos los tipos de proyectos y escenarios.

De igual forma, que la Aspirina por más buena que sea no sirve para curar todas las enfermedades.

Escoge o adapta la metodología de desarrollo de acuerdo a los clientes, entregables, fases, equipo y factores ambientales del proyecto.



_

Nunca satisfarás al cliente o ley de la eterna insatisfacción

Nunca pongas en un contrato o en un levantamiento de requisitos:

"se desarrollará a satisfacción"

La satisfacción es un tema ambiguo, lo que satisface a unos, no satisface a otros, y nunca entregarás el proyecto.

Pon mejor:

"se construirá/desarrollará/implementará de acuerdo con los requisitos aprobados"



_

Fases.. siempre fases

Siempre fasée (sé que es incorrecta gramaticalmente) los proyectos, y ponga pagos de acuerdo a las fases.



_

Sobre el acta de cierre

No ir nunca a una reunión de cierre de proyecto, fase o iteración sin el acta de cierre impresa.


Todas las demás actas podrán manejarse de forma digital pero esta debe realizarse debe obligatoriamente realizarse de forma física

La eficacia de la calidad y la documentación

La calidad y la documentación deben trabajar para ti y no al contrario.




---

Eterna ley de las lecciones aprendidas

Sino aprendes de tu errores (o los de tu empresa) estarás condenado a repetirlos.

Teorema general sobre hacer las cosas demasiado rápido y sin atención

Si te pones a hacer algo rápido y sin revisar para cumplir una entrega rápida, con seguridad gastarás más del doble corrigiendo cuando te lo devuelvan.

Mejor entrega poco pero entrega bien y ve liberando presión

(esta lección esta en construcción)