写在前面

这篇文章主要描述的是在做产品经理的过程中的一些经验之谈，不讲世界观，只聊方法论。
内容比较琐碎，我会尽量以举例的方式来讲述，每隔一段时间就会有更新哦。
另外，受行业限制，内容主要面向安防，其他行业的同学且看且判断是否适合自己。

不要把矛盾放到台面上激化，悄悄处理好就行了

2020-03-24
略

产品经理不需要懂很多项目管理的技巧，但一定要清楚现在进度如何

2020-03-10
前段时间一直在问领导 “在没有项目经理的时候，产品经理需要学习哪些项目管理的能力？”，得到的回答是 “只需要知道1.需求优先级、2.重要的时间节点、3.当前进度，就可以了”。在产品线周例会时被问到 “你们现在到底做到什么阶段了？” 我回答不上来，就是所谓的 “我以为我都知道”，但当前哪些功能做完了，哪些正在做，预计什么时间完成，说不出个清晰的一二三来。

归根溯源为什么会出现这种情况（并不是推脱，责任确实在我），在上一家公司时产品线以项目经理为主导，这类问题都会首先问到项目经理那里，而现在这家公司是产品经理推动开发代表的模式，所以这方面没有去了解的意识。解决问题的方式就是在日常工作中需要知道以下内容：

1. 每周例会时明确：

上周计划的需求有哪些延期了？
这周要完成哪些需求？

2. 每日例会时明确：

~~昨日的计划是否按时完成了？~~（与项目经理讨论过，该部分可以裁剪）
是否存在进度风险点？

3. 重要节点明确：

需要外部系统（或团队）参与的时间节点，如联调等
开发完成（转测）的时间点
测试准出（预计发布）的时间点

产品优势不一定非要自己死磕，借势而为也不失良策

2020-02-17
领导之前训斥我们的一句话是“公司自己的产品之间都没有相互打通”。现在回想起来，作为一个行业的产品矩阵来说，有很大一部分需求是相通的。比如我所负责的产品简称A，这个产品在与同行竞争中已经没有什么很深的亮点需求可以挖掘了，但我司的B算法在行业中领先，对应的B系统也比较有亮点，这部分的需求在A产品中也可以用得到，那么对接过来之后就可以形成我新的优势。

没有不存在缺陷的系统，就算拖着伤口也需要向前奔跑

2020-02-15
我们总要为以前犯蠢的设计付出代价，需要花费人力和时间来优化那些设计上的缺陷。话是这样说，但我陷入了一个误区：所有的缺陷都需要修改。最近发现手里的需求已经多到计划排到了下个季度，其中有一半是新功能，一半是缺陷优化。
在学习IPD的时候听到一句话：所有的行为都是为了实现商业成功而生。那么什么样的需求算是对商业成功有帮助呢？功能做的再方便、易用，也不可能成为你的卖点，亮点功能才是。坦白说由于安防行业的特性，对业务的易用性容忍度是互联网不能比拟的，哪怕系统再难用，只要领导愿意买，产品就能盈利（因为客户和用户是两拨人，决策者的人不是用户，最直接的用户也决定不了买谁的）。虽然有悖产品经理的原则，但却是事实。
那么，在当你发布一个新的版本时，销售会向客户提出：我们用起来多么多么方便么？交互如何完善？不会的，客户只关心你提供了哪些新的、领先别的厂家的功能。看到这里，产品经理手中的需求可以分为两部分：

1. 价值需求，即实现就能够帮助产品推广的价值所在。
2. 缺陷需求，即为以前犯下的蠢填的坑。

经常说需求池要排优先级，我试着将价值需求的优先级分为 +4 / +3 / +2 / +1，缺陷需求是 -3 / -2 / -1，权重越大则越优先。优先级排序是 +4 > +3 = -3 > +2 = -2 > +1 = -1

经过这样排序，应该能够很清晰的看出来需求池中哪些是当前最有必要做的。也许，拖着伤口奔跑也不是什么坏事儿，毕竟要恰饭的嘛，赚钱才是王道。

整理一份检查单，每个需求做完都应该被检查

2020-02-15
功能设计如何保证面面俱到是个老生常谈的问题，哪怕评审过两三轮的需求，在开发过程中都会发现一些遗漏的地方。冒着生命危险（指开发）发起需求变更实在不是什么好方法，能在需求阶段尽可能的考虑周全当然是最好的。
所以嘛，为了我的生命安全（确信），列了一张检查单，每逢某个需求做完时就对照着看一遍有没有遗漏。这里只写了一部分，后面再慢慢填补。

是否需要记录用户操作日志？
是否有性能需求？
如果是“图表”，点击数据项是否要跳转？
该功能是否要同步，比如web端和app端逻辑保持相同？系统配置中是否增加？首页统计项是否需要？
新版本发布，系统中需要修改的版本号及说明？

0~1岁的产品经理，最应该学什么

2020-02-15
很多人告诉我第一年要多读产品经理丛书。诚然，书是每个人提升中必然要拥抱的东西，私以为并不适合这个阶段的产品经理。入职前可以看一本《结网》或《人人都是产品经理》这类经典书了解下产品经理的职责、岗位等即可，第一年看了再多的理念和世界观也会很难用起来，不如多花些时间在如何更出色的完成工作上，在有了一定的工作经验后再看书会更有效果。
1. 要多看其他系统的交互、基础组件
在刚开始产品经理的工作时很容易设计出“反人类”的交互，这种坑非得踩过几次才知道。
举个例子，在设计新产品导航时，看到了阿里云控制台的导航是总览+侧边栏的方式，当时也没有细想就搬到了自己的产品上，实际做出来之后感觉很差，原因在于阿里云这样设计是因为两个导航是父子关系。如下图所示，总览导航中“云服务器ECS”、“云解析DNS”之类的是一级栏目，侧边栏中的“实例”等是二三四级栏目，这样设计的原因是阿里云的产品很多（一级栏目特别多），而每个产品都相当于一个子站，其中的二三四级就属于常规的功能。如果系统并非在这种情况下，照搬导航栏的交互是非常不妥的。
日常在用的系统、自己公司或竞品的产品（尽量找同类型的产品），看交互和页面布局，重点关注细节上的东西，比如导航栏是怎么样的交互方式？列表的筛选条件是如何交互的？
看完之后可以总结出来几种基础的设计模式，考虑为什么要这么设计？背后的潜在逻辑是什么？

2. 要多了解自己负责的产品
做G端的产品第一年大都是在跟进项目，负责定制化的需求，或是为产品的某一个独立模块做设计。在不熟悉的情况下风险有很多，比如：在设计时使用与原产品中惯用的相悖的交互、某个功能点可以归到原有的页面中去，因为不熟悉产品而重新另起了个页面，功能散乱、对现有数据结构或引擎逻辑不清楚，设计的功能不切实际......
在这里我所说的“了解”，不仅仅是在页面上点点点的那种。我入职的第一个月，对着产品的页面反反复复看，也梳理了功能矩阵，但后来真正接手了这个产品时才发现远远不够。接手产品后第一个阶段的工作就是重组目录结构，在仅凭第一印象、不了解页面间的逻辑关系时做出的决定，事后证明是错误的（比如我曾以为功能A和功能B属于一类，可以归到一个模块下，后来发现大错特错又将其恢复回原样）。
这个“了解”的过程并不是自己独立能够完成的，需要找到原产品经理、研发经理，甚至是开发和测试去，经过不断的问，一点点的构筑成这个产品自顶向下的视角（也就是从整个产品的视角）。
需要了解哪些方面？

• 整个产品的定位，包括面向的用户、核心需求、发展方向；
• 指导政策背景（安防行业尤其重要）、市场分布、销售情况
• 功能结构，包括模块自身的定位、模块间的联系、每个页面属于什么类型的（列表、档案、展示还是配置管理）
• 简单的实现逻辑，包括数据流向、基本的数据结构（当前功能的数据在哪张表里，有哪些字段）
• 如何实现的（实时查询还是离线计算，是否依赖第三方系统等）.....

其实远远不止这些。在熟悉这些之后，在设计时确实能够减少无法实现/设计缺陷的问题，减少返工的可能性。

3. 要多了解所在的行业 / 业务系统
对产品经理来说，对行业的认知深度是很重要的。就像很多人所说，产品经理的终极是行业专家。
对于安防行业来说，近5年来的政策、各部门的关系、负责职能等都是非常重要的。
除了行业知识外，提升最快的就是了解同行业其他业务系统的需求、定位。这一点上很羡慕做互联网的同学，能体验到竞品的系统，也有很多书籍可以参考。安防圈相对封闭的环境，最直接的方法就是和用户面对面沟通，但是机会难求。在这种情况下就需要先从自家公司的产品下手，一般都会有N多个产品，去了解其核心定位、面向的用户、与其他产品间的关系，是快速成长的捷径。
很幸运遇到了云从的“老师”文化，每隔一段时间公司就会组织各产品线全国线上培训，交流经验心得、产品相关知识等等。好的公司，就是让你能在需要的时候提供足够的学习资源给你，最近因为疫情在家里呆着，把公司内部网课看了很多，受益颇深。

我失去了作为产品经理最重要的专注力

2020-02-15
本来这一段的内容叫《成为产品经理一年，我失去了最重要的专注力》，可仔细想想，并不是因为做的产品经理才失去的专注力，而只是因为我自身的原因。
产品经理的工作状态经常需要作为粘合剂将各个部门的沟通工作串起来，多线操作是常事儿。但最近越来越发现，本来应该专注的工作（比如设计、思考、学习）都会不自觉的看微信，分心起来。
在这种情况下就需要刻意的锻炼自己的专注力，目前想到的方法就是提醒自己把目前手头的事情做完，再开始下一项工作，让节奏慢下来。另外就是在学习时开启番茄钟，把无关的应用屏蔽掉。目测要用1~2个月的时间来锻炼，且看后面的结果吧~

如果让你重来一次，你会怎么做

2019-12-16
入职新的公司后，负责的产品与之前有一些重合。离职休假这段时间里，真正有时间和精力去思考自己负责的产品要做什么。在这个过程中发现以前有些需求，并不是那么重要，去除糟粕的过程是非常重要的。
如果给你的产品重生一次的机会，请珍惜并抓紧。