转载

产品经理的技术修养

晚饭的时候听妻子说他哥（也就是我大舅子）从产品岗转到了技术岗，打算持续两年左右，目的是为了更进一步的了解技术从而能更好的与程序员沟通。我就想，产品真的需要以这种方式才能与程序员和谐共处吗？恐怕这是徒劳的，我没法忍受一个对我写的程序指手画脚的产品经理。我合作过很多产品经理，其中不乏佼佼者，但这些优秀的产品经理从未跟我讲过我要怎么写程序才能符合他的需求；而且我合作过的产品里，甚至有一位我把他看作我的导师，带我突破了技术生涯的第一次瓶颈，从一个新的角度来观察产品实现。

如无必要，勿增实体。

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

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

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

产品经理的技术修养

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

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

产品经理的技术修养

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

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

按关键词查询到结果
选择 A 分类的选项后筛选结果，A 分类不再根据结果重新计算，A 分类外的需要根据结果重新计算
选择 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 上描述好了的，一对一、一对多、多对多这些关系就在那里，它是静态的，与外面能看到的东西是相映射的。

我没有书可以推荐，因为我也没有买过，而这个经验就是一位产品经理曾经教给我的，在那之前我了解 ERM、UML，但从来没有重视过。

5. 与敏捷共舞

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

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

好吧，别跑题了，说回来。产品经理好歹有个 Manager 的头衔，虽然很多产品经理自嘲自己就是个光杆司令，我们来讲点经理该干的活。

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

个体和交互胜过过程和工具；
可以工作的软件胜过面面俱到的文档；
客户合作胜过合同谈判；
响应变化胜过遵循计划；
虽然右项也有价值，但是我们认为左项具有更大的价值。

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

需要注意，上面说希望程序员像特种兵一样主动出击，但从团体来讲，平常的表现更像海盗、海员，精力旺盛而又神经脆弱，要有活干，有新活干，有挑战性的活干，留够 10%~20% 的连续的自由时间、思考空间，这也许会给您的公司带来意想不到的效果。

6. 来扯个蛋蛋

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

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

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

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

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

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

原文 https://segmentfault.com/a/1190000008045547

正文到此结束