技术思维有哪些

本文笔者将从可行性、角色分工、极限情况、安全性、性能、隐性消耗、关联改动、问题定位等角度来阐述产品经理必须要具备的七种技术思维。

我们常说，作为技术人员要有产品思维，从产品和运营的角度去思考技术方案。

是的，我们也这样做了。然而，从我多年的需求沟通及项目协调的经验来看，产品人员其实也可以有一点技术思维。

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

互联网的产品人员，可能整个职业生涯都要与技术人员打交道。有些产品是技术出身，对于某个领域的技术有一定了解，但是涉及到具体需求可能并没有开发人员了解深入，问题提不好反而弄巧成拙。

而对于大多数的产品人员，可能都是在职业生涯的慢慢积累中，逐渐接触到一些零散的技术知识，虽不成体系，但遇到类似的问题，或可举一反三弄懂其原理。但在遇到新的项目或未知的领域时，仍然不知从何下手，徒增的只是盲目的自信而已。

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

此前我写过一篇《如何洞悉隐性需求》，算是从开发的角度提示一些可能会被产品同学漏掉的需求细节，在需求沟通方面，可以作为本篇的补充。

一、技术思维之可行性策划产品的初期，原则上是不应该受可行性的干扰，先想到好点子，剩下的交给技术解决。

但是，到了具体的产品需求文档形成之前，可行性就成为最后一道门槛了。是时候找开发哥聊聊，到底能不能做了！这时候，产品同学最怕的就是开发哥甩过来一句：实现不了……

那么到底能做还是不能做，是不是就只有开发说了算呢？当然不是！至少还有老板~

然而，作为一个小产品，总把老板搬出来也不是个事儿。况且，不是每个需求都有老板关注和授权，狐假虎威肯定是要出事情的。

那么，在日常无穷无尽的小需求中，如何防止被开发『忽悠』就是最核心的技能了。如果不想被『忽悠』，首先自己要做足功课。自己负责的产品、相关的平台已有功能、基础能力等，都要了如指掌，否则如果对于自己的产品细节都不够了解，怎么去提新需求？

那么到底能做还是不能做，是不是就只有开发说了算呢？当然不是！至少还有老板~

然而，作为一个小产品，总把老板搬出来也不是个事儿。况且，不是每个需求都有老板关注和授权，狐假虎威肯定是要出事情的。

那么，在日常无穷无尽的小需求中，如何防止被开发『忽悠』就是最核心的技能了。如果不想被『忽悠』，首先自己要做足功课。自己负责的产品、相关的平台已有功能、基础能力等，都要了如指掌，否则如果对于自己的产品细节都不够了解，怎么去提新需求？