编辑导读：产品经理需要懂技术吗？这是一个永远有人在讨论，永远没有答案的问题。而作为一个从技术转做产品的人，本文作者在工作中总结了自己的一些感悟，比如技术型产品经理的定位是什么？产品经理对技术的了解程度如何划分？如何设计出一个架构合理的系统？本文对此展开分析，与你分享。
计算机专业+一年IOS前端开发转型产品，让我对技术的了解相较于一般的产品经理要多一些，平时也更多的承担技术强相关的系统方案设计工作，因此有一些我一直在不断反思，尝试给出更好答案的问题，比如：技术型产品经理的定位是什么？产品经理对技术的了解程度如何划分？如何设计出一个架构合理的系统？
本篇文章准备就这类问题尽量展开去讲，抛砖引玉。
一、技术型产品经理的定位
我对技术型产品经理的定位是：以用户需求为导向，充分利用现有技术及新技术的研究，为用户提供更高质量的产品。
这句话有两个要点，一个是充分利用现有技术，另一个是推动新技术的研究。
1. 充分利用现有技术
第一点强调的是什么呢？是扛需求、是推动业务落地的能力。所谓充分利用现有技术，核心要点是保证自己能够提出一个合理范围内的落地方案，既不畏首畏尾，让产品落了俗套，又不天马行空，完全不具备可行性。这才能叫可落地。
需求的来源有很多：竞品的新特性、领导的需求、自己的需求、合作方的需求等等，每个人站在自己的角度讲自己的想法。能落地吗，谁该做什么？这是技术型产品经理要问自己的第一个问题，他应该具有对全链路的把控能力，前端、后台、总控、意图、解析、对话，每个部分该承担什么？改动量如何？任务该如何拆解？存在什么依赖关系？
技术型产品经理需要兼具从用户和技术的角度看问题的能力。平衡技术实现与用户需求，把最初想法转化成真实可落地的实施方案，是技术型产品经理的一个重要的任务。
关于这点，我有一条约束自己的标准，这里分享出来，即：问题是否到我为止？换言之，我能否有能力成为所有问题的最后责任人？交付到我这的问题，要么我解决，要么我找人解决，我对最终交付负责。
2. 推动新技术的研究
第二点强调的是：预见性和解决未来问题的能力。作为产品经理，应当对整个业务的发展方向有正确的理解；作为技术型产品经理，应当对业务发展所需的技术有一个明确的认知。
因为我们可做、能做、还没做的事情太多了，都要做吗？显然不是。事情有个轻重缓急，作为产品经理，推动技术研究朝着未来业务最需要的地方发展就是自己的职责。
这一点要求我们根据业务的发展方向，明确什么是重要而不紧急的事，然后在条件允许的情况下，优先去处理它们。否则等到所有的事情都重要且紧急之后，那每天的工作会变成到处救火，且犯错的概率也会由于缺乏深入思考的时间而大大提高。
举个真实例子，我八月份提过一个需求，九月份上线之前，有个业务方的新需求明确依赖我提过的这个需求，而且还非常着急。如果等接到需求我再开始筹备，至少要将他们的上线时间推迟半个月。
关于这点，我同样有一条约束自己的标准，虽然自己暂时还做不到，但这里也分享出来，即：别人是否有机会向我提出问题？换句话说，就是我是否能够总是比别人先发现问题，然后推动问题在真正产生负面影响之前解决。
二、产品经理对技术的了解层级
我曾给出一个三层的划分，用于描述产品经理对技术的了解层级：
第一层：知道什么能做，什么不能做。也即知道所谓的技术边界。不论是自己提需求，还是承接别人的需求，你都能肯定的做出『支持』或『目前还不支持』的判断。
第二层：知道什么好做，什么不好做。也即，当产品需求超出了目前系统的边界时，或者说某需求当下『不能做』时，你有能力给出一个权衡了产品需求与系统改动量的初步技术方案。能做到这一层的人，可以说是一个称职的技术型产品经理了，至少有能力跟技术人员进行高效的沟通。
第三层：知道什么该做，什么不该做。也即，你知道系统中的每个模块的定位和意义，并有能力以业务需求为导向协助技术人员、甚至引导技术人员完成对系统架构的优化与改造，使其在未来能够更好的满足业务发展对于技术的要求。
第三层比较抽象，这里做一下解释。当业务场景较为简单且有限时，很容易出现一种情况，就是系统设计与业务严重耦合。实现一项业务功能的链路会很长，从头到尾涉及到很多模块，这块逻辑你做也可以，他做也可以，往往人们总是倾向于选择最符合直觉，看起来最直接的方案。但这样通常会造成模块间定位不清，逻辑分散的情况，当业务渐渐复杂起来，就不得不进行重构，否则就再难拓展。
所谓该做不该做，就是当你与技术人员合作设计方案的时候，应该从业务发展的角度看待问题，帮助技术人员明确各个模块的定位，使得我们的系统能够在尽可能长的时间保证可用性，能够随着业务的发展一同成长，而不是频繁重构。
举个形象些的例子，就像走一条路，第一层的技术型产品经理可以判断，这条路上有没有障碍，能不能走通；当走不通的时候，第二层的技术型产品经理可以了解，这些障碍物到底好不好处理；第三层的技术型产品经理会知道，这些障碍物究竟该怎样处理，才能让它们在最长的时间范围内不会成为干扰。
三、技术型产品经理的抽象能力
抽象能力是技术型产品经理最为重要的能力之一。
抽象能力能够帮助我们在分析时不至于陷入到繁杂的细节之中，能够透过现象看本质，一针见血地解决问题的核心。
我举两个例子来说明抽象能力的作用。
1. 合理的信息通路
第一个，在设计新体系时，我时常会抽象出一个概念，叫做信息。一个体系的建立需要各个模块的配合和协作，我不可能知道每个模块每行代码的逻辑，那我靠什么来判断一个方案是否可行呢？靠判断是否存在合理的信息通路。
是，我确实不知道每个模块的详细逻辑，但我知道某项任务的完成，所必须的信息是什么。
先从整个任务的角度去看，将所有的模块看做一个整体，看它的输入输出是否合理，如果一个系统未能获取到它完成任务所必须的信息，这个方案必然就是不成立的，因为信息无法无中生有。
再从每个模块的角度去看，每个模块在系统中的作用是什么？它们的输入和输出是什么？它们有没有得到完成任务所必须的信息？它们对信息做了怎样的加工？最终模块的输出是否是我们想要的？
如果这些问题都有一个明确而合理的答案，那么这个方案就是可行的。剩下的只是各个模块内部选择自己最优的实现逻辑、模块间选择最优的协作方式而已。
2. 逻辑上完备
第二个，通过抽象出问题的基本影响因素做到逻辑上完备。在做系统基础架构设计时，有一个很重要的任务就是避免遗漏场景可能性。因为在系统设计初期，所谓的业务场景都只存在与设想中，而系统又需要在未来尽可能长的时间内保持对业务的可支持性，所以如何将当前还未真正遇到的问题进行全面考虑，尽可能的做到高通用性，就成了一个必须要面对的问题。
这里我们可以尝试先想出一些基本且明显的场景，然后据其反向抽象出问题的基本影响因素，并明确每个因素所有可能的情况，然后再利用排列组合的方式去描述一个个场景，就能有效的避免遗漏。
四、好的系统具备什么样的特征
这个问题是我最近一直在思考的，很多时候，我通过直觉能够判断出两个系统设计方案的优劣，但要跟别人解释原因时，却又不知道如何表达，所以我希望能够提炼出一套系统设计需要遵循的方法论，至少用在我自己的工作中。
现在的我还没能力提出一整套完备的体系，所以这里只是从几个我有所感触的维度进行说明。
第一个特征是模块化。承担同一功能的逻辑应当聚合成一个模块，不要散落在各处，从而导致不可复用和难以维护。类似于开发过程中的封装，所有需要同样逻辑的部分都统一的调用同一个方法，而不是每次用到都重新写一遍，还难以保持一致性。
第二个特征是低耦合。承担不同功能的模块保有逻辑上的独立性，逻辑上分离的两个模块不应该存在逻辑上的相互依赖关系，每个模块应该明确定义好自己的输入和输出，并尽量保证输入和输出的通用，而不是和上下位模块深度耦合，这会导致在进行逻辑优化时牵一发而动全身。
第三个特征是通用性。系统的设计是为了解决一类问题，而不是某几个问题。系统定义好自己的输入输出特性，将不同的输入转化为对应的输出，而不是与业务逻辑耦合。不同的模块，必须明确好，哪些模块处理业务逻辑，哪些模块不处理业务逻辑，这样作为一个整体的系统才能有足够的通用性去做后续场景的拓展。
第四个特征是可拓展性。系统对业务的支持一定要做到可拓展性，或者讲，做到规模效应。随着工作量的累积，同一单位工作量所带来的效果的应当是递增的。而不是随着业务需求的增加变得臃肿不堪后在进行重构
五、系统设计中需要明确的问题
在系统设计中，至少需要明确以下问题：
- 该系统涉及到的模块有哪些？哪些模块是已有的，哪些模块是新增的？
- 每个模块的定位，或者说定义是什么？在系统中扮演什么样的角色，起到什么样的作用？旧有模块的定义是否满足我们的要求，新模块的定义是否清晰明确？
- 每个模块的输入输出是什么？每个模块所获得的输入是否刚好满足其能完成任务的需求，既不缺乏信息，也不存在会导致依赖的信息冗余？
- 模块间的上下位关系是否明确，是否与该模块的原有定位相契合？
- 系统整体的模块的调用顺序是什么？是否拥有合理的信息通路？是否保证了模块上下位关系的一致性？是否存在下位模块僭越上位模块进行/被进行跨层级调用的情况？
做个形象点的类比，设计系统就像拼拼图。
第一个问题，就是看我们手上有哪些拼图；
第二个问题，就是看拼图上的画是什么；
第三个问题就是看拼图的边缘是什么样的；
第四个问题，就是看哪些拼图的边缘是相互契合的；
第五个问题，就是拼好后，看整幅拼图是否存在不一致错误。