做产品经理，更多的是做一个产品人，先建立信息秩序，再建立内心的秩序，判断信息，抓住要点，整合有限资源，把自己的价值打包成一个产品向世界交付，并且获得回报。总结起来就是：向世界交付价值并获得回报。（支付宝前PM陆树燊）

需求分析

需求背景

可以用一个模板来理清

• 谁(Who)
• 是什么(What)
• 为什么(Why)

譬如：

• 谁（Who）：消费者/用户 。
• 是什么（What）：想将归档过程数字化。
• 为什么（Why）：为了增强沟通，提高分享效率。

用户画像

数据源

1. 模块上的数据源来自哪里？

举个例子：之前参与评审过【企业门户-企业管理-终端授权】页面。功能随着大家的讨论最后结论是都没有问题，但是最终没有考虑到，终端绑定的数据源S/N是怎么来的。后来整个产品组和赵威一起讨论，才确认出数据源和整个流程的运作，并且画出了流程图。

业务流程图

需求背景与数据源都了解清楚之后，就可以画流程图。这一个环是必须的，不可避免。

功能点

可以用思维导图列出功能点。因为Axure由于有UI交互，每个页面有条件触发，因此XMind等工具罗列出来会更清晰。

字段检查清单

1. 新增主键约束：某一条记录新增的主键标准是什么。这个经常没有考虑到。譬如：IP地址+角色名称构成一个主键吗？重复了怎么处理,是提示还是覆盖？（这一点在批量处理的时候尤其重要）。
2. 无数据情况：是否考虑没有数据的时候要怎么处理，是展示空白？给出“暂无数据“文案提示？ 只展示字段不展示值？这些都要考虑清楚。
3. 极值情况：允许输入的最大值和最小值是多少，超出范围要怎么处理？
4. 异常情况：遇到异常情况要怎么处理？怎么提示？是否允许继续操作？譬如：网络超时要怎么处理？
5. 状态变化：如果牵涉到流程的变动，分别有什么状态？每个状态在什么时候会发生准备，这个配合流程图也许可以比较清楚的说明。譬如：用户可能有从 新增-启用-正常-休假-禁用-离职 等状态。
6. 规则约束：跟第2点有点类似，但是这里可能会更多考虑字段生成的规则。 牵涉到系统自动生成的字段，比如合同编号，随机数，商品编号，更要清楚生成规则，源头不清楚，后面会返工。譬如：采购申请编号：12位数字，系统自动生成，省份编号（2位）+日期（年月日）+4位流水号。
7. 字段关系约束：两个字段或两个记录之间，是一对一，一对多还是多对多的关系，需要说明清楚。譬如：最近接到一个需求，IP地址只允许某些角色登录。那么一个IP地址允许多个角色登录吗?这些需要考虑清楚。
8. 业务关联约束：遇到两个功能相互关联的，比如合同关联发货单，采购申报关联计划，需要清楚描述关联的关系，比如一份计划可以被多个申报关联，但是反过来，一个申报只允许关联一个计划。
9. 消除歧义：需要注意消除歧义。譬如：“六月”和“六个月”概念不同。

列表展示检查清单

1. 排列方式：列表默认按照什么方式排列？
2. 字段排序：哪些字段允许排序？排序是要去数据库重新查询还是当前页面直接排序?
3. 字段多寡：字段是否过多导致展示密密麻麻，甚至出现双滚动条？
4. “无数据情况”：无数据情况要提示什么？

UI & UE

1. 分辨率：是否需要多分辨率支持？
2. 多浏览器：是否需要多浏览器（IE, Chrome, Firefox)支持？
3. 跨设备：是否需要跨设备（Web, IOS, Android)支持？
4. 色彩：本次需求的色彩是否和产品一致？
5. 交互：本次需求的页面交互方式是否和产品保持一致？
6. 弹出框：是否由做自适应？最大与最小长宽是多少？是否有超出三层的弹出框？
7. 双滚动条：列表页、弹出框、Div等是否由出现双滚动条？（横轴、纵轴滚动条）。
8. Error Handling：[图片上传失败...(image-92b135-1534845127502)]
9. 自测化测试工具：UI内容的调整（譬如：按钮名称、菜单栏名称等）需要考虑自动化测试工具的适应性（比如Sahi）

团队协作

评审流程

1. 提前1-5天通过邮件与微信通知参会人员。
2. 开会前明确本次需求的目标。
3. 开会过程中需要记录不同人员意见
4. 会后12小时内，对评审结果通过邮件告知team。
5. 调整过大需要重新开评审会议。

文档

1. 文字要描述清楚，文档自己先check 2遍再发出去，确保没有歧义，没有错别字（蛋疼的搜狗只能输入法...）
2. 每次评审都结果和变更都需要做记录。

领导力与自我管理

自我管理是一个非常有深度的话题，据说谷歌每个员工都能独挡一面，是因为有非常强的自我管理能力。
譬如：那些一眼看过去非常明显的界面问题，应该在版本提交的时候自己优化掉，而不是等QC/QA人员提出来，等别人推着前进。所有开发人员在签入代码前应该自测一边，不要等别人推动自己进步，这样的进步十分有限。

1. 关于评审，一定要自己强势推动，而不是坐等别人推。
2. 公司讲究规范，事无巨细靠文档和邮件约束；一个团队凝聚了却需要靠面对面沟通，prototype支撑，如何权衡平衡两者。
3. 产品迭代更新是不容易，但是如果很容易，就不需要有我的存在，也无法体验出价值了。

晨会

晨会的目的是沟通，发现潜在的问题并且及时规避，培养组员的主动性和思考能力，让每个组员了解大致的目标进度。晨会是敏捷提出自组织的，所以晨会绝对不应该是汇报会，变成检查工作的一个手段。所以也不建议组长坐着，其他成员站着的形式进行汇报，组长应该和组员一样一起参与沟通

1. 组员要明确本次迭代版本的目标是什么。
2. 每天，组员围绕“我昨天完成什么”、“我今天要做什么”、“我昨天有遇到什么问题需要帮助或者协调”这3个主题展开描述。
3. 每个组员用最多3分钟时间来表述。
4. 组员有问题需要抛出来，但是不在晨会上讨论，散会后再沟通。否则会因为组员一个问题拖延大家的时间。

Wiki与保守主义

我觉得一个机制的建立需要一个过程，没办法一夜之间扭转氛围和习惯。比如你做了个WIKI文档，当下次遇到同样问题的时候，大家还是会找你，这时候在给与解释之后，还需要特别耐心的告诉他 其实这个WIKI文档上都写了，有时间可以去看看，多做几次，自然而然大家就会养成找你之前先去查阅WIKI文档了

需求变更流程

数据分析

数据埋点

数据分析

黑客增长

数据可视化