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

16

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?

louniks
fuente
15
Claro, los programadores a menudo saben muchas cosas de las que el dueño del producto nunca ha oído hablar. Tome el desarrollo web, hay servicios, apis, cualquier cantidad de bibliotecas y complementos y elementos de la interfaz de usuario. A menudo trabajamos con clientes que no tienen mucho más que una idea aproximada de lo que quieren hacer, pero no saben cuáles son las formas comunes de implementarlos o qué características adicionales serían posibles.
thorsten müller
1
¿Sientes algún resentimiento o consecuencias negativas por no sugerir características? Parece que su empresa quiere fomentar la práctica y no castigar a quienes no lo hacen.
JeffO
Este es el proceso normal en dos empresas para las que he trabajado. Me he dado cuenta de que la gente de negocios simplemente no tiene idea de lo valiosos que somos los desarrolladores en soluciones / habilidades para resolver problemas. Saltar es probable que te encuentres con el mismo problema. Sugerir nuevas funciones a la gente del producto como si fuera la solución, se llama administrar a los gerentes y funciona bien. El único problema es que no obtienes crédito por tus ideas, pero al menos tus características se implementan.
Jason
OMI, esto es algo muy bueno y muy saludable. Los propietarios de productos pueden ser expertos en el dominio comercial, pero probablemente no estén al tanto de todas las nuevas tecnologías o enfoques técnicos disponibles. Además, los desarrolladores pueden tener ideas sobre el sistema que proviene de la perspectiva diferente de trabajar directamente con el código. Definitivamente desea permanecer en una empresa que agradece las ideas de todos, sin importar el rol. No significa que los propietarios no tengan idea, significa que están abiertos a las ideas de todos.
Ken Liu

Respuestas:

2

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.

Robbie Dee
fuente
1
No interpreto la filosofía de mi empresa como pedirle a los desarrolladores que inventen historias, y no recuerdo haber visto que eso sucediera. Lo que creo que quieren es que, una vez que se ha emitido una idea y un desarrollador se ha apropiado de su ejecución, es responsabilidad del desarrollador defender esa idea hasta el final.
Louniks
1
Entonces, ¿estás diciendo que suenan las alarmas cuando un desarrollador piensa en una idea que el dueño de un producto no pensó? ¿Por qué sería eso algo tan malo?
Stefan Billiet
1
Lanzar ideas está bien, es parte integrante del juego de planificación. Si fuera una historia nueva, cuestionaría esto. Las historias brindan valor al cliente que, para ser francos, los desarrolladores no suelen estar en mejores condiciones para evaluar (a menos que sean expertos en dominios). Si algo aparece en la iteración está determinado por el valor de la historia y el esfuerzo del desarrollador en el juego de planificación. La participación de los desarrolladores en la creación de historias podría causar un posible conflicto de intereses aquí. Esto no quiere decir que no podría suceder, solo que el propietario del producto necesitaría defenderlo, de lo contrario, es la cola que mueve al perro.
Robbie Dee
47

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.

Stefan Billiet
fuente
Creo que lo has logrado: he aterrizado en un equipo que trabaja con tecnologías con las que tengo muy poca experiencia, por lo tanto, es difícil para mí ser proactivo. Tendrá que haber un período de aprendizaje durante el cual permanezca pasivo. Luego, una vez que empiezo a sentirme cómodo con la tecnología, puedo comenzar a ser proactivo.
Louniks
1
@louniks no, te estás perdiendo el punto. La tecnología no es lo que importa. El negocio es lo que importa. ¿Qué tan transparentes son los empresarios? ¿Eres consciente de cómo la empresa pretende ganar dinero? ¿Sabe cómo el producto en el que está trabajando encaja con los otros productos de la empresa? Si no, entonces su empleador es injusto con usted. No puede sugerir funciones si no conoce el plan de negocios.
RibaldEddie
3
@RibaldEddie No estoy de acuerdo con la última parte. Cualquiera debería ser libre de sugerir características. La gerencia y los propietarios de los productos aún pueden determinar si la función va a algún lado. No pase por alto la posibilidad de que un desarrollador con suficiente dominio y conocimiento técnico pueda presentar una característica enorme y rentable que esté completamente fuera del plan comercial original. El propietario de un producto nunca puede tener la misma idea debido al conocimiento técnico limitado.
Dan Lyons
1
Parece una situación peligrosa: significa que las personas de negocios para las que trabaja no saben lo que están haciendo. Es SU TRABAJO ser expertos en esta área. De lo contrario, ¿por qué están allí? Seriamente. Si los desarrolladores están proporcionando este tipo de información, entonces los desarrolladores también podrían dirigir la empresa. Cualquier otra cosa es desperdicio.
RibaldEddie
No siempre se necesita un conocimiento detallado del dominio para sugerir mejoras técnicas ...
Robbie Dee
5

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

rumtscho
fuente
+1 Esa es una respuesta realmente completa. Las "Conclusiones" funcionan como un bien TL;DR.
James Khoury
4

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.

BЈовић
fuente
Parece que en Google los desarrolladores dedican parte de su tiempo a ser propietarios de productos.
JeffO
¿Los empleados de Google que trabajan en sus propios proyectos no son lo mismo a menos que esté hablando de otra iniciativa?
Robbie Dee
@RobbieDee Sí, claro. Trabajan en sus proyectos, pero Google vende servicios que salen de los proyectos.
B 11овић
Lo que quiero decir es que tales proyectos no necesariamente residen dentro de la esfera de un proyecto ágil existente. Pueden ser completamente autónomos.
Robbie Dee