Gerente que solicita una tarea que creo que es innecesaria

Fondo

Trabajo como desarrollador en un departamento de desarrollo de software con otros tres desarrolladores y un gerente. Tenemos una aplicación de escritorio que se modifica constantemente en función de las necesidades del cliente.

Problema

Recientemente, uno de nuestros clientes solicitó la modificación de una característica que ya está presente en el producto. Requiere un par de clics más del mouse para hacer el trabajo.

Mi gerente quiere que esta modificación se implemente según la solicitud del cliente.

Expliqué claramente algunas veces que ya tenemos esa función y funciona bien. Además, expliqué el impacto técnico de cambiar la funcionalidad. Mi gerente quiere que proceda con el cambio según las solicitudes del cliente.

Pregunta

¿Cómo debo proceder?

¿Debo explicar la situación de nuevo? ¿O tal vez buscar otro trabajo? ¿O debería decirle a mi gerente que si es tan simple debería ayudar?

ACTUALIZAR

Cada respuesta a esta pregunta me aclaró una cosa: necesito cambiar mi actitud.

Como casi todos señalaron: no soy el gerente, siempre que informe a mi gerente sobre el inconveniente técnico de una solicitud, no debo juzgar. Además, renunciar sería una solución temporal, ya que el problema radica en mi actitud hacia el trabajo y el gerente.

¡Felicitaciones por llegar a la conclusión correcta!

Respuestas (9)

Mi gerente quiere que proceda con el cambio según las solicitudes del cliente.

Pregunta

¿Cómo debo proceder?

Debe proceder con el cambio según las solicitudes del cliente.

Aparentemente el cliente quiere esta modificación. Y aparentemente su gerente está de acuerdo. Parece que está dispuesto a absorber el impacto técnico para hacer feliz al cliente.

No sirve de nada volver a explicarlo, a menos que crea que su gerente no lo entendió a pesar de que se lo explicó claramente (parece que lo entendió pero no está de acuerdo).

Claramente, su gerente es el que decide qué es innecesario aquí, no usted.

Una vez que se cumpla con la solicitud del cliente, es posible que desee encontrar un momento tranquilo para conversar con su gerente. Su objetivo para tal discusión no debe ser convencer a su gerente de que tenía razón. En cambio, su objetivo debe ser preguntarle a su gerente sobre la decisión, para que comprenda mejor el proceso de solicitud de clientes en su empresa. Está claro que hay cosas de los clientes que no entiendes.

¿O tal vez buscar otro trabajo?

Si necesita un trabajo en el que pueda decidir qué recibe o no recibe el cliente, aunque su cliente y su gerente ya lo hayan decidido, entonces debe buscar un nuevo trabajo.

Tal vez debería buscar un puesto de gestión, donde tendría más influencia en cuanto a qué características se entregan y cuáles no. O tal vez debería buscar un rol de gestión de productos o servicios al cliente, donde interactuaría con los clientes más de cerca, impactaría la línea de tiempo de las características del producto y podría ayudar a decidir qué solicitudes de clientes satisfacer o rechazar.

O, como señala correctamente @IsmaelMiguel, trabajar para una empresa de productos, donde las solicitudes de clientes individuales rara vez se solicitan o cumplen. (Por supuesto, aún tendrá que lidiar con las instrucciones de su gerente).

¿O debería decirle a mi gerente que si es tan simple debería ayudar?

Debes ponerte sarcástico con tu jefe solo si realmente no valoras tu trabajo.

+1 para "Si necesita un trabajo en el que pueda decidir qué obtiene o no obtiene el cliente, aunque su cliente y gerente ya lo hayan decidido, entonces debe buscar un nuevo trabajo".
No estoy seguro de dónde encontraría ese trabajo, incluso siendo presidente tiene límites. Eso es parte de la vida, muchas veces tienes que hacer cosas que no son las que quieres hacer.
Simplemente podría estar desempleado. Tiene desventajas obvias.
+1 aunque quizás podría poner más énfasis en 'asegúrese de haber explicado adecuadamente las desventajas de la decisión que considera incorrecta'
Si el OP quiere trabajar en un lugar donde la opinión del cliente no importa, una opción podría ser empresas con productos muy exitosos como Spotify, Instagram, Snapchat y otros. Allí, la empresa decide lo que obtendrá el cliente y no más discusión.
@IsmaelMiguel Todos ellos todavía entienden su negocio principal: brindar un servicio a sus clientes. Claro, no responden a cada cliente individual que solicita una función, pero aún así tienen que satisfacer las necesidades del cliente y, a veces, eso significa tener una solución técnica tosca. Si realmente quieres estar en una empresa donde la opinión del cliente no importa, tendrás que ir con la empresa: están acostumbrados a la mala actitud: D
@Luaan Ya no podría estar de acuerdo. Buenos puntos!
Otra forma de explicar el escenario es imaginar si contrataste a un tipo para cavar una zanja y se mostró reacio a cavarla X pies de profundidad. Probablemente se sienta frustrado de que él esté tan preocupado por las decisiones de gestión considerando que lo contrató para cavar una zanja, no para administrarla.

Su pregunta se basa en cuestionar la validez y corrección de la solicitud de los usuarios, y la decisión de su gerente de aceptarla y hacer que se tome acción. La solicitud del usuario es válida y la decisión de su administrador es válida.

Este es el trabajo para el que está empleado .

Lo que se le pide es la implementación de un requisito no funcional.

Se le solicita una mejora de la usabilidad, no una expansión de la funcionalidad.

Los requisitos no funcionales de un sistema siguen siendo requisitos .

En este caso, estas correcciones de usabilidad están destinadas a aumentar la productividad del usuario y reducir sus tasas de error.

Las correcciones de usabilidad pueden no ser triviales de implementar. Esto no significa que deban tratarse como preocupaciones de segunda clase. Como desarrollador, estás ahí para crear lo que es importante , no lo que es fácil .

Un libro excelente para ayudar a comprender la usabilidad como una preocupación clave y central de la ingeniería es
"The Design of Everyday Things" de Donald Norman (enlace) .

Un buen ejemplo de un sistema que tiene funciones completas y que necesita un mayor desarrollo de los controles del usuario es el Modelo T de Ford. Como coche, va. Dirige. Para. Lleva pasajeros.

Ahora eche un vistazo a los controles de usuario (enlace) . Ya nadie los hace así, por buenas razones.

Son difíciles (y propensos a errores, es decir, propensos a lesiones) para empezar.

El acelerador es un par de palos en lados opuestos de la columna de dirección, y deben operarse de forma independiente y, a veces, simultáneamente.

Estoy bastante desgarrado con esta respuesta. Es una gran respuesta en la medida en que le dice al OP lo que necesita saber. Pero en lo que respecta a la respuesta del "lugar de trabajo", ¡es completamente irrelevante! No se supone que este sitio sea sobre buenas prácticas de programación/desarrollo, sino sobre el entorno de oficina.
Son requisitos pero son buenos requisitos. Un usuario no siempre es un experto en el dominio. Algunas veces son dos clics para abrir un conjunto de comandos relacionados. Solo puede tener tantos 1 clics en la pantalla principal. ¿Qué tal un automóvil con dos portavasos en un lado de la palanca de cambios para acomodar el varillaje? Requisito no funcional de tener las copas a cada lado. Requiere un rediseño, transmisión menos eficiente, transmisión más costosa y un enlace con una tasa de falla más alta. Si cumple la función es un deseo. Debe priorizar los deseos para obtener el máximo rendimiento de su inversión.
Me gusta tu respuesta y estoy de acuerdo con la mayoría y +1. Tengo una aplicación con usuarios dedicados (a tiempo completo). Realiza un seguimiento de la productividad y, por lo general, la mitad del trabajo lo realiza el 1/4 superior. El 1/4 superior casi nunca tiene un requisito no funcional. Casi todos los requisitos no funcionales provienen del 1/4 inferior y producen menos de 1/10 de la salida. Lo que pide el 1/4 inferior normalmente impedirá a las personas de alto nivel. Estoy leyendo entre líneas aquí y sospecho que el programador tiene más experiencia en el dominio comercial que el jefe. Un tintineo no siempre es mejor que dos.
@AndyT El OP es una pregunta XY. Está refutando la necesidad de llevar a cabo una solicitud de trabajo válida realizada tanto por su cliente (y, de hecho, por el cliente) como por su gerente. Explicar por qué está mal no hacerlo, por qué la solicitud de trabajo de su gerente es válida, parece apropiado. De lo contrario, la respuesta se convierte en "¡Simplemente hazlo!" "¿Por qué?" "Porque tu jefe lo dice". Creo que superamos esas formas de respuesta cuando nos convertimos en adultos jóvenes.
@Frisbee Sí, diferentes formas de enfoques de diseño de interfaz de usuario son apropiadas para diferentes clases de usuarios. Los usuarios expertos normalmente necesitan tareas comunes simplificadas en movimientos eficientes de manos y dedos, y los usuarios intermitentes e ingenuos requieren más visibilidad, disponibilidad y retroalimentación. Pero ahora nos estamos desviando hacia una discusión sobre los problemas de diseño de la interfaz de usuario, en lugar de las razones por las que el jefe puede estar en lo correcto al solicitar este trabajo.
Tal vez si la oración en negrita se reformulara o se repitiera de una manera ligeramente diferente, sería más aplicable: "Las solicitudes de los clientes que son pérdidas de tiempo inútiles siguen siendo solicitudes de los clientes (y cualquier trabajo realizado en ellas es facturable)".
@Frisbee Lo mismo ocurre con los desarrolladores. Por lo general, una pequeña proporción del equipo de desarrolladores es responsable de la mayor parte del código y de implementar la mayoría de los puntos de función. La productividad individual de las personas varía. La productividad del codificador a menudo varía en un factor de cuatro dentro de la misma cultura organizacional y utilizando el mismo entorno de desarrollo. Y sí, las diferentes categorías de usuarios se benefician de los controles de usuario adaptados a su categoría.
@Todd Wilcox Cierto, pero esa sería una respuesta completamente antitética. ¿Quizás deberías escribirlo?
No, no estoy de acuerdo en que sea apropiada una interfaz de usuario diferente para diferentes clases de usuarios. Como dije en este caso, todos son usuarios de tiempo completo con las mismas pautas de contratación. Pongo mi dinero con los que producen. La solicitud correcta no es lo mismo que la solicitud correcta. Haces lo que dice el jefe, pero según lo que leí, apuesto a que el programador es un mejor diseñador y un mejor conocimiento del dominio comercial. Mi punto es que hay requisitos no funcionales malos y buenos. El hecho de que un usuario lo solicite no significa que mejorará el producto. Sigue siendo una buena respuesta.
@Frisbee (Esto ahora se está desviando del tema, pero...) Sí, los usuarios productivos necesitan apoyo. Pero el propósito de las UI es hacer que toda la base de usuarios sea productiva, permitiéndoles realizar las tareas rápidamente y sin errores. ¿Quizás podríamos mover esto al chat? (¿Alguien conoce la interfaz de usuario para lograr esto?)
@EuanM Y sostengo que incluso los programadores que atienden al bajo rendimiento no ayudan a la productividad. El software de desarrollo no es tan difícil de usar. Si necesita ruedas de entrenamiento para Visual Studio, debe buscar otra línea de trabajo. ¿Categorías? Usemos el término experiencia. Sí, un usuario con poca experiencia puede beneficiarse, pero estoy diciendo que lo sopese con un recurso fijo. Mi experiencia es atender a los de gama alta y dejar que ellos levanten a los demás. Un diseño dividido es una gran carga. Como Intellisense ayuda a todos los usuarios. Mi opinión es que hay muchas oportunidades de diseño que benefician a todos los niveles de usuarios.
@Frisbee Estoy totalmente de acuerdo con la última oración. Creo que algunos de los otros son discutibles. :-)
@AndyT Estoy 90% seguro de que dar una respuesta útil en el lugar de trabajo más educación específica del dominio no hace que una respuesta útil sea menos útil. Lo hace más útil para las personas en el mismo dominio que el autor de la pregunta. ¡ Las respuestas del lugar de trabajo pueden ir por la tangente sobre el conocimiento del dominio!
@doppelgreener: en el momento en que comenté que no había una "respuesta útil en el lugar de trabajo", todo era específico del dominio. Desde entonces, EuanM agregó la respuesta real del lugar de trabajo, lo que la convierte en una respuesta mucho mejor (y me gané +1).
@AndyT Ajá, genial. No me di cuenta de eso. :) Entiendo de dónde vienes entonces.
Lo hice explícito . Siempre estuvo ahí.

Trate de pensar en una solución donde ambas situaciones puedan funcionar.

Si esta funcionalidad ya existe, aparentemente no se ha realizado correctamente en términos de interfaz de usuario. ¿Quizás rediseñar los controles o la navegación? Trate de disminuir la cantidad de clics a través de una forma inteligente de lo que quieren.

Además, ¿renunciar cuando su jefe le dice que haga algo con lo que no está del todo de acuerdo? Te debe gustar mucho buscar trabajo, porque esto es bastante común.

No es que me guste saltar de un trabajo a otro. Esta no es la primera vez que sucede algo similar, pero este los supera. Siempre he tratado de ser sincero con mi gerente para superar los problemas.
Y sigue haciendo eso. Pero al final, el gerente es el que tiene las responsabilidades, solo asegúrese de que estén conscientes con algo como "Realizaré la tarea X, pero creo que esto podría ser una mala idea. Cumpliré, pero quería asegúrese de haber dado toda la información sobre las consecuencias"
@raidensan Si este es el mayor desacuerdo que ha tenido con su gerente, lo está haciendo muy bien donde está.
Al menos su cliente realmente quiere algo que usted pueda completar. He tenido clientes en los que rechazaban una muestra previamente aceptada porque parecía "apagada", pero es literalmente el mismo archivo, y luego la semana siguiente decían "¡Es genial! Lo arreglaron". Cuando revisan la misma muestra. Fue una completa locura.
Esta respuesta es la única respuesta que se acerca al hecho de que OP está siendo extrañamente irrazonable sobre algo que es común.

Tu pregunta es un desastre; es una gran contradicción. O ya está en el producto, entonces no hay nada que hacer. O no lo es, y hay problemas técnicos que hay que superar. Pero no ambos. Es imposible que puedas tropezar con dificultades técnicas cuando reinventas la rueda.

Si la característica aún no está en el producto, proceda de la siguiente manera:

Si aún no lo ha hecho, explique todas sus inquietudes por escrito a su gerente. Un correo electrónico debería ser suficiente. Debe contener las inquietudes y las dificultades técnicas que debe superar para resolverlas, y una estimación aproximada del tiempo si es posible. Marque claramente aquellos en los que realmente no tiene idea de cómo resolverlos y solicite su ayuda.

También pregúntele si la característica vale la pena y muéstrele características más importantes que esperan en el backlog. Ahora que le ha proporcionado un marco de tiempo ("5 semanas para todo lo que se resuelve y 4 problemas completamente sin resolver") y posibles usos alternativos de su mano de obra, debería poder tomar una decisión informada.

Si responde "Sí, adelante", implemente todo lo que pueda y comunique todo lo que no pueda resolver. Solicitó la función y le proporcionó un marco de tiempo para resolver los problemas. Todo lo demás está por encima de su nivel salarial.

En primer lugar, se debe comunicar al cliente la existencia de la característica, si no se ha hecho. El hecho de que esté implementado no significa que lo conozcan o que sepan cómo usar la función. Esto debe hacerlo quien sea el contacto principal con el cliente, que podría ser su gerente. Saber acerca de esta característica podría ser todo lo que necesitan. Sin embargo, si encuentran que la implementación no es útil, entonces la forma en que se implementa la función aún deberá cambiarse.

Si el punto de contacto es su gerente y su gerente lo mencionó y el cliente todavía quiere el cambio o su gerente no cree que sea necesario mencionarlo, entonces usted hizo todo lo que podía hacer. Usted presentó el argumento y la persona responsable de tales decisiones ha tomado una decisión. Ahora es el momento de llevar a cabo la decisión.

Sin embargo, parece que hay problemas dentro de su organización. No es raro que el código se degrade con el tiempo. La deuda técnica se acumula y los cambios en un sistema solo provocan la degradación de la integridad del diseño ( entropía del software ). Eventualmente, estos problemas deben resolverse o el costo del mantenimiento del software puede aumentar hasta el punto en que se vuelve extremadamente costoso realizar cambios en un sistema. La falta de tiempo para probar y construir calidad en el proceso también es un problema.

Estas cuestiones organizativas son problemas a más largo plazo. Es un caso de "cambia tu organización" . Puede solucionar estos problemas o comenzar a buscar una nueva organización que sea más apropiada.

Si quieres decirle al cliente, no digas, mira, idiota, ahí estuvo todo el tiempo. Dime, ¿te refieres a algo como esta función aquí?

Proporcione una verificación de lo que debe hacerse al cliente. Haz un dibujo, proporciona instrucciones paso a paso, etc. para asegurarte de que comprendes la solicitud. Esto no es explicarle al cliente cómo se hacen las cosas ahora, es asegurarse de que haga su trabajo correctamente. Incluso puede compararlo con cómo funciona la función ahora, para verificar que su cambio es tan simple como le parece.

EDITAR:

Puede hacer que el cliente o el gerente aprueben este cambio. Puede mencionarle a su gerente que podría ayudar si se le presenta al cliente para que lo "firme" en caso de que, cuando se entregue, se dé cuenta de cuán pequeño es el cambio. Sin embargo, el punto aquí es la comunicación y si su gerente aprueba esto, entonces al menos el trabajo es claro para usted y tiene documentación de que proporcionó lo que se le pidió, y no hizo trampa ni manipuló la solución.

FIN DE EDITAR

Es posible que su cliente esté solicitando una función "existente" y no se dé cuenta. También es posible que su cliente necesite que esto se haga en menos pasos o con menos clics. Estoy familiarizado con muchos sistemas que no eran "aceptables" para los usuarios debido a "más clics".

Es bueno que trate de protegerse de realizar cambios innecesarios o cobrar a los clientes por funciones que ya existen. No es bueno para usted juzgar a un cliente en función de su solicitud o ser como un padre sobreprotector e intentar ayudar a los clientes a ahorrar dinero o hacer las cosas "a su manera" cuando quieren que se hagan de otra manera.

Si no está dispuesto o no puede realizar el trabajo, entonces su gerente debe saberlo. Pero entonces probablemente deberías estar buscando otro trabajo.

Gracias por tu respuesta. No puedo informar a nuestro cliente sin obtener la aprobación de mi gerente. De hecho, es mi gerente quien insiste en que lo hagamos, estoy bastante seguro de que el cliente usaría la función actual. En este momento estoy detrás de la barrera de gestión :(
¿Puede escribir el documento y pedirle al gerente que lo verifique con el cliente?
Edité mi respuesta. Espero que ayude.

Lo siento por ti. Obtengo un diseño detallado sin requisitos funcionales todo el tiempo. No aprecian el diseño de datos actual y las llamadas al servidor. Dos clics pueden ser limpios y extensibles y un clic provoca un cambio en el modelo de datos. Dicen que no les importa, pero cuando se rompe o los datos se corrompen, es su problema. Incluso si lo hace funcionar, tiene una base de código frágil y el próximo cambio es aún más difícil. Es muy frustrante cuando un programador se considera simplemente un codificador y no un diseñador.

En cuanto a lo que puedes hacer. 1) Explique el problema. 2) Luego oponga y exponga su objeción tanto por escrito como verbalmente. Resuma el tiempo para este cambio y el impacto a largo plazo. 3) Y luego hazlo. Si lleva 3 semanas programar y 2 semanas probar, que así sea.

Renunciar es siempre la última opción, pero si esto continúa, el trabajo solo empeorará. El código se volverá más frágil y el jefe no será comprensivo. Es degradante ser tratado como un mono de código. Dicho esto, haz lo mejor que puedas y desarrolla tu conjunto de habilidades. Si todavía está frustrado con su próxima revisión de desempeño, expóngalo. Si menciona el proceso no asociado con un cambio específico, es de esperar que el jefe considere su posición más seriamente. Si el jefe dice que el proceso no va a cambiar, entonces sabes cuál es tu posición. No renuncies. Decide si puedes vivir con ello. Si no puede vivir con eso, haga un plan sobre cómo pasar a su próximo trabajo. Una vez que deje de preocuparse por el trabajo actual, será más tolerable.

Dos clics pueden ser un gran problema para las personas que realmente usan el sistema todo el día. Deja de centrarte en el desarrollador. Las personas que solo se preocupan por la experiencia de desarrollo escriben mal software.
@HLGEM ¿Centrado en el desarrollador? ¿Experiencia de desarrollador? ¿Qué parte del usuario A supera al usuario B por 2:1 no está claro? Si el usuario A dice que la característica X es mucho más importante que esos dos clics que tienen sentido para el usuario A, entonces la característica X es una prioridad más alta y es posible que esos dos clics nunca aparezcan en la lista. Si los dos clics hacen la misma llamada de back-end que toma más de un par de segundos, entonces no cambie. Si un clic provoca un cambio en el modelo de datos que ralentiza las cosas o limita las funciones, eso es algo malo.
@HLGEM Si solo quiero un almuerzo y mi paleta simple solo puede manejar un almuerzo, entonces sí, guárdeme ese clic un día cuando ordene el almuerzo. Si tengo una paleta superior y necesito 4 clics para pedir un menú, entonces ese es un mejor sistema en mi opinión. Menos clic no siempre es mejor.
Está centrado en el desarrollo porque claramente no te importa lo que quiere el usuario.
@HLGEM ¿Claramente no te importa? No hay propósito para esto. Ve a arreglar ese clic y diferir la función X.
No dije que menos clics siempre es mejor, dije que debe escuchar al usuario sobre lo que funciona para él. Hay demasiado en esta industria de personas que diseñan para la conveniencia del desarrollador y no del usuario que está atrapado con la interfaz incómoda todo el día.
@HLGEM ¿Qué parte de "Si el usuario (productivo) A dice que la característica X es mucho más importante que esos dos clics" no está escuchando al usuario?

La respuesta aquí es "¡obtener una aclaración!"

¿Se da cuenta el cliente de que la característica ya existe de una manera más simplificada, o no?

Si no es así... entonces probablemente estarían bastante molestos por no haber sido informados al respecto y, posteriormente, estarían pagando más horas para empeorar la funcionalidad de una función ya existente. Sé que me molestaría eso... cuando digo "Quiero la característica X" al gerente del proyecto, es su maldito trabajo saber si ya está ahí y hacérmelo saber para asegurarme de mi decisión sobre el proyecto. Comisioné es un informado.

Si es así... entonces lo que el cliente quiere para el proyecto es lo que quiere. Los requisitos son los requisitos, tienen su por qué y no te los tienen que explicar. Por ejemplo, pueden tener datos concretos de que ese clic adicional hace algo extraño y positivo para su negocio y lo quieren. O incluso si es solo porque son tontos... tienen derecho a pagarte más por su estupidez si así lo desean. Siempre y cuando tomen esa decisión completamente informados y paguen por las horas que toman de su parte, está bien.

Conclusión: si se trata simplemente de que su gerente de proyecto no mantiene informado adecuadamente al cliente, entonces eso es un problema. Si es el cliente el que realmente quiere un requisito tonto, incluso cuando sabe que ya existe una versión mejor de la función, entonces... entonces sigue siendo un requisito del cliente, incluso si es tonto.

No puede tomar las medidas adecuadas hasta que descubra cuál es el caso... o al menos esforzarse un poco tratando de averiguar cuál es el caso para que su trasero esté cubierto en caso de que resulte que el gerente no estaba haciendo lo suyo. trabajo.

La función ya existe de una manera menos simplificada, no "de una manera más simplificada".
@EuanM - ¿Estás seguro? Me parece que el OP dijo que el cambio "requiere un par de clics más del mouse para hacer el trabajo", lo que describiría una versión menos optimizada de la funcionalidad, es decir, la versión actual sería más optimizada en comparación.
Él dice "requiere..." Gramaticalmente, "eso" se refiere a la última cosa a la que se hace referencia explícitamente, es decir, en este caso, "una característica que ya está presente en el producto". Podría haber querido decir otra cosa. Pero me estoy saliendo de lo que estaba escrito.
@EuanM - En realidad... lo sacaste de contexto. Mira las 2 palabras anteriores. El "eso" se refiere a " modificación de una característica que ya está presente en el producto" . El texto "una característica que ya está presente" es solo el contexto de modificación, no su propio sujeto explícito. Técnicamente, "eso", gramaticalmente, se refiere a la "modificación de una característica" . También diría que esa explicación tiene más sentido lógicamente, ya que un cliente que solicita que una característica sea más optimizada es bastante común y es menos probable que incurra en dilemas internos como los que describe el OP.
El hecho de que un cliente solicite optimizar una función es bastante común, es precisamente por eso que es más probable que sea el problema aquí. Nuestros análisis gramaticales están en desacuerdo, y tendremos que estar de acuerdo en diferir de ellos.
@Euan M - No estoy de acuerdo en diferir :) La gramática es gramática. Si te dijera "Tengo un grano en la cara. Es molesto". ¿Interpretarías eso como que mi cara es molesta o que el grano es molesto?
Parece que afirma que el inglés es un idioma inequívoco. "Vendo escritorio antiguo apto para dama con patas gruesas y cajoneras grandes."
El hecho de que se puedan hacer oraciones ambiguas es solo un intento de distracción del hecho de que no todas las oraciones son ambiguas. "Un grano en la cara" y "una modificación de un rasgo" no son ambiguos en cuanto a cuáles son los temas previstos.

Me encanta cómo todos en Workplace hablan sobre ética y profesionalismo, donde mucho de lo que hacemos es el resultado de intereses y juegos políticos. La situación aquí es bastante obvia y la respuesta es bastante breve:
el cliente quiere donar dinero (es decir, su ignorancia hace que desperdicien dinero en cosas que ya tienen), el gerente no tiene ningún problema con eso. Ese dinero paga tu salario. Siéntete feliz de tomar ese dinero y siéntete feliz de ser más sabio que tu cliente. Lucro.

Gerente que solicita una tarea que creo que es innecesaria
RespuestasAquíPolítica de privacidad1y, 0v