产品经理应该学习的八种技术思维

产品经理应该学习的技术思维，是指产品经理从某种程度上更加缜密地思考与技术相关的问题，如此既可以在技术相关的知识面上有一定积累，也可在一定程度上降低与技术人员的沟通成本。
互联网的产品人员，可能整个职业生涯都要与技术人员打交道。大多数的产品人员，在职业生涯会逐渐接触并积累一些零散的技术知识，但是不成体系。有些产品是技术出身，对于某个领域的技术有一定了解，但是涉及到具体需求可能并没有对面开发人员了解深入，技术调研不清楚反而会弄巧成拙。

一、技术思维之可行性

策划产品的初期，原则上是不应该受可行性的干扰，先调研好用户需求，并且分析需求价值，剩下的基本需要与技术沟通。
到了具体的产品需求文档形成之前，可行性就成为最后一道门槛了。就需要进行需求评审，跟开发细致的沟通是否可行以及具体的实现方式。
那么到底能做还是不能做，是不是就只有开发说了算呢？当然不是！在日常无穷无尽的小需求中，如何防止有价值的需求被敷衍或者有其他想法的开发拒绝，也是比较重要的一门技能。首先自己要对自己负责的产品、相关的平台已有功能、基础能力了如指掌；其次是对于一些基础的技术选型，技术实现方式、技术原理有了解；最后要学会具备一定的沟通技巧。
思维提示：

1. 新开发的系统，尽量熟悉平台已有的基础功能，再来看新特性；
2. 使用外部开放平台的，一般都有现成的文档，虽然未必全懂，但至少大概知道平台功能以及架构；
3. 别人家已经做好的效果，总不能说实现不了吧？如有差异，了解清楚具体原因；
4. 关注不同端的巨大差异，很多实现不了的，其实是终端差异的局限；
5. 理解从芯片、硬件厂商、操作系统不同、手机厂商不同、机型不同、浏览器不同、语言不同等造成的种种差异。

   二、技术思维之角色分工

   评审需求的时候，很多产品会纠结区分“前端需求”还是“后端需求”。前端开发和后台开发有什么区别？这些改动到底要拉前端还是拉后台？

“前端”和“后端”是相对于什么的：
假设用户打开浏览器，看到了一个网页，那么用户第一眼看到的这些，就是所谓的“前端”——即与用户面对面的前。
“后端”就是背后你看不到程序，可以远到地球另一侧的某台服务器上运行的代码，也可以是隐藏在你桌上电脑中的逻辑。
不同的公司对于前后端的定义不尽相同，对于“前后端分离”架构的产品，那么页面层级一定是前端的工作了。而对于某些“服务端渲染”架构的产品，即使是页面，也可能是后台端的问题。

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

1. 熟悉自己负责的产品的基础架构；
2. 页面结构及样式相关，往往需要前端参与，最好拉上前端；
3. 页面无法访问，或者直接输出错误信息，往往要拉上后端或运维；

4. 分不清的时候，咨询开发。

   三、技术思维之极限情况

   产品思维，需要考虑产品的形态、受众群体、交互流程等等
   但是到了开发，还会有各种钻牛角尖的问题。例如，输入框输入 1000 个字怎么办？什么同时 10000 个人访问怎么办？什么 500 个账号薅羊毛怎么办？
   严格意义上来说，这些确实不是产品人员需要考虑的，到了“测试用例评审”这一步，自然会有专业的测试人员提出这些问题。但是，假如这些类似的问题你之前都没有思考过，那么也可能被测试人员怼得很惨。
   要想表现为专业的产品经理，需要你对研发流程的各个环节都成竹在胸，不至于一问三不知，或者一看就根本没有深入思考过。
   这些极限情况也可以称之为“边界情况”、“异常流”，有些异常流可能用户感知不明显，而有些异常流则会对用户造成很大的影响。因此，当出现这些异常的时候，如何给用户更好的提示和引导，或者引领用户去找客服寻求帮助等，就显得尤为重要了。
   思维提示

5. 钻牛角尖思维，暴力一点会怎样；

6. 薅羊毛思维，量上来会怎样；
7. 并发思维，全都一起来了会怎样；

8. 即使是测试或QA的工作，发现问题还是要产品拍板修改，需要提前思考。

   四、技术思维之安全性

   关于黑客攻击的问题，作为产品人员甚至普通的开发人员，都是没有办法的事情，要有极其专业的安全团队才可能应付。但是安全意识的问题，是产研人员都需要注意的。很多产研人员都非常缺乏安全意识，甚至有些是不经意的人为信息泄露，压根算不上技术问题。
   比如：我们在互联网产品里标识用户要有某个特定的维度，可能是用户的手机号、第三方开放平台提供的 openid、淘宝登录名、微信昵称等等。
   那么，当我们以这个维度标识用户，并向他们展示隐私信息的时候，能否确认看到信息的一定是本人呢？有没有可能我们的维度没变，但是用户换了呢？
   严格来说，除了生物认证和实时的真人认证，我们几乎无法确定网络另一端到底是什么人，甚至连是不是人都很难知晓。所以，现在的很多互联网产品，才会有那么多烦人的认证。这个问题尽管无解，并且还要跟真实的用户体验之间做权衡，但是必须要考虑的方面。
   思维提示

9. 弄清楚所负责产品的用户体系，以及“用户”的定义；

10. 考虑展示给用户的信息，有多大可能被别人看到，站在身后看也算；
11. 用户如有多个小号，能否达到 1+1=3 的效果；

12. 系统有没有可能被机器人或外挂直接使用，而无法分辨。

    五、技术思维之性能

    很多东西，比如报错、比如性能，看上去都是技术人员的事情，其实身为一个产品也是需要考虑的
    产品经理希望产品做到什么程度，用户体验需要做到多么良好。如果程序上报错，信息一定是有助于问题定位的方法名、代码位置等等。
    以电商的抢购活动为例，最理想的情况下，是系统有无限的承受能力，大家随便抢，系统也不会挂。但现实的情况是，硬件资源、网络带宽等都是有限的，即使我可以预估真实用户的量，也无法预估羊毛党的量。某个活动一旦有利可图，被转发到几个羊毛群，那基本上分分钟就要被掏空了。
    那么，在这样的现实下，如何能保证对大多数用户来说尽量公平，系统又不至于很快挂掉呢？
    这就是产品和技术要一起解决的问题了。譬如很多抢购活动引入的排队机制，或者提前发放的资格码等。这些需求某种程度上都是由于客观条件的限制，才引入的产品特性，从而产品人员需要修改流程和界面交互等。
    思维提示

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

14. 从用户对产品的使用感受，到最后用户使用的口碑，产品经理都有责任关注；

15. 在很多客观条件的限制下，没有所谓的绝对公平，一定是通过某种技术手段来“维持秩序”。

    六、技术思维之隐性消耗

    所谓隐性消耗，当然是不那么明显的消耗。
    那么，对于产品人员来讲，哪些消耗不容易察觉呢？
    最常见的，就是硬件资源和带宽的消耗，例如某些带有视频的活动，如果出现爆发式增长，就可能快速烧掉云服务账户里的余额。如果公司有资深的运维人员，那么可以在类似的产品上线之前，找运维同学预估流量和费用，以免不小心超出预算。
    同样，有些公司购买的带宽是峰值计费的，那么就很容易出现意外。服务器临时扛不住，紧急加机器也是可以的，最坏的情况就是有短暂的时间无法给用户提供服务。其实一般情况下，产品人员是不太需要考虑这些的，有技术和 IT 人员搞定就可以了。只是特殊的一些产品和活动，才需要把这些预算考虑在内。
    还有一种情况，作为自己有开发团队的公司，遇到任何需求第一反应就是自己的开发能不能做，如果不是特别复杂的需求，一般都会得到“能做”的答案。但是有些时候，同样的能满足需求的东西，如果采用外包的形式交给外部团队，成本却可能降低很多。
    如果说一个需求全是从零开始的话，那么可以说很多公司的开发无论在速度和质量上，都是值得信赖的。但是，当这些需求外部已经有成熟的方案，或者活动模板，甚至是不怎么需要修改的现成代码的时候，这个成本就完全不一样了。毕竟术业有专攻，专门做活动的积累了很多活动；专门做游戏的积累了很多小游戏；这些东西对许多外包公司来说甚至是零成本复制，就看他想赚你多少钱了。
    当然，外部采购也有麻烦的地方，比如：公司资质门槛，财务流程等等，肯定是没有直接给开发哥提需求方便。但如果整个项目的成本和 KPI 都比较明确了，并且考察过有类似的外部团队可以满足需求的话，不妨对比一下成本和效率，开发哥的工资也很贵的。
    思维提示

16. 重点项目要考虑技术侧可能产生成本的地方；

17. 开发说“能做”只是说明可行性，效率和时间还要再评估；

18. 外部采购成熟方案有时效率更高。

    七、技术思维之关联改动

    我们在规划新的产品特性的时候，往往会涉及到对原有系统的改动，由于原有系统可能不是自己负责的产品，即使与对应的产品沟通过，也可能考虑不周。而这些，还只是表面的功能改动，更大的坑还在后面。
    无论从设计到产品，还是从前端到后台，都希望有很多所谓“模块化”的东西，最好像 PS 一样贴过来就能用。对于完全相同或差异不大的功能，模块化固然很好。但是，在需求迭代的历史长河中，总会产生同一模块的大大小小的变种，以及与各个使用模块的系统之间千丝万缕的联系。
    此时，如果你的需求动到了这些所谓的“公共模块”，那么就很复杂。其他使用模块的系统是否需要一起改动，是否需要同步更新，还是保持原样？保持原样的模块是另一份拷贝还是在原有模块基础上兼容？
    在技术的架构上，我们很难既满足想要一起改的时候就完全一起变化。这两个点之间只能是不断地权衡和妥协，没有完美的解决方案。
    因此，在我们寻求公共逻辑和修改迭代的便利性的同时，也需要考虑到关联的模块。
    思维提示

19. 只要你的需求修改到的地方，在技术侧就有可能牵一发而动全身；

20. 模块化未必是好事，只有在保证这些产品模块功能相对一致时才有用；

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

    八、技术思维之问题定位

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

22. 初步判断以及精准的问题描述非常有助于定位问题；

23. 横向对比，再看遇到问题之前做了哪些“异常事件”；
24. 如果确定是共性问题，还是尽快与开发沟通。