Ir al contenido principal

Menos proyectos, más hipótesis!


Si las empresas quieren equipos disruptivos-creativos, tiene que ofrecer un entorno seguro para ello, y una de las implicaciones es ir cambiando el concepto de proyectos por hipótesis.
Una hipótesis es una suposición a partir de datos, desde mi punto de vista el "a partir de datos" es útil para no caer en la anarquía y costos que implica la "intuición", aunque en ciertas ocasiones pueda ser valida.
Recientemente tuve la satisfacción de escuchar a un líder y alto directivo, dirigirse a 700 personas y decirles: "Celebremos las fallas, porque significa que aprendimos algo", estoy seguro que ese momento marcó un punto de inflexión para todos los que forman parte de esa empresa, y muy pronto se verá reflejado en mejores productos para sus clientes.
Fallar es algo natural, humano, cuando estábamos pequeños nos caímos varias veces para luego obtener el gran triunfo de poder caminar. El problema es que las empresas en algún momento olvidaron que estaban formadas por gente, personas, seres humanos. Aquellas empresa que castigan "fallar, experimentar", no lograrán ser competitivas en el entorno de hoy.
Sin embargo, al cambiar el concepto de proyectos por hipótesis o experimentos, los equipos dejan de un lado el miedo a fallar y se enfocan en validar la premisa. En estos casos, "fallar" no depende si la suposición resulta positiva o negativa, en ninguno de los casos fallamos; si validamos la hipótesis rápido y a bajo costo, en ambos casos seriamos exitosos.

¿Falló el equipo? -Historia de la vida real (muy reciente), con algunos cambios para proteger la identidad de los participantes :) -

Teníamos un proyecto, cuyo presupuesto es de US$ 100,000 y una duración estimada de 1.5 años. En lugar de llevarlo con una gestión tradicional, se define un Producto Mínimo Viable y se trabaja con iteraciones cortas, equipo enfocado y entregables continuos de valor (Scrum).
Tres meses después, se puso el MVP en producción, al alcance del cliente final, el proyecto pasó a una fase de validación en los siguientes 3 meses, donde se obtuvo feedback de los usuariosEn esos 6 meses, los altos directivos tomaron la decisión de suspender la iniciativa, porque no se cumplieron los indicadores esperados, (quizás el momento no era oportuno para esa iniciativa), la iniciativa vuelve al backlog.
Resultados:
  • En lugar de esperar 2 años, sólo en tres meses pudieron tener un MVP a disposición del cliente final.
  • En lugar de tener ocupado un equipo por 2 años, a los 3 meses ya pudieron iniciar una nueva iniciativa.
  • En lugar de consumir un presupuesto de US$ 100.000, utilizaron menos del 10%, el resto se pudo utilizar para nuevas iniciativas.
Conclusión,
1.- Cambia proyectos por hipótesis o experimentos. MVPs o Productos Mínimos Viables.
2.- Crear un entorno seguro para que tus equipos puedan ser creativos y disruptivos.
3.- Deja que tus equipos se auto-organicen para lograr validar hipótesis rápidamente y a bajo costo.
Gracias por leer, y bienvenido tus comentarios.!


Comentarios

Gracias Gus por compartir tus experiencias que nos ayudan a los que estamos en este camino a sentirnos seguros sin perder el foco en la mejora continua.
Un abrazo,
Dani.
Rubén Moreno dijo…
Excelente reflexión Gus, lo único que pienso podría enfatizarse más es el "a partir de los datos", ya que pienso que no sólo es útil, sino indispensable, ya que ahí es donde se da la inflexión de cambiar de la "creencia" o "feeling" a las hipótesis como oportunidad de negocio :)
Gustavo Bonalde dijo…
Gracias a ti Dani, por leerme.
Gustavo Bonalde dijo…
Coincido contigo amigo Ruben, siempre con tus comentarios acertados.

Entradas más populares de este blog

¿Cuál programa tomo? ScrumAlliance vs. Scrum.org

Luego de participar en varias discusiones de foros acerca de las distintas certificaciones que existen de Scrum, me decidí a escribir este post para tratar de aclarar este enredo (CSM, CSPO, CSD, CSP, CSC,CST, PSD, PSF, PSM, PSPO, PMI-ACP) que a veces surge con todo esto.

Resulta que los 2 principales organismos ScrumAlliance y Scrum.org (hay otros varios como ScrumManager.net) que ofrecen los cursos de certificación en Scrum, vienen del mismo origen: Ken Schwaber. En una carta del año 2010, Ken explica por qué deja el ScrumAlliance y decide crear un nuevo instituto: "Este viajeha sido moldeado pordos fuerzas opuestas: el deseo dehacer lo correcto,y el deseo deganar dinero.ForméScrum.orgpara reenfocarmis esfuerzos enhacer lo correcto.".. Lo cierto es que no se puede negar el factor "revenue" para estas empresas, por su cursos, certificaciones y assessment que ofrecen, al igual que su objetivo de divulgar Scrum y mantenerlo por un buen tiempo.

A continuación les dejo…

Borrador de la 6ta edición de PMBOK

Les dejo un extracto de los cambios más relevantes del borrador del PMBOK 6, cuya versión definitiva se prevé para el tercer trimestre del 2017.

La secciones de la 1-3 han sido modificadas, dejando la información importante y agregando nueva información que refleja la evolución del Gerente de Proyecto hacia agente de cambio y proveedor de valor de negocio. En la sección 1, se incorporan términos relacionados con enfoques ágiles y entornos iterativos y adaptativos.Los grupos de procesos se mantienen igual que en la versión 5.Cambian de nombre 2 área de conocimiento:
Versión 5 Versión 6 Project Time Management Project Schedule Management* Project Human Resource Management Project Resource Management.

*Me gusta, porque definitivamente el tiempo no se gestiona, podemos gestionar son las actividades.

Hacer las cosas correctas vs Hacerlas correctamente

"Hacer las cosas correctas" es un aspecto de satisfacción en el producto, servicio o resultado que se quiere hacer, mientras que "Hacerlas correctamente" se refiere más al método utilizado en su desarrollo o implementación.

Existen cuatro combinaciones posibles:

Hacer lo correcto y hacerlo correctamenteHacer lo correcto y hacerlo incorrectamenteHacer lo incorrecto y hacerlo correctamenteHacer lo incorrecto y hacerlo incorrectamenteSi lo llevamos a los conceptos de Management: "Estrategia y Táctica", la combinación quedaría de la siguiente manera:
Se tiene una estrategía y se cuenta con una táctica adecuada (el estado del arte)Se tiene una estrategía y no se cuenta con una táctica (según Sun Tzu “Strategy without tactics is the slowest route to victory" )No se tiene estrategía, pero se cuenta con una táctica adecuada (según Sun Tzu "Tactics without strategy is the noise before the defeat”)No se tiene estrategía, ni tampoco con táctica (al menos …