¿Es normal que los desarrolladores sugieran ideas de características a los propietarios de productos? [cerrado]

Recientemente comencé a trabajar como desarrollador, ya que había trabajado antes como administrador de sistemas.

Comprendo que un equipo de desarrollo de software que utiliza las funciones de Agile es que la comunicación "lo que necesitamos implementar" ocurre principalmente en una dirección, desde el propietario del producto hasta los desarrolladores. Los desarrolladores pueden expresar sus inquietudes al propietario del producto sobre la deuda técnica, pero presentar ideas sobre características no debería ser una de sus principales responsabilidades.

La compañía en la que estoy trabajando tiene una opinión diferente. Para ellos, los desarrolladores no solo deben dirigirse a los propietarios de productos de su propio equipo para sugerir ideas de características, sino también a los propietarios de productos de otros equipos si creen que tienen algo que aportar al producto de ese equipo. La idea es que todos somos un gran Equipo <nombre de la compañía>, y todos los desarrolladores deben usar su experiencia para impulsar las funciones que creen que serán útiles.

¿Es este enfoque "normal", por falta de una palabra mejor? ¿Estoy siendo demasiado pasivo, debería tomar la iniciativa y comenzar a transmitir ideas a los propietarios de productos? Por el contrario, ¿la compañía se equivocó completamente y debería buscar empleo en otro lugar?

Depende de lo que entiendas por ideas de características.

En el juego de planificación, no es raro que los desarrolladores proporcionen información sobre una historia que podría terminar en la iteración. Sin embargo, esto es muy diferente de los desarrolladores que crean historias por su cuenta.

En sistemas maduros, los desarrolladores pueden sugerir una forma de solucionar un problema conocido que podría convertirlo en una iteración.

Las mejoras podrían estar bien, por ejemplo, agregar un gráfico para un informe, pero las alarmas sonarían para mí si los desarrolladores presentaran nuevas historias de buena fe. Si hubiera un valor real en esto, me preguntaría por qué no existía una historia no implementada para esto o por qué nunca surgió en la retrospectiva.

La razón por la que muchos desarrolladores son "pasivos", como usted dice, es porque se necesita una cierta cantidad de conocimiento y experiencia de dominio antes de que le lleguen buenas ideas de productos. Pero si vienen, no hay razón para no sugerirlos y defenderlos.

Tenga en cuenta que los desarrolladores, propietarios de productos, vendedores, etc., están todos en el mismo equipo, con el mismo objetivo: construir un producto exitoso. Trabaja hacia ese objetivo como puedas.

Con su charla sobre desarrolladores y propietarios de productos, me parece que no tiene una persona intermedia responsable de las funciones de su organización.

Bueno, en mi organización, soy esa persona. Soy el ingeniero de requisitos, el que aprendió a hacer buenas especificaciones y elegir características que resultan en un software de alta calidad con un diseño de interacción fácil de usar. (En otras organizaciones, es la persona UX la que obtiene el mismo trabajo, es posible que esté más familiarizado con ese término).

Y puedo decirte: obtener una buena especificación es difícil. Por supuesto, los desarrolladores odian hacerlo. Es una carga para ellos: están allí para construir un software, no para pensar en los juegos de poder entre las partes interesadas y los modelos mentales de los usuarios perezosos. ¿Pero sabes que? También es una carga para los propietarios de productos. No saben mejor qué características debe contener su software que los desarrolladores o los usuarios. Crear una especificación viable es una habilidad aprendida, y si nunca la aprendiste, no puedes ser bueno en eso. Claro, hay muchos desarrolladores y propietarios de productos que pueden hacerlo, porque tuvieron que hacerlo en proyectos anteriores. Pero el propietario o desarrollador promedio del producto tiene dificultades con él, porque naturalmente no es su trabajo hacerlo. No todos los que pueden conducir un automóvil pueden diseñar un automóvil; similar,

¿Se puede desarrollar software sin un ingeniero de requisitos? Seguro que puede. Pero poner todo el peso de la especificación sobre los hombros del propietario del producto no es justo y no es bueno para el resultado del proyecto. Especialmente porque se enfrenta a una tarea que es inusualmente difícil para él, obtener aportes y apoyo de otros es muy útil. Si se encuentra en una situación así, no mire a su pobre propietario del producto y dígale "dígame qué hacer para usted y lo haré", realmente no sabe lo que necesita. Pero una discusión con usted lo ayudará a articular sus pensamientos y explorar sus ideas.

Cuando no hay un ingeniero de requisitos en la estructura del proyecto, hay otro problema: no hay moderador. Todos los desarrolladores están en el lado técnico, todos los propietarios de productos están en el lado comercial. Cuando las dos culturas chocan, pueden surgir conflictos, y cada lado juzga al otro como estúpido e irrazonable (porque usa su propio sistema de valores para juzgar). Por lo tanto, hable con el propietario de su producto sobre las posibles características, pero sea cortés y paciente incluso cuando piense que no lo merece; el éxito del proyecto depende de cuán bien se lleven los dos, y a veces tomar una decisión subóptima es mejor que no tomar ninguna decisión debido a un conflicto. Puede ser útil establecer una jerarquía y dar a uno de ustedes dos la última palabra, ya que esto evita conflictos estancados. Si recibe la última palabra, aplíquela incluso si considera que es injusto.

Sobre la parte "pasiva": si no tienes ideas, no intentes inventar algo solo para mostrar actividad. Si el propietario del producto ya es inseguro y no conoce buenos criterios para evaluar sus ideas o las suyas, las ideas extrañas "solo para tener algo" harán que una situación ya difícil sea aún más difícil. Crear buenas ideas de características no es mágico, pero requiere conocimiento. Si no lo aprendió de los libros de texto, probablemente necesitará algunos años de experiencia del desarrollador, especialmente en proyectos donde esté expuesto a usuarios o datos de usabilidad generados por el usuario (análisis, mediciones de satisfacción) antes de que su cerebro clasifique los patrones por sí mismo y comienzas a darte cuenta: hay un problema aquí que podemos resolver Parece que a los usuarios les falta algo en esta página, ¿qué puede ser? Entonces tendrás buenas ideas para compartir.

Conclusión 1: En proyectos sin requisitos de ingeniero, es bueno hacer sugerencias cuando las tenga. Hágalo con sensibilidad y tacto: es imperativo evitar conflictos incluso si eso significa que su buena idea se corta de raíz.

¿Y si estás en un equipo con un ingeniero de requisitos?

¡Me encanta escuchar ideas de largometrajes de todos! Sí, a veces las ideas de los desarrolladores son terribles (cuando quieren que la interfaz de usuario siga la lógica de programación). Las ideas de los propietarios de productos también son a menudo terribles (cuando quieren el sol y la luna con un presupuesto reducido, oh, y se supone que el usuario debe ingresar a páginas de información personal con la mejor calidad de datos, sin obtener nada a cambio). Pero es mi trabajo elaborar una especificación que sea buena para todos en el equipo. E incluso si su idea nunca va a funcionar, escucharla me hace saber que tiene una preocupación. Es posible que haya elegido la solución incorrecta para sugerir, pero esto no hace que su preocupación sea menos válida. Si lo viste, probablemente deba abordarse (o necesito encontrar una razón por la cual no sea una amenaza). Si tiene un ingeniero de requisitos responsable de la especificación, no dude en acudir a ellos con sugerencias. Si no te escuchan, están haciendo algo mal (ten en cuenta que "considerar" no significa "aceptar").

Un ingeniero de requisitos tiene que ver el proyecto desde el punto de vista de cada parte interesada por separado (y a veces al mismo tiempo). Somos solo humanos, y fallamos en eso, a menudo. Si está allí para proporcionar su verdadero punto de vista, en lugar del punto de vista que creemos que tiene, entonces su aporte es muy valioso.

Puedes ser más libre en tu comportamiento aquí. Es mi trabajo hacer el baile de sensibilidad. No sea abiertamente agresivo, esto obstaculiza mi trabajo, pero necesita menos autocontrol y conciencia cultural / comunicacional, porque puedo tomar el relevo. Tampoco estás flotando, en una situación en la que hay dos ideas en conflicto y nadie puede juzgar cuál es mejor. Se supone que debo saber eso, y si no funciona, es mi cabeza en la soga.

Conclusión 2: si hay un ingeniero de requisitos en el equipo, diríjase a ellos con sugerencias de características del producto. No necesitas guantes de terciopelo esta vez.

Y, por último, ¿qué pasa si no hay requisitos de ingeniero, el propietario del producto está abrumado y luchando por obtener ideas, el jefe te está mirando fijamente y no tienes ideas para ofrecer?

Tienes pocas opciones. El primero es, como usted mencionó, dejar de fumar. No todas las organizaciones trabajan de esa manera, y si este entorno no es adecuado para usted, busque uno mejor. Será bueno para ti a largo plazo.

También puede esperar y ver si algo cambia. El próximo proyecto puede tener un propietario de producto más experimentado (o uno con más liderazgo). Pero no puedes detenerte para siempre.

La tercera opción es aprender algunos requisitos de ingeniería usted mismo. Esta es una habilidad muy buscada en estos días. Incluso si nunca planea tomar posiciones donde es un ingeniero de requisitos a tiempo completo, tener esta habilidad mejora su valor como desarrollador, ya que le permite comprender mejor a otros miembros de su equipo (y a sus usuarios) y hace El proceso de desarrollo transcurre sin problemas. Y no tienes que profundizar en ello. Un libro de texto básico que explica tareas, flujos de trabajo, modelos mentales y modelos de datos centrados en el usuario ya le permitirá detectar muchas oportunidades de mejora en un software diseñado por un equipo de empresarios y desarrolladores. Don' Busque los libros más gruesos que sirvan de referencia para los académicos (como la reciente traducción de Pohl al inglés): son más una lista de todos los métodos posibles para cada pequeño paso, sin una explicación de cómo hacerlo realmente. Elija algo orientado a la práctica.

Si lo prueba y descubre que no tiene ningún interés personal en el área, todavía está bien. No te obligues a hacer algo que no te gusta. Pero probablemente debería estar buscando un trabajo en una organización con una estructura de equipo diferente.

Conclusión 3: en lugar de esperar años para obtener una comprensión intuitiva, lea un libro o dos y ya tendrá buenas ideas para proporcionar

Sí, es bastante normal.

Hay un 80% de trabajo bien conocido, un 20% de modelo de innovación en Google, donde las personas dedican el 20% de su tiempo a algo que les gusta. De esta manera, no solo obtienen nuevas funciones, sino también productos y servicios completamente nuevos.

¿Estoy siendo demasiado pasivo, debería tomar la iniciativa y comenzar a transmitir ideas a los propietarios de productos?

Eso depende de tu personalidad. He trabajado con personas realmente apasionadas, pero también con personas sin ninguna emoción que hacen su turno de 8 horas y se van a casa.