¿Por qué la mayoría de los ingenieros / programadores de software siempre actúan como si conocieran mejor su propio producto y piensan que su opinión sobre cualquier aspecto técnico del mismo es irrelevante?

TLDR; Sugeriría siempre apuntar a tener un diálogo con el equipo de desarrollo, no un debate . Ambos tienen información clave que el otro necesita para que el producto sea exitoso .

Sospecho que muchas personas quedan atrapadas en la herramienta que creen que necesitan, a diferencia del resultado que están buscando.

Esto a menudo se debe a que se centran en mejoras incrementales sobre el status quo y no son conscientes de que las tecnologías subyacentes han avanzado significativamente permitiendo un cambio de paradigma en lo que se puede hacer.

Esto puede crear cierto grado de resentimiento cuando el “usuario” o el “propietario del producto” intenta imponer una solución tecnológica al equipo de desarrollo; En procesos como Scrum (desarrollo de software), el propietario del producto no debe cruzar esa línea en absoluto.

Por supuesto, hay un acto de equilibrio: en algunas ocasiones necesita tener una tecnología determinada porque el mercado solo puede manejar un cambio incremental, o el ciclo de vida del producto es lo suficientemente corto como para que adoptar una tecnología final no sea un problema y sea más rápido .

La clave para mí es asegurarme de tener un diálogo, no un debate .

En un diálogo , se supone que todas las partes tienen una parte de la solución, y que deben trabajar juntos para descubrir el mejor camino. En un debate , la suposición es que un lado está bien y otro está mal.

Para citar al excelente Stephen Covey:

– “busca primero entender, luego ser entendido”
– “piensa ganar-ganar”

Referencias: La magia del diálogo: Transformando el conflicto en cooperación: Daniel Yankelovich: 9780684865669: Amazon.com: Libros )

Los 7 hábitos de las personas altamente efectivas

La mayoría de los ingenieros de software no son obstinados, inseguros o arrogantes, y de mente cerrada. Lo mismo puede decirse de los vendedores y personas no técnicas: no todos son sin principios, no académicos, distantes y perezosos, solo persiguen dinero.

El tono en la formulación de su pregunta me lleva a ver un choque de personalidades, y no un diálogo constructivo que comienza con el intento de descubrir la base de la posición de la otra persona.

En general, es muy fácil y algo injusto y, en última instancia, improductivo formar juicios radicales sobre grupos enteros de personas basados ​​en los valores atípicos visibles y vocales con lo que se consideran atributos indeseables. Tal vez el grupo con el que está tratando localmente comparte estas cualidades debido a ciertas compensaciones. Algunos trabajos necesitan que las personas tengan un alto grado de auto-creencia irracional que raya en locos, por ejemplo, empresarios (si lo piensas objetivamente, tendrías que ser un poco loco para comenzar algo cuando las probabilidades están en tu contra en casi todos los sentidos ) Yo diría que lo mismo se aplica a muchos campos donde tienes que luchar contra la razón para hacer lo que seguramente puede suponer un gran sacrificio personal (correr hacia la línea de fuego).

Mire esto desde una perspectiva de comportamiento humano:
Se puede argumentar que la mayoría de las personas se sentirían consoladas al saber que tienen razón, en lo que hacen y en sus puntos de vista sobre el mundo. Una falta total de confianza y ningún modelo para el mundo causaría que la mayoría de las personas experimente algunos problemas importantes. Necesitamos un modelo del mundo y axiomas en los que podamos apoyarnos, al menos a corto plazo.
A veces lo bloquean con fuerza las gargantas de otras personas, ya sea porque son inseguros y quieren la validación del tipo de pensamiento grupal o porque están absolutamente convencidos de su modelo (de nuevo a veces tienes que estarlo). Personalmente descubrí que es más difícil trabajar con estos últimos, pero solo inicialmente. El primero puede estar buscando la aceptación y algunas buenas negociaciones y resonancias en una conversación pueden sacar esto a relucir, y potencialmente podrían ser más flexibles desde el principio.

En todos los casos, se necesita mucho esfuerzo para dejar de lado las inseguridades y el ego, escuchar y seguir aprendiendo. No todos son Buda.
Tener un doctorado o ser multimillonario no requiere ser de mente cerrada ni siempre lo sigue. El más exitoso y satisfecho de sí mismo equilibra confianza, locura y mentalidad abierta. Los libros de autoayuda no te dirán la fórmula. Si hubiera una fórmula, todo el campo de la autoayuda no crecería a su ritmo y mucho menos se mantendría después de que se conociera la solución.

Intenta negociar y hacer eco. Piensa como un psiquiatra. Las personas tienden a suavizarse cuando se sienten escuchadas.
Las causas subyacentes de las diferencias no son la villanía o la malicia, esas son las trampas para eliminar. Eso es lo que hacen las organizaciones de noticias y los políticos felices. Cada uno tiene sus propios motivos, que para ellos son perfectamente sólidos. Es su trabajo desentrañar eso y luego, idealmente, dejarles ver alternativas utilizando un lenguaje que no sea de confrontación, al menos como un comienzo. Si, por supuesto, estás en una posición de gran poder, puedes simplemente STFU y seguir adelante. Pero esa es tu decisión. Solo sé por qué.

Estoy seguro de que esto depende en gran medida de su propio conocimiento que les haya transmitido sobre los aspectos técnicos de un producto (si es un codificador o no) y cuál es el producto (por ejemplo, si es un software escrito real vs. una idea para una aplicación web). Diré que la mitad del tiempo el cliente realmente no sabe lo que quiere. Podrían decir que sí y piensan que sí, pero aún no conocen todas las opciones disponibles y, en general, no pueden predecir lo que querrán al final. Nunca tuve un proyecto en el que el cliente dijera que quería X y siguiera queriendo exactamente X. Realmente no puedo hablar del escenario exacto del título, pero he tenido situaciones en las que hablaré sobre los detalles de algo y seré amable. de tener que cortarlos en ciertos puntos.

No estoy tratando de ser grosero, a veces incluso los dejo terminar, pero la mayoría de las veces puedo ver la viabilidad de lo que quieren, ciertas características e implementaciones de una manera que no pueden, y quieren explica todo cuando realmente no lo necesito todo, y en realidad nos impedirá llegar a las partes importantes. Si los dejo ir en ciertos trenes de pensamiento que quieren seguir, podría tomar fácilmente 3 o 4 reuniones para concretar algunas cosas que deberían hacerse fácilmente dentro de 1, porque no entienden que muchas lo que preguntan es irrelevante, y estaría perdiendo el tiempo. Tal vez volveré a algunas de las cosas que intentaban explicar, pero será de una manera muy específica, y será porque he descubierto la siguiente pregunta lógica. Es difícil de explicar, pero después de un tiempo puede ver claramente que está bien llenar este vacío de conocimiento, ahora esto, ahora esto, ahora esto, en lugar de escuchar una larga explicación y tener que elegir cosas y aún hacer preguntas y verificar dos veces.

La mejor analogía que puedo dar es imaginar si hay un laberinto y tienen que caminar a través del laberinto, tomar callejones sin salida y bucles largos, pero como desarrollador, en ciertas áreas puedes ver un corte recto a través del laberinto. Eso es realmente lo que se siente. No tengo dudas de que muchas otras profesiones tienen lo mismo. Recuerdo que le expliqué algunos de mis síntomas a un médico una vez y él me interrumpió y me di cuenta de que esa era exactamente la misma razón. Él tenía más conocimiento en ese espacio que yo, por lo que fácilmente podría atravesar el laberinto hasta encontrar la respuesta.

También diré que aunque algunas personas realmente tienen el conocimiento necesario para emitir un juicio sobre la mejor ruta a seguir, muchas veces termina siendo la ilusión del conocimiento. Esto es casi más molesto de tratar que alguien que simplemente no sabe algo y está de acuerdo en dejar que el codificador guíe el proceso. Alguien con conocimiento real limitado puede en realidad interponerse y terminar perdiendo el tiempo y tomando una peor dirección solo para saciar su propio ego de sentir que estaban involucrados en el proceso.

Entonces, aunque hay muchas excepciones para cada regla, solo tenga en cuenta que el codificador puede tener una visión mucho mayor y más clara de lo que puede y debe hacerse y que generalmente no estamos tratando de ser un imbécil al respecto, pero a veces el El cliente simplemente no puede ver ciertas cosas.

Este es un problema no solo en el Software sino virtualmente en todo tipo de campos técnicos / de ingeniería … el personal de ventas solo está tratando de calificar una venta mientras que un ingeniero está tratando de hacer una evaluación sobre algo.

Sus resultados previstos son diferentes, lo que agrava el hecho de que la mayoría de los vendedores carecen de credenciales técnicas reales / comprensión del producto que están vendiendo. Pueden conocer las características pero en un grado muy limitado.

Cómo funciona es así:

Vendedor = No sabe nada de todo (Wow JDK es genial, puede escribir software que funcione en CADA máquina … ¿acabo de decir lo genial que es eso?) … un conocedor respaldado por la “personalidad”, la capacidad de construir una buena relación, presentación y habilidades de negociación.

Ingeniero = Saber todo sobre nada (especialización extrema … enfoque muy limitado. ¿Cuántos bytes es el valor predeterminado de asignación de memoria para una cadena en Oracle JVM? Respuesta: ¿Es JRockIt o HotSpot?) … nivel de conocimiento casi inútil (fuera del contexto , incluso para otros campos técnicos … ¿a quién le importa el tamaño del byte JDK String en las operaciones de campo de petróleo y gas, por ejemplo?) respaldado por habilidades de resolución de problemas y experiencia en el dominio.

Estas son caracterizaciones intencionales diseñadas para evocar un entendimiento, la mayoría de las personas no son los “arquetipos” de ninguno de los roles, sino que son fieles en diversos grados. Sin embargo, las culturas generales de cada “tribu” están muy cerca de lo que estoy describiendo aquí.

Los ingenieros son especialistas que con toda probabilidad saben más sobre el producto que vende el vendedor, por lo que es una realidad. Los vendedores inteligentes reconocen con quién están hablando, su propia falta de profundidad y piden expertos técnicos de su organización para unirse a las reuniones … esta es la norma que he visto y he estado haciendo esta evaluación y evaluación tecnológica durante mucho tiempo.

Mucha gente de ventas comete el error de ver a los ingenieros como una especie de impedimento para superar … esa es una actitud incorrecta y termina muy mal en la mayoría de los casos porque los tomadores de decisiones finales no se arriesgarán con la mayoría de las ventas de software si su equipo de ingeniería no es a bordo con él.

El mejor cumplido que recibí fue de un arquitecto de sistemas que me dijo que era el único traje que considerarían permitir en sus reuniones técnicas. Cuando le pregunté el motivo, dijo: “No interceptas la reunión, no haces demandas estúpidas, y lo más importante es que escuches y demuestres que has escuchado lo que decimos”.

Por supuesto, eso me hizo reír. Seguramente los gerentes de producto y otros trajes no pueden ser tan ciegos.

Pero el problema real resultó ser algo diferente, algo casi existencial para la ingeniería. Los pleitos entrarían en estas reuniones técnicas y harían demandas con poco o ningún reconocimiento aparente de las ramificaciones técnicas descritas por los ingenieros. En lugar de una discusión útil sobre todos los requisitos posibles hoy y en el próximo año, y sus compensaciones desde el punto de vista del diseño de ingeniería y codificación, así como desde el punto de vista comercial (para educar a los ingenieros sobre el contexto en el que se utiliza el producto), las reuniones se convertirían en demandas diciendo una versión de “trabajas para nosotros, solo hazlo”.

Desde el punto de vista de la ingeniería, lo peor que puede suceder es diseñar un sistema solo para que surjan nuevos requisitos predecibles fácilmente detectables en el último minuto o después del lanzamiento, que requieren un rediseño significativo del sistema. Los requisitos que pueden aparecer dentro de un año o dos podrían ser útiles para reforzar las decisiones técnicas, pero el problema real es qué necesita el producto hoy, mañana y el próximo año.

Fue pura suerte. Crecí en una familia numerosa donde nos enseñaron a escuchar no solo a enmarcar nuestra respuesta con las palabras que la otra persona había usado. En otras palabras, para demostrar que los había escuchado correctamente y / o darle a la otra persona la oportunidad de darse cuenta de que los entendí mal. Aparentemente, esa habilidad funciona bien si eres un traje en una reunión de ingeniería. Mis preguntas, por pura casualidad, fueron las siguientes: “Si es cierto que tiene esta limitación técnica x, ¿sería posible hacer y? ¿Hay otra forma de lograr y?” o “Me doy cuenta de que esto es espectacular, pero esta es la razón del requisito. ¿Puedes encontrar otras soluciones técnicas para lograr el mismo resultado?”

Porque a la gente básicamente no le gusta cuando les dices cómo hacer su trabajo. No le dice a su mecánico cómo arreglar su automóvil y no le dice a su panadería cómo se supone que deben hacer su pan.

Cuando alguien que no tiene idea de la programación se me acerca y me pregunta “¿Por qué no estamos usando Mongo para este proyecto?” Después de que el proyecto ha estado funcionando durante 6 meses, me dan ganas de golpearlos con un libro.

Contrató a una persona para que se ocupara de los aspectos técnicos de su proyecto y ahora se queja de que están haciendo exactamente eso.

Piensa en los antecedentes de la otra persona. Mientras pasaba su tiempo aprendiendo sobre estrategias de marketing, ellos aprendieron sobre computadoras. Mientras estabas de fiesta, pasaban los fines de semana probando un nuevo software y siendo nerds en su sótano.

Esto es una exageración, pero entiendes el punto. El programador ha invertido cientos de horas de investigación y capacitación y (en la mayoría de los casos) ha pasado más tiempo pensando en el producto que usted.

Si quiere dar su opinión sobre los detalles técnicos, tendrá que hacer un poco de trabajo preliminar y leer la documentación que los ingenieros hicieron sobre su producto. La documentación en sí responderá muchas de sus preguntas y aplastará muchas de sus ideas sin siquiera requerir que un programador lo haga. De lo contrario, serás como un niño de 5 años tratando de explicarle el mundo a su padre.

Al final, generalmente actúan como si supieran mejor porque lo hacen. Es posible que comprenda cómo funciona su producto. Pero ellos conocen la fuente (código) y saben lo que está sucediendo.

En realidad, me encontré con una situación un poco así en el trabajo la semana pasada, pero desde el lado SE. Un usuario algo técnico (todos los usuarios son internos para los principales proyectos en los que trabajo) me pidió que agregara un poco de funcionalidad y me propuso un poco de SQL para encargarme de ello. El SQL hubiera funcionado, pero resolvió el problema de una manera que dejaba un hueco para que se filtraran los datos incorrectos. Espero ser cortés cuando expliqué la preocupación y propuse una solución alternativa, pero no parecía interesado. Su respuesta fue solo hacer lo que sea que lo haga funcionar.

¿Ignoré su conocimiento técnico? No lo creo, pero puede haberlo sentido porque le eché un vistazo a su propuesta, vi un problema y propuse una solución alternativa sin decir nada bueno sobre su solución propuesta. Aunque también estaba un poco confundido porque él no enmarcaba su solución como algo más como una pregunta sobre la mejor manera de crear la funcionalidad deseada.

¿Puedes verte en esto? Si puede o no, es útil si trata a los desarrolladores como socios valiosos, no como monos entrenados que se supone que deben tomar su dictado técnico.

Dijiste “la mayoría”, lo cambiaré de manera optimista a “algunos”.

Algunos programadores son realmente arrogantes. Solía ​​ser uno de ellos. Creemos que de alguna manera estamos por encima de los simples mortales porque sabemos cómo crear software. Y cuando los programadores se juntan en paquetes (trabajan juntos en cubículos) tienden a reforzar esta idea entre ellos.

Una vez leí un artículo que cambió mi forma de pensar: el título era “No hay usuarios tontos, solo programas tontos”. El artículo explicaba cómo el software podría diseñarse de tal manera que cualquiera pudiera usarlo de manera intuitiva y debería ser imposible causar daños o quedar atascado con el software si está diseñado correctamente.

Otra gran revelación para mí fue este libro: El diseño de las cosas cotidianas.

Es posible que pueda “convertir” a un programador arrogante; intente que lea ese libro. También debe leerlo (o escucharlo) y si usted es el jefe, HAGA que sus programadores lo lean.

Y si usted es el jefe … es mejor no aislar a los programadores. Disperse los cubículos de programadores a través del edificio para que escuchen a las personas de ventas y servicio en las llamadas telefónicas y formen pequeños equipos que incluyan un programador con una persona de ventas y servicio para que trabajen con el cliente en mente. Los programadores tienden a trabajar con un enfoque en hacer que el código sea “elegante”. Eso es bueno, pero nadie ve el código excepto los programadores. Es mejor hacer que la experiencia de usuario (UX) sea práctica y productiva.

No soy programador. Demonios, nunca hice nada que valiera la pena, pero puedo darte mis 2 centavos.

No es que sepan mejor, es que son un tercero. Un creador de algo generalmente no sabe si su producto es lo suficientemente bueno, ya que está cegado por el pensamiento de que lo hizo, es su creación.

Tome un autor por ejemplo. Escribió un libro, y está bastante satisfecho con él. Luego viene el editor, un tercero, que ve todos los errores que un creador se perdió.

Nosotros, como creadores, rara vez somos objetivos cuando miramos nuestra creación. Hay una razón por la cual existen las críticas.

Entonces, si haces un programa y crees que hiciste un buen trabajo, siempre habrá alguien que te indicará algo que podrías haber hecho de manera diferente (y probablemente mejor).

Los creadores son, en general (no se aplica a todos), sesgados hacia su creación.

Esta pregunta no solo se aplica a SE / programadores, sino que se aplica a cualquier persona que cree algo.

Antes de que esta pregunta pueda ser respondida, me gustaría entender la pregunta en sí y las suposiciones hechas. (Esto es lo que hacen los ingenieros de software. Si sigues la lógica a continuación, espero que entiendas cómo funciona generalmente la mente de un ingeniero de software).

1. Usted mencionó “la mayoría de los ingenieros / programadores de software”. Me gustaría saber cómo terminamos con esta información. ¿Hay un estudio empírico sobre esto?

2. ¿Cómo define “ingenieros de software” y “programadores” (hay una diferencia considerable entre los dos)?

3. “Saben mejor acerca de su propio producto”: esta declaración implica que el “ingeniero de software” o “programador” no tiene interés en el producto. Me gustaría atreverme y hacer una suposición aquí: que el “ingeniero / programador de software” con el que está hablando construirá este software. Esto significa que tendrá interés en su éxito, lo que implica que el producto también es su producto. Su suposición de que a la persona no le importa “su” producto es un problema.

4. Sobre el aspecto técnico de ser irrelevante. Este es un caso muy subjetivo. Si lo ha enfrentado con “la mayoría de los ingenieros / programadores de software” con los que ha interactuado, hay 2 escenarios posibles. O tienes mala suerte de haberte encontrado con tantas personas muy obstinadas o te han conocido y piensas que tienes una opinión técnica válida, mientras que en realidad no la tienes. No puedo decir cuál es cierto, pero verifique la probabilidad de que 1 persona sea difícil de trabajar contra varias personas que lo son. Las probabilidades no están a tu favor.

En lo que respecta al problema, parece que tiene un problema al trabajar con algunos ingenieros que conoce. Debe arreglar eso y no andar haciendo preguntas en quora con preguntas cargadas solo para confirmar sus sesgos. Esta pregunta puede o no darte las respuestas que te gustan, pero hay un problema subyacente que debe corregirse.

Para mí, todo se reduce al hecho de que puedo darle una nueva perspectiva de sus procesos comerciales y la mejor manera de hacer ciertas cosas. Podría decirse que la mayor parte de mi trabajo es comprender, lo más completamente posible, su negocio y sus requisitos comerciales. Si bien puede explicar lo que hace en función de cómo lo hace ahora, no he estado viviendo y respirando su producto / servicio / negocio durante años y años como lo ha hecho. Esto me da una perspectiva única para resolver los problemas que está tratando de resolver contratándome.

Puedo separar “cómo lo haces ahora” con “cuál es la mejor manera de hacerlo”. A veces me equivoco, pero a menudo un proceso que se me ocurre se simplificará más porque se está desarrollando desde cero en lugar de agregarse a procesos anteriores. Es como entrar a una nueva casa de 4,000 pies cuadrados y ver cómo todas las habitaciones fluyen juntas (mi proceso) versus caminar a través de una casa de 4,000 pies cuadrados que solía ser una casa de 2,000 pies cuadrados pero ahora tiene varias adiciones agregadas. (su proceso) Las cosas simplemente no fluyen tan bien y no es realmente la mejor manera de hacer las cosas. Sin embargo, todo tiene sentido para usted, porque lo ha estado haciendo de esta manera durante mucho tiempo.

Un cliente que puede dar un paso atrás y darse cuenta de estos hechos y comprender que no es necesario obligarlo a cambiar sus procesos solo para que sea más fácil escribir el software, sino que le damos la oportunidad de mejorar sus procesos es el mejor tipo del cliente El peor tipo de cliente es aquel que me contrata para construir un reemplazo para su sistema actual porque no les gusta, pero luego dice constantemente “Tiene que funcionar así porque así es como lo hacemos ahora”. Si quiere que funcione como lo hace ahora, entonces, ¿qué sentido tiene perder el tiempo de todos reconstruyéndolo? Lo odiarás tanto como tu sistema actual si funciona de la misma manera.

Entonces, al final, realmente necesitamos saber al menos tanto sobre su negocio como usted. Si no lo hacemos, no estamos haciendo nuestro trabajo. Usted es quien emite el cheque para pagarnos, por lo que la decisión final es suya, pero le corresponde a usted, como cliente, abrir su mente y darse cuenta de eso solo porque ha estado haciendo algo de cierta manera durante tanto tiempo. Como lo ha hecho, no significa que sea la mejor manera, y que nos haya contratado por alguna razón, y una nueva perspectiva puede ser muy valiosa.

Bueno, como desarrollador, me encuentro con esto al revés. Los usuarios suelen decir cosas de forma general, como “Hacer que sea más fácil de usar”. Pero, ¿cómo puedes saber cómo hacer eso?

Existen muchos programas fáciles de usar. Pero aunque su interfaz parece simple, es el resultado de probablemente años de trabajo de docenas de programadores, o al menos aprovechando la experiencia previa de docenas de programadores en programas anteriores. En el caso de una gran empresa como Microsoft, probablemente cientos de programadores hayan trabajado en ella. Y cometió muchos errores en el camino, cosas que pensaron que funcionarían pero no lo hicieron. Y con los comentarios de los usuarios para descubrir cómo interactuaron con él.

O pueden decirle cómo configurar la interfaz de usuario, por ejemplo: “Coloque todos los controles en una sola página para que no tenga que ir de una página a otra o de una ventana a otra para realizar la tarea”.

Pero eso puede ser contradictorio. Tienen demasiados controles para caber en la pantalla de una computadora y quieren que todos estén presentes a la vez sin tener que navegar entre ellos. O sugiera alguna forma de lidiar con eso que usted sabe por experiencia es totalmente inviable y sería muy frustrante para el usuario, como por ejemplo hacer que la ventana se pueda desplazar y muchas veces el tamaño de la pantalla del monitor disponible, por lo que debe seguir desplazándose hacia arriba y hacia abajo, y quizás de lado y en diagonal para encontrar los controles adicionales y tener que recordar la posición de cientos de controles que están fuera del área de visualización de la pantalla. Eso simplemente no se puede hacer que funcione.

Entonces, lo que sabemos como programadores es: bastante sobre lo que funciona y lo que no funciona en una interfaz de usuario, a menudo aprendió de la manera difícil al tratar de programar ideas y descubrir que no funcionan. Las cosas que puede pensar que son la próxima gran idea en las interfaces de usuario, como hacer que todo sea una gran ventana desplazable para tomar ese ejemplo simple, pueden ser cosas que el programador ya sabe que simplemente no funcionarán en absoluto. Porque esa es su especialidad y área de especialización técnica.

Es como pedirle a alguien que diseñe un puente y le sugieren un puente colgante o un puente de cable, o un puente de arco de celosía, o un puente de proa. Y luego dices que quieres ir con un tipo diferente de diseño de puente.

Está bien, puede tener, por ejemplo, razones estéticas para preferir otro tipo de puente, por ejemplo. Pero si el diseñador de su puente vuelve a usted y le dice “Un puente de cable simplemente no tiene sentido para este tipo de puente” o “Es casi imposible y sería enormemente costoso construirlo como un puente de arco de celosía” o lo que sea – entonces escuchas al diseñador del puente.

Es un poco así con los diseños de interfaz de usuario.

Además de eso, los usuarios a menudo tienen muy poca idea de cómo implementar lo que quieren. Saben o piensan que saben lo que quieren o necesitan. Pero su idea de cómo facilitar el logro de esto con el programa puede no coincidir con lo que quieren poder hacer.

Por ejemplo, a menudo dicen que quieren que agregue alguna función a un programa. Pero cuando lo miras detenidamente, descubres que, en realidad, la razón por la que querían agregar esto era para solucionar algún otro problema en el programa del que aún no han hablado. Había algo que no podían ver cómo hacer, y sugirieron esta nueva característica como una forma de hacerlo. Solía ​​programar estas funciones para los usuarios, pero luego descubrí que, a menudo, después de programarlas tal como lo pidieron, eso (tal vez a veces después de algunas semanas de trabajo a tiempo completo 🙂), descubres que no es lo que necesitaban y no No resuelvan su problema. Y hoy en día, a menudo, después de hablar con ellos, encuentro una solución mucho más simple que resuelve el problema original que fue su razón para pedir la función en primer lugar.

Algo así, para usar una analogía, alguien quiere poder caminar sobre nieve blanda. Pero en lugar de pedirle que diseñe una raqueta de nieve, le dicen: “¿Puede hacerme un par de raquetas de tenis para unirme a los pies? Estoy seguro de que marcará una gran diferencia para los usuarios si solo pueden unirlas. a sus pies “. Y preguntan eso porque han llegado a la conclusión de que esta es la forma correcta de cruzar nieve blanda.

Entonces entras en una larga y compleja discusión pidiéndoles que expliquen cómo quieren que las raquetas de tenis se adhieran a sus pies, y asumes que quieren jugar tenis usando sus pies, y pones todo tipo de ajustes y características basadas en esa suposición, y nunca en ninguna de esas discusiones se menciona nieve suave. Y el resultado final es algo que no sirve para jugar al tenis o caminar sobre la nieve. Y tal vez todo el tiempo tuviste una raqueta de nieve ya incorporada en el programa, pero hubo algo pequeño que se interpuso en su uso como estaba previsto, lo que los llevó a la conclusión de que “simplemente no funciona” y es por eso que se le ocurrió esta solicitud de raquetas de tenis. Y después de pasar semanas intentando programar en esta raqueta de tenis unida a sus pies, descubres que unas pocas horas de trabajo arreglando la raqueta de nieve integrada habrían resuelto todos sus problemas.

Puede ser muy frustrante como desarrollador cuando esto sucede. Solo toma unas pocas horas pensar en las ideas, pero el desarrollador pasará días, semanas o más para tratar de programarlas, y luego descubrirá que no funcionan, una forma muy ineficiente de proceder.

Es por eso que los desarrolladores pueden hacer preguntas bastante extrañas, que los usuarios pueden encontrar difíciles de entender. Y puede ser capaz de decir directamente, cortando una larga explicación “Lo siento, eso no funcionará, o es demasiado difícil de hacer, pero qué pasa con …”. Vienen a ello con otra perspectiva. Vea las cosas desde un ángulo algo diferente y bajo una luz diferente del usuario. En mi caso, no estoy empleado por nadie más, escribo mis propios programas y les pido comentarios a los usuarios y, a menudo, recibo solicitudes de nuevas funciones de ellos, pero creo que la situación es similar.

La respuesta podría ser más evidente si la reformuló como:

“¿Por qué las personas siempre piensan que saben más que todos los demás acerca de sus campos nominales de experiencia y descartan cualquier opinión contradictoria como irrelevante, especialmente si la opinión es de un extraño?”

Esta es la naturaleza humana fundamental, se necesita autoconciencia * y * práctica para superar este sesgo natural y comportarse de manera diferente. En general, la mayoría de los programadores no están muy optimizados para la diplomacia y, por lo tanto, no suprimen esta reacción. Aquellos que tienden a ser los que trabajan en estrecha colaboración con otros equipos, actuando como enlaces o defensores.

En resumen, cualquiera que haga lo contrario es una excepción que se ha entrenado para suprimir sus instintos reactivos.

Porque es el trabajo del programador manejar los aspectos técnicos. Cuando alguien con falta de experiencia técnica toma decisiones técnicas, generalmente baja.
En cambio, es mucho más útil si personas no técnicas (o incluso personas técnicas pero sin saber cómo funciona internamente una aplicación específica) brindan opiniones desde el punto de vista del usuario (sobre cómo debería actuar la aplicación / sistema y no cómo debería hacerlo). implementarse), en función del cual el programador asignado a las tareas puede tomar decisiones técnicas.

Hay un dicho que dice que los médicos son los peores pacientes. Esto también se aplica a las personas que actúan como médicos.

Porque están entrenados para diseñar software y tú no.

He trabajado en empresas que contratan expertos en asuntos comerciales para hacer análisis de requisitos y análisis de negocios. Puede que sepan mucho sobre el área de negocios, pero no tienen idea de lo que están haciendo al tomar decisiones de diseño.

Terminas con cuadrículas que tienen cientos de columnas metidas en ellas y ningún respeto en absoluto por una o muchas relaciones. En los sistemas financieros, los tiene solicitando una funcionalidad que equivale a deshacerse de grandes cantidades de datos para sobresalir. No entienden los diagramas UML ni tienen ningún otro medio para representar o comprender las relaciones entre entidades.

Hay un millón de razones por las cuales un analista de negocios técnicamente capacitado, un analista de requisitos o un ingeniero de software está mucho mejor ubicado que usted para diseñar software.

TL; DR No es que sepan más acerca de su producto, probablemente no; pero puede estar seguro de que saben más sobre su producto y sus usuarios en la plataforma que están desarrollando.

No nos da demasiada información para dar una respuesta significativa, pero hablaré sobre mi propia experiencia.

Soy un desarrollador de iOS. Lo he estado haciendo durante 6 años. Como, bebo y duermo iOS, Objective-C y Swift todos los días.
Este año he desarrollado una cantidad considerable de aplicaciones, que varían mucho en complejidad.

Un cliente tiene una idea para una aplicación y me contrata para desarrollarla. El cliente me habla de la idea y, créanme, la escucho.
Ahora, voy a asumir que usted es uno de estos clientes, el problema es cuando doy mis propias ideas sobre la aplicación, considerando a un usuario de iOS.

Ahí es cuando las cosas salen mal.

Usted me dice que conoce mejor su producto y no voy a discutir sobre eso, pero puede apostar que sé mejor acerca de poner su producto en manos de un usuario de iOS.
Me dice que quiere que parezca un sitio web, use la navegación como una aplicación de Android o una idea de una interacción ridícula, y le diré que no estoy de acuerdo con eso.

Lo que realmente estás haciendo es no respetar a tu usuario.

A menos que contrate un código mono, recibirá comentarios sobre su producto en la plataforma para la que se desarrolla el ingeniero.
Lo más probable es que estén tratando de hacer que su aplicación sea más útil y menos confusa para el usuario, aumentando así sus posibilidades de éxito.

Y deberías alegrarte por ello.

Algunas personas que se hacen llamar ingenieros de software o programadores no son en absoluto profesionales y muchos de ellos tienen opiniones demasiado exageradas de su propio conocimiento. Por otro lado, así lo hacen muchas personas en otros campos. Cuando las personas con alto ego se juntan, pueden ocurrir enfrentamientos como el que usted describe. Si realmente sabe más de lo que los “ingenieros” de software admiten, tal vez debería contratar a diferentes ingenieros de software. Desafortunadamente, hay muchos desarrolladores de software de alto ego en todo el mundo que no aprecian lo poco que saben.

(Como tengo un doctorado, me siento calificado para comentar sobre el siguiente elemento 🙂)
Me he encontrado con un problema similar llamado “dolor en el culo PhD”. Esta es la persona que tiene un doctorado en algo y piensa que esto los convierte en expertos en cosas que van más allá de su esfera de conocimiento. Desafortunadamente, a veces las personas que los contratan suponen que su título avanzado los hace más conocedores que aquellos con títulos menores y, por lo tanto, cuando hay disputas, los doctores a menudo ganan, incluso cuando están equivocados.
Un problema común ocurre con el desarrollo de software. Los PITAP están diseñando algoritmos avanzados o escribiendo programas experimentales en lenguajes exóticos y piensan que saben cómo diseñar software. De hecho, saben poco acerca de cómo hacer que el software sea confiable, robusto, mantenible, soportable, de alta calidad, etc. A menudo producen código descuidado, mal documentado, mal administrado y esperan que los “programadores de nivel inferior” lo arreglen y lo hagan Es adecuado para entregar a los clientes. Las personas altamente competentes que limpian el desorden y a menudo ruegan a la gerencia por cosas como una mejor documentación, declaraciones más claras de requisitos, etc., a menudo se consideran menos competentes porque entienden los problemas y no andan exagerando.

De todos modos, el punto que deseo destacar es que nadie lo sabe todo y la forma más productiva de producir productos finales de alta calidad es ser humilde, reconociendo cuánto no se sabe.

No puedo hablar por todas las personas de TI, pero generalmente cuando me comunico con un proveedor de software independiente (ISV). Ya ejecuté varios rastreos, perfilé el rendimiento de su aplicación, miré el esquema de la base de datos y tengo varias ideas sobre cómo se podría mejorar el rendimiento y / o la interfaz de usuario.

Principalmente quiero hablar con alguien que conozca el producto lo suficientemente bien como para:
A. explique el caso de uso / circunstancias que podría haber pasado por alto y que hicieron necesario su diseño O
B. alguien que apreciará los comentarios e implementará los cambios.

Principalmente consigo el último. De vez en cuando recibo adivinanzas y / o humo de personas que no se dan cuenta de que no saben, o BS para cubrir su incompetencia / imagen.

Recomendación.
Si eres parte del equipo de diseño de producto.
Escuche los comentarios de los clientes. No asuma que lo sabe, el cliente puede estar usando su producto de una manera que ni siquiera anticipó que se usaría.
Tome notas y agradézcales por sus comentarios. (No tiene que usarlo. Especialmente si se da cuenta de que solo están promoviendo su propia visión de tecnología religiosa. Es decir: “¡Oh! Debería reescribirlo en <última versión técnica 2.0 de la moda>“)

Si no lo eres
Toma nota. Evaluar su conjunto de habilidades. Luego, envíe sus comentarios o conéctelos con el equipo del Producto, según corresponda.

Nota: La mayoría de las personas confían demasiado en sus habilidades.
El 98% de las personas piensa que están por encima del promedio al conducir su automóvil.
Parece que un porcentaje similar del personal de TI tiene una confianza suprema en sus propias habilidades.
Según la gran cantidad de soluciones que veo que contienen datos incorrectos y son ineficientes, sospecho que muchos de nosotros estamos bromeando.

Dado que eres tan caricaturista en esta pregunta, culpo a tu actitud de que la conozcas mejor que todos los demás.

Recuerde, el software es un negocio donde los programadores generalmente necesitan discutir para encontrar la mejor solución. Cuando alguien brama, es una invitación a discutir por años de experiencia. Y ciertamente parece presentarse como alguien que quiere que su opinión técnica sea más importante que las personas que hacen el trabajo.

Sin embargo, si proporcionó detalles sobre su posición, puede haber otras razones. Algunas compañías (lo suficiente como para preguntarle cuando entrevisto para un puesto, para poder evitar esos lugares) tienen culturas corporativas terribles, por ejemplo, y la relación entre ingenieros y personas de “negocios” es muy cruda, generalmente debido a que algunos se imaginan juego personal de un lado u otro. Y muchos programadores no quieren que se les vendan cosas, por lo que destrozarán cualquier cosa que huela a una estafa o un producto sin valor. Pero como dije, también podría ser que los estés frotando de la manera incorrecta.