- Cuando los desarrolladores dicen No, saber responder puede ayudar a un gerente de producto a hacer valer su criterio y alcanzar sus objetivos
- Cuando dicen que una función no puede implementarse dentro del tiempo propuesto por razones técnicas, hacer las preguntas correctas puede ayudar a destrabar la situación
1. ¿Hay otras soluciones técnicas para construir la función?
- Hay muchas formas de construir una función, y el primer enfoque que se intenta no siempre es el óptimo
- Los desarrolladores quieren crear funciones impresionantes usando la tecnología más reciente, pero eso puede llevar a una sobreingeniería en lugar de optimizar por simplicidad
- Los desarrolladores con un conjunto técnico específico quizá no perciban soluciones más simples que estén fuera de su campo de conocimiento
- Por eso, conviene guiarlos para que piensen de forma más creativa sobre la solución técnica
- Algunos de los mejores gerentes de producto con los que he trabajado tenían suficiente perspectiva y conocimiento técnico del entorno como para hacer preguntas inteligentes que ayudaban a los ingenieros a pensar fuera de lo convencional
2. Si tuvieran que proponer una solución con estas restricciones, ¿cómo lo harían?
- Si los desarrolladores plantean objeciones a la solución que propusiste, pídeles su propia solución
- Los desarrolladores son una fuente enorme de creatividad e innovación, y al preguntar si existe una versión más simple de la función, les das espacio para pensar creativamente
- Cuando entienden el núcleo del problema, pueden pensar con creatividad y encontrar una solución que funcione dentro de las restricciones del proyecto
3. ¿Podemos considerar un enfoque por etapas para esta función?
- Cuando dicen que no es posible implementar la función debido a su complejidad técnica, pregunta si el proyecto puede dividirse en etapas y organizarse con distintas fechas de lanzamiento
- Aunque existe la tentación de entregar una gran visión de una sola vez, un enfoque por etapas es más iterativo y ofrece resultados concretos más rápido
- Las prioridades pueden cambiar, y un enfoque por etapas permite coordinar con los desarrolladores qué funciones agregar después
4. ¿Qué obstáculos podemos quitar o resolver para hacer posible este trabajo?
- Esta es una pregunta frente a objeciones relacionadas con recursos: cuando los desarrolladores mencionan recursos limitados (por ejemplo, tiempo o cantidad de desarrolladores disponibles), elimina activamente trabajo para liberarles tiempo
- Algunas formas posibles: eliminar tareas por completo, encargarte tú de tareas que no requieran a un desarrollador, asumir la comunicación con otros equipos y/o terceros, o facilitar el trabajo haciéndote cargo del proceso y retirando funcionalidades legacy
Conclusión
- Puede resultar incómodo "presionar" cuando los desarrolladores dicen "no se puede", pero hacerlo puede hacer que te ganes más respeto
- Hay que profundizar un poco más para entender por qué un ingeniero se opone, identificar la razón e ir eliminando las objeciones una por una
- Todas estas son buenas preguntas porque reconocen las dificultades y restricciones específicas que un ingeniero puede enfrentar al implementar una función
- También dejan claro que estás dispuesto a poner manos a la obra para ayudar al equipo y al proyecto, ya sea haciendo trabajo pesado tú mismo o ajustando los requisitos y el calendario según sea necesario
8 comentarios
Al final, todo depende de cómo se coordine.
Gracias por el buen contenido.
Si se pregunta con lo de arriba, parece que se filtrará rápido a quienes en realidad solo dicen que no porque simplemente no quieren hacerlo.
Como PM/PO, cuando me tocó coordinar entre el área de negocio y el área de TI en proyectos, hubo dos metodologías que me ayudaron bastante.
Claro, la premisa es que tanto el área de negocio como la de TI sean capaces de entenderse.
La primera es avanzar por etapas.
La segunda es reducir el alcance.
Esas dos.
La mayor dificultad al llevar proyectos tanto del lado de negocio como del lado de TI es el "tiempo".
El plazo ya está definido, y muchísimas veces el volumen de trabajo parece imposible de completar dentro de ese tiempo.
En esos casos, hay que hacerlo por etapas: phase 1, 2, 3... con un calendario secuencial. Las funciones más importantes en phase 1, las menos importantes en phase 2, y así sucesivamente.
Pero en los proyectos que no se pueden hacer así por etapas, es decir, los que tienen que salir de una sola vez,
hay que reducir el alcance para que encaje en el "plazo". De todo lo que iría en phase 1, 2 y 3, hay que cortar todo excepto las funciones "realmente necesarias".
Con estas dos metodologías, la mayoría de las veces tanto el área de negocio como la de TI están de acuerdo, siempre que sepan escuchar.
Porque es mejor eso que dejar que el proyecto se descarrile y que luego cada quien reciba un regaño de su jefe...
En fin.
Ánimo a todos^^
PD:
Hay un último toque.
Incluso usando esos dos métodos, muchas veces los desarrolladores siguen mostrando resistencia.
En ese caso,
si dices:
"Revisémoslo una vez hacia la mitad del proyecto. Si parece que vamos a necesitar más tiempo, yo me haré responsable de conseguir una extensión del plazo"
muchas veces se les cambia la cara a los desarrolladores.
Y cuando luego se revisa a mitad del proyecto, en el 95% de los casos resulta que no hacía falta más tiempo.
Además, muchas veces una vez que los desarrolladores empiezan a programar, avanzan bastante rápido.
Como alguien que tiene un rol en el que debe coordinarse con desarrolladores, me gustaría trabajar con desarrolladores con los que se pueda tener este tipo de conversación. Hasta ahora solo me he topado con desarrolladores que de entrada dicen que no se puede, y eso me frustra. La mayoría de las veces, cuando les insisto y les pregunto de una u otra forma, resulta que simplemente no conocían una manera de hacerlo...
Jajajajaja, duele en el pecho..
Preguntas que, como ingeniero, deberías hacerte antes de decir "NO".
A mí también me parecen preguntas realmente muy buenas para hacerse a uno mismo.
Antes que ingenieros, somos personas. Estoy de acuerdo en que el hábito de decir No de forma automática es un problema para un ingeniero, pero creo que sería de gran ayuda que del lado de PM/PO tuvieran ese tipo de preguntas en mente.