抽象的面试问题「项目工程师面试题」
今天给大家普及一下抽象的面试问题「项目工程师面试题」相关知识,最近很多在问抽象的面试问题「项目工程师面试题」,希望能帮助到您。
编辑导语:作为产品经理,你是如何抽象功能设计的?B端场景与C端场景下的抽象产品功能设计,又有哪些不一样的思路?假如这类问题出现在面试场景中,你该如何拆解和应答?本篇文章里,作者就该问题进行了解答,一起来看看吧。
面试官发问:请你以一个项目为例,谈谈你是如何抽象功能设计的?这是面试中非常常见的场景,面试初中高级的产品岗大概率会遇到的问题。
以前看过一个很牛的自媒体的主理人说,我每天坚持输出一篇高质量内容,还要做社群运营,大家觉得我好像无所不知,相关的问题都能信手拈来。其实并没有什么高深的技巧,我只是提前把可能遇到的问题思考过了,剩下的都是开卷考试。面试也是如此,不打无准备之仗。
接下来文章从3个方面和大家聊一聊这个问题可以怎么答,并在文章末位附有实操案例。这是我个人的答题思路,欢迎拍砖交流(本文立足于B端产品的面试场景)。
一、面试官考察的重点是什么?大家要认识到一点,在面试现场提出的任何问题,都是有考察成分的。哪怕你们聊得很愉快,聊起了生活与家庭,氛围很融洽,实际上你说的话都会有意无意被面试官放到审视的位置。
所以提前对面试官的问题做好分类思考,在面试过程中保持思路清晰,是一种有效的策略。
比如此问题,我认为面试官主要考察几个方面:
1. 考察抽象思维能力B 端和 C 端在产品设计上,有一些差异点。C 端要求洞悉用户心智,了解用户画像,用户群体相对单一,决策人即为使用人。
而B端的需求提出人和最终使用者很可能不是同一个人,B 端产品在日常工作中更多的是整合各类岗位的诉求、抽象业务场景做标准化的设计,需求的复杂度高于 C 端的单一场景。因此面试官很看重 B 端产品的抽象设计能力。
但是抽象的东西不好表达,所以要从项目立足阐述抽象的思路和结果。个人认为B端的抽象设计能力与 C 端的创新想象力有异曲同工之妙。
2. 考察项目复盘能力对比项目实践,项目复盘带来的成长更是倍数级的。经常做复盘的人应该有这种感受,某个时刻,脑袋豁然开朗,很多业务场景和诉求都串联起来了,一下子都明白了问题的本质所在。
而没有复盘习惯的人,碰到这类问题会当场傻了,也许在心里嘀咕:我也就凭感觉、凭经验做的,没想很多啊。容易在回答时陷入细节,直接讲述当时接到了什么需求,然后做了什么功能,导致答题的思维高度不够。
3. 考察方法论的沉淀而方法论的输出,说明你的项目沉淀到了足够的深度,而且把踩过的坑总结成为了一套逻辑自洽的心法,大概率在以后的工作中能帮助你避开很多不必要的麻烦。大家在工作中可以观察有逻辑做事的人和凭感觉拍脑袋做事的人,在出方案的效率与执行结果上,有非常大的差距。
某运营大神在人才选拔上有一个深刻的见解,他认为识别人才,可以从三个层次去区分。
第一层次的人才是“野生纯天然”,这一层强调企业和平台背书的作用,可能在相同的环境下去做同样的事情,谁都能拿到不错的结果;第二层次的人才是“见过好体系”,就是在业界得到了基本的学习和锻炼,有系统的方法论;第三层次的人才是“建过好体系”,能因地制宜地做好体系设计。
我们避免成为第一类,离开了平台你什么都不是;我们立志成为第三类;但是在面试中大多数的情况,需要有技巧地展现我们属于第二类人才。让面试官明白,系统的方法论能帮助企业避开不必要的坑。
一个有抽象思维、有复盘思考习惯、有能复用的方法论的人才,谁不爱呢?
4. 从这个话题切入,了解更多的项目细节,鉴别项目真伪和实践深度这个出发点就好比面试开场就要求做自我介绍一样,初次见面的陌生人,总得找点共同话题交流吧。最好的共同话题就是项目本身了,项目容易造假,加水分,但是细节是很难注水的。一般针对项目连续问 4-5 个问题,有水分的人基本就进行不下去了。
所以在面试中,切记从实际出发,可以从思维高度上去包装,但不要无中生有。有人就问了,我的项目经验不足,不注水要怎么答啊。看下去,下文给你真诚作答的加分思路。
二、解题的思路是什么?回到最开始的问题,请你以一个项目为例,谈谈你是如何抽象功能设计的?4步走解决这个问题。
1. 5why原则深挖业务当前的痛点,并与多方业务人员交谈提取需求共性在开始之前先介绍项目的背景是基本的礼貌,面试官不一定是本行业的从业人员,对你公司的业务模式也没有深刻的了解。先说明项目背景,有利于在共同认知基础上开展对话。
鉴于B端业务的跨部门,跨角色,一个需求的提出,往往有错综复杂的历史因素。所以抽象需求的要点是通过多方交谈,提取需求共性。经典的5why 原则是经证实的有效、简单、实操性强的“刨根问底”的方式。在答题的时候,可以详细说明自己推理的思路。
2. 参考行业内的标准化解决方案王戴明老师在他的《SaaS产品经理:从菜鸟到专家》一书中提出,学习的方式有:向自己学、向他人学、向书本学、向标杆学。
向自己学适用于项目的复盘与总结,遇到新的问题的时候,我们可以参考向他人和标杆学习。业内领头羊的实施方案,已经成功验证了商业逻辑是成立的,告诉我们此路已通。
特别是B端内研系统的产品,不应仅仅局限于解决眼前的问题,这样会让我们只能做到60分及格。而是应该放开视野,看看商业化产品的的解决方案是如何设计的,推敲背后的业务逻辑和市场机会,有利于设计灵活而强大的产品架构,了解当前设计方案的局限性与边界,从60分做到80分。
例如权限的设计,在行业内有很成熟的解决方案。无非是用户、角色、权限(数据权限,功能权限)的关系,根据项目的复杂度还会涉及用户组、角色组、组织架构关系。
了解Oracle、Salesforce等跨国软件的权限架构,可以让我们清晰认识到复杂业务的顶级设计方案,但是不意味着我们的项目就需要用到这么高级的权限架构。也许最简单的用户 权限在当前的项目阶段就已够用。
3. 解决方案梳理并输出原型,与相关方沟通、确认行业内的顶级解决方案可提供思考方向的参考,但方案的设计需要结合自身的项目状况,考虑实际落地的策略。B端产品在寻找竞品解决方案有一定的门槛,并不一定能找到可参考的案例,但是解决问题的底层逻辑都是相通的。
另外在设计原型、输出解决方案(流程图、文字描述等)的过程中,我们可以排查将来研发或者上线推广的障碍点,提前与研发团队的小伙伴们,业务相关方沟通、确认。和业务方确认原型是比较重要的一步,有条件的情况下可以进行demo演示操作,或者按照场景演示demo,确认方案能否解决他们遇到的问题。
这三步操作中,比较有难度的就是在提取需求共性上,初入门的小伙伴们往往会被业务部门五花八门的需求弄晕,业务要啥就做啥。如果有持续的思考和行业案例积累,输出适合自身业务的标准化解决方案就是手到擒来的事情了。
三、加分亮点如果你觉得以上的作答毫无亮点,或者底气不足,可以从这2个方面补充一下。
1. 上线结果反馈,主动反思是否达到预期,是否有调整空间其实无论是项目介绍还是功能的抽象设计,都可以用这样的思路来回答,典型的STAR原则(情形、任务、行动、结果)或者PDCA原则,这也是反映我们项目复盘能力的一种策略。
大概率上,面试官对你上文的作答感兴趣,也会继续追问当时抽象设计的功能,最终效果怎么样?如果再做一遍,你会怎么做?可以做得更好吗?
2. 对于没上线的功能,给出规划和实施的思路,以及说明方案潜在的风险与难点
如果你深度参与业务并反思了业务的瓶颈,一定会规划了不少功能,希望帮助公司解决问题。也有可能有些功能做了,因为种种原因没有上线。
在遇到本文“抽象功能设计”的问题而又没有更好的案例时,可以选择这种答题思路。把你对业务的观察、调研推理思路、产品规划和落地策略一一剖析给面试官,展示你的产品思维、业务思维亮点。
四、案例实操面试官:请你以一个项目为例,谈谈你是如何抽象功能设计的?
作答:
我们公司主营服饰、珠宝私域电商业务,企业私域直播为主要的营销渠道。
大致的业务流程是:买手和运营部门负责日常商品与直播场次选品,销售通过微信为客户1V1提供服饰搭配、直播导购、代下单、售后等一条龙服务,这种服务形式和公司的客户群体为50岁以上的中老年女性有关。
企业内部的OMS系统支撑着业务的运作,其中商品管理模块链接了买手、销售这两个角色:买手推荐给销售的商品会出现在这个列表,销售日常会在列表中搜索商品,帮客户搭配导购或者直接代下单(业务背景介绍)。
在与业务对接的过程中,我发现销售总是要加一些查询条件,比如尺寸、颜色、价格,方便他们快速找到某款商品。而买手提出的需求是关于商品排序方面的,比如直播主推标记的商品要排在首页,新款商品也要排在首页。
接到需求的时候我准备按照销售的要求加查询条件,但直觉这一方案并不能解决实际的问题。于是我开始追问他们具体的业务场景:
1)问销售:
为什么要查商品的尺寸信息?查询出来的结果是否满意?大多数场景下能快速找到自己想要的商品吗?2)问买手:
为什么要让主推和新品排在首页,而不是按照商品的上架时间来排序?为什么主推商品权重大于新品?为什么关注商品的备注信息?(深挖业务痛点)最终根据多方信息的反馈和交叉对比,我提取出了1个核心观点:该模块承担着“根据既定目标快速检索商品”和“主动推荐合适商品,提升转化效率”的目标。如果把立即购买理解为 C 端的商城,这个模块要达成的目标就是:提升【人找货】以及【货找人】的效率(提取业务需求共性)。
于是我将需求规划为2个阶段:
第一阶段提升人找货的效率,具体实施措施包括扩大商品搜索的范围,不仅仅局限于销售提出的查询条件;以及商品按照买手的规则和常用的电商商城规则重新排序,让优质的商品排列在最前面,获得最大的曝光。
第二阶段,可以根据客户的画像智能推荐相关的商品,提升客单价和转化率。但是介于系统内的历史因素,要达到这一步有一些难度,需要提前在相关接口中埋点、搜集数据,再做下一步的迭代(参考行业标准化方案)。
第一阶段的规划落到原型上非常简单,但是所有业务部门看过后都赞口不绝,催促快速开发上线。至此我认为功能的抽象设计已经达成了阶段性的胜利,接下来就是观察上线结果是否符合预期了(原型、方案确认)。
本文由@RaRa 原创发布于人人都是产品经理。未经许可,禁止转载。
题图来自Unsplash,基于 CC0 协议。