教你8招!不会被程序哥哥追着砍 - 优设网 - UISDC

教你8招!不会被程序哥哥追着砍

2019/06/11 10278评论 5

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

因此,本文的目的是希望从特定的一些方面阐述基本的技术思维,即拿到一个需求或见到某款互联网产品时,技术人员关注更多的点可能是什么。以此,来让产品人员一窥开发者的脑回路到底是怎样设定的,增进日后的相互理解。

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

技术思维之可行性

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

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

思维提示

  • 新开发的系统,尽量熟悉平台已有的基础能力,再来看新特性;
  • 使用外部开放平台的,一般都有现成的文档,虽然未必全懂,但至少大概知道平台能力;
  • 别人已经做好的效果,总不能说实现不了吧?如有差异,至少要给我讲清楚;
  • 关注不同端的巨大差异,很多实现不了的,其实是终端差异的局限;
  • 理解从芯片、硬件厂商、操作系统不同、手机厂商不同、机型不同、浏览器不同、语言不同等造成的种种差异。

技术思维之角色分工

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

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

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

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

思维提示

  • 熟悉自己负责的产品的基础架构;
  • 页面结构及样式相关,往往需要前端参与,最好拉上前端;
  • 页面无法访问,或者直接输出错误信息,往往要拉上后端或运维同学;
  • 实在分不清,只能一起约了。

技术思维之极限情况

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

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

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

思维提示

  • 开发哥的钻牛角尖思维,暴力一点会怎样;
  • 开发哥的薅羊毛思维,量上来会怎样;
  • 并发思维,全都一起来了会怎样;
  • 即使是测试或 QA 的工作,发现问题还是要产品拍板修改,跑不掉的。

技术思维之安全性

每隔几年,就会出现一次较大的用户隐私信息泄露问题,最近一次的事件大家都知道,就是 Facebook 的隐私泄露事件,以及国内的 WIFI 万能钥匙。还有「开房信息泄露」,是由于被黑客攻击。

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

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

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

思维提示

  • 弄清楚所负责产品的用户体系,以及「用户」的定义;
  • 考虑你展示给用户的信息,有多大可能被别人看到,站在身后看也算;
  • 用户如有多个小号,能否达到 1+1=3 的效果;
  • 你的系统有没有可能被机器人或外挂直接使用,而无法分辨。

 

技术思维之性能

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

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

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

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

思维提示

  • 产品的工作没有界限,多了解点什么知识都没坏处;
  • 互联网产品都会在某个环节或阶段有性能瓶颈,由此可能产生意外的需求特性;
  • 从脑子里的一个点子,到最后用户使用的口碑,产品经理都有责任关注;
  • 在很多客观条件的限制下,没有所谓的绝对公平,一定是通过某种技术手段来「维持秩序」。

技术思维之隐性消耗

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

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

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

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

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

思维提示

  • 重点项目要考虑技术侧可能花钱的地方;
  • 开发说「能做」只是说明可行性,效率和时间还要再评估;
  • 外部采购成熟方案有时效率更高。

技术思维之关联改动

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

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

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

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

思维提示

  • 只要你的需求修改到的地方,在技术侧就有可能牵一发而动全身;
  • 模块化未必是好事,只有在保证这些产品模块功能相对一致时才有用;
  • 技术人员也一直在纠结优化与过度优化之间的界线,这个界线完全取决于产品的走向。

技术思维之问题定位

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

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

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

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

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

思维提示

  • 初步判断以及精准的问题描述非常有助于定位问题;
  • 横向对比,再看遇到问题之前做了哪些「不寻常的事」;
  • 如果确定是共性问题,还是尽快丢给开发吧。

结语

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

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

欢迎关注作者的微信公众号:「姬小光」

优设大课堂

非特殊说明,本文版权归原作者所有,转载请注明出处
本文地址:https://www.uisdc.com/8-technological-thinking

发表评论 加载中....

评论加载中....

uisdc

评论区都快饿瘪了,看看我期盼的小眼神...

版式设计 交互设计师 界面设计 排版布局 职场 设计师干货 优设专访 优设大课堂 设计达人 配色 视觉设计 web前端开发 素材下载 AI教程 设计流程 设计理论 神器下载 字体下载 设计师专访 psd下载 设计规范 用户体验设计 海报设计 设计趋势 平面设计 动效设计 logo设计 图标设计 ICON 产品设计 神器推荐 App设计 字体设计 职场规划 酷站推荐 交互设计 ui设计 优秀网页设计 设计师职场 ps技巧 酷站 用户体验 PS教程 网页设计 经验分享

您还没有登录

优设启用更安全省心的 微信扫码登录

微信扫码

300万设计师聚集地!优设网是极具人气的设计师平台
2012年成立至今,一直专注于设计师的学习成长交流

把好文章收藏到微信

打开微信,扫码分享
学设计 优设网 在这里