¿Cómo puedo animar a un compañero de trabajo a informar problemas y describir esos problemas pero no a sugerir soluciones?

Este es uno en el que buscaría soluciones laterales. Di sin rodeos que no valoras su opinión y no la obtendrás. Pero (como ha informado): dedique mucho tiempo a validar la idea, pero explique por qué la solución no funcionará, pierda mucho tiempo y obtenga muy poco valor.

He tenido mucho éxito al guiar la conversación para alcanzar mis propios fines en estos. Mi objetivo es: (1) confirmar y aclarar el problema (2) aclarar cuáles son los criterios para una solución (3) examinar un enfoque que conduzca a una respuesta final

Confirmar problema

Así que ahí es donde empiezo: no empiezo con si la solución funcionará o no, empiezo con obtener los detalles completos del problema, aclarados en jerga de ingeniero (no en jerga de analista). No sé muy bien cómo llegan los problemas a su puerta: las llamadas telefónicas pueden ser muy diferentes de algo con un retraso de tiempo como el correo electrónico o los tickets de problemas.

Pero en todos los casos, dejaría en claro que usted toma muy en serio sus comentarios y la naturaleza del problema. Pero generalmente me gusta tener una lista de verificación y no me importa decirles a los usuarios que debo completarla antes de llegar a la parte de la solución:

• ¿Qué vio que estaba mal/malo?
• ¿Fueron los datos o la forma en que fueron presentados?
• ¿Qué estabas haciendo cuando ocurrió?
• ¿Qué te impide hacer?
• ¿Ocurre en otro momento? ¿Puedes hacer que suceda de nuevo? ¿Me puede dar los pasos para que pueda hacer que suceda de nuevo?
• ¿Cuál es la prioridad aquí? (debería estar un poco corroído a "¿qué te impide hacer?")

Sé que suena loco, pero también asegúrese de que los usuarios sean muy conscientes de que está tomando notas y anotando todo. Parafrasea lo que escuchaste y asegúrate de haberlo entendido bien. Un montón de preguntas rápidas formuladas superficialmente generarán una respuesta hostil. Una conversación profunda sobre el problema calmará el temor de que no vas a hacer nada al respecto.

Necesita mantenerse un poco encaminado, pero cuando llegas a "¿qué estabas tratando de hacer?" y "¿qué no puedes hacer con este problema?" - déjalo adentrarse un poco en el mundo del analista. Si bien no puede resolver el problema "a su manera", sí necesita resolver el problema de una manera que funcione para ellos, y eso significa que necesita saber más que un poco sobre lo que están tratando de hacer. Es un espacio blando: puedes pasar un tiempo infinito aquí, y a las personas inteligentes les ENCANTA hablar sobre lo que hacen, por lo que hay algo de trabajo que guía la conversación sobre esto.

Aclarar los requisitos de una solución.

A menos que el problema sea increíblemente claro, probablemente haya numerosas soluciones disponibles. Pero una solución para el analista no es necesariamente factible y una solución para el desarrollador de SW puede no ser realmente una solución para el analista. Deje de lado la conversación "Tengo razón/usted tiene razón" y hable sobre los requisitos para la solución.

A veces puedo dividirlo en dos partes: - Si tuviera que darte algo rápido y sucio, ¿cuál es el cambio más pequeño que podría hacer que te satisfaga? - Si tuviera una varita mágica y pudiera arreglarlo ahora mismo sin tiempo ni esfuerzo, ¿cómo sería la solución?

A partir de ahí, generalmente recae en la persona del software redefinir estas soluciones como requisitos. Aunque los analistas son personas realmente inteligentes, objetivas y conscientes de la información, no son desarrolladores de software y no entienden la jerga muy específica que se utiliza en los métodos de diseño de una experiencia de usuario. Por lo tanto, generalmente termino afirmando lo que creo que es obvio sobre los requisitos de las dos soluciones: "imprescindibles" es cualquier cosa tanto en el mínimo como en la opción chapada en oro. "Quiero tener" en la solución ideal solamente. Pido dos piezas de datos, porque a menudo descubro una gran cantidad de cosas ocultas del tipo "No las necesito en absoluto, es solo mi suposición" en esa solución "mínima" que nunca aparece en la solución "agradable tener".

Al igual que los desarrolladores asumen cosas sobre los usuarios, los usuarios a menudo hacen suposiciones sobre lo que es "fácil". ellos su solución no es nada fácil...

¿Cómo es esto?

Por lo general, un cambio simple es algo que el desarrollador y el usuario pueden acordar por teléfono en este momento... pero apuesto a que el grado de frustración que describes no suele ser de ese tipo.

Entonces, el desarrollador puede necesitar algo de tiempo para crear algo. Pero este es un buen momento para que los prototipos, las muestras de capturas de pantalla y otras ideas vuelvan a ser examinadas por el usuario antes de que ocurra cualquier trabajo pesado. Es como un proyecto mini-ágil: lanza algo y obtén información sobre si funciona antes de implementar y probar cualquier cosa.

Tomarse el tiempo aquí está bien. Sé que siempre siento la presión de anotar algo en una pizarra y terminar... pero este es el momento en el que puedes detenerte un segundo y pensarlo de verdad antes de prometer lo imposible. Descubrí que tomarse unos momentos para pensar aquí en realidad genera confianza, porque en este punto se dan cuenta de que el problema no es "fácil", pero usted está tan comprometido en encontrar una solución como ellos en solucionar el problema.

Conclusión

Esto generalmente genera mucha confianza. Nunca dijiste "no", "estás equivocado" o "tus ideas son completamente imposibles", por lo que nunca creaste el resentimiento que surge de ser excluido. Por lo general, a la gente le gusta proporcionar los detalles de sus problemas, sus sueños de un producto perfecto y dar opiniones sobre algo que aún no se ha hecho, por lo que no está pidiendo nada loco.

Descubrí que muy rara vez las personas (incluso las personas de alto nivel) esperan que usted haga lo que piden sin preguntas, preocupaciones o ideas alternativas. De hecho, la mayoría de las personas inteligentes se dan cuenta de que tiene que haber una ronda de preguntas antes de seguir adelante.

Es solo cómo marca el ritmo de las preguntas y cuáles hace.

No creo que el hecho de que quieran sugerir soluciones sea un problema, creo que de hecho es muy bueno, porque a veces puede funcionar y si no funcionan constantemente por la misma razón, puede valer la pena intentarlo. corregir esa limitación.

Lo que se necesita capacitar es la confianza de que cuando el ingeniero dice que no funcionará, no debería tener que explicar por qué. Se les debe agradecer su sugerencia y alentarlos a seguir pensando en posibles formas de arreglar las cosas, pero también deben confiar en que la ingeniería hará su trabajo y si la idea no funciona, no necesitan saber por qué ganó. no funciona, solo que su esfuerzo por ayudar no está siendo simplemente ignorado.

(Divulgación completa: soy un analista de datos de alto nivel).

Los analistas de datos también son desarrolladores. Comience a tratarlos con el mismo respeto que le daría a otro desarrollador que trabaja en una aplicación relacionada con la suya. Eso es lo que son. Por supuesto que deberían hacer sugerencias. Por supuesto, debe ser libre de hacer su propia solución. Sabes cosas que ellos no saben sobre la aplicación, pero saben cosas que tú no sabes sobre cómo se usan los datos fuera de tu aplicación. Trabajen juntos para encontrar soluciones que se ajusten a las necesidades de ambos grupos.

Si hacen sugerencias con frecuencia, significa que sus soluciones probablemente les hayan causado problemas con frecuencia. Necesita escuchar más acerca de por qué las soluciones que tiene no funcionan para ellos y escuchar sus sugerencias seriamente e intentar una solución intermedia que brinde a ambos grupos lo que necesitan.

Si las sugerencias tienen algo que ver con la estructura de la base de datos (incluidas cosas como restricciones, claves foráneas, estructuras de tablas), entonces ellos son los expertos y debe escuchar con mucha atención. A veces, las cosas que le hacen la vida más incómoda mejorarán drásticamente la calidad de los datos, lo cual es muy importante para las personas que tienen que escribir informes y exportar datos para los clientes. Es bastante vergonzoso explicarle al cliente por qué tiene registros duplicados, por ejemplo, porque los desarrolladores de la aplicación no pusieron ningún control en la entrada de datos. Cuando los datos se utilizan por razones reglamentarias, pueden ir más allá de la vergüenza y convertirse en serios problemas legales para la organización.

A menudo he visto a los desarrolladores diseñar a corto plazo considerando solo lo que será más rápido y fácil para mí. Al acceder a los datos, esa es una estrategia perdedora porque los datos incorrectos o el mal rendimiento de la base de datos son mucho más críticos. A menudo, los desarrolladores de aplicaciones no ven los problemas reales de rendimiento y datos porque no tienen que generar informes con miles de registros. No tienen que explicar los datos deficientes al cliente. Lo que parece una buena solución cuando solo busca ingresar un registro a la vez o extraer los 15 registros que desea mostrar en una pantalla no es una buena solución para las personas que tienen que consumir el conjunto de datos quién más adelante.

Así que escucha las sugerencias y trátalas con seriedad. Si un desarrollador de aplicaciones en otro proyecto hiciera una sugerencia porque su producto afecta el suyo, ¿no se lo tomaría en serio? ¿Le molestaría tener una conversación con él para explicarle por qué eso no funciona o para explorar otras posibilidades? Los analistas de datos merecen el mismo tratamiento.

Esta es una gran pregunta que ha surgido en todas las organizaciones para las que he trabajado. Al abordar el problema, es importante tener en cuenta que la mayoría de las personas que ofrecen soluciones piensan que están siendo útiles sin darse cuenta del trabajo adicional que se requiere para lidiar con la retroalimentación basada en la solución. La raíz del problema es, por supuesto, cultural, pero generalmente se puede reducir a dos cosas:

1. Falta de comprensión de su proceso.
2. Confusión sobre los roles/habilidades de los diferentes equipos y/o miembros del equipo

Al principio puede parecer obvio, pero comprender cómo funciona el desarrollo en su tienda es clave para todos los equipos. ¿Cómo se ve el proceso de desarrollo desde arriba? ¿Qué jugadores están involucrados en varios puntos? ¿Cuál es su ciclo de iteración? ¿Dónde están sus controles y saldos? Una breve presentación/conversación sobre cómo encajan las partes móviles es crucial para que los equipos desarrollen una comprensión y un respeto mutuos por el proceso. Esta discusión preparará el escenario para su conversación de seguimiento (y más puntual) con respecto a los roles del equipo.

Comprender el rol de uno es esencial dentro de una organización, pero igualmente importante es el respeto por la experiencia. Parece que tiene equipos excelentes, pero su comprensión de dónde encaja su experiencia en el proceso es malinterpretada. Abordar el problema como grupo visualizando y discutiendo el traspaso del analista al ingeniero ayudará. Asegúrese de que el equipo tenga un debate sobre la eficiencia obtenida al simplificar el ciclo de retroalimentación. Su equipo debería poder pasar de: problema -- solución propuesta por el ingeniero (obteniendo retroalimentación adicional cuando sea necesario) -- desarrollo. Nuevamente, este es un buen lugar para resaltar partes esenciales de su proceso: revisión de código, ciclos de iteración, pruebas de usuario, etc. para ayudar a todos a confiar en el equipo y en los controles y equilibrios que ha incorporado a su proceso.

Otra estrategia que he usado es la estrategia "Te cubro las espaldas". La relación entre analistas e ingenieros realmente puede solidificarse cuando las personas sienten que se respaldan mutuamente. Si los analistas enfocan sus esfuerzos en comprender los problemas, los requisitos y la buena elaboración de informes, pueden liberar a los ingenieros del estrés y la distracción que resulta de tener que dar marcha atrás. Lograr que los analistas comprendan cuán importante es su función generará orgullo y los ayudará a mantenerse enfocados.

Y finalmente, un tercer problema a menudo se presenta cuando los equipos que brindan comentarios carecen de la terminología utilizada por los equipos de desarrollo (por ejemplo, errores, mejoras, nuevas funciones). Este problema generalmente se puede corregir rápidamente a través de una presentación simple que explica las diferencias, publicando las definiciones acordadas y creando mecanismos para la retroalimentación. Este problema no parece coincidir con su situación particular (se alinea más estrechamente con las unidades de servicio al cliente que brindan comentarios), pero pensé que valía la pena mencionarlo.

En la herramienta de informes, dales dos campos:

Please Describe The Issue in Detail
[                                         ]

If you desire, please add a suggested fix
[                                         ]

Luego simplemente ignore el segundo campo en el back-end.

;)

Intentar que cambien su estilo de comunicación será, en el mejor de los casos, una batalla cuesta arriba. Debe concentrarse en el lado de la conversación que puede controlar : el suyo. Use su descripción de una solución para llegar a una descripción del problema, luego guíelos a una descripción de una solución que se ajuste a los requisitos que no conocen.

Cuando se le presente una solución por primera vez, no empiece a hablar de por qué no funcionará. Primero hable sobre por qué creen que funcionaría . Guíe esta conversación para obtener una buena descripción del problema. Luego proponga una alternativa a su solución que cumpla con los requisitos o utilice tecnologías que quizás no conozcan. Si todavía se oponen, solo entonces describa por qué su solución es inviable.

También es útil no pensar en este tipo de conversaciones como algo que se “atasca”. Es una parte importante del trabajo y es una de las razones por las que tuviste que tomar esas clases no técnicas para obtener un título. Por todos los medios, esfuércese por hacer que la comunicación sea lo más eficiente posible, pero si necesita dedicar tiempo a educar a sus analistas, no debe considerar que es una pérdida de tiempo.

Agradece que no solo obtienes soluciones sin ninguna identificación del problema en sí.

Asegúrese de proporcionar una explicación de la solución que implementó. No tiene que cubrir todos los escenarios posibles, pero podría mencionar algo sobre sus sugerencias. Para la mayoría de los problemas, deberían poder averiguar por qué tuviste que hacerlo a tu manera. Si no, tendrías que dar más detalles.

Mira esto como parte del proceso de aprendizaje. Si creo que las cosas deben hacerse 1-2-3 y usted tiene una razón para 3-2-1, estaré en desventaja al tratar de implementar su solución si no me dice por qué. Supongo que lo que haces es muy complicado y es importante que todos los involucrados estén en sintonía.

Esto parece ser una falla en el proceso de notificación de problemas en su organización.

Tome la visita de un médico, por ejemplo. Muchas personas se han convertido en médicos de wikipedia gracias a unas pocas horas investigando sus síntomas en línea. Ahora, el modelo de diagnóstico alienta e incluso requiere la retroalimentación del usuario (paciente). Ahora tiene diagnósticos de envenenamiento de pacientes con cosas que leen en línea.

El modelo actual de su informe de errores permite o probablemente incluso fomenta demasiados comentarios del informador de errores, lo que lo obliga a tener que jugar 21 preguntas con sus analistas. Yo lo recomiendo

1. Establezca un proceso/procedimiento de notificación de errores/errores documentado formalmente que describa claramente a los actores involucrados y sus respectivos roles.

2. Invierta en herramientas/métodos que pongan cierta distancia entre usted y los analistas (al menos JIRA). La distancia/desconexión fomenta cierto grado de encapsulamiento entre las partes involucradas. Cuando la mayor parte del seguimiento/informe de problemas ocurre en un foro como JIRA, IMO, el reportero de problemas encontrará menos conveniente bromear/discutir soluciones probables (dada la definición adecuada de roles dentro del sistema). Básicamente, su equipo puede prestar atención a las partes importantes de cualquier JIRA y no prestar atención a las discusiones que hacen perder más tiempo.

Originalmente me preguntaba si había una desconexión en los grupos entre lo que mi empresa llama "errores" y "mejoras". Muy a menudo, un problema se puede ubicar en cualquier categoría, pero muchos encajan mejor en una u otra. La información se devuelve como el tipo de datos incorrecto: error. El analista quiere la capacidad de convertir los datos entre tipos al momento de la recuperación: mejora. Entonces, tal vez los analistas estaban sugiriendo soluciones como parte de las solicitudes de mejora. Algunos comentarios del OP sobre la pregunta y las diversas respuestas implican que podría ser parte del problema, pero solo una pequeña parte.

Organice algunos seminarios entre grupos. Pueden variar desde una explicación de los diversos software con los que los desarrolladores tienen que lidiar hasta los flujos de trabajo de los analistas. Grábelos en video para que los nuevos empleados también puedan verlos. Creo que eso ayudaría a ambos grupos a comprender qué es y qué no es posible.

No creo que esta sea una respuesta completa o la mejor, por supuesto, ¡pero es demasiado larga para un comentario!

La solución adecuada para esto es una base de datos de seguimiento de errores, donde los analistas no solo pueden informar errores, sino también enviar sus ideas como solicitudes de funciones (en lugar de perder el tiempo discutiéndolo con usted). Podría haber algunos diamantes entre las piezas de carbón allí.

Si a alguien se le ocurre una o dos ideas muy buenas, puede incorporarlas como una característica en el próximo hito.

[L]as sugerencias a menudo no se pueden implementar en el software debido a otros requisitos de software con los que los analistas no están familiarizados.

¿Los analistas en realidad no le están diciendo qué tipo de código escribir? Guíelos para que describan las soluciones en términos de casos de uso. Las cosas que parecen imposibles de implementar a corto plazo, como la corrección de errores, se pueden hacer con la planificación adecuada y la inversión de recursos.

Es difícil obtener ideas en el software, por lo que debe elegir tantos cerebros como sea posible.

Quizás la mejor solución sería empoderarlos para generar ideas que sean realmente implementables en función de las limitaciones que está manejando, para hacer esto podría agilizar los documentos con los alcances y límites del proyecto.

En caso de que las ideas sigan siendo abrumadoras, implementar un formato para enviar errores que incluya un posible campo de corrección (que podría decidir ignorar) podría ser el camino a seguir.