技术型产品经理与系统设计

技术型产品经理与系统设计

熟悉我的人会知道,我对技术的了解相较于一般的产品经理要多一些,平时也更多的承担技术强相关的系统设计工作,因此有一些我一直在不断反思,尝试给出更好答案的问题,比如:技术型产品经理的定位是什么?产品经理对技术的了解程度如何划分?如何设计出一个架构合理的系统?

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

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

八个月前,我在文章《趋势三段论》中提过这样的观点,技术型产品经理的定位是:以用户需求为导向,充分利用现有技术及推动新技术的研究,为用户提供更高质量的产品。

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

1、充分利用现有技术

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

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

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

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

2、推动新技术的研究

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

1、合理的信息通路

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

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

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

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

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

2、逻辑上完备

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

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

举个例子,通过头脑风暴,我想到了系统需要解决的12种场景,但是否完备了?我不清楚。但是我通过反向抽象,发现影响场景的基本因素有3个,它们的可能性个数分别为2、3、3,那么通过排列组合,我就知道,完备的场景数应当是18种,也就意味着我需要继续验证我当前的设计是否支持剩余的6种情况。当然有的情况在实际业务场景中是不可能存在的,不过做最初设计时多考虑一分,未来落地时就会少一分风险。

四、好的系统具备什么样的特征

这个问题是我最近一直在思考的,很多时候,我通过直觉能够判断出两个系统设计方案的优劣,但要跟别人解释原因时,却又不知道如何表达,所以我希望能够提炼出一套系统设计需要遵循的方法论,至少用在我自己的工作中。

现在的我还没能力提出一整套完备的体系,所以这里只是从几个我有所感触的维度进行说明。

第一个特征是模块化。承担同一功能的逻辑应当聚合成一个模块,不要散落在各处,从而导致不可复用和难以维护。类似于开发过程中的函数封装,所有需要同样逻辑的部分都统一的调用同一个函数,而不是每次用到都重新写一遍,还难以保持一致性。

第二个特征是低耦合。承担不同功能的模块保有逻辑上的独立性,逻辑上分离的两个模块不应该存在逻辑上的相互依赖关系,每个模块应该明确定义好自己的输入和输出,并尽量保证输入和输出的通用,而不是和上下位模块深度耦合,这会导致在进行逻辑优化时牵一发而动全身。

第三个特征是通用性。系统的设计是为了解决一类问题,而不是某几个问题。系统定义好自己的输入输出特性,将不同的输入转化为对应的输出,而不是与业务逻辑耦合。不同的模块,必须明确好,哪些模块处理业务逻辑,哪些模块不处理业务逻辑,这样作为一个整体的系统才能有足够的通用性去做后续场景的拓展。

第四个特征是边际成本递减。系统对业务的支持一定要做到边际成本递减,或者讲,做到规模效应。随着工作量的累积,同一单位工作量所带来的效果的应当是递增的。借用云栖大会中阿里iDST工程师的说法,每个技术人员所能支持的业务方数量应当是递增的,而不是说5个业务方需要1个技术人员,那10个业务方就需要2个,100个业务方就需要20个,这显然是不合理的。

五、系统设计中需要明确的问题

在系统设计中,至少需要明确以下问题:

  1. 该系统涉及到的模块有哪些?哪些模块是已有的,哪些模块是新增的?

  2. 每个模块的定位,或者说定义是什么?在系统中扮演什么样的角色,起到什么样的作用?旧有模块的定义是否满足我们的要求,新模块的定义是否清晰明确?

  3. 每个模块的输入输出是什么?每个模块所获得的输入是否刚好满足其能完成任务的需求,既不缺乏信息,也不存在会导致依赖的信息冗余?

  4. 模块间的上下位关系是否明确,是否与该模块的原有定位相契合?

  5. 系统整体的模块的调用顺序是什么?是否拥有合理的信息通路?是否保证了模块上下位关系的一致性?是否存在下位模块僭越上位模块进行/被进行跨层级调用的情况?

做个形象点的类比,设计系统就像拼拼图。第一个问题,就是看我们手上有哪些拼图;第二个问题,就是看拼图上的画是什么;第三个问题就是看拼图的边缘是什么样的;第四个问题,就是看哪些拼图的边缘是相互契合的;第五个问题,就是拼好后,看整幅拼图是否存在不一致错误。

结语

写完之后,回顾整篇文章,我发现我讲了三层事情:

  • 第一层:抽象能力、产品理解、技术知识

  • 第二层:工作定位

  • 第三层:实践方法

抽象能力是技术型产品经理的重要能力,是进行顶层设计的基础。同时,技术型产品经理要兼具对产品的理解和技术的了解。这些构成了一个技术型产品经理的能力体系。

技术型产品经理要明确自己的工作定位,兼顾当下与未来,既要有能力推动当下业务落地,又要有足够的预见性去解决未来的问题。

技术型产品经理时常要与技术人员合作进行系统/平台的设计,保证系统及其各个模块拥有明确的目的(定位)、合理的链接(信息通路)、必备的要素(模块),是设计一个完备系统的基本要求。

技术型产品经理与系统设计

熟悉我的人会知道,我对技术的了解相较于一般的产品经理要多一些,平时也更多的承担技术强相关的系统设计工作,因此有一些我一直在不断反思,尝试给出更好答案的问题,比如:技术型产品经理的定位是什么?产品经理对技术的了解程度如何划分?如何设计出一个架构合理的系统?

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

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

八个月前,我在文章《趋势三段论》中提过这样的观点,技术型产品经理的定位是:以用户需求为导向,充分利用现有技术及推动新技术的研究,为用户提供更高质量的产品。

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

1、充分利用现有技术

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

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

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

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

2、推动新技术的研究

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

1、合理的信息通路

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

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

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

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

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

2、逻辑上完备

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

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

举个例子,通过头脑风暴,我想到了系统需要解决的12种场景,但是否完备了?我不清楚。但是我通过反向抽象,发现影响场景的基本因素有3个,它们的可能性个数分别为2、3、3,那么通过排列组合,我就知道,完备的场景数应当是18种,也就意味着我需要继续验证我当前的设计是否支持剩余的6种情况。当然有的情况在实际业务场景中是不可能存在的,不过做最初设计时多考虑一分,未来落地时就会少一分风险。

四、好的系统具备什么样的特征

这个问题是我最近一直在思考的,很多时候,我通过直觉能够判断出两个系统设计方案的优劣,但要跟别人解释原因时,却又不知道如何表达,所以我希望能够提炼出一套系统设计需要遵循的方法论,至少用在我自己的工作中。

现在的我还没能力提出一整套完备的体系,所以这里只是从几个我有所感触的维度进行说明。

第一个特征是模块化。承担同一功能的逻辑应当聚合成一个模块,不要散落在各处,从而导致不可复用和难以维护。类似于开发过程中的函数封装,所有需要同样逻辑的部分都统一的调用同一个函数,而不是每次用到都重新写一遍,还难以保持一致性。

第二个特征是低耦合。承担不同功能的模块保有逻辑上的独立性,逻辑上分离的两个模块不应该存在逻辑上的相互依赖关系,每个模块应该明确定义好自己的输入和输出,并尽量保证输入和输出的通用,而不是和上下位模块深度耦合,这会导致在进行逻辑优化时牵一发而动全身。

第三个特征是通用性。系统的设计是为了解决一类问题,而不是某几个问题。系统定义好自己的输入输出特性,将不同的输入转化为对应的输出,而不是与业务逻辑耦合。不同的模块,必须明确好,哪些模块处理业务逻辑,哪些模块不处理业务逻辑,这样作为一个整体的系统才能有足够的通用性去做后续场景的拓展。

第四个特征是边际成本递减。系统对业务的支持一定要做到边际成本递减,或者讲,做到规模效应。随着工作量的累积,同一单位工作量所带来的效果的应当是递增的。借用云栖大会中阿里iDST工程师的说法,每个技术人员所能支持的业务方数量应当是递增的,而不是说5个业务方需要1个技术人员,那10个业务方就需要2个,100个业务方就需要20个,这显然是不合理的。

五、系统设计中需要明确的问题

在系统设计中,至少需要明确以下问题:

  1. 该系统涉及到的模块有哪些?哪些模块是已有的,哪些模块是新增的?

  2. 每个模块的定位,或者说定义是什么?在系统中扮演什么样的角色,起到什么样的作用?旧有模块的定义是否满足我们的要求,新模块的定义是否清晰明确?

  3. 每个模块的输入输出是什么?每个模块所获得的输入是否刚好满足其能完成任务的需求,既不缺乏信息,也不存在会导致依赖的信息冗余?

  4. 模块间的上下位关系是否明确,是否与该模块的原有定位相契合?

  5. 系统整体的模块的调用顺序是什么?是否拥有合理的信息通路?是否保证了模块上下位关系的一致性?是否存在下位模块僭越上位模块进行/被进行跨层级调用的情况?

做个形象点的类比,设计系统就像拼拼图。第一个问题,就是看我们手上有哪些拼图;第二个问题,就是看拼图上的画是什么;第三个问题就是看拼图的边缘是什么样的;第四个问题,就是看哪些拼图的边缘是相互契合的;第五个问题,就是拼好后,看整幅拼图是否存在不一致错误。

结语

写完之后,回顾整篇文章,我发现我讲了三层事情:

  • 第一层:抽象能力、产品理解、技术知识

  • 第二层:工作定位

  • 第三层:实践方法

抽象能力是技术型产品经理的重要能力,是进行顶层设计的基础。同时,技术型产品经理要兼具对产品的理解和技术的了解。这些构成了一个技术型产品经理的能力体系。

技术型产品经理要明确自己的工作定位,兼顾当下与未来,既要有能力推动当下业务落地,又要有足够的预见性去解决未来的问题。

技术型产品经理时常要与技术人员合作进行系统/平台的设计,保证系统及其各个模块拥有明确的目的(定位)、合理的链接(信息通路)、必备的要素(模块),是设计一个完备系统的基本要求。



欢迎投稿 职场/创业方向. 邮箱wangfzcom(AT)163.com. 王夫子部分资料来自互联网和网友上传,版权属原作者.:王夫子社区 » 技术型产品经理与系统设计

    标签:

点评 0