Soy un desarrollador de software que trabaja para una consultoría que lleva a cabo una variedad de proyectos en una variedad de dominios. Los proyectos suelen tener un plazo de entrega relativamente corto (por ejemplo, unos pocos meses).
Encuentro que los clientes expertos en dominios tienen la costumbre de no responder mis preguntas de manera correcta, completa o concisa, tanto por correo electrónico como por teléfono o en persona. Esto me frustra porque normalmente no tengo mucho tiempo para hacer el trabajo, y siento que tengo que seguir persiguiendo a los clientes, ya que solo responden parcialmente a mis preguntas y, a menudo, me generan nuevas confusiones.
Las preguntas que suelo hacer son bastante abiertas, p.
No entiendo el requisito X, ¿podría explicar qué significa -lo que sea-?
O:
He encontrado -algún problema-, aquí hay algunas formas propuestas de resolverlo, ¿qué piensas?
Por lo general, estas son preguntas amplias o no obvias que requieren un poco de reflexión para responder.
Un problema común que experimento es que los expertos de dominio tienden a asumir que sé de lo que están hablando cuando usan términos especializados o discuten cosas específicas dentro de su dominio. También podrían comenzar a hablar de algo completamente diferente, por ejemplo, otro requisito. A veces recibo una respuesta detallada que puede que solo responda una parte de la pregunta y requiere un análisis sustancial para obtener la información que necesito, o una perorata sobre algo relacionado tangencialmente.
Descubrí que cuando interrumpo y pido una aclaración, los resultados realmente dependen de la persona; a veces las cosas pueden aclararse, pero otras veces básicamente repiten lo que ya dijeron, y algunos de ellos pueden volverse impacientes y condescendientes. Incluso si explican lo que significan algunos términos, todavía no soy un experto en el dominio, por lo que solo tengo una comprensión superficial de lo que están hablando, y es difícil saber qué partes son relevantes o no.
Aquí hay un ejemplo artificial y falsificado:
Pregunta: Mencionó que quería que los receptores de PGA se mostraran en una lista: cada PGA contiene una gran cantidad de datos, así es como pienso mostrarlos. ¿Eso te parece bien?
Respuesta: Queremos una forma de mostrar los receptores de PGA que ingresan en tiempo real. Actualmente no sabemos de dónde vienen, por lo que sería bueno si pudiéramos tener una lista que muestre cada uno de sus números e información. Luego entra el QXT2 y procesa esos números. ¿Podemos tener una pantalla para esto? En este momento lleva mucho tiempo ingresar todos los valores P para los datos, pero no estoy seguro de cuál es la mejor manera de hacerlo. El sistema actual se creó hace mucho tiempo y hemos agregado muchos tipos diferentes de LFG desde entonces, cada uno con su propio sistema bongo, que debe ingresarse en una hoja de cálculo separada y cargarse antes de ejecutar la aplicación. Creo que la lista de PGA debería ir en la pantalla principal y tener tantos elementos como se cargaron desde el archivo. Puede que esta no sea la mejor manera de hacerlo, pero funcionará por ahora. Solo tenga en cuenta que el sistema bongo para los PGA debe estar en formato .xml, por lo que no sé cuánta información querrá mostrar para cada uno. Necesitamos cada uno para calcular los valores de T a lo largo del tiempo.
Mis pensamientos al ver algo como esto son que respondió a la pregunta, pero también abrió muchas otras preguntas y está lleno de ambigüedad, que puede o no ser relevante. Puedo tener una comprensión superficial de lo que es, por ejemplo, "PGA", pero nada más, así que no sé si vale la pena preguntar y masticar más tiempo.
¿Estoy siendo poco claro en mis preguntas, o debo formularlas de manera diferente para obtener mejores respuestas, por ejemplo, son demasiado abiertas? Por lo general, trato de evitar restringir las posibles respuestas porque quiero que los clientes piensen en el problema y/o la solución, no solo en "elegir A o B".
No haces preguntas abiertas. Usted hace preguntas concisas y dirigidas para obtener información relevante específica relacionada con una tarea o proyecto que les importa o en el que tienen algún interés.
La gente no está ahí para enseñarte.
Ayúdalos (respondiendo a la pregunta) a que te ayuden.
No, repito, no esperes que la gente esté feliz (o esperando) para ayudarte (aunque lo digan). Todos tienen sus propias responsabilidades de las que ocuparse y es posible que ayudarlo no esté en su lista de prioridades (en la mayoría de los casos).
Si hace preguntas que deberían ser respondidas mediante un tutorial/búsqueda en Google o necesita una sesión de lluvia de ideas, es muy probable que su pregunta sea ignorada/sin respuesta. Haga preguntas basadas en objetivos, directas y relevantes y agregue toda la información relevante en la pregunta misma. Además, mientras se comunica por escrito, no envíe un correo electrónico a múltiples destinatarios, manténgalo muy específico, uno o dos como máximo. Si tiene un problema que debe ser respondido por varias personas, divídalas en preguntas individuales y dirija cada una a la persona respectiva.
Algunos consejos rápidos para hacer una mejor pregunta y aumentar el cambio de obtener una respuesta:
"¿Cómo hago esto" ?
Muestre sus esfuerzos hasta el momento. Decir:
"Intenté hacer X, así que evalué P y Q, y aquí está la lista de pros y contras. En mi opinión/análisis, P nos ayudará de una mejor manera, ¿ves lo mismo? Alguna alternativa mejor que me haya perdido ?"
"Esto no funciona, ¿cómo hacer que funcione?" .
Preguntar:
"Intenté hacerlo funcionar configurando P, configurando Q y pasando por R, pero al final mostró un error que decía "¡hubaa dubba do!". Una búsqueda rápida en Google muestra que necesito importar G y H para resolver esto, intenté pero el mensaje cambió a "Ho Ho Ho!". Se adjuntan configuraciones de muestra que utilicé y los detalles del entorno para la operación. Cualquier pensamiento rápido es apreciado, y si cree que sería necesaria una sesión de depuración, hágamelo configurar uno"
En pocas palabras: cuanto más les facilite la respuesta, más probable es que obtenga una respuesta. Guarde las preguntas abiertas para una sesión de capacitación/aprendizaje.
Por último, pero no menos importante, aquí hay una buena referencia sobre cómo hacer buenas preguntas. cito al autor
"Por conveniencia, y dado que Stack Overflow es tan popular, asumiré que la pregunta se hará en Stack Overflow o en un sitio similar de Stack Exchange. La mayor parte de la publicación en realidad no depende de eso, pero si está preguntando en otra parte, es posible que deba modificar un poco el consejo".
Creo que esto va a ser impopular....
Para el software en mi trabajo, contratamos PRIMERO por la experiencia en la materia, es más fácil enseñar C y ensamblaje (sí, y los rudimentos del desarrollo integrado de núcleo pequeño) que enseñar el flujo de trabajo de TV en vivo y los problemas retorcidos que la gente de operaciones tiene que tratar a veces.
Un buen programador que comprende cómo funciona el dominio es, según nuestra experiencia, MUCHO más útil que un programador brillante que solo puede seguir una especificación y no sabe qué bits es probable que se rompan (y que no reconoce la estupidez en la especificación, hay es generalmente algo).
Lo mismo ocurre con el desarrollo de procesos comerciales y el manejo de cosas como los sistemas CRM. Conozca el negocio primero, si tiene que atacar el desbordamiento de la pila para saber cómo codificarlo, eso es un problema menor que no comprender en un nivel bastante profundo lo que realmente tiene que lograr.
Nuestro gerente de producto es un experto en la materia, pero ¿sabe qué? También lo son algunos de nuestro equipo de desarrollo (y el tema NO es el desarrollo de software).
Esto tiene una ventaja bastante clara, los expertos hablan el mismo idioma y, aunque pueden estar en desacuerdo, esa pelea generalmente tiene una solución que es MEJOR que la que se le ocurrió originalmente a cualquiera de los dos.
El experto en el equipo de desarrollo está diseminando conocimientos al resto del equipo y deteniendo muchas preguntas tontas, por lo que al tipo externo solo se le pregunta sobre las cosas que no tienen una respuesta clara y se le pregunta en su idioma. . El chico del equipo de desarrollo también está muy involucrado en la arquitectura porque una PYME generalmente tendrá al menos una idea sobre a dónde podría ir un producto determinado.
Incluso para un 'mono de código', la comprensión contextual es mucho más importante que la habilidad técnica; de lo contrario, elegiré un lenguaje de nivel superior y dejaré que el compilador maneje mi código por mí (¡Más barato, menos errores y sin pensión que pagar)!
Si su única PYME está muy arriba en la empresa, tiene un problema porque se está perdiendo el tiempo, la PYME está molesta y la gente está trabajando con especificaciones que NO entienden el razonamiento detrás, esto no genera resultados buenos o incluso muy útiles.
Contrate a alguien en el equipo de desarrollo que hable el idioma de cualquier dominio y sepa un poco de desarrollo de software, vale la pena.
Cuando trabajo con expertos en el dominio en mi trabajo actual de ingeniería de software, tiendo a preparar preguntas de sí/no que tengo la intención de hacer dando contexto de por qué me estoy haciendo una pregunta, por ejemplo, un enlace sobre un problema / ticket / tarea relacionado, lo que deduje de preguntando si mi comprensión es correcta o cuál de mis dos escenarios es el correcto.
Del mismo modo, si necesito aclaraciones para un requisito, probablemente prefiera una conversación por chat, teléfono o en persona para poder hacer comentarios sobre si la aclaración llega al punto o no, y si no, aclararme lo que estaba preguntando o preguntar. mas preguntas.
Si necesita capacitación para comprender a los expertos del dominio, ese es otro problema. El conocimiento debe fluir en su empresa para que comprenda cuál es su campo de trabajo, y eso es principalmente responsabilidad de su gerencia que tenga un conocimiento actualizado de abreviaturas, acrónimos, etc. e incluso diría que idealmente incluso absorba parte del conocimiento del dominio para que lo entienda directamente cuando se le presente una especificación.
Es tentador creer que una pregunta más abierta les daría a los expertos del dominio más espacio para ir directamente a su requerimiento, pero por lo general esto solo hace que pierdan el tiempo explicando lo que ya saben, reformulando sin aclarar o incluso perdiendo el punto por completo.
De todos modos, evitaría las expresiones abiertas sobre "pensamiento" o "entradas" sobre un tema vago, ya que no serán satisfactorias, ya que necesita información específica para escribir un código de trabajo.
Las preguntas abiertas son excelentes para las entrevistas. No son la herramienta adecuada para recopilar requisitos.
Cuando preguntas, "¿cuáles son tus pensamientos sobre X?", el mejor de los casos es que el experto piensa "oh, wow, he estado haciendo X durante 20 años y esta persona me pregunta sobre mis pensamientos. ¿Por dónde empiezo? ". En el peor de los casos, asumen que sabes casi tanto como ellos, o asumen que no puedes aprender lo suficiente para hacer lo que se necesita.
En su lugar, pida confirmación. "Creo que X funciona como Y, ¿es correcto?". O, "muéstrame cómo haces Z". Inevitablemente, esto dejará lagunas, ya que habrá cosas que no sabe y sobre las que debe preguntar. Es por eso que necesita tener la primera iteración del software en sus manos lo antes posible (incluso en forma de prototipo) y trabajar rápidamente hacia la próxima iteración que responda a los comentarios de la primera. Prepara a tus expertos para que esperen esto.
Descubrí que la forma más fácil de obtener información útil de los expertos en el dominio es en realidad crear el software que hace lo que crees que es correcto y luego ver qué opinan. Para tomar sus ejemplos:
En lugar de decir esto:
Mencionó que quería que los receptores de PGA se mostraran en una lista: cada PGA contiene una gran cantidad de datos, así es como pienso mostrarlos. ¿Eso te parece bien?
hacer esto:
Ya que dijiste la semana pasada que querías que los receptores PGA se mostraran en una lista, aquí hay una maqueta de lo que estoy trabajando. [incluir captura de pantalla] La idea es que te muestre el mondo bongo de la PGA en la lista, pero puedes hacer clic en el ícono pequeño para abrir más detalles. Esto va a estar listo a partir de la próxima semana cuando Steve suba las figuras de Scooby Doo.
Eso significa que si hay algo realmente problemático, tendrán algo concreto para construir: "Oh, está bien, pero ¿puedes asegurarte de que el PGA se resalte de alguna manera si el factor de humo es superior al 74%? También deberíamos ver el El valor R también está en la lista y necesitamos poder filtrar donde R < 4 o R > 4".
Le entregué el software y dije que es una prueba, algo experimental, así que no confíe en su resultado. Y luego los usuarios han sido invitados a probarlo. Cuando lo hacen, su ojo experimentado a menudo puede ver dónde algo se ve un poco mal y puede diagnosticar el problema. Y diga: no está haciendo lo correcto en el caso en que X se cumple porque entonces esto sucede y debemos tener en cuenta el blegbod.
Por lo tanto, no use correos electrónicos y conversaciones para comunicarse sobre los requisitos del software. Utilice el software para hacer eso. Use cosas como demostraciones, scripts UAT, maquetas, etc. De esta manera, es mucho más fácil para usted decir "¿Es esto lo que quiere decir?". También es mucho más fácil de esta manera para las pymes decir "eso es correcto" o "no, eso es incorrecto porque X".
Los usuarios finales pueden compartir con usted información útil más allá del "bien y el mal". Es posible que no puedan ver los problemas que tienen y digan: "Mira, se necesitan siete clics para llegar a la pantalla que más uso, y luego necesito ingresar la misma información nuevamente y luego esperar a que se cargue". todo mientras el cliente está impaciente al teléfono". Pero si tienes la oportunidad de sentarte con ellos y seguirlos, este tipo de cosas te resultarán evidentes. Si no puede, piense en usar algo como historias de usuarios y mapas de procesos.
Si tuviera una historia de usuario, podría haber dicho algo como "Como plomero de PGA, necesito enumerar los receptores por separado para valores R bajos y altos, para poder ver de un vistazo dónde el factor de humo excede el umbral legal". . Entonces habrías sabido de antemano qué implementar porque sabrías por qué lo estabas haciendo.
Si tuviera un mapa de procesos, estaría claro lo que el plomero de PGA está tratando de lograr y cómo habilitarlo.
Un buen punto de partida es comprender que sus "expertos" se seleccionan principalmente por su competencia en la realización de sus propios trabajos, no por explicar o comunicar el contenido de esos trabajos explícitamente a otros.
Las personas (que podrían llamarse "estudiantes", y así es como voy a caracterizar su papel aquí) que no comparten ampliamente la educación, la formación o la experiencia tácita que tienen los expertos, por supuesto, tenderán a valorar la comunicación explícita. de los expertos sobre lo que implica su trabajo en todos los aspectos. Pero poseer tales habilidades de comprensión y comunicación explícitas como un experto , con miras a reproducir esa experiencia, es el dominio del educador profesional.
Estos "expertos" suyos no son educadores de oficio, y por lo general no serán académicos o intelectuales por naturaleza, por lo que no deben ser tratados a priori como personas a las que solo se les pueden hacer preguntas y de las que se puede esperar una buena respuesta coherente.
La forma estándar en que los expertos en negocios se reproducen a partir de los no expertos es, en primer lugar, convertir a los no expertos en estudiantes de educadores profesionales (es decir, colocarlos en un curso de estudio formal), en segundo lugar, ubicar a los no expertos junto con expertos experimentados donde el la información se transfiere lentamente por ósmosis (generalmente a lo largo de los años) y, en tercer lugar, simplemente permitiendo que los no expertos realicen un trabajo experto hasta que lo descubran por sí mismos (permitiendo potencialmente que se cometan errores en el camino, nuevamente generalmente durante años).
Lo que está haciendo es esperar que sus expertos en negocios adopten el papel de educador profesional para que coincida con el papel que usted ha adoptado como estudiante.
Pero usted está implícitamente poniendo a los expertos en negocios en ese tercer modo de aprendizaje, donde deben aprender (ahora como no expertos) cómo ser educadores profesionales al arreglárselas por sí mismos lo mejor que puedan. Por lo general, esto es sin liberarlos de sus trabajos diarios.
Si encuentra que este enfoque le duele, entonces sabe que el médico le dirá "entonces no lo haga". Sus otras alternativas para obtener el conocimiento de estos roles podrían incluir un curso de estudio formal con un educador real, o podría implicar que su empleador lo siente para hacer este trabajo por un tiempo para adquirir experiencia con él (lo que al menos puede darle un vocabulario compartido y un sentido común compartido con los expertos cuyos cerebros está tratando de elegir).
Si continúa con su método existente de simplemente hacer preguntas a distancia, simplemente tiene que aceptar que a menudo va a ser un poco desordenado y frustrante por naturaleza, debido a la falta de coincidencia entre el papel que está asignando al experto: el papel de educador- y su función empresarial real, que normalmente no es nada por el estilo.
Descubrí que cuando interrumpo y pido una aclaración
Evite interrumpir. Por lo general, es grosero y solo están hablando "demasiado" porque hiciste la pregunta incorrecta. Haz mejores preguntas.
Nunca debe hacer preguntas abiertas al SME a menos que esté socializando. Por lo general, hay diferentes niveles de expertos en el tema, que van desde personas de su propio departamento hasta personas de otros departamentos/empresas externas, ascendiendo hasta el experto de nivel superior con el que está tratando. Evite hacer muchas preguntas al experto de nivel superior. Obtenga la mayor cantidad de preguntas respondidas por personas de nivel inferior primero antes de tomar las que nadie más puede responder a la persona de nivel superior. Tampoco des por sentado el tiempo de nadie. A veces están tan ocupados que solo pueden reunirse con usted una vez cada dos semanas. Nunca asuma que tendrá la libertad de tomar otra hora de su tiempo. Pero van a ser más receptivos cuanto más respetuoso seas con su tiempo cuando trates con ellos.
Recuerde: ellos son expertos en el dominio y usted (!) es un experto en el software que está diseñando o construyendo. (Que podría estar diseñado para servir a los usuarios dentro de ese dominio de experiencia [que usted tampoco tiene]).
Además, "toda la razón de esto, por supuesto igualmente compartida por ambas partes", tiene un propósito muy específico . Su objetivo mutuo (!) es lograr "la creación oportuna de una excelente pieza de software". Sin embargo, solo usted (digamos...) es el "experto en el dominio" en la tarea específica de creación de software.
"Y así, aquí están los dos".
Formule la mayoría de las preguntas tan específicamente como pueda en términos de lo que su software necesita hacer y/o proporcionar. Tal vez prepare algunos escenarios de casos de uso ("historias de usuarios", como se les suele llamar en estos días) para comentarios y contribuciones.
He estado en ambos lados de esta situación particular, y aquí hay algunas cosas que he aprendido.
Mi regla general básica es que las preguntas específicas obtienen respuestas específicas, y las preguntas abiertas y generales obtienen respuestas abiertas y generales . El problema con las preguntas abiertas es que no es obvio cuando en realidad has respondido toda la pregunta. Siempre hay más que podríasdecir sobre el tema, pero en algún momento sientes que es suficiente y dejas de escribir. Esto no es realmente un problema en una conversación cara a cara porque puede hacer preguntas de seguimiento para explorar más. La comunicación asíncrona como el correo electrónico hace que esto sea significativamente más difícil. Si necesita hacer preguntas amplias y abiertas, es mejor hacerlo en persona o por teléfono. Las respuestas incoherentes suelen ser una señal de que, para empezar, la pregunta no era muy específica. La red Stack Exchange es en realidad un buen ejemplo de esto. Piense en el tipo de preguntas específicas y enfocadas que atraen respuestas de calidad rápidamente frente al tipo de preguntas que se cierran como "Demasiado amplias" o "No estoy seguro de lo que está preguntando".
La jerga, las abreviaturas específicas de la industria y los nombres en clave internos son siempre un problema. Tu pyme trabaja casi exclusivamente con un conjunto de personas que tienen una base común de conocimientos que tú no tienes. Es posible que su PYME también desconozca por completo que estos términos y conceptos no le son familiares, o que un término puede significar algo completamente diferente en otros contextos. Por lo general, sigo con un mensaje como "Soy un poco nuevo en su equipo/empresa/industria y no estoy familiarizado con algunos de estos términos. ¿Puede definir qué significa el término 'BFG' en este contexto?" Esta es una pregunta específica que debe responderse en una oración corta o dos. También hace que el lector sea consciente de que es posible que no comprenda toda su jerga y que debe tener un poco más de cuidado con los mensajes futuros.
Además, recuerda que todo este proceso es simétrico. Ambos son PYME con un amplio conocimiento de su propio tema de interés y solo una familiaridad pasajera con el tema del otro lado. Cuando hace preguntas sobre los detalles de implementación (como su ejemplo de "aquí hay algunas formas en las que he pensado en resolverlo"), es probable que la otra persona encuentre su pregunta tan confusa y difícil de entender como usted encuentra su respuesta. Las personas que no son programadores tienden a responder mejor cuando hace su pregunta en términos de un boceto o una maqueta de GUI (como en "cuál de estas dos interfaces parece más fácil de usar"). Si comienza a hablar de cosas demasiado por debajo de las capas de la GUI, los no programadores tienden a no entenderlo por completo o no les importa. Si algún aspecto de sus componentes internos realmente necesita la participación de SME para funcionar correctamente, intente formular la pregunta de una manera que minimice o elimine todo lo relacionado con el software. No intentes hacerles "pensar en el problema y/o la solución"; ya lo hicieron una vez, y su solución fue contratarte. Quieren externalizar la mayor parte del pensamiento posible.
Realmente me gusta el ejemplo que proporcionó, y creo que "responde" la pregunta. No es lo que esperabas, pero ellos mismos no saben la "respuesta correcta y concisa". Podría haber hecho en alguna ocasión algo similar a sus expertos.
Mencionó que quería que los receptores de PGA se mostraran en una lista: cada PGA contiene una gran cantidad de datos, así es como pienso mostrarlos. ¿Eso te parece bien?
Estás preguntando sobre un control de interfaz. Esto puede parecer una pregunta simple y delimitada. De hecho, si tienen un diseño claro en mente sobre cómo debería funcionar el software, puede ser así. Sin embargo...
Queremos una forma de mostrar los receptores de PGA que entran en tiempo real.
No necesitan "una lista". Su requisito real es, de alguna manera, mostrar los receptores de PGA en tiempo real.
Actualmente no sabemos de dónde vienen, por lo que sería bueno si pudiéramos tener una lista que muestre cada uno de sus números e información.
Aunque probablemente se justifique una lista de tipos.
Luego entra el QXT2 y procesa esos números
Aquí, están mencionando su flujo.
¿Podemos tener una pantalla para esto?
lo que añade otro requisito. Sin embargo, es importante tener en cuenta que debería haber una pantalla secundaria de esa lista.
En este momento lleva mucho tiempo ingresar todos los valores P para los datos, pero no estoy seguro de cuál es la mejor manera de hacerlo.
El sistema actual se creó hace mucho tiempo y hemos agregado muchos tipos diferentes de LFG desde entonces, cada uno con su propio sistema bongo, que debe ingresarse en una hoja de cálculo separada y cargarse antes de ejecutar la aplicación.
Información histórica.
Creo que la lista de PGA debería ir en la pantalla principal y tener tantos elementos como se cargaron desde el archivo.
Alguna idea que puede ser sabia o no.
Puede que esta no sea la mejor manera de hacerlo, pero funcionará por ahora. Solo tenga en cuenta que el sistema bongo para los PGA debe estar en formato .xml, por lo que no sé cuánta información querrá mostrar para cada uno.
Algunos consejos útiles mezclados.
Necesitamos cada uno para calcular los valores de T a lo largo del tiempo.
Además de una explicación de los datos que necesitará procesar de los bongos
De hecho, creo que lo has explicado bastante bien:
en cierto modo respondió la pregunta, pero también abrió muchas otras preguntas, que pueden o no ser relevantes
Tienes un problema de diseño. Si esto fuera un desarrollo en cascada. Se redactaría un diseño desde el principio y luego se grabaría en piedra. "Aquí hay una pantalla 2.6.4 con una vista de lista llena de PGA y tres botones".
Creo que está trabajando a partir de un conjunto de requisitos incompletos. No estoy seguro de cuál es tu papel exacto en este proyecto, quién sería el responsable de reunir todos los requisitos y formalizarlos. Si se trata de otra persona, es posible que deba pasárselo a esa persona para que descubra (¿con la ayuda de su equipo?) lo que debe hacerse.
La respuesta experta abre una serie de preguntas (a menos que ya se conozcan). Antes de escribir una línea de código, debe haber un diseño . Esto puede usar un bonito programa de diseño gráfico, lápiz y papel o incluso estar completamente en su cabeza, pero es necesario comprender qué se necesita y (más o menos) cómo hacerlo. Es posible que entre todas esas palabras algunas cosas se arreglen solas, otras requieran la ayuda del equipo de desarrollo o de los expertos. Probablemente me reuniría con el experto en dominios para revisar esta pantalla y cómo diseñarla. Tampoco es raro que a partir de los aportes recibidos allí, el equipo de desarrollo produzca una propuesta, que luego vuelve...
En resumen, en este ejemplo falso, te estabas centrando en una parte muy específica, mientras que hay muchas piezas importantes a su alrededor mal definidas, que necesitan enfocarse primero.
(nota cómo, finalmente, deberías poder responder dicho correo electrónico explicando cómo encajan el PGA, los bongos y el LFG en esa pantalla)
Hay muchas respuestas excelentes aquí, así que lo haré breve para agregar algo que aún no se ha cubierto. Es una estrategia que generalmente utilizo como último recurso cuando otros métodos fallan.
Prepara algo que sepas que está mal. Preferiblemente incorrecto de una manera obvia específica para lo que desea preguntar. Luego haz que lo revisen. Lo más probable es que recibas algunas críticas específicas que te ayudarán.
Una vez más, pruebe otros métodos primero. Pero he descubierto que algunos expertos y tipos de prospectos malhumorados responden a este enfoque de una manera mucho más útil que cualquier otra, y puede ser un camino hacia una relación más constructiva. Sí, puede que tengas que lidiar con sentirte como un idiota por un tiempo, pero muy pronto tendrás su conocimiento y se jubilarán o seguirán adelante y entonces sabrás por ti mismo qué es como responder a este tipo de preguntas.
Respuesta corta: si puede descubrir cómo hacer esto, infórmenos a todos, porque los desarrolladores de software han estado luchando con esto desde los primeros días de la profesión.
Pero dicho esto, algunos consejos útiles que puedo transmitir:
La mayoría de los expertos en la materia con los que he trabajado AMAN la oportunidad de explicar sus trabajos. Te encuentras con algunos que adoptan la actitud de "Todo el mundo debería saber esto. Si no lo sabes, debes ser una especie de idiota babeante". Pero a la mayoría les gusta pensar en sí mismos como genios por haber dominado este campo difícil que nadie más entiende, y están felices de explicar toda la sabiduría que han ganado a través de años de experiencia a cualquiera que los escuche.
Y cuando acaba de ingresar a un nuevo dominio, esto puede ser excelente para usted. Puede encontrar personas que le explicarán todo sobre el dominio en detalle.
Pero, y aquí está el gran "pero", probablemente no saben nada sobre el desarrollo de software. No saben nada acerca de cómo funcionan realmente las computadoras. Por lo tanto, tratar de traducir su conocimiento en requisitos de software es un proceso difícil.
Un ejemplo que he visto una y otra vez: le diré al SME: "Está bien, ya explicó qué hacer en los casos X e Y. ¿Qué debe hacer la computadora en el caso Z?".
Y él dirá: "Oh, no te preocupes por eso, eso casi nunca sucede".
Y digo: "Si CASI nunca sucede, ¿significa eso que sucede a veces?"
Y él dice: "Oh, claro, de vez en cuando. Pero si sucede, haz algo razonable".
Ese tipo de instrucciones funcionan bien cuando se trata de seres humanos. Por supuesto, podría decirle a una persona razonablemente inteligente: "Si la pieza sale de la máquina cortada incorrectamente, colóquela en el contenedor de rechazo. Si sale con marcas de quemaduras, límpielas con este producto químico. Cualquier otro problema, hágalo". lo que puedas para arreglarlos". Y eso estaría bien para un humano. Pero como estoy seguro de que sabe si es un desarrollador de software, no puede simplemente decirle a una computadora "haga algo razonable" o "haga lo que pueda para arreglarlo". Tienes que dar instrucciones específicas.
He tenido muchas conversaciones en las que el SME se molestó claramente conmigo porque seguía presionándolos para obtener instrucciones detalladas sobre lo que la computadora debería hacer en casos extraños, cuando YA ME HABÍAN DICHO que estas situaciones rara vez ocurren y que la computadora debería hacer simplemente lo que puede manejarlo correctamente.
Del mismo modo, pregúntele a cualquier mecánico de automóviles cómo hace para diagnosticar un problema con un automóvil. Muy pocos dirán que realizan la prueba 1 y luego, dependiendo de los resultados, realizan la prueba 2 o la prueba 3, etc. En su lugar, dirán algo como: "Abro el capó y busco algo que no sea bien." Y sí, para un ser humano, si abre el capó del automóvil y ve que sale vapor de la manguera con fugas, no dice: "Está bien, prueba n. ° 1, verifique si le estamos dando una chispa al cilindro 1. " Vas directo al problema obvio. Pero, por supuesto, una computadora no funciona de esa manera.
Entonces, mi punto es que el trabajo del desarrollador es a menudo tomar las declaraciones vagas de "use su inteligencia" de las PYME y convertirlas en pasos concretos. Hasta cierto punto trato de explicar esto a las PYME, ya veces lo entienden ya veces no. Pero por lo general paso la mayor parte de mi tiempo tratando de precisar sus conceptos confusos. Como, "Dices, 'mira lo que está mal'. Está bien. ¿Puedes decirme qué podría estar mal? Dame algunos ejemplos. ¿Cómo sabes que es A y no B?" Etc.
Una vez que comienzas a clavarlos, a menudo encuentras huecos. Como recuerdo una vez que revisé los requisitos y descubrí que habían dicho qué hacer para los envíos urgentes locales; para envíos estándar (no urgentes) de larga distancia; y para largas distancias, envíos express. Pero nunca habían dicho qué hacer con los envíos estándar locales, que supongo que probablemente sería el grupo más grande. Aparentemente, las PYME simplemente se saltearon el caso común y se dirigieron directamente a los casos especiales. Es su trabajo como desarrollador averiguar dónde están los agujeros y hacer preguntas para llenarlos.
Como alguien más mencionó, generalmente es más productivo armar una solución propuesta y pedirle a las PYME que identifiquen las fallas que simplemente hacer preguntas abiertas sobre "¿cómo puedo resolver esto?" Porque si supieran cómo implementarlo en la computadora, no te necesitarían. Si les das algo concreto, pueden decir: "Oh, espera, esto no funcionará bien cuando la barra de navegación no se active" o lo que sea. Si solo hace una pregunta abierta, es probable que deambulen por todos lados.
Formule una lista de preguntas escritas, breves y directas.
Me ocupo de los requisitos de personas que, por lo general, ni siquiera son expertos en el dominio y, a menudo, se trata de un caso en el que el cliente no sabe lo que quiere . Incluso con expertos, puede haber malentendidos y confusión, por lo que las preguntas deben ser concisas y lo más limitadas posible.
Por ejemplo:
He visto que X hace A, pero los requisitos dicen que X necesita hacer B. ¿Prefieres si hace A o B?
He notado que C parece estar fallando, puedo arreglarlo con U o J. Mi preferencia es U, pero me pregunto qué podrías pensar.
Si recibe una respuesta de 'No sé' o cualquier expresión de confusión, puede interpretar que significa que no saben. Puede tratar de encontrar a otra persona o usar su mejor juicio, tomando notas de por qué eligió ese curso de acción.
Los expertos tienen grandes dificultades para traducir su conocimiento a un formato de software computarizado, por lo que a menudo no les es posible responder directamente a ninguna pregunta relacionada con el software, a menos que lo reduzca.
Las preguntas cerradas a menudo se traducen mejor en la selección de opciones binarias que hacen las computadoras. Los abiertos son más útiles para obtener una visión general.
Si todavía no entienden, es posible que tengas que
Usa analogías
Entonces, al tratar con personas que no son expertas en tecnología, a menudo trato de simplificar la consulta a una analogía.
Detecté un caso en el que la persona H no se registra en el sistema debido a un error de software XYZ.
¿Qué es el fallo XYZ?
Bueno, digamos que la persona H ingresa al sistema, y justo cuando presiona enviar, la energía falla instantáneamente; ¿La persona H sigue registrada o se han perdido todos sus datos?
Incluso si malinterpretan la analogía, puedes adaptarla:
Bueno, las fallas de energía son raras.
La falla de energía aquí podría significar muchas cosas, como que alguien jala el cable, el viento derriba el cable, comienza el fuego. ¿El paciente H todavía está registrado o necesitamos un sistema para manejar eso?
En lugar de decir "el formulario podría perder datos debido a un problema de software", lo cual es incomprensible para las mentes no expertas en tecnología, lo he transformado en un ejemplo del mundo real de cómo los datos podrían perderse físicamente de una manera similar, que generalmente solicita un comentario o sugerencia lo suficientemente cercano que se puede adaptar al software.
Sus preguntas y metodologías deben adaptarse al individuo en particular. Lanzar preguntas abiertas dejará a los inseguros aún más inseguros, por lo que a menudo recurren a cosas que ya te han dicho.
Entonces, para evitar cualquier incertidumbre, bríndeles la menor cantidad de información necesaria para trabajar.
El problema general aquí es que se le pide que sea analista de negocios.
La distinción entre un desarrollador y un analista existe por una razón. Interrogar a las PYMES y convertir sus respuestas en requisitos inteligibles y completos es una tarea de análisis empresarial, no una tarea de desarrollo de software. No tienen el mismo conjunto de habilidades y no usan los mismos métodos.
Si el cliente está pagando la tarifa por hora del desarrollador para que busque respuestas que deberían haber sido documentadas por un analista de negocios (menos costoso) incluso antes de que usted comenzara a facturar el tiempo para el proyecto, el cliente está mal atendido y el proyecto está siendo mal administrado por parte de su equipo.
Si no hay un rol de analista de negocios integrado en el proyecto, tal vez porque es nominalmente un proyecto scrum y se supone que debe trabajar en él sobre la marcha, entonces debería trabajar lo suficientemente cerca con las PYMES para que estos incómodos e intermitentes y los intercambios de correo electrónico ambiguos no son un problema; debe estar en contacto constante con ellos y debe tener muchas oportunidades para obtener aclaraciones gradualmente.
Parece que a su empresa de consultoría le falta al menos una capa de comunicación.
¿Tiene un líder de equipo/proyecto o gerente de proyecto? Así es como se supone que funciona el flujo:
Ahora, dado que tiene este flujo de trabajo, la persona que es experta en el proyecto no es el cliente; es el director del proyecto. El director del proyecto debe tener una idea de cómo debería ser el producto final y también cómo debería ser cada parte intermedia del proyecto a medida que se entrega al cliente, porque ellos fueron los que organizaron la división del proyecto en pequeños, boletos entregables. Por lo tanto, deben tener la mejor imagen; deberías preguntarles cualquiera que sea la pregunta. Luego, si no saben, irán al cliente y le pedirán una aclaración; se espera que la PYME del lado del cliente sea capaz de transferir conocimientos a cualquier consideración secundaria, como las que ha descrito, al director del proyecto mucho más fácilmente de lo que podría hacerlo a un desarrollador como usted.
Cygnus oscuro
profundo64azul