谈谈我如何使用文档采集和管理要求

　　本文不是对理论知识的总结，而是我实际工作的过程，从简单的UI设计器到主要产品，逐步学习了使用文档管理需求的过程. 过程和内容全都是经验的结果，因此它可能并不适合每个人，但是如果您想了解如何从UI设计转换到UX设计，可以参考它.

　　内容

　　1. 转型之路. 2.雏鸟的需求. 1.总结了用户访谈的需求.

　　2. 用户建议优化需求3.业务部门提高需求4.自己提高需求3.优化和更新需求管理

　　四个. 初步结果可见

　　1. 转型之路

　　大约一年半以前，由于公司结构的调整，我面临了职业选择. 我当时待在公司里，与另一个团队（例如失踪的产品经理）一起尝试新工作，或者离开公司，继续自己的设计之路.

　　经过一番努力，我选择了前者并开始担任交互设计师. 有几个主要注意事项:

　　1. 公司的行业和发展前景良好. 与职业选择相比，我认为行业选择实际上更为重要，因为设计本质上是为商业服务而设计的，商业繁荣也可以带来设计；

　　2. 我进入设计站已有多年了. 我个人认为，职业发展一方面需要不断提高设计能力. 另一方面，许多人可能会忽略它，也就是说，他们需要加深对业务的理解并参与整个业务流程. 了解更多有关业务和流程的信息，不仅可以加深对设计细节的控制，还可以更好地理解原创需求，并更快地解决问题.

　　3. 产品需要与服务业务的上游和下游联系，并且可以行使汇总和表达的能力. 这也是我一直缺乏的能力. 在实践中学习无疑是补课的好机会.

　　两个. 雏鸟的需求集合

　　当没有*敏*感*词*可以在工作场所直接学习时，这是询问您认识的人并阅读相关书籍和材料的最直接的方法. 因此，我开始阅读大家都知道的书-“每个人都是产品经理”. 我粗读了一下，并了解了产品经理和需求之间的致命关系. 本书提供了有关需求采集和需求整理的两个信息. 表单，所以我尝试使用此表单记录需求.

　　让我们首先讨论需求采集. 在我之前，我们团队的要求更加复杂. 测试人员或团队负责人从用户那里采集了这些信息，并将其直接记录在jira上. （Jira是我们公司使用的项目管理软件. 可以分解任务. 每个角色可以共享和跟踪任务. 从需求到设计，开发，测试到在线，您都可以直观地查看每个需求和完成情况. ）但是，就需求记录而言，它不是很理想，主要是因为当我们采集需求时，我们记录了用户需求，并且在许多情况下，用户需求并不等于产品需求.

　　举一个简单的例子，用户说他想要一匹更快的马，但是在需求评估之后，我们确定无法实现这一需求，因此我们改变了主意，生产一辆比马更快的汽车来完成他的任务. 索赔.

　　书中提到有五种采集需求的方法，即现场调查，AB测试，日记研究，卡片分类方法和自我要求. 练习后，我主要通过汇总用户访谈，汇总用户建议，自己提出要求以及业务部门提出要求来采集需求. 辅助方法是日记研究.

　　1. 用户面试摘要要求

　　最初的需求采集始于用户访谈. 我们的客户，移动，测试和算法部门共有十多人，他们去了用户的工作场所互相拜访，访问站点并记录需求. 一开始，我没有使用书中的表格来记录需求. 当然，如果您仔细地为每个需求填写采集表单，则前提是您不能让用户填写这些表单和内容. 如果您已经进行了问卷调查，那么众所周知，即使是简单选择的问卷，也需要很多努力才能使受访者填写，更不用说正文内容了. 因此，开头记录的内容相对简单，即时间，用户和用户表示的内容.

　　用户访问非常令人恐惧，这也是我一生中第一次正式的用户访问. 虽然我上大学时曾做过许多项目，但我做得不错，但与实际情况相比却完全不同. 由于没有事先准备，用户只能解释她遇到的问题，因此用户只能描述她可以想到的部分. 作为录音机，我发现我对我们的产品了解不多，因为这些产品是该领域的专业产品，并且专注于牙齿矫正. 一方面，我对某些用户的说明不了解，另一方面，我的用户说明无法回答应该改进哪个部门和链接的问题. 我只能咬住*敏*感*词*并先记录下来. 当我回过头来进行整理时，我会请我的高级同事帮助理解和分析.

　　在经历了这种混乱的经历之后，我决定为后续的用户访谈做一些准备，因此，我有以下两个文档，即受访者数据准备和访谈过程计划. 考虑到对软件的旧功能的反馈，这两个文档主要是为研究新需求而准备的. 后来，当访问用户时，他们也起到了很好的作用.

　　在采集采访对象信息的阶段，采用了日记研究的方法. 通过在系统和Internet上采集用户信息，将其汇总在文档中，并将该信息同步到参与访谈的同事. 与受访者保持亲密关系可以使流程更加顺畅.

　　表格只是表格. 各个行业和特定项目中可能涉及的内容可能不同. 建议在进行用户访谈之前做一些准备，例如了解受访者. 这有助于在面试中控制气氛. 当他放松并信任您时，他将更愿意与您交流，这将帮助您理解要调查的某些内容. 当双方停滞不前时，您也可以快速找到新主题以继续采访. 至于尴尬.

　　2. 用户建议完善自己的要求

　　用户经常向销售，测试，客户服务或其他部门的同事提供反馈. 这些意见然后通过它们传达给我们. 有些是建议，有些是抱怨，有些是赞美. 对我们来说，这都是第一手经验，通常可以总结出更重要和优先的需求.

　　3. 业务部门的需求

　　业务部门还向项目经理提出了原创内部要求，并将其记录在jira上以供执行. 后来，在调整部门结构之后，建立了新的流程. 内部需求由专门的负责人每月采集. 将它们汇总为需求表，然后测试部门（更加熟悉公司的所有部门和产品）将执行部门和团队区分开，并将其转发给相应的团队负责人. 团队评估后，将反馈项目进度和实施计划. 目前，新流程仍然相对平稳，但是随着需求的增加，搜索和更新仍然变得困难.

　　4. 问自己的需求

　　在接受用户采访之后，我对产品的使用变得更加频繁和具体. 对于互动中不合理或反馈不足的情况，我也可以有更深的体会，并总结一些意见.

　　一些交互需求涉及前端和后端以及各个部门. 这似乎是一个很小的功能，但是一旦修改，需要参与的部门可能太多，您可能会崩溃. 为了实现这一目标，您需要与所有部门进行沟通并制定计划. ，然后上网，在中间的艰辛中，我有时间以后再总结. 根据主持人的条件，我发现已经有很多了〜

　　当然，还有许多其他方法. 后来，我尝试了微信面试. 将来有更多方法时，我可以总结一下以供您参考〜

　　3. 优化和更新需求管理

　　需求管理1.0

　　访谈内容与录音和访谈表格一起记录. 即使进行了准备，但在实际情况下，聊天的内容还是很容易跳动的，尤其是当您同时是谈话的领导者和记录者时，您需要不时提供用户指南，以避免每个人都陷入尴尬的情况无声. 返回后，从访谈内容中总结需求，整理表格，然后通过电子邮件将其发送给相关部门，以确保可以将需求传达给负责人. 该表以以下方式记录，称为需求管理1.0.

　　然后，出现了上述需求管理表格. 我们将责任的内容组织成需求，并将其放入相应的表格中. 根据下图的内容和需求属性进行管理.

　　需求管理2.0

　　一段时间后，我迅速发现了问题，例如业务价值描述，业务属性，业务优先级，开发量，成本绩效等. 我根本无法给出准确的描述. 团队中没有这样的事情. 有这种决定权的人，尤其是在缺少管理和记录人的情况下.

　　此外，随着需求的增加，搜索，关联和管理变得越来越困难. 在进行需求评估之前，通常有必要将当前需求组织到一个新表中，以进行需求评估，然后将结果状态添加回原创表单. 确认该版本的所有要求后，根据需要将所有要求填写到jira中并进入正式的开发过程.

　　在这样的过程中，有很多信息需要反复确认，因此我大部分时间都在确认内容，整理表格并转移需求. 为了确保几种形式的内容可以匹配，我花了很多精力，很长时间以来，我一直找不到很好的解决方案.

　　随着对表格记录的需求增加，我对产品的理解也加深了. 为了便于管理和搜索，还优化和更新了表内容，过滤选项和属性顺序，并且优化了每个需求的每个维度. 分类，易于查找，计数和关联，因此有以下版本2.0.

　　-增加需求编号: 无论信息是否被复制和对应，都可以通过编号快速找到该信息；

　　-增加相关需求: 随着需求的增加，可能会采集许多类似的需求，并且可以增加相关的序列号. 相关需求可以在需求审查期间同时查看，以便在实施时可以一起解决；

　　-增加jira链接: 计划到开发周期中的需求需要跟踪流程和结果，并增加jira链接以定位需求的执行效果；

　　-状态类型和原因增加: 需求可能不会始终进入开发阶段，而已开发的需求可能不一定会进入发布阶段. 随着需求的增加，需求状况变得更加复杂，主要的增长需要进行研究. 推迟发布和项目暂停. 如果不能立即解决需求，则将其标记以进行调查，并与相关人员讨论以确定该需求；由于项目中止，开发后的需求可能会推迟或不发布. 添加相关状态并说明异常状态的原因，便于查看和追溯；