通信间隙 : User vs Analyst-Designer

Question

通常的做法是使用案例研究、构建工作流和数据流等。但这并不一定会在用户/发起人和分析设计人员之间创建一个共享的词汇表:一个或另一个通常都会必须获得其他专业领域“内部”的术语和观点，这通常会导致误解和开会澄清(进入 RAD 技术，如进化原型(prototype))等。

用户/发起人专注于他/她的需求/环境，不想，也不应该被迫获得，从他们的角度来看，不相关的“编程术语”。学习新环境的责任在于分析师/设计师(/程序员)。

您如何克服学习曲线？当您面对需要软件解决方案的用户时，什么对您有用？

Answer 1

我用评论

“如果你不能向酒吧女招待解释你的物理学，那它就不是很好的物理学”和“除非你能向你的祖母解释，否则你不会真正理解某件事”(归因于卢瑟福和爱因斯坦)

当我与客户谈论需求时作为口头禅。

采取双管齐下的方法，一个高层次的 Powerpoint 或白板演示，如果您可以让用户在 POC 或模型上放松。

然后逐行做详细的需求。细节决定成败。让他们签署这些细节。给他们贴上标签并编号，这样他们就可以逐行分析。

如果在high level set之前做详细的需求，用户永远无法掌握设计中的任何概念，陷入最细微的细节规范中。在没有任何框架或概念的情况下，用户将围绕图钉头上的天使数量旋转。

只要客户和开发团队可以使用相似的语言，敏捷性和迭代就很好。确保设定并满足期望。