通常的做法是使用案例研究、构建工作流和数据流等。但这并不一定会在用户/发起者和分析师-设计者之间创建共享词汇表：通常，其中一方都必须获得其他专业领域“内部”的术语和观点，这通常会导致误解和澄清会议（进入 RAD 技术，如进化原型）等。
用户/发起人专注于他/她的需求/环境，并且从他们的角度来看，不想也不应该被迫获取不相关的“编程术语”。学习新环境的责任在于分析师/设计师（/程序员）。
你如何克服学习曲线？当您面对需要软件解决方案的用户时，什么对您有用？
我用的是评论
“如果你不能向酒吧女招待解释你的物理学，那它就不是很好的物理学”和“除非你能向你的祖母解释它，否则你并没有真正理解某些东西”（出自卢瑟福和爱因斯坦）
当我与客户谈论需求时，这是我的口头禅。
采取双管齐下的方法，高级的 Powerpoint 或白板演示，以及是否可以让用户自由地使用 POC 或模型。
然后逐行做详细的要求。细节决定成败。让他们签署这些细节。对它们进行标记和编号，以便他们可以进行逐行分析。
如果您在高级设置之前完成详细需求，那么用户将永远无法掌握设计中的任何概念并陷入最微小的细节规范中。在没有任何框架或概念的情况下，用户将围绕大头针头上的天使数量旋转。
只要客户和开发团队能够使用相似的语言，敏捷性和迭代就很好。确保设定并满足期望。
本文内容由网友自发贡献，版权归原作者所有，本站不承担相应法律责任。如您发现有涉嫌抄袭侵权的内容，请联系:hwhale#tublm.com(使用前将#替换为@)
