收藏|产品经理必须知道的7种技术思维是的，我们也做到了。但是从我多年的需求沟通和项目协调的经验来看，产品人员其实是可以有点技术思维的。所谓技术思维，并不是说你真的用技术人员的思维方式看问题。那样你肯定做不出好的产品，这两种思路是水火不容的。这里所说的技术思维，只是在一定程度上让你对技术相关的问题思考得更仔细一些，这样既可以在一定程度上积累技术相关的知识，又可以在一定程度上减少与技术人员的关系。通讯费用。互联网产品人员可能在整个职业生涯中都要和技术人员打交道。有些产品有技术出身，对某个领域的技术有一定的了解，但对开发者的具体需求未必有深入的了解。问题问不好，会弄巧成拙。对于大部分产品人员来说，在职业生涯的积累过程中，可能会逐渐接触到一些零散的技术知识。虽然不是很系统，但是大家可能会遇到类似的问题，触类旁通地理解其中的原理。但是遇到一个新的项目或者一个未知的领域，还是不知从何下手，增长的只是盲目的自信。因此，本文的目的是从一些具体的方面来讲解基本的技术思路，即技术人员在拿到需求或者看到某个互联网产品时可能比较关注的是什么。通过这种方式，产品人员可以一窥开发者的脑回路是如何设置的，日后增进相互了解。之前写过一篇《如何洞悉隐性需求》，就是从开发的角度提醒一些产品同学可能漏掉的需求细节。在需求沟通方面，可以作为本文的补充。技术思维的可行性在产品规划的初期，原则上不应该打扰可行性。先想好创意，剩下的交给技术。但在具体的产品需求文档形成之前，可行性成为最后一道门槛。是时候和开发小哥谈谈了，能不能做！这时候做产品的同学最怕的就是开发小哥抛出一句话：实现不了……那么能不能做，是不是只有开发说了算？当然不是！好歹有个boss啊~不过作为小产品，老是把boss搬出去也不是问题。再说了，也不是每一个需求都能得到老板的重视和授权，狐狸成虎一定会出事的。那么，在层出不穷的日常小需求中，如何防止被开发“忽悠”就是核心技能了。不想被“忽悠”，就得先做好功课。你必须了解你所负责的产品，相关平台已有的功能，基础能力等，否则你对自己产品的细节了解不够，怎么提出新的需求？新开发系统的思考提示，尽量熟悉平台已有的基础能力，再看新特性；使用外部开放平台的，一般都有现成的文档，虽然不一定全部看懂，但至少知道平台的能力；别人已经做出了很好的效果，不能说做不到吧？如果有区别，至少给我解释清楚；注意不同终端之间的巨大差异，很多无法实现其实是终端差异的局限；从不同的芯片、硬件厂商、不同的操作系统、不同的手机厂商、不同的机型、不同的浏览器了解不同的语言、不同的语言所造成的各种差异~技术思维的角色划分在reviewrequirements的时候，很多产品最头疼的问题可能是为了区分“前端需求”和“后端需求”。前端开发和后端开发有什么区别？前面在哪里，后面在哪里？这些变化是拉动前端还是拉动后端？在这里，首先要弄清楚“前”和“后”是相对的。假设用户打开浏览器，看到一个网页，用户首先看到的就是所谓的“前端”，也就是与用户面对面的前端。先说“背”，这个“背”就是你身后看不见的一切，它可以是地球另一端的服务器上运行的代码，也可以是隐藏在你桌面电脑中的逻辑.至于中间地带，就有点模棱两可了。不同的公司对前端和后端有不同的定义。对于所谓“前后端分离”架构的产品，至少页面层面必须是前端的工作。对于一些“服务端渲染”架构的产品，连页面都可能是后台同学的错。所以，对于自己负责的产品，首先要搞清楚基本结构，才能确定一个大概的边界。目前在互联网行业，整体趋势是走向“全栈”，即前端也可以是后端，后端也可以是前端，所以甚至更难区分角色和分工。思维提示熟悉自己负责的产品的基本结构；页面结构和样式相关，经常需要前端参与，最好拉前端；如果页面无法访问，或者直接输出错误信息，往往需要拉后台或者运维同学；分不清，只能一起约~技术思维的极端情况产品思维需要考虑产品的形态、受众、交互过程等等，这些已经很神经了——破坏。但是到了开发的时候，总是有各种死胡同。破烂的小输入框输入1000个字符怎么办？如果10,000人同时访问怎么办？500个账户怎么办？严格来说，这些确实不是产品人员需要考虑的。在“测试用例评审”这一步，专业的测试人员自然会提出这些问题。但是如果你之前没有想过这些类似的问题，你可能也会被测试人员惊呆了。要想以专业的产品经理形象出现，就需要对研发流程的各个环节了如指掌，做到三问不问，或者根本不深思熟虑。这些极端情况也可以称为“异常流量”。有些异常流量对用户来说可能不是很明显，而有些异常流量会对用户产生很大的影响。因此，当出现这些异常情况时，如何给用户更好的提示和引导，或者引导用户寻求客服帮助等，就显得尤为重要。本文来自公众号【纪晓光】，经授权转载。思考提示开发小哥的角质思维，有点暴力会怎样；开发小哥的羊毛思维，量上去了怎么办；并发思考，如果大家齐心协力会发生什么；就算是测试或者QA工作，发现问题还是要对产品做决定，修改，脱不了干系~技术思维的安全每隔几年，就会有一大片用户隐私信息泄露问题。最近的一个已知是Facebook的隐私泄露事件和国内WIFI万能钥匙。至于之前的门系列，虽然也是用户隐私，但是跟网络关系不大，主要是为了电脑维修。还有“开房信息泄露”的案例，是因为遭到黑客攻击。至于被黑的问题，作为产品人员甚至是普通开发人员，都没有办法应对。只有极其专业的安全团队才能应对。我们这里说的只是安全意识的问题。别说是产品人员，很多工作一两年的开发人员都缺乏安全意识。甚至还有一些不经意的人为信息泄露，根本不是技术问题。比如我们在互联网产品中识别用户，有一个特定的维度，可能是用户的手机号，第三方开放平台提供的openid，淘宝登录名，微信昵称等。那么，当我们在这个识别用户的时候维度，给他们看隐私信息，能不能确定看到信息的人一定是他自己？有没有可能我们的维度没变，但是用户变了？严格来说，除了生物认证和实时实时认证外，几乎不可能确定网络的另一端是谁，甚至很难知道是不是人。所以现在很多互联网产品都有那么多烦人的认证。虽然这个问题无解，还要和真实的用户体验进行权衡，但始终是一个不容忽视的方面。思考自己负责的产品的用户体系和“用户”的定义；考虑你向用户展示的信息被其他人看到的可能性有多大，即使你站在你身后；如果用户有多个账号，能不能达到1+1=3的效果；有没有可能你的系统是直接被机器人或者外挂使用的，无法区分~技术思维的表现很多东西看起来都是技术人员的工作，比如报错，性能，物理这些真的需要吗考虑一个产品？这个问题就看你自己了，你希望你的产品做成多少，能不能用，或者在任何情况下都能做到人性化。如果程序报错，信息一定是方法名、代码位置等有助于定位问题的信息。那么用户需要看到这个吗？用户看到后的体验如何？因此，互联网产品要想做到尽善尽美，就必须考虑到各种情况。当然，不去想也没关系，那么接下来就是在开发、测试、运维同学不断的提问和疑惑中慢慢填坑了。以电商抢购活动为例。理想情况下，系统容量是无限的，大家随便抢，系统是不会挂的。但现实是硬件资源和网络带宽是有限的。即使我能估计出真实用户的数量，也无法估计出羊毛党的数量。一旦某个活动有利可图，转发给几个羊毛团，分分钟被刷光。那么在这样的现实中，如何才能保证对大多数用户尽可能的公平，系统不会很快挂掉呢？这是产品和技术要共同解决的问题。比如很多抢购活动引入的排队机制，或者提前发放的资格代码。这些需求在某种程度上是由于客观条件的限制而引入的产品特性，从而迫使产品人员修改流程和接口交互。那么在你负责的产品中，有没有因为性能或者其他方面的限制，有什么“特色”？思维提示，产品的作用是没有极限的，多了解一点也无妨；互联网产品在某个环节或阶段会出现性能瓶颈，可能会产生意想不到的需求特性；从脑海中的一个想法到最终用户的使用产品经理有责任关注口碑；在很多客观条件的制约下，没有所谓的绝对公平，一定是通过一些技术手段来“维持秩序”~技术思维的隐性消费所谓隐性消费，当然就是不太明显的消费。那么对于产品人员来说，有什么消费是不容易察觉的呢？最常见的是硬件资源和带宽的消耗。比如一些有视频的活动，如果出现爆发式增长，可能会很快烧掉云服务账户中的余额。如果公司有经验丰富的运维人员，可以请运维同学在同类产品上线前预估一下流量和成本，以免一不小心超出预算。同样，一些公司购买的带宽是按峰值计费的，所以很容易出现意外。服务器暂时处理不了，紧急情况下加机器也是可以的。最坏的情况是短时间内无法为用户提供服务。其实一般情况下，产品人员不需要考虑这些，技术人员和IT人员就可以搞定。只有一些特殊的产品和活动需要考虑这些预算。还有一种情况，作为一个有自己开发团队的公司，遇到任何需求第一反应就是自己的开发能不能做。如果需求不是特别复杂，一般都会给出“可以做”的回答。但有的时候，如果把同样能满足需求的东西，以外包的形式交给外部团队，成本可能会低很多。为什么是这样？我们的发展就这么受挫吗？当然不是！如果一个需求全部从头开始，那么可以说很多公司的开发无论是速度还是质量都是值得信赖的。但是，当有成熟的解决方案、有活动的模板，甚至不需要修改的现成代码时，成本就完全不同了。毕竟艺术行业有专攻，专攻活动的人积累了很多活动；专做游戏的，积累了很多小游戏；这些东西对于很多外包公司来说甚至是零成本复制的，就看他们想从你身上赚多少了~当然，外购也有比较麻烦的地方，比如公司的资质门槛，财务流程等等，开发小哥直接提供需求肯定方便。但是如果整个项目的成本和KPI都比较清楚，并且查过有类似的外部团队可以满足需求的话，不妨对比一下成本和效率。开发小哥的工资也很贵~思考Tips重点项目要考虑技术方面可能花钱的地方；开发说“能做”只是说明了可行性，效率和时间需要重新评估；有时候外购的成熟方案效率更高~技术思维变化的联想我们在规划新的产品功能时，往往会涉及到对原有系统的改动。由于原系统可能不是我负责的产品，所以即使我已经和对应的产品沟通过，也未必考虑周全。这些只是表面的功能变化，更大的坑还在。在后面。不管是从设计到产品，还是从前端到后端，我都希望有很多所谓的“模块化”的东西，最好像PS一样贴出来用。对于相同或差异不大的功能，模块化很好。然而，在漫长的需求迭代历史中，同一个模块总会有大大小小的变体，以及与使用该模块的各个系统有着千丝万缕的联系。此时，如果你的需求触及这些所谓的“公共模块”，麻烦就来了。其他使用模块的系统是否需要一起更改，是否需要同时更新，或者保持原样？原始模块是另一个副本还是与原始模块兼容？在技??术架构上，想一起改就很难一起改，不想一起改就想改哪个就改哪个。这两点之间只能不断的取舍和妥协，没有完美的解决方案。因此，我们在寻求通用逻辑和修订迭代方便的同时，也需要考虑到日后分道扬镳时难解难分的纠葛。思路提示只要你的需求修改了，在技术方面可能会牵一发而动全身；模块化不一定是好事，只有当这些产品模块的功能比较一致时才有用；技术人员一直纠结于优化过度优化和过度优化之间的界限，完全取决于产品的方向~技术思维的问题定位是什么？问题定位也需要产品参与？开发它有什么用？！话虽如此，还是那句话，这就是产品经理素质的体现。如果你什么都不会，没有人会责怪你，但如果你表现出一些技术专长，人们就会对你刮目相看。举个简单的例子，以前经常有同事截图说页面乱了。而且我看完之后，经常会直接回复“ctrl+0”。那么，为什么当事人自己看不到问题呢？连中间转发的那几个人都看不到？这里有两个技术要点：第一，chrome浏览器ctrl+滚轮会缩放页面，放大比例会保存当前页面的设置，再次打开页面还是上次的缩放比例；第二，无论你的屏幕截图在你的显示器上看起来是大是小。转发给我后，实际像素应该和我打开的页面一样。如果页面没有放大，你截图的部分和我浏览器中对应的部分应该是一样的。如果大小不一致，就说明一定有缩放。那么这种简单的问题定位根本不需要问开发者，你可以问：如果规模化了会不会乱？结合上面提到的角色分工，目前大部分主流公司都是采用前后端分离的架构，所以页面出现问题往往可以先找到前端。那么，除了这种表面上的区分找前端还是后端，是不是可以做点别的？当然。最简单的方法就是先横向确认一下，你这里有问题，其他人是不是也有问题。WIFI有问题，网线也有问题。等等。这些基本判断也是开发者的定位思路。先大致确定问题的范围，你会发现很多时候问题往往发生在自己身上。开发者也会犯类似的错误，弄了半天才发现竟然是这么低级的错误。因此，当您可以尝试自己发现低级错误时，您就进入了开发人员的大脑回路。思维提示初步判断和准确的问题描述对定位问题很有帮助；横向比较，然后看看在遇到问题之前做了哪些“不寻常的事情”；如果确定是通病，第一时间丢给开发吧~结语本文大致描述了开发人员在满足需求或遇到问题时，一般会有什么样的“技术思维”。归根结底，技术都是冰冷的代码逻辑，没有任何情绪化和临时杀戮的决定。只有尽可能清楚地考虑所有细节和可能出现的情况，才能开发出健壮和稳定的系统。同样，作为产品经理，你的产品能够为用户提供稳健稳定的服务，也是产品成功的体现。既然如此，就必须调查各方面的技术问题。因此，一个优秀的产品经理必须熟悉每个角色的分工，熟悉每个角色的性格和思维方式，才能让每个角色无障碍地分工合作，从而生产出优秀的互联网产品。.了解技术专家的思维方式可能是一个好的开始。本文来自公众号【纪晓光】，经授权转载。
