技术

产品经理到底要不要懂技术？

这是一个经久不衰的问题，因为在研发生产过程中，产品经理要经常和技术人员讨论细节，如果完全不懂技术，似乎很难沟通。所以，这本质上是一个沟通的问题，标题中的“技术”换成“设计”、“运营”、“市场”等也是适用的。
第一，底线是可以和技术人员无障碍沟通，并不要求你会写代码。具体点说，技术人员可以直接用平时和同伴说话的方式与你交流，而不用刻意翻译。如果对话过程中经常出现听不懂甚至解释了还是不明白这类情况，很容易让彼此间失去信任，直至没法沟通。当然，和高水准的技术人员配合，会轻松很多，他们更会换位思考，尽量用通俗一点的语言进行沟通。此外，良好的沟通能力和理解能力，也可以弥补专业知识的不足。
第二，多向技术伙伴请教，自学一些技术知识。如果你懂一些术语或者会说一些“黑话”，让技术人员觉得“你即使不会写代码，但也是懂的”，会拉近彼此的距离，建立一种自己人的信赖感，这在沟通、协作过程中会有很大的帮助。所以，对于技术出身的产品经理，这点确实是天生的优势，但他们要注意的是不要滥用技术，越俎代庖。一方面自身应该把更多的时间精力用在思考产品层面的事情；另一方面也不应挫伤技术人员对产品的“责任感”与“参与感”。
第三，根据所负责的产品，决定要懂哪些技术，懂到什么程度。做技术驱动型的产品，比如Baidu搜索，那必须是特定方向的技术出身，否则很难胜任，而如果你要做一个导购类的App，就相对容易一些。所以，要补哪方面的“技术常识”，最好能先明确将来你要做什么产品，可能碰到哪些技术。
第四，要特别关注技术方案与业务场景的关联。有些技术方案的选择会反过来影响业务，这种情况下产品经理最好能给技术人员提出建议。举几个例子：你要知道iOS的开发分客户端和服务器端，能根据业务需要建议数据更新的方案；你要能想到把一些静态素材做成配置文件以方便修改；你要能给出建议，将经常需要改动的那几个页面做成H5页面。

开发的Secret Toolbox

如果你不被技术人员认可，或者把他们逼得太紧，就容易逼出一系列可怕的大招——开发的Secret Toolbox，下面给大家分享一下。
► Copy&Paste：不假思索地“复用”，满足当前需求就好，不考虑逻辑的可扩展。比如，A和B现在1对1，不考虑将来有可能1对N，即使是业务上已经做出提示。
► Hardcode：写死代码，不用配置文件和变量。当你发现某个参数不妥，想要多改几次试试时，会发现工作量超乎想象，而且怎么改都改不干净。
► Less Testing：减少测试，或者不重视测试。听到一个很搞笑的故事，某位技术同学写完代码做单元测试，第一次没过，百思不得其解，于是再测一次看看，结果过了，再测，又过了。于是，就认为第一次是幻觉。
► Skip Error Handling：不考虑异常情况，直接假设用户都是正常使用（当然，在业务方认可时确实可以这样做）。举一个最简单的例子，输入框没有做安全上限的长度控制，用户可以通过输入过长的内容来直接使网站挂掉。
► Descope：偷摸减需求，只做主流程，不做分支流程。不用举例，真的会有，验收时产品经理发现了还好，但只验收主要场景是发现不了的。
► Less Review：减少设计评审、代码Review等。强技术的确可以少评审，但会动用Secret Toolbox的同学往往并不是很厉害的人。
► No Autotest：不提供测试自动化。工欲善其事，必先利其器，一直不磨刀，整体效率就一直上不去。

测试

【测试是个专业活】
能否开除测试，转而让大众来测，找到一个Bug给100元？（100块够不够、给不给、怎么给。）
0.开发做单元测试和冒烟测试
1.很多Bug其实并不是非黑即白，也许产品就是这么设计的。这些内部的测试知道，但外部的大众不知道，他们用起来觉得不爽，当Bug提了，这钱是给还是不给？
2.专业的测试需要测试用例（Test Case），但常见的测试用例（临界值相关、内存会不会泄漏、特殊字符……专业测试人员分分钟把开发认为没问题的程序挂掉）在大众那里可做不到，TC评审也做不到。大众永远是知其然不知其所以然，所以只能做黑盒测试，没有办法做白盒测试。
3.专业测试提的Bug是分级的（成熟的产品应该有Bug分级标准和规范）。研发流程里有相应规定，几级以上的Bug必须全部close才能发布；开发也会按照级别来确定修复顺序，并不是所有的Bug都需要马上修复。而大众提交上来的Bug，还得额外安排人去做分级Review。
4.专业测试会把Bug指定给特定的开发或产品经理，因为他们知道技术角度的模块划分，以及对应的负责人，只有这样才能方便流程向下执行。而大众提交上来的Bug，还得安排人去做assign to。
5.专业测试懂得用开发明白的语言描述Bug，能说清楚是什么机器、什么系统、什么版本，特别是能说清楚“如何重现”（复现）。而大众提上来的Bug，出错环境不明确，Bug重现不了，急死你。
6.内部经常有针对Bug的讨论，部分Bug可以defer或reject。那么问题来了，谁来牵头组织讨论，以确定Bug状态的流转与控制？可不要指望大众会“跟进”自己提交的Bug。（defer-推迟; 延缓；reject-拒绝；）（遗留处理）
7.如果开发比较牛，能理解大众提的Bug，但改完后谁来确认是否修复，谁来close这个Bug，整体的回归测试谁来做？
8.以上只是狭义的功能测试，还有性能测试、压力测试怎么办？大众没法帮你模拟10万人同时做某个操作。还有，自动化测试谁来做？

设计

设计师的分工，主要有以下四种。
► 交互设计：关注的是产品与用户互动的过程，具体的输出为产品线框图、低保真原型等。
► 视觉设计：更加注重用户界面看上去的美观、好用，具体的输出为视觉稿、高保真原型等。
► 工业设计：主要对应产品里的硬件、实物、包装等的设计。
► 服务设计：更加关注线上、线下的服务流程，以及如何提升用户体验等。
在需求细化的环节中，产品经理和设计师要并行作业，所以两者任务的界限有点模糊。如果用一句话来区分他们，就是产品经理负责结构化思维，设计师负责形象化表达。

运维

发布相关的概念属于运维的范畴。因为有了丰富的云服务，现在互联网业务的运维工作轻松很多。在团队不大时，甚至可以交给开发工程师代劳。
运维工作要负责维护并确保整个服务的高可用性，还要不断优化系统架构、提升部署效率、优化资源利用率以提高整体的ROI（Return on Investment，投资回报率）。目前大规模集群已司空见惯，如何管理好成千上万台服务器上的服务，成为运维工程师面临的最大挑战。
移动互联网的“打包”“发包”，iOS怕审核，Android烦渠道。