入职至今，也快半年了。极速前进的时候容易看不清路标而走错方向，误闯红灯。所以我提醒自己时时回头看看自己已经完成的事情和自己规划的目标是否匹配，尽可能的做一下复盘总结。

向自己提几个最简单的问题：这期间，我做了什么？所做的东西有价值吗，我学会了什么？这些事情中暴露了自己的哪些缺陷？这些不足如何弥补？新的一年希望达到什么样的效果？如何达成？

入职以来，独立完成了6个案子，合作完成了2个案子，学会深入分析需求，按照自己的“方法论”把抽象需求一点点的还原为场景，进行设计转化。其中有三个案子是自己印象比较深刻的。

①明星APP（JAY&ME）-竞拍自动冻结扣费组件

针对明星App内已有的金币竞拍组件，设计竞拍冻结及自动扣费机制，从产品机制的完善来减少流拍、恶意抬价等负向行为。

工作思考：

| 流程图的作用 · 产品机制完善的作用 · 评审会沟通要点

①对流程图作用的新认知：这个案子在前端表现上很简单，但在规则的制定及数据处理规则上，需要非常细致，才能保证加入新的机制后，用户正常竞拍不会出现影响。这个类型的产品设计，光用前端页面和文字描述，是很难迅速将具体业务场景完全传达给开发同学的。需要用流程图来更逻辑、规范的传达。因为这个案子，开始重新理解“流程图”的作用，之前认为流程图只是一个工作技能而已，是一个沟通中的辅助文档。通过这个案子发现，在一些业务流程较复杂的设计中，流程图不仅仅是一个工具，更是一种沟通桥梁，页面只能表示操作过程，无法说明操作逻辑，需要它才能做到设计和执行（开发）的统一理解。相类似的还有“订餐”流程、“购物”流程等等。并且，流程图如果梳理不清楚，产品也不可能跑通——一张完善的业务流程图是一个好产品的开端。很多业务在用户角度来说，页面简单，操作也只是短短几步，但其中那些看不到的规则和逻辑才是重点，这些内容如果没有梳理清楚，产品是跑不通的，产品人员需要非常清楚每一个步骤、每一个异常对应的输出内容是什么，是否可行。才能保证用户所有操作后看到的内容是产品希望他们看到的。

此外，不同的产品内容还需要不同的流程图类型来配合，比如涉及多个角色互相联系的流程（如科研平台案子：专家、后台管理人员、科研项目人员等），需要泳道图配合表示；单个角色的业务流程，比较适合操作流程图……

②产品机制完善的作用：在这个案子中产品机制的完善能够减少恶意操作，而在更广泛的产品迭代中，产品机制的完善能够减少很多运营压力，从功能上帮助提升产品的指标（比如产品竞拍收入、成交数量等）。因此，要重视对于产品功能机制的完善，不能过分的依赖运营，很多时候机制完善能最低成本的改变一些负向行为。

③评审会沟通要点总结：这个案子是我职业生涯第一次正式的开发评审会，算是认真准备了一番，沟通还算顺利。基本问题都在评审会上梳理清楚并且解决，后期没有太大的变更和返工。

总结评审会的方案介绍，大致如下，可以用于今后大部分需求评审流程——

①介绍需求内容及目的——和公司里一些策划同学聊过，有部分同学基本都是直接开始介绍方案内容，常常遇到开发认为方案没必要或者太复杂等情况（不排除部分需求确实“伪”了些），但私以为跳过“需求内容及目的”的介绍是一个重要原因。忽略这个步骤，开发同学自然不能很好的理解表面需求为什么被你做成了眼前这个方案，他们一般只简单了解需求，不会完全代入你的角度思考这个需求希望达成的目的，不能完全理解解决方案的出发点，这才造成了“怼”方案。

②根据目的详细介绍产品原型（有流程图等辅助工具时，需要详细讲解流程图）——不要觉得原型都画好了，备注都写好了就可以将文件打包丢给开发自己边做边看，一来开发人员对同一段备注、同一个操作的理解和你未必相同，容易造成理解偏差而返工；二来可以在这个介绍过程中让你在一个新的角度重新审视自己的设计，结合开发的角度评判设计是否有冗余、是否可以更优？

③清晰记录每一条与会人员的提问或疑惑——测试或开发同学可能会提出一个个疑问，让你在评审会上或结束后进行解答，这些问题的解答不是关键，关键是要记录下他们的问题，思考为什么他们会有这样的疑惑？是自己的备注说明不够清晰？还是自己的流程设计在实际开发角度上是有问题的？找到别人会有疑问的成因，分析是不是自己的设计上有漏洞，并且找到漏洞来改正。从这个角度常常能够学到埋头设计中学不到的思考维度和内容。

②守护-启动模块设计

公司守护项目准备以H5游戏形式接入QQ，为了保障产品完整性及用户体验，需要进行启动模块相应设计。考虑不同场景下（例如：首次启动、版本更新、日常使用、活动运营、合作推广等）所需要的启动模块功能（例如：启动页、加载页、推广页、游戏防沉迷提示等）

工作思考：

| 学会触类旁通

这个案子主要是对已有项目的完整性补给，启动模块本身内容不多，前端简单展示，后台支持快速配置是这个案子的重点。但这个案子对我来说最大的意义是学会“触类旁通”的工作技能。在做启动模块以前，搜索了启动页的来源、作用、常见表现手法等来帮助自己更深入的理解。虽然所了解与整理的内容不一定对本案都有作用，但系统化的了解和输出，让自己能用更全局的角度思考案子，产出解决方案。

③群聊主动触发用户行为机制

根据不同群、场景，思考设计，如何提醒用户做某些事情的“群聊僚机机制”。

| 组件与产品的关系思考 · 产品信念感

这是入职以来变动最多，耗时最长的一个案子。一开始全心在看自己所接的需求，应该怎么理解，虽然输出了解决方案，但和并行的几个案子产生了冲突。

作为专一的策划人员来说，只从自己接到的需求出发问题不大，但从产品的角度来说，只着眼组件本身，而没有顾及组件与产品的关系，组件与其他组件的关系，就有些失责了。

通过这个案子我也思考了一下组件与产品的关系，产品是所有组件的核心与主干，而组件们作为产品的枝干，是基于本体，进行丰富与生长。我们在每一个组件的设计中，需要了解“本体”的方向，就像榕树永远长不出柳树枝，如果只着眼案子本身，思考的再深入也可能长出的是怪胎，是无价值与意义的。如果要做产品人员，应该脱离公司流程的种种束缚，学会跳脱业务需求，回到整体上做思考。

开发同学跟我说了有冲突案子之后，我和很多人进行了沟通，对整个案子进行了大的改动，过程辛苦了些，但后来得到肯定，蛮值得的。同事说我倒霉，接了个这么坑的案子，产品内的各种冲突与反复修改，不然妥协开发说的东西改改就算了。我倒是觉得，最后能和其他协同开发人员一起想清楚整体的提醒机制是什么样的，这些过程中的精力付出也是有价值的。想到在PMCAFF上的一个问答。

有一个用户提问说“你觉得作为一个产品经理最应该具备的特性是什么？”，很多用户做了专业能力上的回答，答得很全面也很正确，我补充回复——“关于【能力】方面的特性基本上楼上都说挺全了，我想说说能力以外的个人性格特性——“信念”。我觉得做产品的人得要有信念感（听起来挺虚，可在入职场以后我愈发觉得重要，而且是一个分水岭）一是对职业有信念感，要相信自己的工作和做出来的东西有价值、能够创造价值，才能用这个“虚构的精神力量”推动自己在能力上不断跟进，才会督促自己不断更新自己，做的更好。二是对自己的产品有信念，明确产品到底要成为什么样，实现什么大众需要的东西？才能让自己注意各种各样的细节，不断的完善。”      希望自己可以一直保持信念感往前走。

总结入职半年做的案子，都是在满足基本需求的IM应用基础上，对应用的体验、流程做完善，让用户使用过程更流畅，使得整体留存提升。几个案子中自己处理的还算满意，但也暴露出一些问题：对于技术不够了解，和开发的沟通不够专业；公司无法获取用户数据，对于自己的设计难以验证，设计过于主观（自己多做一些小玩意自行验证）

18年的大目标：

----希望新的一年里，能够往上走一个层次，不停留在这些需求如何落地的层面，而是学着从主创的角度思考，怎么样把产品目标转化为所谓的需求，甚至是怎么从方向中拆解出具体目标。

----希望自己能够有一个比较专注的垂直领域，有自己的深刻理解，成体系的理解，程度为丢到该领域的任意一个产品中都能快速上手。

----不丢失对产品的喜爱、敬畏和信念感。

18年具体小目标：

----产品相关书籍17年有两本未看完的抓紧看完

----其他领域的书籍看3-4本

----个人产品观粗略形成

----多和开发同学沟通，理解他们的思维以及实际开发问题

----每个月产出1篇以上竞品体验报告/观点

----PMCAFF认可数达到300