spinner

¿Proyecto?, ¿Producto?, ¿Quién hace qué? Un project manager es alguien que se encarga de administrar tareas, tiempos y alcance, generalmente de un proyecto o de una persona pero no tiene conocimiento o pasión por el dominio/responsabilidad del producto.

Me remontaré un poco al significado etimológico del concepto manager que fue tomado del italiano maneggiare que significa básicamente “conducir una acción» y más específicamente en el ámbito de caballos, comúnmente el término se acuño para deportistas o artistas que necesitaban ser manejados. De aquí que las responsabilidades que se asocian son a administración de tareas.

El enfoque que tiene un manager es principalmente sobre alcance, tiempos y presupuesto que conllevan para llegar a metas, esto suena algo parecido a desarrollo de software ¿no?, pues si, si estuviéramos desarrollando software en 1950 y si usáramos modelos rígidos como waterfall donde la planeación es poco tolerante a cambios o mejor dicho ni siquiera está diseñada para los cambios. Por eso es y era tan importante para la administración de proyectos definir las actividades y sus tiempos (milestones) así como estar detrás de que se cumplan los tiempos por si algo sale mal. Las consecuencias de definir el alcance y tiempos antes de que siquiera alguien conozca lo que realmente se va a construir y sin tener aprendizaje ni contacto real con la complejidad (más adelante lo veremos) son:

  • Pérdida de ROI (Return On Investment)
  • Estimaciones no fundamentadas
  • Rigidez al cambio por si el mercado o negocio cambia de dirección
  • Riesgos técnicos
  • Deuda técnica
  • Desviación de la visión del producto

Entre muchos más que la entrega continua de valor, empirismo y validación de aprendizaje resuelven.

Estos pilares de papel para el desarrollo de software no funcionan debido a que sólo se centran en el proyecto y el negocio no se ve incluido en esta parte la cual es muy importante porque al final al usuario se le entrega un producto.

Hasta este momento no hemos visto cómo es que el project manager o las actividades aportan valor, de hecho lo que van a ir aportando son entregables grandes y a largo plazo, lo que significa que involucra menos al cliente y por lo tanto su feedback se obtiene después de mucho tiempo para cuando cualquier ajuste requiere mucho más esfuerzo por el impacto que tendrá ajustarlo.

La mentalidad del agilismo no incluye un rol como el de un manager, quizá porque no está del todo correcto para el desarrollo de productos complejos, aquí otra palabra importante, ¡productos!, no proyectos, porque durante el ciclo de vida del software nosotros ¿entregamos qué?, un producto que ofreceremos al mercado. Pero entonces ¿qué diferencias tienen?. Todas. Todas las diferencias.

Antes de pasar completamente a las diferencias me gustaría abordar un pequeño resumen del tema de complejidad (pues bien podría ser otro post o varios libros literalmente), para dejar en claro por qué hacer project management no cumple con el desarrollo de software.

Teoría de la complejidad

En la teoría de complejidad hay diferentes niveles de complejidad.

  • Simples (sense-categorize-respond): problemas sencillos que se solucionan con mejores prácticas. Es decir estos problemas están bien identificados y existen recetas que siempre o casi siempre funcionan para resolverlos. Un ejemplo es una receta de cocina que tiene bien establecidos los ingredientes, tiempos, cantidades etc. Obvio en el alta cocina hay problemas culinarios complicados o complejos incluso.
  • Complicados (sense-analyze-respond): estos problemas requieren de cierto análisis, si el análisis no está bien hecho entonces pueden suceder cosas feas. Supongamos la creación de una casa donde se requiere estudios de suelo, materiales, física y bueno, profesionistas. “Para un experto, el dominio de lo complejo se repite de proyecto en proyecto, por eso las buenas prácticas son establecidas una y otra vez.
  • Complejos (probe-sense-respond): estos problemas ya dejan de ser complicados pues pierden el grado para poder predecir situaciones y se basan en lo que vas experimentando o haciendo. Un ejemplo sería la construcción de un aeropuerto, un poco inconcebible por el número de dependencias que tendrá. Para salir victorioso en estos problemas necesitas hacer visible lo desconocido, esto no es otra cosa más que comprender el problema que estás afrontando esto te permitirá inspeccionar y adaptar conforme vayas avanzando y aplicar prácticas emergentes en tu camino hasta el futuro. Esto último suena familiar ¿no? ¡SCRUM!
  • Caótico (act-sense-respond): estamos en un caso donde la relación causa y efecto no tiene pistas claras. Imaginen una situación donde dos extraños se conocen y acaba de ocurrir un desastre natural, prácticamente cualquier cosa que hagan estará hecha una vez y no se podrá repetir. Aquí probablemente nazcan nuevas prácticas.

Entonces podemos deducir que hacer project management es: abordar un problema complejo (caótico en algunos casos) de forma complicada o plana lo cual si bien es efectivo en muy pocos casos, no es eficiente tampoco pues no se puede tratar de forma lineal un problema que necesita prácticas emergentes y que necesita del empirismo para poder ir avanzando.

Product mindset VS Project mindset

En la siguiente tabla veremos diferencias más claras entre uno y el otro:

La teoría aunque es mucha siempre es más fácil aprenderla, llevarla a la práctica suele ser complicado pues por lo general cambiar la forma en que pensamos implica una dificultad mayor a nivel personal, por eso es importante intentarlo con el pensamiento de que vamos a fallar ¿recuerdan el empirismo y adaptación? Esto nos permitirá ir evolucionando y corrigiendo los fallos, eso significa empirismo.

Una vez que hayamos cambiado nuestra forma de pensar hacia el enfoque de producto y menos hacia la administración de tareas y de personas así como de alcances no validados con información real, en ese momento las situaciones se darán de forma natural pues aprovecharemos la transparencia, la visión, el feedback, la colaboración, comunicación y todos los beneficios que nos da este enfoque de entrega continua de valor para nuestro producto.

Imagen: Pixabay
Ilustraciones: Marco Atltzin Pérez.

Las opiniones vertidas por el autor son enteramente suyas y no siempre representan la opinión de BBVA Next Technologies.

¿Quieres saber que más cosas hacemos en BBVA Next Technologies?