产品经理的技术修养

晚饭的时候据说大舅子从产品岗转到了技术岗，目的是为了更进一步的了解技术从而能更好的与程序员沟通。我就想，产品真的须要以这种方式才能与程序员和谐共处吗？哎，我是无法忍受产品经理对我写的程序指手画脚。我合做过不少产品经理，其中不乏佼佼者，但这些优秀的产品经理从未跟我讲过我要怎么写程序才能符合他的需求；并且我合做过的产品里，甚至有一位我把他看做个人导师，带我突破了技术生涯的第一次瓶颈，从一个新的角度来观察产品实现。

如无必要，勿增实体。

1. 不要试图去教程序员如何写程序

就像产品不可能愿意接受技术教他一个产品该如何设计同样，程序员也（更）不肯意别人批评他程序写的不对，甚至本身的同行说这个话都得撩开了键盘敲一仗。至于实习生或刚加入的新人，那有技术经理罩着，还轮不到产品出马。若是发生这样的事，这不是在把一个项目往好的方向带，只会更糟糕，到不可调和的境地。

这种状况有没有，从个人经从来看仍是不少的。大约两年前我接手过一个项目的管理工做，整个团队人心涣散，5个技术杠着3个产品；技术经理也是半路接手，对外压力重重对内没法服众。我记得当时首当其冲的一个需求是对已经存在的数据作一个搜索过滤的功能，操做上相似 LinkedIn，长得就像这样：

上面是搜索框，左侧是更细致的分类筛选。

当时已经上了一个关键词搜索引擎了，可是左侧的筛选功能产品始终不满意，特别是一个细节在用到了各类什么异步请求、分块查询，最终实现仍是不太好：

从第一个图到第二个图，勾选了英国后，地区的全部统计量都没变，而除地区外的条件切换了；若是我再勾选目前就任，则就任板块全部选项和数量（包括没勾选的）都不会变，而地区除已勾选的外根据条件改变……

产品特意写了一个很长的文档来描述这个动做应当如何变化如何查询，没错，他真的写了一个不太严谨伪代码，显然他是懂一些程序判断逻辑和 SQL 的。大体上是：

1. 按关键词查询到结果

2. 选择 A 分类的选项后筛选结果，A 分类再也不根据结果从新计算，A 分类外的须要根据结果从新计算

3. 选择 B 分类的选项后须要记住 A 分类的数量，而后 B 再也不从新计算，计算 A 分类已选以外的选项
   ……

请原谅我没办法回忆清楚那份逻辑，太晦涩太难懂了，要记录和判断各类条件，没等看完就扔了。

在我看来，HTTP 的无状态特性是不太适合这种须要记录各个环节的需求的，既然已经有人实现了，那我能够认为必定存在一个函数 fn1 和 fn2 给定相同条件 x 时能返回我要的 分类统计 和 查询结果，我如今只要实现这个黑盒就能解决这个问题。

分析结果是确实我不须要存放已经计算过的 A 分类、B 分类的结果（排除须要优化运算量的状况），也不用管什么先点后点的顺序，我只须要给出已经选择的选项值便可，好比 url 查询: ?wd=王&area[]=1&area[]=2&work[]=x ，以这个条件我就能获得左侧的分类和统计以及右侧的结果，而整个过程我不须要用到 Session,Cookie 等任何暂存状态的东西。若是你先点 A 再点 B 而后 A、B 已选的条件的统计数量不能改变，这根本就是个现象而不是需求；这个查询对应的 URL 在另外一个新开的不一样的浏览器同一用户打开看到结果和统计值应当一致，他须要这个 URL 来作信息分类推广，这个需求一样只是个现象而已。能够经过现象来检验程序，但不要用现象来约束程序。

事实上，只要在计算数量时排除此分类对应的条件就 OK 了，根本没什么点击顺序，我敢打保票效果一致，就这么简单。你说这效率是否是不高，那把左侧计算和查询分开请求好啦，还不够就再来点缓存啦；但缓存不该当是一个优先考虑的措施，若是把一个程序看做一个洋葱，应当先把里面那个芯弄活了，至于外面的皮（缓存、过滤）多一层少一层能决定它未来活得好很差，不该当决定它此刻的生死。

其实相似这样的搜索筛选逻辑如今处处都是，你能够去 LinkedIn 也能够去京东、淘宝尝试。至于我给咱们公司写的程序，那无法公开也不必，这里我写了个相似功能的代码: SearchHelper，虽是单机也能撑起还凑合的数量，感兴趣的能够看看提提意见。

2. 什么样的文档是恰到好处的文档

文档是产品与其余部门交流的重要工具，下面这幅漫画你们应该都见过（侵删）：

不少事口头是说不明白的，嘴巴上说“记得记得”，过上个把月，照样板着个脸死无对证。

之前在魔都某公司，拼尽力气抗下一个项目，初期只有我和产品两人。每次去见客户都由他牵头，会议纪要却都是客户发，回到公司商量细节，他也历来不记录，我只好每次在白板上尽可能画清楚而后拿手机拍照而后发封邮件请他确认。这个经历实在很糟糕，最后这个项目也成了个人滑铁卢；固然了，错不能全推给人家，我当时也自认为本身够牛B、能作到原型即产品一步到位快速开发快速修改。

产品主要的文档有 BRD、MRD、PRD、原型，前二者通常不用给技术看，但也不能什么都掖着藏着，那是心虚的表现。一个老练的程序员最怕（不喜欢）什么呢？就是你跟他说：“你别管了，老板（客户）就要这样”。还有些产品沉迷于原型、仿真（这里不讨论 UI、UX 等分工），画得很精细，但不外乎仍是在传达一个命令：“照个人来作别问为何”。

其实到我这个年纪还真懒得问“为何”了，老油条了嘛，但你要想你的产品够健壮，想最大限度的挖掘开发人员的能力，颇有必要讲明白这个“为何”，由于————请看下一节。

3. 来，咱们一块儿找不一样（相同）

【侵删】

我女儿很爱玩相似的游戏，在一堆图案里找相同的或不一样的。晚饭时我妻子还问我产品经理跟程序员有什么区别？我想了想指了桌子上两个水壶，一个大的我女儿的，一个小的是她的。产品看到是两个水壶，一个粉色的，上面有卡通图案，有杯盖，里面有内胆；一个红色的，弹簧盖，里面有内胆。而程序员看到的是：

你会说这也过小瞧产品了吧，这个谁不会画。是的，谁都会如此分析，可是根本的地方在于产品感觉不到痛。产品会在一个项目启动时画，会在新需求来时画，画不少不少这样的树叉子，却不多想，若是再来第三个给我这大老爷们用的杯子时，要如何并入这棵树。

假设，这回来了一个搞艺术的客户，他要一个 L 形状的杯子，钱多人嘛傻不傻不知道。尼玛这让人咋搞，老子模具一直都是造圆筒形；产品说那还不简单拿两个圆筒焊到一块儿不就得了；我靠，我这但是全自动化封闭式车间；产品说那你就在末端人工处理一下嘛别跟钱过不去嘛；操，那我外壳、喷漆、包装咋办……

我不懂制造业上面的类比可能不太恰当。不少时候状况就是这样，曾经拍胸脯说“不会变了、你写死吧”，到某天变起来牵一发动全身。

4. 程序 or 数据库

那看来是否是产品就必须深刻前线体察一下军情呢？个人回答是不必且不须要。

若是你真的想了解点技术，从程序入手不如从数据库入手（此观点限于信息系统或类信息系统）。了解一点数据库结构、ERM 知识对产品的底层认知会更完全，由于在信息系统中，全部的程序都是围绕着数据的增删改查来展开的，HTTP 的 REST 规范也是将众多咱们看到各类五花八门的动做规范为 4 类状态转换的。

包括程序员，若是你只纠结于程序逻辑，极可能会“不识庐山真面目”，“只缘身在此山中”。树总归仍是那棵树，只是多了、少了些叶子而已。不少所谓复杂的逻辑不外乎几个 CRUD 互相调用罢了，好比：保存完新闻要联动索引并给运营发条审核消息，获取新闻内容同时要附带做者信息和统计信息以及热门评论；有的可能查询套查询，有的可能要远程调用其余接口。可是其背后，为何能够这样调用、关联，都是 ERM 上描述好了的，一对1、一对多、多对多 这些关系就在那里，它是静态的，与外面能看到的东西是相映射的。

我没有书能够推荐，由于我也没有买过，而这个经验就是一位产品经理曾经教给个人，在那以前我了解 ERM、UML，但历来没有重视过。

5. 与敏捷共舞

有人说程序员跟妓女同样，吃的是青春饭，30 岁之后要想办法转管理。呵呵，这行当是辛苦了点，什么热门什么就更新快，就像如今的前端技术进展得我这个10多年前就从创意到数据通吃的老家伙（别捅、让我慢慢装个 B）都看不懂了。

我以为程序员就要像特种兵（某些服务程序员的程序员除外，他们是后勤保障，也多是火箭军），必须迈开腿，从海底爬过去、从飞机跳下去，到前线去才能打胜仗；留在首长身边当个卷帘大将撑门面？看咱们也有研发部也是科技公司耶——呸、无聊。

好吧，别跑题了，说回来。产品经理好歹有个 Manager 的头衔，虽然不少产品经理自嘲本身就是个光杆司令，咱们来说点经理该干的活。

上面扯了那么多“术”的层面，可融合的“道”在哪呢？项目老是延期、技术叫苦连天，本该是融洽的上下游（注意了不是上下级）关系，咱们的好政委，咋就能闹翻呢？解决之道在“敏捷”，来，大声朗读：

• 个体和交互 赛过 过程和工具；

• 能够工做的软件 赛过 面面俱到的文档；

• 客户合做 赛过 合同谈判；

• 响应变化 赛过 遵循计划；

• 虽然右项也有价值，可是咱们认为左项具备更大的价值。

千万、千万别把第五句给漏了，这很重要、这很重要、这很重要。不要一开始敏捷了，就再不写文档、不作纪要、不记录 QA 了，搞一块白板鬼画符顶多拍个照就完事了。这个意思是说，两边都很重要，若是作获得固然也要作到右边的，只是咱们认为（来不及了）能够适当的放弃右边的一部分，更看重结果而不拘泥于形式；但显然你得视项目大小、时间跨度来考量，哪些右边的措施是必须的，保障项目长期正常运转的。

须要注意，上面说但愿程序员像特种兵同样主动出击，但从团体来说，表现更像海盗，精力旺盛而又神经脆弱，要有活干，有新活干，有挑战性的活干，留够 10%~20% 的连续的自由时间、思考空间，这也许会给您的公司带来意想不到的效果。“敏捷”也不是灵丹妙药，我甚至感受这有点像宗教，光一个小圈子没有外在配合（扩张）是玩不转的。

6. 再来扯个蛋

《旧约》里有个“巴别塔”的故事都听过吧，讲的是起初人类都讲同样的语言因此合做很顺畅，能够构建能通天的巴别塔好去找神聊聊，神怒了神马玩意还吵吵嚷嚷的还让不让好好睡觉了，如是把人类拔散了赶到各地，让人们说不一样的语言用不一样的文字，今后世界吵归吵但吵不到他老人家了。

这个故事放在这里有相通的道理，“人心齐、泰山移”。往大了说产品要跟研发一条心，要和谐不要分裂；往小了说，没有名词解释、组件设计的产品文档都是耍流氓。你都没定义好关键词，开个会鸡同鸭讲扯又扯不清楚；或是没有个组件定义，讲什么都要来一大段，不能把信息压缩，传来传去变了味。

固然我做为一个曾经转产品没转成功的码农，呵呵，此文章写得立场不明，双方都不要骂我好吧。

---

刚想起点再补充下，我这人键盘唠。

上面说到不要随便“教”人写程序，即便你就是程序员也不要这么干，对方不提出须要帮助不要去帮助，而那些解决不了问题还不呼叫支援的只会发愣的程序员让他自生自灭好了。因此我不会主动去“教”咱们的前端程序员如何作，他作得很棒让我眼前一亮，瞎指挥什么呢；一样我不会去指挥咱们的 App 开发，尽管 Java 我会 C 也没忘干净，但那毕竟不是个人领域，不要去装什么大尾巴狼，正确的目标会指引着一切正确的运转。固然了，我不发号施令也不会偷闲躲静，不会中止写程序和实践新技术。

让人们能走到一块儿的是道，不是术。

---

再唠 5 毛钱的。

篇幅有限能力欠费，不少点没能覆盖到。“革命只有分工不一样，没有高低贵贱之分”。产品经理有产品经理该干得活，程序员有程序员该干的活，不存在谁踹了谁饭碗的问题，实际状况中可能存在出了误差领导光骂产品不骂技术的，一是由于产品经理蹲在上游，离得近；二是不少老板不是技术出身，聊不来。

有些软手段可能在某些环境下也不太玩得转，但总要有些东西要坚持的。