关于梳理产品
业务层的流程很好梳理，眼见即可。很大一部分2B的产品需要考虑架构上的问题，包括定制开发时本身的架构，都很迷糊。
关于用户体验
在入职之前一直在看产品经理的书，大都是讲用户体验、交互设计的，所以在学习公司现有的产品体系时就很容易陷入过度关注体验的问题。学习过程中本来记录了很多想提出的意见，后来看到这张图的时候重新梳理一遍，筛掉了大部分“可以有，但没必要”的建议。
| 优先级 | 定义 |
|---|---|
| 5（最高优先级） | 涉及公司战略和规划的相关需求 |
| 4 | 业务发展/收入增长的相关需求 |
| 3 | 降低成本的相关需求 |
| 2 | 提升工作效率的相关需求 |
| 1 | 提升用户体验的相关需求 |
这张表的来源是前辈的一篇博客，里面提到了B端产品需求的优先级顺序，用户体验的优先级是最低的。而且现在产品正处在“基线版本→数据标准化→功能迭代”的关键阶段，开发团队的任务很重（不是996胜似996），在这个时候提出一些非常鸡肋的小修改会招至嫌弃，所以一些无关紧要的建议暂时还是搁下了。总结下来对于B端产品的用户体验问题分为两块：
- 体验上出现了障碍（影响用户正常使用）的一定要改；
- 体验上不重要的优化在平衡团队工作压力后决定。
关于撕逼（emmm）
讨论产品功能规划时，行销人员有时会提出一些奇奇怪怪的意见，语气也比较强势。后来和老大聊起这件事儿的时候，他告诉我作为产品经理要坚守的一个原则就是：“合理的建议吸收，不合理的拒绝”。毕竟产品做成什么样还是产品经理说了算对不。
关于产品工作量
离开学校和小公司，进入现在的公司的这一个月都在研究产品线和相关的技术架构，越发感觉很多项目完全不是一个级别的东西。在学校里见到的项目，都是实现功能即可（反正没人用），而公司产品的规模大了（用的人多了）、产品线多了，就需要各种架构来支撑，需要造很多中间件来支撑并发量等等。从动画的角度来说，大概就是“一个能动就行，一个千万特效”。从本质上来说是一样的：让用户看完这个故事，但体验和观感也完全不同。
关于文件归档
整理以前的历史文件过程比较熬人，拿到过去版本所有的产品材料之后第一个念头就是“先读一遍，然后归档”。产品的资料比较特殊的地方在于像一个二维表，就像这样：
| 低保真 | 高保真 | 功能需求 | 立项材料 | 竞争情报 | 标准方案 | ... | |
|---|---|---|---|---|---|---|---|
| v1.0 | |||||||
| v1.1 | |||||||
| ... |
这个结构的文件归档就比较让人头秃，试了好多种办法最后决定这样：
/
├── 低保真
│ ├── v1.0 // 版本1.0的所有低保真文件
│ ├── v1.1 // 版本1.1的所有低保真文件
│ ├── file1 // 当前最新版本的文件1
│ ├── file2 // 当前最新版本的文件2
│ └── ... // 当前最新版本的文件N
├── 高保真
│ ├── v1.0 // 版本1.0的所有高保真文件
│ ├── v... // 版本N的所有高保真文件
│ ├── file1 // 当前最新版本的文件1
│ └── ... // 当前最新版本的文件N
├── 功能需求
│ ├── v1.0 // 版本1.0的所有需求文件
│ ├── v... // 版本N的所有需求文件
│ ├── file1 // 当前最新版本的需求文件1
│ └── ... // 当前最新版本的需求文件N
├── 立项材料
│ └── ...
├── 竞争情报
│ └── ...
├── 标准方案
│ └── ...
├── ...
├── udt // 未归档文件
├── etc // 其他文件
└── bak // 弃置不用的历史版本
这样做的好处在于新版本的内容很多都是新增的，并不包含所有的内容。以高保真为例，新版本中往往只会存新功能的高保真，很多没改动的功能还要到老版本文件夹中找，这样寻找会比较方便。
另外，为什么要把新版本的内容摊开，因为从使用频率上来说，新版本内容使用的是最多的，将老版本收纳到深一层，结构不会特别乱，存取也比较方便。
网友评论