(电子商务研究中心讯) 了解项目，熟悉业务流程及背景
当你接手了一个项目时，先不要去着急了解这个产品的功能，它的用户体验好不好。
首先最重要的是了解这个产品属于B端产品还是C端产品，它的受众人群是广大C端用户还是合作公司？因为二者的本质还是有比较大的差别。
使用B端产品的用户，希望通过这款产品可以将自己内部管理混乱的流程标准化，最最重要的就是可以提高人效。为了提高人效也许不会那么注重用户体验，更不会有一些很炫酷的交互，正如张小龙大神所说的：用完即走。因为作为B端产品不需要对用户增加什么粘性。
其次需要熟悉为什么要有这个产品，打造这个产品的初衷是什么？为了解决当时的什么问题？有和没有这个产品对实际业务有什么影响？提高人效是否可以量化(如：没这个产品办一件事需要1小时，有了这个产品后，办相同的事只需要1分钟)？整个产品的未来规划是什么？
尤其是B端产品，要紧跟公司的战略发展，必须熟悉了解公司当前的战略发展是什么，最重要的战略合作伙伴有哪些，这个产品在公司战略发展中起到什么样的地位。
相信对这个产品有了以上的了解后，在日后的产品需求优先级的判断，及产品设计中会更游刃有余。
需求收集
通过对以上内容对产品的历史及未来有了一定的了解后，接下来就要进入整个产品的初始阶段：收集需求。既然是一款紧随公司战略发展的B端产品，那么高优需求一定是来自业务部门以及相关战略合作公司。
首先收集最高优紧急的需求，也就是与当前公司战略发展最密切相关的，根据关键需求梳理MVP主流程，同时产出流程图。然后确认该流程图中所涉及的角色有哪些，每个角色应该有哪些最基本的功能，才能使整个流程不阻塞，走的通。
有些B端产品不仅涉及到公司内部的多个部门，还涉及到公司战略发展的合作伙伴，这时你就会发现每个部门或合作公司，都会对这个产品都会提一些自己的需求。
这时最重要的两个问题出现了:
1.需求提交流程规范化
当有很多部门或合作公司同时对你所负责的产品提需求时，作为PM，我们是需求的收集方，同时也是需求的过滤方，更是善于梳理流程的专业户。
可以让每个部门选出一个负责收集该产品需求的负责人，每个部门人员的需求统一提交至需求负责人处；同时，每个部门的需求负责人，再选出一个总的需求负责人，由总的需求负责人收集所有部门负责人的需求，同时过滤掉一些提交重复的需求，最后以正式的形式(邮件)交至PM手中。
接到需求后，PM线下和各部门需求提交人积极沟通，了解需求背后的逻辑，需求产生的原因，自己再过滤一些伪需求。
2.需求优先级判断要明确
当非常多的需求到PM手中后，不可能所有需求都在一个版本做完，就算PM产品设计能做得完，但是也得问问天天加班加点的程序员哥哥愿不愿意啊～
所以，要制定重要的需求优先级排序，明确下一个版本要达成什么目标，需要什么功能，在不影响大版本发版的情况下，可以对哪些小的功能进行优化。
明确了需求优先级后，便可以进入到下一个环节—产品设计。
通过以上行为收集了需求，并且明确了需求的优先级，对下一个版本的迭代目标有了更深的理解之外后，再补充一下需求收集中。尤其是迭代目标需要注意的几个重点，避免踩坑：
无论任何需求传递到PM手中，都要与提这个需求的人直接沟通，而不是层层传递，拒绝接收二手需求(如：运营中心市场部门员工A提交需求至本部门需求负责人B手中，B再将需求汇总传递至运营中心总需求负责人C手中，C将需求传递至PM，PM需要对需求进行核实了解，应直接找到A，而不是B或C)
当PM收集了很多需求后，自然要结合公司发展战略，总结出下一个版本需迭代的高优需求。既然是公司战略层面的问题，自然少不了开会。每次开会，会议的决策人最好在场，避免以后将本次会上的所达成的结论推翻。需求高优不高优，有时就是老板一句话的事儿。并且在会议结束后，要将会议纪要同步所有相关人员，做到信息一致。
产品设计
Axure是PM吃饭的家伙，你可以不会PS，不会编程，但是Axure你必须得会。
我非常享受画产品原型的时候，因为这个时候，才是PM真正发挥创造力的时候。此阶段最重要的两个产物，是产品原型和PRD文档，产品原型决定了你的产品长什么样，而PRD文档决定了你的产品规则逻辑。
作为产品小白，刚开始画产品原型的时候，面对一大片空白区域，真的不知如何下手，这一点我深有体会。此时不妨去看看别的产品是怎么做的，竞品也好，还是当今最流行的产品也罢，真的会帮助你少踩不少坑，最好多看几款产品，取其精华去其糟粕。
作为一款B端产品，要本着提高人效的心态去完成这款产品，似乎不需要多么炫酷的交互。因为这个产品的用户是上来工作的，不会因为你一个超炫的视觉效果而爱上这个产品，从而多加加班。
但是最基本的交互是必须要的，如什么时候用浮层，什么时候用弹窗，什么时候打开一个新页面，筛选是用下拉还是点击，完成一件事的操作流程是否足够简洁等等。
界面样式，只是这个产品的表现形式，应该对任何一个细小的功能有更多的联想。例如一个工单列表页，涉及到很多信息：工单提交人、工单实施人、提交工单时间、工单状态、工单完成时间、工单所在地、工单名称等等等等。
这里就涉及到信息展示的问题，要联想到谁会用到这个页面？可能是管理者要登录后台看自己公司的工单信息，那么他希望看到什么？可能要看看自己哪个员工又签单了，什么时候签的单，工单的进展如何了，并且看到这些信息之后有什么样的操作？可能要对已完成的工单操作一下服务成功，或者把某一个进展不顺利的单重新分配给自己其他员工，他希望的达到怎样的效果？
所以要对如此多的信息进行筛选，列出操作此功能的人最关心的信息，将其不关心的信息弱化，或者在工单详情页去展示，并且配上可能出现的场景操作。
在产品设计中，一定要注意产品设计的细节，任何细节都不可想当然。因为研发会根据你所有的需求描述去实现产品，可能会因为一个小细节的变动，牵一发而多全身，有时只是PM的一句话，但是却是研发工作的一整天。
PRD文档的书写要细心，尽量要多考虑产品的边界值，如：设置密码，密码的长度控制在多少位，是否需要特殊符号，大小写是否有区分，对输入不规范的报错形式是怎样，文案怎么写能让用户知道自己输错了等等。
一些技术难题，可以抛给研发去处理，但是对于产品需求，一定要自己去构思完成。
产品开发
终于到了将自己的构思实现出来的重要一步，交付研发。其中自然少不了评(si)审(bi)，我们现阶段的产品评审流程为：组内评审—设计评审—和业务部门评审—研发评审—项目启动。
如果想着研发哥哥会按照自己的产品原型和需求文档，任劳任怨的实现出来，那你就大错特错了。
正式启动研发后，还会发现之前评审没有发现的种种问题。项目正式启动研发后，有以下几点总结：
每天最好以站会的形式和大家同步彼此的工作进展，因为有些研发会有多项目并行的情况，如果有影响上线时间的情况出现，那么也好做出调整，而不是后知后觉。
需求和研发成本如何取舍，根据当前项目紧迫程度做好评估。如某一个需求，研发成本比较高，那此时需判断此需求是否影响主流程，是否属于MVP功能，如果会影响主流程，非做不可，但是做了会影响上线时间，那么就要及时协调研发资源，如果又没有多余的研发资源可供协调，那么就要考虑变更需求或听取研发的其他建议了。如果不是影响主流程的需求，那么就要根据当前项目紧迫程度做好评估，是否可以将此需求延迟至下一个版本。
如有延期上线风险，合理调动研发资源。
尽量考虑周全所能遇到的场景，以便研发设计技术框架。
我所用到的项目管理工具是jira，会在每一次的项目启动后建立相关的用户故事和任务，任务分配给各自负责的研发就好，用户故事可以存放原型和PRD文档。
测试环节
辛苦的程序猿哥哥通过加班加点的写代码，终于通过了联调，将自己的代码部署到了测试环境，那么就该测试和PM上场了。
测试评审尽量叫上相关研发人员，可以作为产品实现是否正确的二次确认。并且评审要细致，将各个功能的不同操作所导致的结果考虑情况全面，归根结底还是PRD文档要书写全面，因为测试同学会根据PRD文档来写测试case。没错，一切都是产品的锅。
每一次新版本的迭代，不仅要测试新增加的功能是否有bug，还是测试产品的主流程是否受到本次迭代的影响。
关于bug，我认为两种非常紧急且重要：
阻塞性bug
影响业务的bug
阻塞性的bug自然不用多说，例如你用微信聊天，信息发不出去；用携程买机票，没法儿出票。
而影响业务的bug是指：用携程买机票，本来机票1000块，但是用户1块就买到了，这个bug不属于阻塞性，但是却影响重大。
产品上线
我们产品上线的流程为：研发提交上线申请—测试回复测试通过并且展示bug处理情况—产品验证是否通过—产品上线—产品发release邮件周知老板们及项目成员。
产品上线意味着两件事：
可以进入到下一个版本迭代的工作当中了。
对本次上线的产品功能负责。
在此主要整理一下产品上线后的注意事项：
尤其是一款B端产品，一定要在产品上线前几天，对公司内部用到该产品的所有部门进行相关培训，并且编写产品功能使用手册及时同步大家。
线上回归测试，收集bug，严重bug紧急修复；影响不大的bug可以考虑到下一个版本迭代修复。
收集用户的使用反馈，对体验不好的功能进行优化。
