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

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

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

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

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

技术思惟之可行性

策划产品的初期，原则上是不该该受可行性的干扰，先想到好点子，剩下的交给技术解决。可是到了具体的产品需求文档造成以前，可行性就成为最后一道门槛了。是时候找开发哥聊聊，到底能不能作了！这时候，产品同窗最怕的就是开发哥甩过来一句：实现不了… 那么到底能作仍是不能作，是否是就只有开发说了算呢？固然不是！至少还有老板~

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

思惟提示

1. 新开发的系统，尽可能熟悉平台已有的基础能力，再来看新特性；
2. 使用外部开放平台的，通常都有现成的文档，虽然未必全懂，但至少大概知道平台能力；
3. 别人家已经作好的效果，总不能说实现不了吧？若有差别，至少要给我讲清楚；
4. 关注不一样端的巨大差别，不少实现不了的，实际上是终端差别的局限；
5. 理解从芯片、硬件厂商、操做系统不一样、手机厂商不一样、机型不一样、浏览器不一样、语言不一样等形成的种种差别~

技术思惟之角色分工

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

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

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

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

思惟提示

1. 熟悉本身负责的产品的基础架构；
2. 页面结构及样式相关，每每须要前端参与，最好拉上前端；
3. 页面没法访问，或者直接输出错误信息，每每要拉上后端或运维同窗；
4. 实在分不清，只能一块儿约了~

技术思惟之极限状况

产品思惟，须要考虑产品的形态、受众群体、交互流程等等，这些已经很伤脑筋了。但是到了开发这里，却老是各类钻牛角尖，什么小破输入框输入 1000 个字怎么办？什么同时 10000 我的访问怎么办？什么 500 个帐号薅羊毛怎么办？

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

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

本文来自公众号【姬小光】，已受权转载。

思惟提示

1. 开发哥的钻牛角尖思惟，暴力一点会怎样；
2. 开发哥的薅羊毛思惟，量上来会怎样；
3. 并发思惟，全都一块儿来了会怎样；
4. 即便是测试或QA的工做，发现问题仍是要产品拍板修改，跑不掉的~

技术思惟之安全性

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

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

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

严格来讲，除了生物认证和实时的真人认证，咱们几乎没法肯定网络另外一端究竟是什么人，甚至连是否是人都很难知晓。因此如今的不少互联网产品，才会有那么多烦人的认证。这个问题尽管无解，而且还要跟真实的用户体验之间作权衡，但总归是不能不考虑的方面。

思惟提示

1. 弄清楚所负责产品的用户体系，以及『用户』的定义；
2. 考虑你展现给用户的信息，有多大可能被别人看到，站在身后看也算；
3. 用户若有多个小号，可否达到 1+1=3 的效果；
4. 你的系统有没有可能被机器人或外挂直接使用，而没法分辨~

技术思惟之性能

不少东西，看上去都是技术人员的事情，好比报错、好比性能，身为一个产品真的须要考虑这些吗？这个问题就要靠你本身了，你但愿你的产品作到什么程度，是能用就行，仍是在任何状况下都能对用户友好。若是程序上报错，信息必定是有助于问题定位的方法名、代码位置等等。那么用户须要看到这些吗？用户看到以后是怎样的体验呢？

因此，互联网产品若是想作到尽可能完善，就要考虑到各类状况。固然，你不考虑也能够，那么接下来就是在开发、测试、运维同窗不断的提问和质疑中慢慢填坑。

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

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

思惟提示

1. 产品的工做没有界限，多了解点什么知识都没坏处；
2. 互联网产品都会在某个环节或阶段有性能瓶颈，由此可能产生意外的需求特性；
3. 从脑子里的一个点子，到最后用户使用的口碑，产品经理都有责任关注；
4. 在不少客观条件的限制下，没有所谓的绝对公平，必定是经过某种技术手段来『维持秩序』~

技术思惟之隐性消耗

所谓隐性消耗，固然是不那么明显的消耗。那么对于产品人员来说，哪些消耗不容易察觉呢？最多见的，就是硬件资源和带宽的消耗，例如某些带有视频的活动，若是出现爆发式增加，就可能快速烧掉云服务帐户里的余额。若是公司有资深的运维人员，那么能够在相似的产品上线以前，找运维同窗预估流量和费用，以避免不当心超出预算。

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

还有一种状况，做为本身有开发团队的公司，遇到任何需求第一反应就是本身的开发能不能作，若是不是特别复杂的需求，通常都会获得『能作』的答案。可是有些时候，一样的能知足需求的东西，若是采用外包的形式交给外部团队，成本却可能下降不少。

这是为何呢？难道咱们的开发就这么挫吗？固然不是！若是说一个需求全是从零开始的话，那么能够说不少公司的开发不管在速度和质量上，都是值得信赖的。可是，当这些需求外部已经有成熟的方案，或者活动模板，甚至是不怎么须要修改的现成代码的时候，这个成本就彻底不同了。毕竟术业有专攻，专门作活动的积累了不少活动；专门作游戏的积累了不少小游戏；这些东西对许多外包公司来讲甚至是零成本复制，就看他想赚你多少钱了~

固然，外部采购也有麻烦的地方，好比公司资质门槛，财务流程等等，确定是没有直接给开发哥提需求方便。但若是整个项目的成本和 KPI 都比较明确了，而且考察过有相似的外部团队能够知足需求的话，不妨对比一下成本和效率，开发哥的工资也很贵的~

思惟提示

1. 重点项目要考虑技术侧可能花钱的地方；
2. 开发说『能作』只是说明可行性，效率和时间还要再评估；
3. 外部采购成熟方案有时效率更高~

技术思惟之关联改动

咱们在规划新的产品特性的时候，每每会涉及到对原有系统的改动，因为原有系统可能不是本身负责的产品，即便与对应的产品沟经过，也可能考虑不周，而这些，还只是表面的功能改动，更大的坑还在后面。

不管从设计到产品，仍是从前端到后台，都但愿有不少所谓『模块化』的东西，最好像 PS 同样贴过来就能用。对于彻底相同或差别不大的功能，模块化当然很好。可是在需求迭代的历史长河中，总会产生同一模块的大大小小的变种，以及与各个使用模块的系统之间千丝万缕的联系。

此时，若是你的需求动到了这些所谓的『公共模块』，麻烦就来了。其余使用模块的系统是否须要一块儿改动，是否须要同步更新，仍是保持原样？保持原样的模块是另外一份拷贝仍是在原有模块基础上兼容？

在技术的架构上，咱们很难既知足想要一块儿改的时候就彻底一块儿变化，而不想要一块儿修改的时候，又能够随便想改哪一个改哪一个。这两个点之间只能是不断地权衡和妥协，没有完美的解决方案。所以，在咱们寻求公共逻辑和修改迭代的便利性的同时，也须要考虑到将来分道扬镳时千丝万缕的纠缠。

思惟提示

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

技术思惟之问题定位

什么？问题定位也要产品参与？那要开发有何用？！话虽这样说，但仍是那句话，这是体现产品经理素养的地方。若是你彻底不懂，没人会怪你，可是若是你表现出一些技术上的专业性，你们就会对你另眼相看。

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

这里有两个技术点：第一，chrome 浏览器 ctrl+滚轮 会缩放页面，并且放大比例会对当前页面保存设置，再次打开页面仍是上次放大的比例；第二，无论你的截图你的显示器上看上去是大是小，转发给我以后实际的像素应该跟我打开的页面是同样的，若是页面没有被放大的话，你的截图部分，和个人浏览器里对应的部分看起来应该是同样的。若是大小不一致，说明必定有缩放存在。那么这种简单的问题定位，就根本不须要去问开发人员，可是你能够问：为毛缩放了就会乱掉呢？

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

这些基本的判断也是开发人员的定位思路，先大概肯定问题的范围，你会发现，不少时候问题每每出如今本身这里。开发人员也会犯相似的错误，甚至定位了很久才发现，原来是如此低级的一个错误。因此，当你能尝试本身发现低级错误的时候，你就进入了开发人员的脑回路了。

思惟提示

1. 初步判断以及精准的问题描述很是有助于定位问题；
2. 横向对比，再看遇到问题以前作了哪些『不寻常的事』；
3. 若是肯定是共性问题，仍是尽快丢给开发吧~

结 语

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

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

本文来自公众号【姬小光】，已受权转载。