本篇不是理论知识的总结，而是本人在实际工作中，从一个单纯的UI设计师到一个初级产品的转岗心路，逐步学习使用文档来管理需求的过程，其中的过程和内容都是经验所得，故可能并不适用于每一个人，但如果你有兴趣了解如何从一个UI设计转岗到UX设计，倒是可以参考下。

目录 

一、转型之路 

二、初出茅庐之需求收集 

  1. 用户访谈总结需求

  2. 用户建议提炼需求 

  3. 业务部门提需求 

  4. 自己提需求 

三、优化更新之需求管理

四、初见成效

一. 转型之路

大概在一年半以前，由于公司架构调整，我面临了一个职业选择，是继续留在公司，换个团队尝试新的工作内容，比如团队缺失的产品经理，还是离开这个公司，继续自己的设计之路。

经过一番挣扎，我选择了前者，先从一个交互设计师开始做起，主要有着几点考虑：

1.  公司行业和发展前景不错，相对职业选择，我认为行业选择其实更加重要，因为设计本质说是为了商业服务，商业繁荣则设计也能鸡犬升天；

2.  入了设计的坑好多年了，个人认为职业成长一方面需不停提升设计能力，另一方面，可能很多人会忽略，就是需加深对业务的了解，参与整个业务流程。更多了解业务和流程，不仅可以加深对设计细节的把控，更加更好了解原始需求，更快达到解决问题的目的。

3.  产品需要接触服务业务的上下游，可以锻炼总结和表达能力，这也是我一直比较欠缺的能力，在实践中学习无疑是一个很好的补足机会。

二. 初出茅庐之需求收集  

在职场没有可以直接学习的前辈的情况下，问认识的人和看相关的书和资料是最直接的办法了。于是开始看大家都知道的那本书——《人人都是产品经理》，粗略看了一遍，了解了产品经理和需求之间的宿命关系，书里提供了两个关于需求收集和需求整理的表格，于是我尝试使用这个表格来记录需求。

先说说需求收集，在我之前，我们团队的需求传达比较复杂，测试或者团队领导从用户那里收集过来，然后直接记录在jira上。（jira是我们公司用的一个项目管理软件，可以将任务拆解，各个角色都可以分摊追踪任务，从需求到设计，开发，测试直至上线，都可以直观查看每个需求和完成度）。但是在需求记录方面，并不是太理想，主要是因为我们收集需求时，记录的是用户需求，而很多情况下，用户需求并不等于产品需求。

举个简单的例子，用户说要一匹更快的马，但是经过需求评估，我们确定这个需求无法实现，于是我们转换思路，生产了一辆比马快的汽车，来完成他的要求。

书里提到有5种需求收集方式，分别是现场调查，AB测试，日记研究，卡片分类法和自己提需求。经过实践，我收集需求的方式主要为用户访谈总结，用户建议总结，自己提需求和业务部门提需求四种，辅助手段为日记研究。

1. 用户访谈总结需求

最开始的需求收集从一个用户访谈开始。我们客户端，移动端，测试和算法四个部门，总共十几个人，去用户的工作场所拜访了对方，现场访问并记录了需求。一开始，我并没有使用书中的表格来记录需求，如果认真填写每一个需求的收集表，当然前提是，你不可能让你的用户去填写这些表格和内容，要是做过问卷调查的人就知道，即使简单的选择问卷，要让受访者填写也需要非好大一番功夫，何况是文字填写的内容。所以一开始记录的内容，比较简单，就是时间，用户和用户表达的内容。

那次用户访问非常慌乱，也是我人生中第一次正式的用户访谈。虽然大学时候做过很多项目，也像模像样做过，但是和实际情况比起来，完全不是一回事。由于事先没有任何准备，只能让用户来阐述她遇到的问题，于是用户只能按照自己能想到的部分来描述。作为记录人员的我才发现，我对我们的产品这么不了解，因为产品专业领域性较强，专注于医学正畸的，一方面我听不懂用户的一些描述用语，另一方面，用户描述的问题应该属于哪个部门哪个环节应该改善的问题，我也回答不上来，只能先硬着头皮先记录下来，等到回去整理的时候，再问资深的同事，帮忙理解和分析。

有了那次比较混乱的经历后，我决定为后面的用户访谈做一些准备，于是有了以下两个文档，分别是访谈对象资料准备和访谈流程规划。两个文档主要是为了调研新需求准备的，兼顾对软件旧功能的反馈。后来在访问用户时，也都起到了很好的作用。

在收集访谈对象资料阶段，使用了日记研究的方式，通过收集用户在系统和互联网上的信息，总结到文档中，并将信息同步给一起参加访谈的同事，不仅可以有助于拉近和访谈对象的距离，让过程变得更顺利了些。

表格只是一种形式，各个行业和具体项目可能涉及的内容都可能不同，建议在做用户访谈之前做好一些准备，比如了解访谈对象，这有助于在访谈时控制氛围，当用户放松且对你怀有信任的时候，他会更加愿意和你沟通，从而有助于你了解你想要调研的部分内容，也可以在双方都停滞的情况下迅速找到新话题来继续访谈而不至于尴尬。

2. 用户建议提炼需求

用户经常会将意见反馈给销售、测试、客服或者其他部门同事，这些意见再通过他们传达给我们，有一些是建议，有一些是抱怨，也有一些是表扬，对我们来说，这都是第一手的体验，常常可以总结出比较重要和优先的需求。

3. 业务部门提需求

原本内部的需求也是由业务部门提出给到项目经理，记录在jira上的形式来执行的，后来部门结构调整后建立起了新流程，内部需求由专门的负责人每月收集起来，统一汇总到一张需求表格中，再由测试部门（比较熟悉公司所有部门和产品）来区分执行部门和团队，转发给对应团队负责人，团队评估之后反馈工期和执行方案。目前来说，新流程还比较流畅，只是随着需求变多，搜索和更新还是变得困难起来了。

4. 自己提需求

随着用户访谈，自己对产品使用也变得频繁具体起来，对交互中存在不合理或者反馈不足的地方，也能够有更深的体会，总结出一些意见来。

有些交互需求，涉及到前后端和各部门，看起来是个不起眼的小功能，但是一旦修改，需要参与的部门可以多到让你崩溃，为了实现需要跟所有部门沟通，再制定方案，再到上线，中间的艰辛，以后有时间可以再总结下。按照提出人条件搜索，发现已经有这么多了~

当然还有很多别的方式，后来还试过微信访谈，等以后有更多的方式时，可以再总结下给大家做参考~

三. 优化更新之需求管理 

需求管理1.0

访谈的内容用录音和访谈表格记录下来，即使做了准备，然而实际情况下，聊天内容还是比较跳跃的，尤其当你同时是谈话引导者和记录者的情况下，不时需要给用户引导，避免大家都不说话的尴尬情况出现。回去之后再从访谈内容中总结需求，整理好表格，邮件给相关部门，确保需求能够传达到负责人那里。这个表格用了以下的方式来记录，称之为需求管理1.0。

然后前面提到的需求管理表格出场了，将我们负责的内容，整理成需求，放进对应的表格中。根据下图内容和需求属性来进行管理。

需求管理2.0

这样进行了一段时间，很快发现了问题，商业价值描述，商业属性，商业优先级，开发量，性价比这几列，我根本无法给出准确的描述，团队里，也没有有这种能力来做这个决定的人，尤其在管理和记录的人本来就缺失的情况下。

而且随着需求的增多，查找和关联以及管理都变得越发困难，常常需要在需求评审之前，先把当前的需求整理成新的表格，来进行需求评估，再将结果状态补充回原表格。待确认该版本的所有需求，再将所有需求按照要求填写到jira中，进入正式开发流程中。

这样的过程，需要反复确认的信息较多，于是我大部分的时间都在确认内容，整理表格，搬运需求，为了确保几个表格中的内容能够对应起来，花了很大的精力，很长一段时间，都找不到很好的解决办法。

随着表格记录的需求增多，我对产品的了解也加深了，为了方便管理和搜索，对表格内容和筛选选项、各属性顺序也都进行了优化更新，对每个需求各个维度都进行分类，方便查找、统计和关联，于是就有了如下的版本2.0。

• 增加需求编号：不管信息如果复制对应，都可凭编号快速定位；

• 增加关联需求：随着需求增多，可能会收集到很多类似的需求，增加关联序号，在需求评审时可同时查看关联的需求，方便在实现的时候可以一起解决；

• 增加jira链接：排入开发周期的需求需要追踪过程和结果，增加jira链接可定位到需求的执行效果；

• 增加状态类型和原因：需求不一定都会进入开发阶段，开发完的需求也不一定会进入发布阶段，随着需求增多，需求状态也变得复杂起来，主要增加了待调研，推迟发布和项目中止。若需求不能立刻解决，则标记待调研，找相关人员一起讨论确定；开发结束的需求可能会推迟发布或者因项目中止也不发布。增加相关状态并解释不正常状态的原因，方便回顾和追溯；

• 增加发布信息：开发量估计，预计发布时间，实际发布时间和发布版本；

• 增加开发信息：需要了解之前的功能时，尤其是比较久远之前的需求，可以帮助迅速定位到负责的人；

表格主要是为了方便管理，不同的项目也有不同的需求属性，比如内部需求的表格，需求状态也是不同的，这个可以根据自己实际需求来决定使用的内容。

四. 初见成效

因为出色的需求管理和文档能力（领导原话），19年绩效考评超过了100%，这对我来说，是从没有过的肯定，不得不骄傲一下。

表格和文档可以用来管理需求，制定项目计划，记录团队活动，甚至是定制自己的人生计划，根据自己的需求，来决定维度，颗粒度，在相同框架下，每个人都可以发展出最适合自己的管理方式，这个表格一直在变，虽然已经一段时间没有大的变化了，但是我相信，这也不会是最后的版本。

最后，我认为文档作用不应该是漂亮的内容，华丽的形式，而是切实解决问题的情况下，还能将所思所想所做清晰传达给更多的人。

希望对你有所帮助，给我个赞吧~

Powered by Froala Editor