互联网的产品人员，可能整个职业生涯都要与技术人员打交道。有些产品是技术出身，对于某个领域的技术有一定了解，但是涉及到具体需求可能并没有开发人员了解深入，问题提不好反而弄巧成拙。而大多数的产品人员，可能都是在工作中慢慢积累，逐渐接触到一些零散的技术知识，虽不成体系，但遇到类似的问题，尚且可以举一反三弄懂其原理。但在遇到新的项目或未知的领域时，仍然不知从何下手。
因此，本文的目的是希望从特定的一些方面阐述基本的技术思维，即拿到一个需求或见到某款互联网产品时，技术人员关注更多的点可能是什么。以此，来让产品人员一窥开发者的脑回路到底是怎样设定的，增进日后的相互理解。
所谓技术思维，并不是让你真的用技术人员的思考方式看待问题。这里所说的技术思维，只是让你从某种程度上更加缜密地思考与技术相关的问题，如此既可以在技术相关的知识面上有一定积累，也可以在一定程度降低与技术人员的沟通成本。
策划产品的初期，原则上是不应该受可行性的干扰，先想到好点子，剩下的交给技术解决。但是到了具体的产品需求文档形成之前，可行性就成为最后一道门槛。是时候找开发哥哥聊聊，到底能不能做。这时候，产品同学最怕的就是开发哥甩过来一句：实现不了。那么到底能做还是不能做，是不是只有开发说了算？当然不是，至少还有老板。
然而，作为一个小产品，总把老板搬出来也不是个事儿，况且，不是每个需求都有老板关注和授权的。那么，在日常无穷无尽的小需求中，如何防止被开发「忽悠」就是最核心的技能了。如果不想被「忽悠」，首先自己要做足功课。自己负责的产品、相关的平台已有功能、基础能力等，都要了如指掌，否则如果对于自己的产品细节都不够了解，怎么去提新需求？
思维提示
- 新开发的系统，尽量熟悉平台已有的基础能力，再来看新特性；
- 使用外部开放平台的，一般都有现成的文档，虽然未必全懂，但至少大概知道平台能力；
- 别人已经做好的效果，总不能说实现不了吧？如有差异，至少要给我讲清楚；
- 注端巨异，，终端异；
- 理解从芯片、硬件厂商、操作系统不同、手机厂商不同、机型不同、浏览器不同、语言不同等造成的种种差异。
评审需求的时候，很多产品最头疼的，可能就是区分「前端需求」还是「后端需求」了。前端开发和后台开发有什么区别？到底哪里是前哪里是后？这些改动到底要拉前端还是拉后台？
首先确「」「」相。假户浏览，页，户眼，谓「端」，即户。「」，「」背切，远球另某码，隐藏脑逻辑。
至于中间的地带，就有点暧昧了。不同的公司对于前后端的定义不尽相同，对于所谓「前后端分离」架构的产品，那么至少页面层级一定是前端的工作了。而对于某些「服务端渲染」架构的产品，即使是页面，也可能是后台同学的工作。
因此，对于自己负责的产品，要先弄清楚基本的架构，才好确定一个大概的界限。目前在互联网行业，整体的趋势都是趋于「全栈」，即前端也能做后台，后台也能搞前端，那么区分角色分工，就难上加难了。
思维提示
- 熟悉负责基础架构；
- 页面结构及样式相关，往往需要前端参与，最好拉上前端；
- 页面无法访问，或者直接输出错误信息，往往要拉上后端或运维同学；
- 实在分不清，只能一起约了。
产品思维，需要考虑产品的形态、受众群体、交互流程等等，这些已经很伤脑筋了。可是到了开发这里，却总是各种钻牛角尖，输入框输入 1000 个字怎么办？同时 10000 个人访问怎么办？ 500 个账号薅羊毛怎么办？
严格意义上来说，这些确实不是产品人员需要考虑的，到了「测试用例评审」这一步，自然会有专业的测试人员提出这些问题。但是假如这些类似的问题你之前都没有思考过，那么也可能被测试人员批评。想要表现得专业，需要你对研发流程的各个环节都成竹在胸，不至于一问三不知，或者一看就根本没有深入思考过。
这些极限情况也可以称之为「异常流」，有些异常流可能用户感知不明显，而有些异常流则会对用户造成很大的影响。因此，当出现这些异常的时候，如何给用户更好地提示和引导，或者引领用户去找客服寻求帮助等，就显得尤为重要了。
思维提示
- 开发哥的钻牛角尖思维，暴力一点会怎样；
- 开发哥的薅羊毛思维，量上来会怎样；
- 并发思维，全都一起来了会怎样；
- 即使是测试或 QA 的工作，发现问题还是要产品拍板修改，跑不掉的。
每隔几年，就会出现一次较大的用户隐私信息泄露问题，最近一次的事件大家都知道，就是 Facebook 的隐私泄露事件，以及国内的 WIFI 万能钥匙。还有「开房信息泄露」，是由于被黑客攻击。
关于黑客攻击的问题，作为产品人员甚至普通的开发人员，都是没有办法应对的，要有极其专业的安全团队才可能应对。我们这里说的，只是一点安全意识的问题。不要说产品人员，很多工作一两年的开发人员都非常缺乏安全意识。甚至有些是不经意的人为信息泄露，压根算不上技术问题。
比如，我们在互联网产品里标识用户要有某个特定的维度，可能是用户的手机号、第三方开放平台提供的 openid、淘宝登录名、微信昵称等等。那么，当我们以这个维度标识用户，并向他们展示隐私信息的时候，能否确认看到信息的一定是本人呢？有没有可能我们的维度没变，但是用户换了呢？
严，除认证认证，乎法确络另端，甚至难晓。互，烦认证。问题尽，并户验权衡，终归考虑问题。
思示
- 弄清楚所负责产品的用户体系，以及「用户」的定义；
- 考虑你展示给用户的信息，有多大可能被别人看到，站在身后看也算；
- 户，否 1+1=3 效；
- 你的系统有没有可能被机器人或外挂直接使用，而无法分辨。
，，报、，身需考虑吗？问题靠，希望程，，任何况户。程序报，息问题法、码。户需吗？户怎验呢？
所以，互联网产品如果想做到尽量完善，就要考虑到各种情况。当然，你不考虑也可以，那么接下来就是在开发、测试、运维同学不断地提问和质疑中慢慢填坑。
以电商的抢购活动为例，最理想的情况下，是系统有无限的承受能力，大家随便抢，系统也不会挂。但现实的情况是，硬件资源、网络带宽等都是有限的，即使我可以预估真实用户的量，也无法预估羊毛党的量。某个活动一旦有利可图，被转发到几个羊毛群，那基本上分分钟就要被掏空了。
在这样的现实下，如何能保证对大多数用户来说尽量公平，系统又不至于很快挂掉呢？这就是产品和技术要一起解决的问题了。譬如很多抢购活动引入的排队机制，或者提前发放的资格码等。这些需求某种程度上都是由于客观条件的限制，才引入的产品特性，从而倒逼产品人员修改流程和界面交互等。那么在你负责的产品中，有没有因为性能或其它的限制而产生的「特性」呢？
思维提示
- 产品的工作没有界限，多了解点什么知识都没坏处；
- 互联网产品都会在某个环节或阶段有性能瓶颈，由此可能产生意外的需求特性；
- 从脑子里的一个点子，到最后用户使用的口碑，产品经理都有责任关注；
- 在很多客观条件的限制下，没有所谓的绝对公平，一定是通过某种技术手段来「维持秩序」。
所谓隐性消耗，当然是不那么明显的消耗。那么对于产品人员来讲，哪些消耗不容易察觉呢？最常见的，就是硬件资源和带宽的消耗，例如某些带有视频的活动，如果出现爆发式增长，就可能快速烧掉云服务账户里的余额。如果公司有资深的运维人员，那么可以在类似的产品上线之前，找运维同学预估流量和费用，以免不小心超出预算。
同样，有些公司购买的带宽是峰值计费的，那么就很容易出现意外。服务器临时扛不住，紧急加机器也是可以的，最坏的情况就是有短暂的时间无法给用户提供服务。其实一般情况下，产品人员是不太需要考虑这些的，有技术和 IT 人员搞定就可以了。只是特殊的一些产品和活动，才需要把这些预算考虑在内。
还有一种情况，作为自己有开发团队的公司，遇到任何需求第一反应就是自己的开发能不能做，如果不是特别复杂的需求，一般都会得到「能做」的答案。但是有些时候，同样的能满足需求的东西，如果采用外包的形式交给外部团队，成本可能会降低很多。
呢？需求从零始，论速质，赖。，需求已熟案，或者模，甚至怎需改码，。毕竟攻，积累，游戏积累游戏，许甚至零复。
当然，外部采购也有麻烦的地方，比如公司资质门槛，财务流程等等，肯定是没有直接给开发哥提需求方便。但如果整个项目的成本和 KPI 都比较明确了，并且考察过有类似的外部团队可以满足需求的话，不妨对比一下成本和效率。
思维提示
- 重点项目要考虑技术侧可能花钱的地方；
- 「」，效率估；
- 外部采购成熟方案有时效率更高。
我们在规划新的产品特性的时候，往往会涉及到对原有系统的改动，由于原有系统可能不是自己负责的产品，即使与对应的产品沟通过，也可能考虑不周，而这些，还只是表面的功能改动，更大的坑还在后面。
论从，从端，希望谓「模」， PS 贴。相或异功，模固。需求迭历史，模变，及各使模系统千丝缕系。
此时，如果你的需求动到了这些所谓的「公共模块」，麻烦就来了。其他使用模块的系统是否需要一起改动，是否需要同步更新，还是保持原样？保持原样的模块是另一份拷贝还是在原有模块基础上兼容？
在技术的架构上，我们很难既满足想要一起改的时候就完全一起变化，而不想要一起修改的时候，又可以随便想改哪个就改哪个。这两个点之间只能是不断地权衡和妥协，没有完美的解决方案。因此，在我们寻求公共逻辑和修改迭代的便利性的同时，也需要考虑到未来分道扬镳时千丝万缕的纠缠。
思维提示
- 需求改，牵身；
- 模块化未必是好事，只有在保证这些产品模块功能相对一致时才有用；
- 技术人员也一直在纠结优化与过度优化之间的界线，这个界线完全取决于产品的走向。
什么？问题定位也要产品参与？那要开发有何用？话虽这样说，但还是那句话，这是体现产品经理素养的地方。如果你完全不懂，没人会怪你，但是如果你表现出一些技术上的专业性，大家就会对你刮目相看。
举简例，遇某捉急截图，页乱。，往往复「ctrl+0」。，问题？甚至转呢？
这里有两个技术点：第一，chrome 浏览器 ctrl+滚轮，会缩放页面，而且放大比例会对当前页面保存设置，再次打开页面还是上次放大的比例；第二，不管你截图的显示器上看上去是大是小，转发给我之后实际的像素应该跟我打开的页面是一样的，如果页面没有被放大的话，你的截图部分，和我的浏览器里对应的部分看起来应该是一样的。如果大小不一致，说明一定有缩放存在。那么这种简单的问题定位，就根本不需要去问开发人员。
再结合前面所说的角色分工问题，目前主流公司大都采用前后端分离的架构，所以页面上出现问题，往往可以先找前端。那么，除了这种粗浅的区分找前端还是后台，还能不能做点别的呢？当然能。最简单的，就是先横向确认一下，你这里有问题，其他人是不是也都有问题。WIFI 有问题的，是不是网线的也有问题。以此类推。
这些基本的判断也是开发人员的定位思路，先大概确定问题的范围，你会发现，很多时候问题往往出现在自己这里。开发人员也会犯类似的错误，甚至定位了好久才发现，原来是如此低级的一个错误。所以，当你能尝试自己发现低级错误的时候，你就拥有了开发人员的脑回路了。
思维提示
- 初步判断以及精准的问题描述非常有助于定位问题；
- 横向对比，再看遇到问题之前做了哪些「不寻常的事」；
- 如果确定是共性问题，还是尽快丢给开发吧。
本篇粗略讲述了开发人员见到需求或者遇到问题的时候，大致都有哪些「技术思维」，这些思维出于严谨，却又难免有吹毛求疵，钻牛角尖之嫌。技术说到底，都是冷冰冰的代码逻辑，没有什么感情用事和临时的杀伐决断。只有把所有细节和可能出现的状况尽量考虑清楚，才能开发出健壮稳定的系统。
同样，作为产品经理，你的产品能健壮稳定地给用户提供服务，也是产品成功的表现。既然如此，这方方面面的技术问题，则不可不察。所以说，优秀的产品经理，就是要对各个角色的分工了如指掌，熟悉每个角色的性格脾气和思维方式，才能撮合各个角色无障碍地分工协作，从而产出出色的互联网产品。了解技术人员的思维方式，或许是个良好的开端。
欢迎关注作者的微信公众号：「姬小光」
浙公网安备33011002017549号