Publicado por
(
23:58
)
Después de un exitoso proyecto en el que, y sin que sirva de precedente, se han cumplido todas las fases (entre otras: reunión de Kick-off, fundamental en este proyecto Queda por delante una nueva etapa en la que dar soporte y mantenimiento a la release.
Damos la enhorabuena a todos los stakeholders involucrados. Y, sobre todo, ánimos para la nueva etapa.
Publicado por
(
12:47
)
El XXI Congreso ISPIM (International Society for Professional Innovation Management) tendrá lugar en Bilbao del 6 al 9 de Junio de 2010, con el título de “The Dynamics of Innovation”.
El congreso cuenta con el patrocinio de Innobasque (Agencia Vasca de Innovación) y está organizado por ISPIM.
Publicado por
(
20:01
)
La primera es basarse en el tiempo, es decir, el responsable del producto, que a mí me gusta llamar Product owner (PO), decide claramente CUANDO se va a realizar el release y cuando llega la fecha la nueva versión se pone a disposición de los usuarios con las nuevas funcionalidades que se hayan conseguido desarrollar desde la planificación. Por supuesto es muy importante saber que funcionalidades son las más importantes para que sean desarrolladas las primeras.
La segunda es basarse en funcionalidades. En este caso el PO hace hincapié en qué funcionalidades son requisito indispensable para que una nueva versión se ponga a disposición de los usuarios finales y cuando estas son desarrolladas, se obtiene el nuevo release.
Publicado por
(
17:59
)
Cuasiestimaciones, así es como he decidido traducir el concepto de Guesstimates. Es gracioso el por qué se ha tenido que inventar esta palabra. En un principio la palabra estimación por sí sola ya lleva una connotación de incertidumbre, por lo que a la hora de dar una estimación se presupone que esta puede ser errónea.
Aun así, los miembros del equipo directivo no son capaces o no quieren entender esto y creen que una estimación es una verdad y punto.
De hecho en el caso de que una estimación no se cumpla es muy probable que incluso castiguen a la persona responsable. Por supuesto, este hecho nos lleva a que las personas responsables de dar una estimación se cubran las espaldas y/o den sobreestimaciones o en su defecto cuasiestimaciones. De esta manera, aunque parezca increíble, los jefes asumen el hecho de que la cuasiestimación no tiene por qué ser correcta y aceptan una desviación.
En el mundo del software esto se ha puesto muy de moda y por lo menos en el caso que yo conozco con estas cuasiestimaciones estamos obteniendo mejores estimaciones que anteriormente. Por un lado creo que el equipo de desarrolladores ha mejorado a la hora de estimar (cuasiestimar) pero además el equipo directivo ya no presiona con las fechas tanto como antes al estar claro que las estimaciones no son una verdad total.
Suscribirse a:
Entradas (Atom)