专栏首页姬小光收藏 | 产品经理不可不知的 7 种技术思维

收藏 | 产品经理不可不知的 7 种技术思维

正文约 6000 字,预计需要 20min 阅读

我们常说,作为技术人员要有产品思维,从产品和运营的角度去思考技术方案。是的,我们也这样做了。然而,从我多年的需求沟通及项目协调的经验来看,产品人员其实也可以有一点技术思维。

所谓技术思维,并不是让你真的用技术人员的思考方式看待问题,那样肯定做不出好产品,两种思维方式是不可调和的。这里所说的技术思维,只是让你从某种程度上更加缜密地思考与技术相关的问题,如此既可以在技术相关的知识面上有一定积累,也可在一定程度上降低与技术人员的沟通成本。

互联网的产品人员,可能整个职业生涯都要与技术人员打交道。有些产品是技术出身,对于某个领域的技术有一定了解,但是涉及到具体需求可能并没有开发人员了解深入,问题提不好反而弄巧成拙。而对于大多数的产品人员,可能都是在职业生涯的慢慢积累中,逐渐接触到一些零散的技术知识,虽不成体系,但遇到类似的问题,或可举一反三弄懂其原理。但在遇到新的项目或未知的领域时,仍然不知从何下手,徒增的只是盲目的自信而已。

因此,本文的目的即是希望从特定的一些方面阐述基本的技术思维,即拿到一个需求或见到某款互联网产品时,技术人员关注得更多的点可能是什么。以此,来让产品人员一窥开发者的脑回路到底是怎样设定的,增进日后的相互理解。此前我写过一篇《如何洞悉隐性需求》,算是从开发的角度提示一些可能会被产品同学漏掉的需求细节,在需求沟通方面,可以作为本篇的补充。

Q

技术思维之可行性

策划产品的初期,原则上是不应该受可行性的干扰,先想到好点子,剩下的交给技术解决。但是到了具体的产品需求文档形成之前,可行性就成为最后一道门槛了。是时候找开发哥聊聊,到底能不能做了!这时候,产品同学最怕的就是开发哥甩过来一句:实现不了… 那么到底能做还是不能做,是不是就只有开发说了算呢?当然不是!至少还有老板~

然而,作为一个小产品,总把老板搬出来也不是个事儿,况且,不是每个需求都有老板关注和授权,狐假虎威肯定是要出事情的。那么,在日常无穷无尽的小需求中,如何防止被开发『忽悠』就是最核心的技能了。如果不想被『忽悠』,首先自己要做足功课。自己负责的产品、相关的平台已有功能、基础能力等,都要了如指掌,否则如果对于自己的产品细节都不够了解,怎么去提新需求?

T

思维提示

1,新开发的系统,尽量熟悉平台已有的基础能力,再来看新特性;

2,使用外部开放平台的,一般都有现成的文档,虽然未必全懂,但至少大概知道平台能力;

3,别人家已经做好的效果,总不能说实现不了吧?如有差异,至少要给我讲清楚;

4,关注不同端的巨大差异,很多实现不了的,其实是终端差异的局限;

5,理解从芯片、硬件厂商、操作系统不同、手机厂商不同、机型不同、浏览器不同、语言不同等造成的种种差异~

Q

技术思维之角色分工

评审需求的时候,很多产品最头疼的,可能就是区分『前端需求』还是『后端需求』了。前端开发和后台开发有什么区别?到底哪里是前哪里是后?这些改动到底要拉前端还是拉后台?

这里首先我们要明确一下『前』和『后』是相对于什么的。假设用户打开浏览器,看到了一个网页,那么用户第一眼看到的这些,就是所谓的『前端』,即与用户面对面的前。再说说『后』,这个『后』就是背后你看不到的一切的一切,可以远到地球另一侧的某台服务器上运行的代码,也可以是隐藏在你桌上电脑中的逻辑。

至于中间的地带,就有点暧昧了。不同的公司对于前后端的定义不尽相同,对于所谓『前后端分离』架构的产品,那么至少页面层级一定是前端的工作了。而对于某些『服务端渲染』架构的产品,即使是页面,也可能是后台同学的锅。

因此,对于自己负责的产品,要先弄清楚基本的架构,才好确定一个大概的界限。目前在互联网行业,整体的趋势都是趋于『全栈』,即前端也能做后台,后台也能搞前端,那么区分角色分工,就难上加难了。

T

思维提示

1,熟悉自己负责的产品的基础架构;

2,页面结构及样式相关,往往需要前端参与,最好拉上前端;

3,页面无法访问,或者直接输出错误信息,往往要拉上后端或运维同学;

4,实在分不清,只能一起约了~

Q

技术思维之极限情况

产品思维,需要考虑产品的形态、受众群体、交互流程等等,这些已经很伤脑筋了。可是到了开发这里,却总是各种钻牛角尖,什么小破输入框输入 1000 个字怎么办?什么同时 10000 个人访问怎么办?什么 500 个账号薅羊毛怎么办?

严格意义上来说,这些确实不是产品人员需要考虑的,到了『测试用例评审』这一步,自然会有专业的测试人员提出这些问题。但是假如这些类似的问题你之前都没有思考过,那么也可能被测试人员怼得很惨。要想表现为专业的产品经理,需要你对研发流程的各个环节都成竹在胸,不至于一问三不知,或者一看就根本没有深入思考过。

这些极限情况也可以称之为『异常流』,有些异常流可能用户感知不明显,而有些异常流则会对用户造成很大的影响。因此,当出现这些异常的时候,如何给用户更好的提示和引导,或者引领用户去找客服寻求帮助等,就显得尤为重要了。

T

思维提示

1,开发哥的钻牛角尖思维,暴力一点会怎样;

2,开发哥的薅羊毛思维,量上来会怎样;

3,并发思维,全都一起来了会怎样;

3,即使是测试或QA的工作,发现问题还是要产品拍板修改,跑不掉的~

Q

技术思维之安全性

每隔几年,就会出现一次较大的用户隐私信息泄露问题,最近的一次大家都知道,就是 Facebook 的隐私泄露事件,以及国内的 WIFI 万能钥匙。至于之前的门系列,虽然也是用户隐私,但是跟互联网关系不大,主要是修电脑的锅。还有『开房信息泄露』那次,是由于被黑客攻击。

关于黑客攻击的问题,作为产品人员甚至普通的开发人员,都是没有办法的事情,要有极其专业的安全团队才可能应付。我们这里说的,只是一点安全意识的问题。不要说产品人员,很多工作一两年的开发人员都非常缺乏安全意识。甚至有些是不经意的人为信息泄露,压根算不上技术问题。

比如,我们在互联网产品里标识用户要有某个特定的维度,可能是用户的手机号、第三方开放平台提供的 openid、淘宝登录名、微信昵称等等。那么,当我们以这个维度标识用户,并向他们展示隐私信息的时候,能否确认看到信息的一定是本人呢?有没有可能我们的维度没变,但是用户换了呢?

严格来说,除了生物认证和实时的真人认证,我们几乎无法确定网络另一端到底是什么人,甚至连是不是人都很难知晓。所以现在的很多互联网产品,才会有那么多烦人的认证。这个问题尽管无解,并且还要跟真实的用户体验之间做权衡,但总归是不能不考虑的方面。

T

思维提示

1,弄清楚所负责产品的用户体系,以及『用户』的定义;

2,考虑你展示给用户的信息,有多大可能被别人看到,站在身后看也算;

3,用户如有多个小号,能否达到 1+1=3 的效果;

4,你的系统有没有可能被机器人或外挂直接使用,而无法分辨~

Q

技术思维之性能

很多东西,看上去都是技术人员的事情,比如报错、比如性能,身为一个产品真的需要考虑这些吗?这个问题就要靠你自己了,你希望你的产品做到什么程度,是能用就行,还是在任何情况下都能对用户友好。如果程序上报错,信息一定是有助于问题定位的方法名、代码位置等等。那么用户需要看到这些吗?用户看到之后是怎样的体验呢?

所以,互联网产品如果想做到尽量完善,就要考虑到各种情况。当然,你不考虑也可以,那么接下来就是在开发、测试、运维同学不断的提问和质疑中慢慢填坑。

以电商的抢购活动为例,最理想的情况下,是系统有无限的承受能力,大家随便抢,系统也不会挂。但现实的情况是,硬件资源、网络带宽等都是有限的,即使我可以预估真实用户的量,也无法预估羊毛党的量。某个活动一旦有利可图,被转发到几个羊毛群,那基本上分分钟就要被掏空了。

那么在这样的现实下,如何能保证对大多数用户来说尽量公平,系统又不至于很快挂掉呢?这就是产品和技术要一起解决的问题了。譬如很多抢购活动引入的排队机制,或者提前发放的资格码等。这些需求某种程度上都是由于客观条件的限制,才引入的产品特性,从而倒逼产品人员修改流程和界面交互等。那么在你负责的产品中,有没有因为性能或其它的限制而产生的『特性』呢?

T

思维提示

1,产品的工作没有界限,多了解点什么知识都没坏处;

2,互联网产品都会在某个环节或阶段有性能瓶颈,由此可能产生意外的需求特性;

3,从脑子里的一个点子,到最后用户使用的口碑,产品经理都有责任关注;

4,在很多客观条件的限制下,没有所谓的绝对公平,一定是通过某种技术手段来『维持秩序』~

Q

技术思维之隐性消耗

所谓隐性消耗,当然是不那么明显的消耗。那么对于产品人员来讲,哪些消耗不容易察觉呢?最常见的,就是硬件资源和带宽的消耗,例如某些带有视频的活动,如果出现爆发式增长,就可能快速烧掉云服务账户里的余额。如果公司有资深的运维人员,那么可以在类似的产品上线之前,找运维同学预估流量和费用,以免不小心超出预算。

同样,有些公司购买的带宽是峰值计费的,那么就很容易出现意外。服务器临时扛不住,紧急加机器也是可以的,最坏的情况就是有短暂的时间无法给用户提供服务。其实一般情况下,产品人员是不太需要考虑这些的,有技术和 IT 人员搞定就可以了。只是特殊的一些产品和活动,才需要把这些预算考虑在内。

还有一种情况,作为自己有开发团队的公司,遇到任何需求第一反应就是自己的开发能不能做,如果不是特别复杂的需求,一般都会得到『能做』的答案。但是有些时候,同样的能满足需求的东西,如果采用外包的形式交给外部团队,成本却可能降低很多。

这是为什么呢?难道我们的开发就这么挫吗?当然不是!如果说一个需求全是从零开始的话,那么可以说很多公司的开发无论在速度和质量上,都是值得信赖的。但是,当这些需求外部已经有成熟的方案,或者活动模板,甚至是不怎么需要修改的现成代码的时候,这个成本就完全不一样了。毕竟术业有专攻,专门做活动的积累了很多活动;专门做游戏的积累了很多小游戏;这些东西对许多外包公司来说甚至是零成本复制,就看他想赚你多少钱了~

当然,外部采购也有麻烦的地方,比如公司资质门槛,财务流程等等,肯定是没有直接给开发哥提需求方便。但如果整个项目的成本和 KPI 都比较明确了,并且考察过有类似的外部团队可以满足需求的话,不妨对比一下成本和效率,开发哥的工资也很贵的~

T

思维提示

1,重点项目要考虑技术侧可能花钱的地方;

2,开发说『能做』只是说明可行性,效率和时间还要再评估;

3,外部采购成熟方案有时效率更高~

Q

技术思维之关联改动

我们在规划新的产品特性的时候,往往会涉及到对原有系统的改动,由于原有系统可能不是自己负责的产品,即使与对应的产品沟通过,也可能考虑不周,而这些,还只是表面的功能改动,更大的坑还在后面。

无论从设计到产品,还是从前端到后台,都希望有很多所谓『模块化』的东西,最好像 PS 一样贴过来就能用。对于完全相同或差异不大的功能,模块化固然很好。但是在需求迭代的历史长河中,总会产生同一模块的大大小小的变种,以及与各个使用模块的系统之间千丝万缕的联系。

此时,如果你的需求动到了这些所谓的『公共模块』,麻烦就来了。其他使用模块的系统是否需要一起改动,是否需要同步更新,还是保持原样?保持原样的模块是另一份拷贝还是在原有模块基础上兼容?

在技术的架构上,我们很难既满足想要一起改的时候就完全一起变化,而不想要一起修改的时候,又可以随便想改哪个改哪个。这两个点之间只能是不断地权衡和妥协,没有完美的解决方案。因此,在我们寻求公共逻辑和修改迭代的便利性的同时,也需要考虑到未来分道扬镳时千丝万缕的纠缠。

T

思维提示

1,只要你的需求修改到的地方,在技术侧就有可能牵一发而动全身;

2,模块化未必是好事,只有在保证这些产品模块功能相对一致时才有用;

3,技术人员也一直在纠结优化与过度优化之间的界线,这个界线完全取决于产品的走向~

Q

技术思维之问题定位

什么?问题定位也要产品参与?那要开发有何用?!话虽这样说,但还是那句话,这是体现产品经理素养的地方。如果你完全不懂,没人会怪你,但是如果你表现出一些技术上的专业性,大家就会对你刮目相看。

举个简单的例子,以前经常会遇到某个同事捉急地截图过来,说页面乱了。而我看过之后,往往会直接回复『ctrl+0』。那么,为什么当事人自己看不出问题?甚至中间转发的几个人也看不出来呢?

这里有两个技术点:第一,chrome 浏览器 ctrl+滚轮 会缩放页面,而且放大比例会对当前页面保存设置,再次打开页面还是上次放大的比例;第二,不管你的截图你的显示器上看上去是大是小,转发给我之后实际的像素应该跟我打开的页面是一样的,如果页面没有被放大的话,你的截图部分,和我的浏览器里对应的部分看起来应该是一样的。如果大小不一致,说明一定有缩放存在。那么这种简单的问题定位,就根本不需要去问开发人员,但是你可以问:为毛缩放了就会乱掉呢?

再结合前面所说的角色分工问题,目前主流公司大都采用前后端分离的架构,所以页面上出现问题,往往可以先找前端。那么,除了这种粗浅的区分找前端还是后台,还能不能做点别的呢?当然能。最简单的,就是先横向确认一下,你这里有问题,其他人是不是也都有问题。WIFI 有问题的,是不是网线的也有问题。以此类推。

这些基本的判断也是开发人员的定位思路,先大概确定问题的范围,你会发现,很多时候问题往往出现在自己这里。开发人员也会犯类似的错误,甚至定位了好久才发现,原来是如此低级的一个错误。所以,当你能尝试自己发现低级错误的时候,你就进入了开发人员的脑回路了。

T

思维提示

1,初步判断以及精准的问题描述非常有助于定位问题;

2,横向对比,再看遇到问题之前做了哪些『不寻常的事』;

3,如果确定是共性问题,还是尽快丢给开发吧~

结 语

本篇粗略讲述了开发人员见到需求或者遇到问题的时候,大致都有哪些『技术思维』,这些思维出于严谨,却又难免有吹毛求疵,钻牛角尖之嫌。技术说到底,都是冷冰冰的代码逻辑,没有什么感情用事和临时的杀伐决断。只有把所有细节和可能出现的状况尽量考虑清楚,才能开发出健壮稳定的系统。

同样,作为产品经理,你的产品能健壮稳定地给用户提供服务,也是产品成功的表现。既然如此,这方方面面的技术问题,则不可不察。所以说,优秀的产品经理,就是要对各个角色的分工了如指掌,熟悉每个角色的性格脾气和思维方式,才能撮合各个角色无障碍地分工协作,从而产出出色的互联网产品。了解技术人员的思维方式,或许是个良好的开端。

作者 | 姬小光 来源 | 姬小光 [ ID: hi-laser ]

本文分享自微信公众号 - 姬小光(hi-laser),作者:姬小光

原文出处及转载信息见文内详细说明,如有侵权,请联系 yunjia_community@tencent.com 删除。

原始发表时间:2019-06-10

本文参与腾讯云自媒体分享计划,欢迎正在阅读的你也加入,一起分享。

我来说两句

0 条评论
登录 后参与评论

相关文章

  • 和不懂技术的产品经理共事是怎样一种体验?

    第二个是转岗。据了解有很多技术人员在工作几年后出于职业发展的考虑都会选择成为产品经理。当然,各大企业在进行产品经理招聘时给出的高薪资,也是吸引了越来越多的人加入...

    java达人
  • 人工智能美学 算法美学 指南v1.0

    逻辑思维是目前人工智能实现效果最好的思维方式,一般我们把此类也称为计算思维,人工智能在计算能力、精准程度、图像识别以及简单重复性劳动等方面已经超越人类水平。

    mixlab
  • 闲鱼疯转6800份!大厂内部数据分析资料首公开

    在任何一个企业中,每个运转的环节都会产出其对应的数据,当企业出现问题时,正确完整的数据分析可以帮助决策者做出明智有利的决策。

    乔戈里
  • 如何转型做产品经理?

    ? 本文来源:IEG技术藏经阁 经常看到乐问(腾讯内部平台)上有一些同学问,非产品如何转型做产品经理? 测试如何转型做产品经理等等,诸如此类的问题。  最近重...

    腾讯大讲堂
  • 产品/项目经理,有效提高效率的11种方法

    产品 / 项目经理由于所处的环境,面对的情况和接触的人群复杂多变,往往需要具备较为全面的能力。与能力匹配的就是拥有不同的思维方式。

    笑看
  • 找不到喜欢的思维导图 App,他做了个小程序取悦自己 | 晓组织 #2

    每周,我们都会邀请优秀的小程序开发者,从产品/开发/运营等角度,分享他的小程序实战经验。如果你想成为「晓组织」的一员,请发送邮件至 bigbang@ifanr....

    知晓君
  • 【区块链技术工坊31期】许向:艺术品领域区块链探索实践

    1)题目: 【区块链技术工坊31期】艺术品领域区块链探索实践 2)议题: 正所谓古语有云,盛世兴古董,乱世重黄金。 刚巧我们正处于一个盛世中,各种古玩、...

    辉哥
  • 75道常见AI面试题,看看你的知识盲点在哪?(附解析)

    【导语】正值求职、跳槽季,无论你是换工作还是找实习,没有真本事都是万万不行的,可是如何高效率复习呢?之前我们给大家推荐了一份 Python 面试宝典,收藏了近 ...

    AI科技大本营
  • 区块链搭车游戏掘金 行业人才仍存巨大缺口

    多款区块链游戏在2018年悄悄上线了。除了代打、直播,区块链会成为下一个游戏生财的好渠道吗? 最早为人所知的区块链小游戏是2017年11月上线的CryptoKi...

    区块链领域
  • 【广州产品经理大会实录】如何做好一款大众化产品

    5月10日,由人人都是产品经理和腾讯大讲堂共同举办的2015中国产品经理大会全国巡回-广州站在华南理工大学举行,本篇是酷狗音乐高级产品总监《如何做好一款大众化产...

    腾讯大讲堂
  • 直播预约|容器产品运维经典难点问题解析

    ? 从过去的【单体式应用+物理机】,到现在【微服务应用+容器云】的运行环境的变革。日趋复杂的运维开发环境,我们需要更加容易扩展、性能优越、方便监控的管理服务,...

    腾讯云原生
  • 程序员转型发展:拆除这些墙,才会发现更蓝的天空

    摘要: 这可能是最坏的时代,也可能是最好的时代,总之,这是属于我们的时代,只要你敢于打破禁锢你思维的那堵墙,未来无限可能。本文中就为大家分享了对于程序员转型的思...

    小莹莹
  • 张小龙的产品观

    用户1756920
  • 产品经理:所谓的互联网思维

    今天说说所谓的互联网思维吧,有系统的了解后,看一些产品或者行业趋势的时候也有一些新的坐标系。

    Java猫说
  • 如何利用产品思维提升用户体验?

    事件:2018年初,夏威夷民众的手机突然收到一则警报,指有导弹正向夏威夷袭来,要求民众立刻进入防空洞或避难所躲避,并强调这不是演习。原因是,当天夏威夷军方紧急事...

    腾讯大讲堂
  • 开发工具总结(7)之多年珍藏的Android开发必备网站和工具

    版权声明:本文为博主原创文章,未经博主允许不得转载。https://www.jianshu.com/p/781c1b56bc5b

    AWeiLoveAndroid
  • 【干货】1000位产品经理推荐的数据分析书籍

    世界如此喧嚣,知识何其稀少。这是一个信息爆炸的时代,被资讯洪流裹挟的我们,都养成了非常不好的思维习惯:把信息当作知识,把收藏当作学习,把阅读当作思考,把储存当作...

    钱塘数据
  • 巴黎圣母院会不会数字重建 用科技激活历史遗迹?

    ? 2019年4月16日,北京时间0点,法国著名建筑巴黎圣母院突发大火,塔尖坍塌、玫瑰花窗烧毁,整个建筑受损严重,800年的历史正面临着摧残。 ? 起火的原因...

    腾讯文旅
  • 原创设计论坛+企鹅潮玩展2019联合举办,尽在腾讯深圳总部

    ? 腾讯ISUX isux.tencent.com 社交用户体验设计 ? I ? UX原创设计论坛,由腾讯ISUX用户体验设计部旗下原创馆创办。自2018年...

    腾讯ISUX

扫码关注云+社区

领取腾讯云代金券