文/某鸟
起笔之前，我算了算距离写上一篇文章的时间，大概已有半年左右。且这两年写的东西都是写随想云云，真正算上输出的，可能要追溯到两年之前。伴随着职业生涯的高歌猛进，单单是为了让一篇文章言之有物，叙之有理，就已经足以让我难产了。
所以能在一篇文章中只描述自己的理解，而不深究其因果渊源，美其名曰『总结』，大抵是年终馈赠给我最好的借口了。
转岗产品经理
如果回看这一整年，转岗一定是绕不过去的坎。如果把画第一张原型稿的时间看作正式转岗的话，到今天为止，正好整整七个月。
记得去年向一个著名产品经理发求职信时，还只是怯懦的表述自己『有产品野心』。在那个阶段，大概就已经把产品经理岗位标注为自己未来职业发展的一环，但更多的是想占个便宜，希望能『无产品经理之职，学产品经理之实』。究其原因，是因为每次对产品经理工作岗位的职责做推演，都觉得其艰辛复杂且枯燥。
而今年决定转岗，则是判断当时的时间节点，可能是自己在目所能及的未来里最容易转岗的机会。庆幸自己身处创业公司，具体情节不再赘述。
我不知道自己算不算入了门
虽然对转岗一事早有预谋，但直到现在，我都无法确切地描述出产品经理的定义。大部分的转岗原因，反而是因为对研发工作的担心。
担心的东西并不是职业发展，而是视野受限。人的时间和精力总是有限的，在研发工作的大环境里，技术本身占有了很高的优先级，你就会觉得相对来说，其它的事并没有那么重要。而这其实是一种被动的傲慢，它既体现在你分配闲暇时间的比重上，也体现在你获取和理解信息的选择上。
但其实，技术从来不是全部。
想起 DOTA 中的一个梗：『想要最快地熟悉 DOTA 中所有英雄的技能，只需要选择「影魔」走中就可以了』。影魔本身是个很特别的英雄，如果操作得当，可以在游戏的中前期为队伍赢来极大的优势。但同样由于该英雄名声在外，但没有任何逃生能力，所以在大部分情况下，会被当做重点针对对象。
当下里选择产品经理作为新岗位，可能和依靠选择『影魔』作为熟悉其它英雄技能的方式有着异曲同工之妙。如果当下里自己最想补齐的短板是视野，那么产品经理这个岗位可能是最佳选择。
说到视野，我们来聊聊维度吧
维度这个词可能意义太多，保险起见，我们先加个定义，这里的维度是指某个特定的抽象层级。
之所以提到这个词，是因为接下来想总结自己对这几年工作的一些心得，以拆分维度来进行分析是一个挺不错的方式。
一般来说，当你选定一个维度的时候，就是选定了一类抽象的对象。通过对这个对象的不断定义，你会得到很多该对象的特征，作为在当前维度解决问题的大前提。而接下来针对当前维度的所有决策，都是基于某个特征下的逻辑推演。不同的前置特征会呈现出多种关系，在互斥的时候，决策就会出现冲突，需要最优解；在有依赖的时候，决策就会出现时序；诸如此类。
抽象层级的产生是人在进行逻辑思考中的必然产物。你不会把苹果和水果放在同一个层级比较，不会去讨论水和火的哪个更重，也不会去讨论橙子和维生素 C 哪个更有营养价值，如果你真的讨论了，相信我，你想到的维生素 C 是『维 C 片』。
好了，对维度或者说抽象层级的解释到此为止吧。其实我知道用一堆臆想的概念来解释另一堆概念是不负责任的，但将所有的概念溯源到某本经典书目上，且我可能还没读过，在一篇总结里，我决定偷这个懒。
通过对一个维度进行理解，我们可以得到以下的收获：
理清维度的内在逻辑链：逻辑链本身可以为我们带来决策参考，比如前置条件会变为后续结论的局限。举个例子吧，储存形式受制于硬件。如果一份数据储存在无法进行数据修改的光盘上，就无法进行删除和修改的操作。如果想实现删除和修改，就必须换一种储存介质。
理清不同特征之间的关系：抽象对象的特征往往并非臆想，而是可以溯源到现实时间的固化现象。而这些特征在不经过特别设计的情况下，往往互有关联。关联的形式上文有聊过一些，不再赘述。实际上，针对某个维度的工作行为，实质上就是在利用这些固有特征解决问题。所以这些特征的关系往往会决定你实际的工作性质。如果特征是相互冲突的，那工作核心就是在调和冲突，如果特征具有复杂的依赖关系，那工作核心就是调和依赖关系。
理清不同维度之间的关系：相同的特征，在不同的聚合方式下，可以填充不同的维度。而这些特征，就是不同维度间的基本联系。举个例子，你想买电脑，这个时候我们要挑选硬件，显卡可以被当做一个固化特征。在性能维度中，你期望尽可能的好，在外形维度中，你期望尽可能的小，而显卡的性能和尺寸普遍是成正比的。简单来说，对显卡的决策需要同时考虑到两个维度，求最优解。
上述例子其实也可以解释为电脑的不同特征影响了决策，这就从维度关系简化为了特征关系。因为维度是人为选择的分析工具，所以如何去选择维度本身并没有对错，可以用来分析问题就可以了。
比较复杂的维度关系一般是不同维度内在逻辑链的依赖性，比如缓存体系设计中，数据的读取应当尽可能从缓存数据而非实际储存数据，其逻辑基点是读取性能的平衡。但这为写入数据带来了负担，因为写入一次变为了写入两次，只要写入操作出现时间差，就会出现读取数据的不一致。在两条逻辑线中，核心冲突是数据一致性与性能平衡的冲突，简单来说，想节省主储存器的性能就要引入次储存器，而引入次储存器就会带来数据不一致，反而引起数据读取准确性出问题。
这个例子就是典型的不同维度的逻辑线互有依赖而导致的冲突，且无法被单纯的解读为特征依赖，因为特征本身是孤立的。
对于认真阅读的朋友，我能理解到你的困惑和质疑，所以我额外解释两点：
维度是人为选择用于分析和解决问题的工具，维度的逻辑基点是现实世界中的固化特征。固化特征本身只是信息，但特征间会产生逻辑关系，而逻辑关系可以被推演，从而形成逻辑线。当你找到一条可以用于分析当前问题的逻辑线时，就找到了一个稳定的抽象层级。之所以将它称为维度，是因为它很类似于多维体系中的建模方式，孤立的点是无法确定一个平面的，但当它和其它的孤立点建立连线之后，线条就可以用来确定平面，乃至更高维度的确定范围。
用维度作为分析问题的工具，其核心并不是拿到一个固定的维度模型来套用推演，而是根据实际特征，构建出一个符合当前情况的合理维度，而逻辑推演本身是在验证当前逻辑线的可行性，所以不需要质疑我举的例子中维度是否合理。
最后，无端地补一句话，实际上，写代码就是在表述逻辑。
我在产品经理工作中找到的维度
虽然产品经理和研发人员之间的矛盾是一个让人津津乐道的话题，但在我来回走了一遭之后，能感觉到，其实产品经理和研发人员的工作在某些程度上具有很高的相似性，或者说，其实产品经理与研发人员的部分维度是共享的。
我试着总结了一些研发人员的经典维度。
数据维度
数据维度的核心抽象对象就是数据。这个维度下的主要前提有两个：
- 现实世界中的信息只能以数据形式储存在计算机世界中。
- 已储存的数据以两种形式来表示信息：数据本身，数据间的关系。
以储存作为前提，可以推演出的是对数据的操作方式。
- 比如对已储存数据的查看、删除、修改。
- 比如产生新数据的添加、复制、运算。
以承载信息作为前提，可以推演出的则是对数据的应用方式。
- 比如最底层的储存形式只是二进制数据，如果想让二进制数据描述某类确切信息，需要一个翻译机制，所以会有编码/解码器存在，从基本数据类型，到文本、图片、视频，都是如此。
- 如果想模拟现实中对一组特征加以聚合，来描述一个抽象对象，就会需要格式化的数据，由一个高层级的数据结构来聚合低层级的数据结构。
- 如果希望描述不同抽象对象之间的联系，就需要利用两个抽象对象之间的关联特征，来描述关系化的数据。
系统维度
系统维度的核心抽象对象是模块。基于模块化系统设计，核心前提有两个：
- 复杂的系统，可以被切分为小而独立的功能模块。
- 模块与模块间的通信方式构成了完整的系统。
其实系统设计是个浩瀚的大工程，类内函数/类/程序框架层级/独立服务都可以视作独立模块。在这个维度下，核心复杂度实际上是设计模块间通信方式。举个不太被察觉的例子，我们如何体现系统结构的层级呢？其实是依靠设计好的通信方向与跨层级禁止通信规则。
工程维度
工程维度下的逻辑基点是将程序视作一个可持续化生产的工程，它的抽象对象并不是固化的事务，而是生产方式。一般来说，工程维度实际上是程序设计维度的一个补充，但其重要性与复杂度，已经足以单独列出进行考虑了。
工程维度的核心目标是保证程序本身具备高效的可维护能力。这是一个典型的目标倒推型维度，它的特征是基于假定目标衍生出来，而非程序出现之初就已经固化的特征。诸如可监控、易调试、容错策略、易回溯、可量产等等的衍生目标，会倒推出在程序设计之初，就需要额外考量的问题。
资源维度
资源维度其实也是系统设计中的一个补充维度。最常见的资源就是储存空间与运行时间，除此之外，硬件性能、网络带宽、电池电量，也是程序设计中的典型资源。之所以单独拎出来一个维度，是因为不同资源间往往呈现出竞争关系。比如导航程序在长期调用 GPS 定位硬件的时候，会加剧电量消耗，那么就需要就这两者之间做平衡。
之所以将其定义为一个补充维度，是因为资源问题只有在触顶临界值时，才会出现需要解决的问题。比如同样是 GPS 调用，一个外卖程序只需要在每次下单时确认你当前的位置，那么就不用在这里考虑电量问题，因为对电量资源的消耗可以忽略不计。
需求维度
虽然这里把产品需求也作为一个维度，但实际工作而言，产品需求本身就是一个决策结论，换句话说，它恰恰是在程序在解决问题过程中的主要逻辑基点之一。
所以在研发角度来聊需求维度，其实是在聊需求维度与其它研发维度的关系。由于需求会作为其它任何一个研发维度解决问题的前提之一，所以在这个维度的核心复杂度就是合理的设计需求与程序设计之间的关系。
所以很遗憾，如果我们把需求与程序设计之间的关系定义为抽象对象，这也是一个典型的目标倒推型维度。它的典型特征和工程化类似，是要自行推演基于需求的衍生特征，然后与其它逻辑线适配。
而这，通常也是产品经理与研发同事之间典型冲突的根源。
(至于产品经理拍脑门说这个功能明天要上线这种，研发柜子里还是放把刀比较方便...)
之所以先聊常见的研发工作维度，是因为实际上，这其中很大一部分也是产品工作的常见维度。不过产品工作与研发工作的工作侧重点稍有不同，产品工作更多的是做决策，而研发工作更多的是做实现。所以研发工作的维度是不断下移的，当程序复杂度上升，分析问题的维度就需要下沉，来解决更细致的问题。而产品工作的维度是上移的，当各个维度的复杂度提升，且无法进行决策的时候，就需要可以将各个维度视作典型特征，由此构成一个上升维度，用于做决策。
举个简单的例子，当产品经理给定某个需求的时候，研发需要将需求细化，下沉到各个维度来评估复杂度，然后反馈复杂度。而产品会把需求和实现复杂度同时作为决策依据，由此来决定是否进行实现。
不过也正是这个原因，维度概念对于产品经理来说，要比研发来得更为重要。因为在研发大环境中，是存在经典维度的。同时由于大量的人基于相同的维度来解决问题，所以会逐渐的产生一大批更为具体的问题与解决方案。
当然，以上只是针对应用层的研发工作。目前已知的抽象复杂度最高的研发工作是『编程语言设计』，无论是语言背后的数学与逻辑原理，还是解释器自举...总之，很复杂...
而对于产品经理(尤其是我这个新手产品经理)来说，想总结出一个经典维度并非易事。一方面，是因为出于决策目的，分析问题的维度从来是不嫌多的。
另一方面，则是因为在不同的场景下，不同维度的优先级并不相同，所以综合各个维度产生的顶层决策模型也不得不随之改变。
我之前有假设过一个思路，如果能够把需求类型化，是不是也就可以将不同类型需求的对应维度固化。但随后这个观点被自己证伪了，因为存在不同的公司阶段、人力情况、业务情况、用户情况，在特定时间下的需求是具有唯一性的。如果强行类型化，一方面类型化需求的参数化特征多到令人发指；另一方面，在已知特定阶段的情况下，还将影响类型化需求的特征全部复盘一遍，反而会降低产出。
接下来，我试着总结一些我目前总结到的产品经理常见维度吧。以下维度仅供自用，嗯 = =
研发维度
一般来说，研发维度是产品经理的底层维度，它的主要决策点是实现的可行性与复杂度，除此之外，在特定场景下，还需要考虑维护复杂度以及前向兼容/后向拓展的复杂度。
可行性的核心考量依据是数据和产品逻辑，其中尤其以数据为重。而数据之中，又以数据关系为重中之重。究其原因，是因为如果数据关系与产品逻辑如果无法做到高度契合，产品就会反向受制。比如今天在用一个软件时，我在没设置生日的情况下，它提醒我今天生日。我猜测，这是因为它将1月1日作为了生日的初始值。如果我现在作为产品想引导用户填写生日，就很难。因为我不知道这里的1月1日究竟是真实的用户生日，还是默认值。
由于之前有三年的研发经验，在这个维度上进行决策，对自己来说，确实是一件相对容易的事情，但后续的维度，就不再那么容易了。
业务维度
我在这里对业务维度定义，是指以程序与各个操作角色之间正常流转作为目标的目标倒推型维度。如果只是程序与用户之间的关系，那至少角色少，还不算复杂。但当运营同事、客服同事开始参与起来，复杂度也就变高了。尤其不同角色的操作开始出现时序与固化流程的时候，嗯，考验的时候就来了。当然，还远不止此，记得研发维度中的工程维度么？实际上，成型化的软件工程本身还需要运维同事、测试同事与研发同事的介入。简单来说，业务维度的复杂度实际上就是参与角色之间关系的复杂度。
用户维度
产品经理是直面用户的，毋庸置疑。但真正可以影响产品决策的，就很值得商榷了。迄今为止，我还没有总结出自己觉得完全合理的逻辑线，只是从工作经验慢慢区分出有些前提是可以证伪的。比如『用户想要什么』，这个问题用户其实回答不了，而产品经理也无法据此来得出直接结论。不同的用户想要的东西可以不同，而用户也未必真的知道自己想要什么。产品和用户的关系，并不是在用户维度来思考的，真正可以在用户维度思考的问题，只是交互和体验。也就是当我们已经决定了要如何服务于用户时，怎样降低使用门槛，简化使用方式，诸如此类。
商业维度
产品与用户的关系，其实是应该在商业维度决策的事情。都说『用户是上帝』，『用户要什么我们就给什么』，怎么想也觉得只有上帝才能做到要什么都给吧，矛盾的不行。
从商业维度来看待的产品与用户关系，实质上就是供求与交易，所以产品需要同时满足公司利益与用户诉求。从来不存在产品层面上的伟大，伟大是属于公司的，产品只是基于公司战略下的产物而已。
可能是在互联网行业里被洗脑的太久，其实是浅显的道理，我却花了很久才想通。
为什么商业维度对我如此重要。我举个例子，用户想要钱，产品可以给他钱么？如果损害公司利益，不可以。但如果以此作为交换，换取更大的利益，可以，比如补贴换取用户粘性。再比如，我们公司卖好吃的，所有人都想买，但我们就俩厨师。所以核心问题就变成了解决产能问题，和在产能不足的情况下，如何保持用户关注度的问题。
所以，在我目前的认知里，产品的顶层维度，应该是构建合理的商业模型。对于当下里的我来说，这也就是天花板了。
再聊几句产品经理
在干工作时不能瞎聊梦想，但梦想还是有的。
在技术不断发展的未来，一定会需要这样一类人。他们一边关注着不断涌现的科技成果，一边关注着当下社会中人们的诉求与困惑，然后将那些科技成果诠释为可以满足人们生活所需的产品，供人们改变生活。这些人未必是产品经理，不过，我有一点点想做这样的人。
『站在科技和人文的交叉路口』，我大概是这么理解的。
草草的写在最后
写到现在，时间已经是 2018-01-01 23:51:43，我没想到，这篇从昨晚开始写起的总结，一写，就是一天。
而到现在为止，也只是对这几年的工作感悟，稍稍有个交待。但不敢再开话题了，明天还要上班。
其实我知道整篇行文仓促，文中细节也大多经不起推敲。虽然美其名曰『总结』，但实际上，只不过是把自己未经验证的想法画了个圈。
不过如果要问我这几年工作最大的收获是什么，那确实就是上面聊的这些东西。
究竟什么是解决问题的能力？不是写代码，也不是画原型，而是如何在实际情况中，合理分析，得出结论，做出决策。
而如何提高解决问题的能力？一方面，是要拓宽自己的视野，能够对更多的事实有所认知，从而优化决策。而另一方面，则是要总结出好的方法和工具，提高自己分析和解决问题的效率。
对于事实有所认知，仅仅知道定义是不够的。必须要走进去，知道它的成因，它的发展脉络，它所遵循的逻辑。当你服务一个人吃饭的时候，你只知道他会吃饭是不够的，你要知道他什么时候饿，饿了想吃什么，不饿的时候会不会也想吃什么，更要知道这一切都是为什么。
记得在一部电视剧里看到过一句话：『现象并不代表真相，逻辑才是。可人们往往看到了现象，就觉得看到了全部』。
最后的最后
貌似还没对 2018 做展望，对于一篇年终总结来说，不写展望感觉就像拉完屎不提裤子一样，总觉得少了点什么。
我本来想在结尾说，我想找一个看完这篇文章会对我产生兴趣的异性进行求偶活动。但写完之后，我觉得如果我真说了，如果不是我傻逼，那就是我和求偶对象都是傻逼 = =...不过，能看到这的应该都是真爱。是不是异性？再说吧。
聊点正经的，前几天看《十三邀》中访问林志玲的一期，其中有几句话颇为认同，原句忘了，我翻译下：
一定要保护好自己的感受力和好奇心
庆幸 2017 买了个相机，当你有了相机之后，你就会开始观察和思考，什么景色是美好，什么值得记录。借由此，你也真的会感受到美带来的愉悦。
遗憾 2017 没有什么额外的出行计划，打算在 2018 补齐。我对风景不是很感冒，照完了照片总觉得像壁纸一样。更喜欢在陌生的城市里走街串巷，看人们认真生活的模样，看时间掠过之后，留下的痕迹和遗忘。
转了产品经理之后，我借着慢慢学会的多维思考，第一次质疑了一个前提，人生的追求可能并不唯一，幸福也可能不是唯一诉求。
想到这点，起源于我为自己买了一本日历。每一天都要撕一页的操作，让我第一次如此切实地感受到时间是个消耗品。对比之下，无论是多么先进的科技，多么好的屏幕，都无法对时间的流逝做出如此真实的隐喻。那么，如果只追逐效率的我们，是不是错过了什么？
至少现在，与幸福无关，我不想错过这种感受。所以我决定，今年的每天早起，我要撕一次日历。为流逝的时间们，献上一份祭品。
其它还有什么呢？祈祷涨工资，自我催眠学习进步，立个坚持不了几天的戒烟或是早睡的 Flag？自己控制不了的事情，就不留在 2018 年底笑话自己了。
不过整个 2017 年，自己对游戏贡献了太多时间，打了两个赛季的暗黑，没完没了的炉石日常，是该放放了。打算找个代练，保证每个月能拿到炉石的新卡背，然后就删游戏了。
我还是那个我，认命，但不信命。
对自己从不抱太大期待，但想做更好的自己。
姻缘靠天注定，性生活暂时靠自己。
做工作时要多逼自己，来了什么心情也不用压抑。
附上一首批命诗：
天空未留痕迹，鸟儿却已飞过。 —— 泰戈尔
晚安吧 (*^__^*)
某鸟 夜书于 2018年01月02日
