技术型产品经理与系统结构设计浅谈

我的 2023-07-29 05:03:43

计算机专业+一年IOS前端开发转型产品，让我对技术的了解相较于一般的产品经理要多一些，平时也更多的承担技术强相关的系统方案设计工作，因此有一些我一直在不断反思，尝试给出更好答案的问题，比如：技术型产品经理的定位是什么？产品经理对技术的了解程度如何划分？如何设计出一个架构合理的系统？

本篇文章准备就这类问题尽量展开去讲，抛砖引玉。

一、技术型产品经理的定位

我对技术型产品经理的定位是：以用户需求为导向，充分利用现有技术及新技术的研究，为用户提供更高质量的产品。

这句话有两个要点，一个是充分利用现有技术，另一个是推动新技术的研究。

1. 充分利用现有技术

第一点强调的是什么呢？是扛需求、是推动业务落地的能力。所谓充分利用现有技术，核心要点是保证自己能够提出一个合理范围内的落地方案，既不畏首畏尾，让产品落了俗套，又不天马行空，完全不具备可行性。这才能叫可落地。

需求的来源有很多：竞品的新特性、领导的需求、自己的需求、合作方的需求等等，每个人站在自己的角度讲自己的想法。能落地吗，谁该做什么？这是技术型产品经理要问自己的第一个问题，他应该具有对全链路的把控能力，前端、后台、总控、意图、解析、对话，每个部分该承担什么？改动量如何？任务该如何拆解？存在什么依赖关系？

技术型产品经理需要兼具从用户和技术的角度看问题的能力。平衡技术实现与用户需求，把最初想法转化成真实可落地的实施方案，是技术型产品经理的一个重要的任务。

关于这点，我有一条约束自己的标准，这里分享出来，即：问题是否到我为止？换言之，我能否有能力成为所有问题的最后责任人？交付到我这的问题，要么我解决，要么我找人解决，我对最终交付负责。

2. 推动新技术的研究

第二点强调的是：预见性和解决未来问题的能力。作为产品经理，应当对整个业务的发展方向有正确的理解；作为技术型产品经理，应当对业务发展所需的技术有一个明确的认知。

因为我们可做、能做、还没做的事情太多了，都要做吗？显然不是。事情有个轻重缓急，作为产品经理，推动技术研究朝着未来业务最需要的地方发展就是自己的职责。

这一点要求我们根据业务的发展方向，明确什么是重要而不紧急的事，然后在条件允许的情况下，优先去处理它们。否则等到所有的事情都重要且紧急之后，那每天的工作会变成到处救火，且犯错的概率也会由于缺乏深入思考的时间而大大提高。

举个真实例子，我八月份提过一个需求，九月份上线之前，有个业务方的新需求明确依赖我提过的这个需求，而且还非常着急。如果等接到需求我再开始筹备，至少要将他们的上线时间推迟半个月。

关于这点，我同样有一条约束自己的标准，虽然自己暂时还做不到，但这里也分享出来，即：别人是否有机会向我提出问题？换句话说，就是我是否能够总是比别人先发现问题，然后推动问题在真正产生负面影响之前解决。

二、产品经理对技术的了解层级

我曾给出一个三层的划分，用于描述产品经理对技术的了解层级：

第一层：知道什么能做，什么不能做。也即知道所谓的技术边界。不论是自己提需求，还是承接别人的需求，你都能肯定的做出『支持』或『目前还不支持』的判断。

第二层：知道什么好做，什么不好做。也即，当产品需求超出了目前系统的边界时，或者说某需求当下『不能做』时，你有能力给出一个权衡了产品需求与系统改动量的初步技术方案。能做到这一层的人，可以说是一个称职的技术型产品经理了，至少有能力跟技术人员进行高效的沟通。

第三层：知道什么该做，什么不该做。也即，你知道系统中的每个模块的定位和意义，并有能力以业务需求为导向协助技术人员、甚至引导技术人员完成对系统架构的优化与改造，使其在未来能够更好的满足业务发展对于技术的要求。

第三层比较抽象，这里做一下解释。当业务场景较为简单且有限时，很容易出现一种情况，就是系统设计与业务严重耦合。实现一项业务功能的链路会很长，从头到尾涉及到很多模块，这块逻辑你做也可以，他做也可以，往往人们总是倾向于选择最符合直觉，看起来最直接的方案。但这样通常会造成模块间定位不清，逻辑分散的情况，当业务渐渐复杂起来，就不得不进行重构，否则就再难拓展。

所谓该做不该做，就是当你与技术人员合作设计方案的时候，应该从业务发展的角度看待问题，帮助技术人员明确各个模块的定位，使得我们的系统能够在尽可能长的时间保证可用性，能够随着业务的发展一同成长，而不是频繁重构。

举个形象些的例子，就像走一条路，第一层的技术型产品经理可以判断，这条路上有没有障碍，能不能走通；当走不通的时候，第二层的技术型产品经理可以了解，这些障碍物到底好不好处理；第三层的技术型产品经理会知道，这些障碍物究竟该怎样处理，才能让它们在最长的时间范围内不会成为干扰。

三、技术型产品经理的抽象能力

抽象能力是技术型产品经理最为重要的能力之一。

抽象能力能够帮助我们在分析时不至于陷入到繁杂的细节之中，能够透过现象看本质，一针见血地解决问题的核心。

我举两个例子来说明抽象能力的作用。

1. 合理的信息通路

第一个，在设计新体系时，我时常会抽象出一个概念，叫做信息。一个体系的建立需要各个模块的配合和协作，我不可能知道每个模块每行代码的逻辑，那我靠什么来判断一个方案是否可行呢？靠判断是否存在合理的信息通路。

是，我确实不知道每个模块的详细逻辑，但我知道某项任务的完成，所必须的信息是什么。

先从整个任务的角度去看，将所有的模块看做一个整体，看它的输入输出是否合理，如果一个系统未能获取到它完成任务所必须的信息，这个方案必然就是不成立的，因为信息无法无中生有。

再从每个模块的角度去看，每个模块在系统中的作用是什么？它们的输入和输出是什么？它们有没有得到完成任务所必须的信息？它们对信息做了怎样的加工？最终模块的输出是否是我们想要的？

如果这些问题都有一个明确而合理的答案，那么这个方案就是可行的。剩下的只是各个模块内部选择自己最优的实现逻辑、模块间选择最优的协作方式而已。

2. 逻辑上完备

第二个，通过抽象出问题的基本影响因素做到逻辑上完备。在做系统基础架构设计时，有一个很重要的任务就是避免遗漏场景可能性。因为在系统设计初期，所谓的业务场景都只存在与设想中，而系统又需要在未来尽可能长的时间内保持对业务的可支持性，所以如何将当前还未真正遇到的问题进行全面考虑，尽可能的做到高通用性，就成了一个必须要面对的问题。

这里我们可以尝试先想出一些基本且明显的场景，然后据其反向抽象出问题的基本影响因素，并明确每个因素所有可能的情况，然后再利用排列组合的方式去描述一个个场景，就能有效的避免遗漏。