我正在尝试提出一个快速问题或练习来评估受访者针对需求编写职位的设计和沟通技巧。
我考虑过要一份快速食谱（比如烤奶酪三明治），但感觉不太对劲。 （配方描述了如何制作某些东西；需求描述了最终的对象本身）。
我对建议以及您被问到的好（或坏）问题的示例都很感兴趣。
I'm trying to come up with a quick question or exercise to evaluate interviewees' design and communication skills for a requirements-writing position.
I've considered asking for a quick recipe (like for a grilled cheese sandwich), but that doesn't quite feel right. (recipes describe how to make something; requirements describe the resulting object itself).
I'm interested both in suggestions, and examples of good (or bad) questions you've been asked.
发布评论
评论（6）
确保您的作家了解基本的英语拼写、语法和标点符号。背诵“他们正在那边寻找奖金支票”，并确保他们不会搞乱“他们在那里”、“那里”和“他们的”。
也许比需求编写更重要的是需求收集。如果此人将参与这方面，您可能需要向候选人提出一个假设的项目，并让他们问您他们会向利益相关者提出的各种问题，以便收集需求。
Make sure your writer knows basic English spelling, grammar, and punctuation. Recite "They're looking over there for their bonus checks," and make sure they don't mess up "they're," "there," and "their."
Perhaps more important than the requirements writing is the requirements gathering. If this person will be involved in this aspect, you might want to pose a hypothetical project to the candidate and have them ask you the sorts of questions they'd ask stakeholders in order to gather requirements.
使用当前项目的需求并查看它们的表现如何。
从现有需求中提取一小部分简化的内容，看看它们如何响应。他们会问相关问题吗？他们对问题有深入的了解吗？他们能否建立融洽的关系来解决问题？他们看起来很好奇吗？
我并不是要要求他们为您做真正的工作，只是评估他们对实际问题的简化版本的响应。
提出假问题不太可能告诉你他们在工作中会如何回应。
Use requirements from a current project and see how well they do.
Take a small, simplified part of your existing requirements and see how they respond. Do they ask relevant questions? Do they develop an understanding of the problem? Can they establish rapport towards problem-solving? Do they seem curious?
I didn't mean to ask them to do real work for you, just evaluate their response to a simplified version of a real problem.
Asking fake questions is unlikely to show you how they'd respond on the job.
我不确定具体的问题，但与个人进行详细的对话，听听他们如何选择词语、构建句子以及与你互动，将是衡量基本沟通技巧的好方法 - 这通常会翻译也可以进行书面通信。
例如，选择候选人熟悉的技术主题，并要求他们详细描述该主题的某些方面。听听他们选择的描述有多精确以及他们选择的词语实际上有多合适。需求文档通常由开发人员按字面意思实现，因此作者使用的术语和词语必须是正确的，这一点至关重要。 “词语有意义”——正确使用它们。 :)
另外要注意的是频繁使用通用的、模糊的或宽泛的术语。翻译成需求文档后，这将导致混乱、需求冲突以及浪费时间来澄清。大多数公司都有一个共同的用语或“行话”来要求。作家应该学习，但如果你缺乏学习和正确使用描述的纪律，那么这对你的写作没有任何好处。
最后，在对话过程中，提出澄清问题并观察他们的回答是否只是他们最初所说内容的改写版本，或者他们是否改变立场并使用新的角度进行澄清。因为我们看待事物的方式并不相同，所以能够重新表述一个概念，使特定的听众更容易理解，这对于澄清会议非常有帮助。在采访或讨论中，您是倾听者，优秀的需求编写者应该能够帮助您理解他们在说什么。
I'm not sure about a specific question, but having a detailed conversation with the individual and listening to how they choose their words, construct their sentences, and interact with you would be a good way to gauge basic communication skill - which will often translate to written communications as well.
For example, select a technical topic the candidate knows well and ask them to describe, in detail, some aspect of the topic. Listen to how precisely they choose their descriptions and how appropriate the words they are choosing actually are. Requirements documents are often implemented literally by developers so it's critical that the terms and words the writers are using be the correct terms. "Words have meanings" - use them correctly. :)
Something else to listen for is the frequent use of generic, vague, or broad terms. Translated into a requirements document, this will lead to confusion, conflicts in requirements, and time wasted to clarify. Most companies have a common diction or 'lingo' that req. writers are expected to learn, but if you lack the discipline to learn and use descriptions correctly, then it will do your writing no good.
Finally, during the conversation, ask clarifying questions and observe if their response is just a rephrased version of what they originally said, or if they change gears and clarify using a new angle. Because we don't all see things the same way, the ability to rephrase a concept to be more understandable to a specific listener is very helpful for clarification sessions. In an interview or discussion, you are the listener and a good requirements writer should be able to help you understand what they are saying.
如果您正在寻找产品管理候选人，那么问题应该与业务系统分析师类型的职位有所不同。
我肯定会考虑这个人如何接受一个简单的问题陈述并将其发展为一组需求，并可能确定它们的优先级。
你可以拿像笔这样简单的东西。问题陈述可能是“当我在会议上做笔记时，我需要在纸上写一些东西”。对于这个问题陈述，您可以提出各种要求，例如：
对于需求人员来说，他们必须能够从以下内容中提炼出需求：抽象用例，并提出很多问题。希望有帮助。运气真好！
If you are looking at Product Management candidates, the questions should be somewhat different from Business System Analyst-type positions.
I would definitely take into consideration how the person takes a simple problem statement and develops it into a set of requirements and perhaps prioritizes them.
You can take something as simple as a pen. The problem statement could be that "I need something to write with on paper, while I take notes in a meeting". For this problem statement you could come up with a variety of requirements, such as:
For a requirements person, they must be able to distill requirements out of abstract use cases, and ask lots of questions too. Hope it helps. Goof luck!
可能的问题
寻找：
寻找：
关于烤奶酪问题，您可能会期望潜在客户提出一些问题：
烹饪规格（多长时间、多热）
有很多很多问题，具体取决于您希望食谱的准确性。但答案就在提出的问题中，而不一定是菜谱。好的食谱答案会指导人们在哪里/何时将奶酪放在哪个面包上，等等。这个问题可能看起来很简单，但它确实很复杂，这一切都取决于什么是“假设”和什么不是。 可能的披露：除了给定的之外，不要做出任何假设。
Possible Questions
Looking for:
Looking for:
Regarding the grilled cheese problem, some questions you might expect the prospect to ask:
Cooking specifications (how long, how hot)
There are lots and lots of questions depending on how accurate you'd want the recipe to be. But the answer is in the questions asked, not necessarily the recipe. Good recipe answers would direct someone where/when to put the cheese on which bread, etc. This question may seem simple, but it is really involved and it all depends on what is "assumed" and what is not. Possible disclosure: Make no assumptions other than given.
我从一位雇主那里听到的一个好消息是，他们桌上有一部电话（固定电话），他们要求您完成如何测试它的步骤。
A good one I heard from one employer was they had a telephone (landline) on the table and they asked you to go through the steps of how you would test it.