都写到（三）了，你还没看过（一）和（二）吗？别发愣了，赶紧看看去啊。

技术篇

1、技术评估在先

在企业中，产品经理一直被灌输：想好了再找技术，别动不动先让技术实现。

我承认作为一个技术，我觉得这太好了。简直了。

究其原因，不是技术不愿意帮忙，被忽悠太多次。

“有跟你废话这功夫，我作出来给你看！”这是开发的典型的症状：跟非技术人员说一分钟话，他都觉得浪费了生命，盯着黑乎乎的屏幕看别人直播写代码看4个小时，还能嘿嘿傻笑。

不过话得这么说。你是一个“烂产品经理”吗？如果你甘愿做一个“烂产品经理”，只会把“领导”的需求画成图，然后甩给技术，那你还是“先都想好了再和技术聊吧”。

如果你不是，或者你现在是“画图机”，但是以后不想了，我建议：

在你稍微想明白一点儿事儿的时候，就赶紧找技术评估。

这句话里面有几个要点：

第一，什么叫：“你”，这里的“你”可不是你一个人，在你找技术以前至少要和两拨人聊聊你的想法：运营和销售。

和他们说说你的产品，如果运营的人说“这个主意看着好，但是我这里没办法支持”，就说明你的产品脱离了公司能承受的范围，在你公司不适用；如果销售说“这个我卖不出去”，我一直崇尚的销售应该是“狗屎都能卖出去”，连“狗屎都能卖出去”的销售对你这个产品还是卖出不去，那就不是他的问题了，你得自己想想。

第二，什么叫：“一点儿事”，这里说的一点儿事可不真的是“一点儿”，你至少得有理有据的列举出这些：

产品的一句话说明：不论你用“电梯演讲”方式还是“产品包装盒”方式，你得能让人一下知道你要做的是个啥？记得遵循“自己花10分钟都解释不清的东西，就别指望用户会用”的原则；

产品的用户群体：做一个Persona，编一段用户自传。然后先看看身边没有这样的人。注意，别把自己当成“人”。我原来团队中有一个做UX的闺女，Persona设计出来以后，我问她：“你身边有这样的人么？我身边反正没有” 。 她翻个白眼马上怼我：“我呀，我就是这样人啊，我就是你身边这样的人呀“。后来我学聪明了，给这个问题加了个前提条件：不算你！

用户使用场景和体验地图：没有场景的Persona都是瞎扯蛋，Persona只有放在场景中才能鲜活，而”放在场景中“这五个字，就是用户体验地图。用户体验地图不必做的那么详细，说大的Happy Path就可以了。

大用户故事：有了体验地图以后，再写几个主要的大用户故事。毕竟你找开发确认的事情就是”能不能做？“，万一这个二货反问你：”你都没说你让我做什么，我怎么说的出能不能做？“，你不能让他问住，对不对。那时候你就可以拿出这一摞用户故事冲他努努嘴。

第三：什么叫：“想明白”，就是说，

基本的逻辑应该不矛盾，你的用户场景和体验地图给用户带来的价值和你一句话描述中的应该一样。比如你在电梯演讲中说：产品带给用户的价值是”学到了新的知识“，结果体验地图都是”用户玩的特别上瘾“，那二货开发必然翻着白眼怼你”这都什么破玩意“。

完成了上面三点，就可以找技术评估了，评估得时候，千万不要问：这个几天能做完？那估计又得遭二货们的白眼了。这还算轻的，遇到较真的，你可能一周以后才得到答案，然后你还不能改了，因为他们已经付出劳动了。

其实在这个阶段，你只要知道”难不难“就行，对吧。你就可以直接问“难不难”，可能会得到下面几个答案：

容易，弹指一挥间：指随便一天、半天就完事；

还行，简单：指至少1，2天能完事；

应该可以做吧：指这得差不多1周；

你得给详细点儿，现在不知道难不难：指他也不知道，以前没做过；

你的团队对于这四个答案对应的时间可能和我说不一样，多看看以前的项目或者和这帮二货做几个项目，就知道他们嘴里的“应该可以做吧”是几天了。

2、不要对没有实际经验的框架纠结选型

技术选型严格的说跟产品经理没关系，一般开发讨论的时候也不会叫上你，不过万一他们叫你旁听，你最好听听，你或许能出其不意地让他们对你刮目相看。

怎么做呢？

如果你发现两个技术人员对于框架的选型有不同的意见，并且谁也说不服谁。你可以插一句嘴：你俩说的这两个框架你们过去都用它做过项目么？

如果一个回答：没有。或者，虽然没用过，但是我对特别熟。

那你就可以直接挺另一个开发。除非另一个开发也没用过他说的那个框架。

如果两个框架都被使用过，你可以让他们分别讲讲在哪个场景，哪个项目用过，然后你判断哪个场景更像你的这个，就挺他。

你看，你不用特别懂技术，是不是也有参与感？

3、一定要有上线清单

产品做完了，该上线了，尤其是第一次上线，或者是“改版性质的大版本上线”，你要是遇到“贼大胆”，没有清单就敢弄生产环境，你得善意提醒一下。

什么叫“上线清单”，就是一步一步写明白了上线都干什么。这个清单是“傻瓜式”的，如果你的开发团队让你照着清单尝试操作一下，验证一下清单完整不完整，你应该庆幸你遇到了负责任的团队，尽管他们把你当傻子了。

简单的清单就是TO DO说明，类似这样的：

1. 连接服务器：ssh XXX@XXX

2. 拷贝更新包到XXX目录中：scp ... 

3. 检查这个目录里面有没有最新的包：ls /opt/....

...

这可不是例子，你没看错，就是这么详细，每个步骤做什么，什么命令都要写清楚，还要几个人review呢。原因我后面说。

简单的清单一定要配一个失败计划，也就说，不管哪个步骤失败了，就立刻启用这个计划回滚，回到上一个版本。

复杂的上线计划是一个流程图，每一个步骤都有：“成功了怎么样；失败了又怎么样”这样的分支，操作的时候完全按照这个执行。

为什么非要有个上线清单，而且这么傻瓜呢？两点：

第一、人，在意外的情况下，和驼鹿是一样：先发愣然后瞎跑。

你要是在加拿大凌晨5点，天还不亮的时候开车，就可能在路上遇到牛一样壮的驼鹿，它们看到你亮着车灯过来，一定会停在路中间盯着，直到你撞上它，跟它同归于尽，你要是侥幸打轮想避开，那就得看这个家伙机灵不机灵，它要是不机灵你就能躲开，他要是机灵，你完了：不知道它会向前窜还是向后躲，你仍然只有50%的机率躲过它。

上线的时候，开发人员和驼鹿差不多，只要出一点儿事，一定是先发愣，然后失去理性思维，胡乱操作一气。

很多年前的满座网上线事故我至今记忆尤新：

半夜2点，我和几个“留守技术”在上线，已经开始。。。

忽然我接到CEO电话：“我X，网站上不去了！赶紧看看。”

我马上跟开发说：“咱不是平滑上线么？怎么会访问不到”？开发就愣住了，回答我：“对啊，不应该啊”。

然后就开始找问题，找了2分钟，在我看来就跟过了2年一样漫长，我问：“找到了吗？要不回滚吧”。。。

然后就手忙脚乱的回滚，回滚了一半，忽然想起来，这次的修改涉及到数据库的结构变化，回滚了以后数据保存不了。

然后就开始匆忙的回滚数据库，结果鬼使神差的把读写分离中的“读库”修改了，导致数据库同步失败。

最快的办法是删除读库，重新配置读写分离然后恢复同步。就开始删库，然后就不留神把主库删了。。。

后来复盘的时候发现，最初是因为一台服务器只拷贝了更新，没有重启服务，导致服务不可用。一行命令就好的事，但是一步错，步步错。

第二、开发都有一个毛病：好奇心强，不论出了多大事，一定是抑制不住的想找原因。那儿网站都down机了，这儿还一行一行看代码研究呢。

所以，上线清单的好处显而易见吧。上线的时候，人就是机器，完全按照步骤。（后来用CD了，这些事情真的机器干了，人就不用当机器了。）

写完这一篇，《产品经理应该知道的这点儿事》就都写完了，不知道你觉得怎么样呢？在评论中也给点儿反馈呗。