那些年我走过的弯路之——一蹴而就
很多产品经理平时工作都非常努力，但产出效率却并不高，导致产品经理工作事倍功半，产出效率低的原因有很多，其中之一是完美主义，这一点在之前的文章《为什么说完美主义的产品理念背后有个天坑》中已经做过详细的分析，今天再给大家分享另外一个影响产品经理工作效率的大敌：一蹴而就。
火山算不上一位聪明的产品经理，但的确是一名非常勤奋的产品经理。在创业公司那几年，在公司里算是典型的劳模。记得当时我们CEO经常挂在嘴边的一句话，要论敬业程度，在公司里如果说火山排名第二，没人敢说第一。每当老板这么说起时，我内心都会泛起一丝隐隐地自豪感。现在想想，自己当初做过的很多项目，其实都是处于事倍功半的状态，投入了很多的时间和精力，但实际的产出效率并不高。接下来给大家分享一个真实的项目案例——一个我初做产品时曾经犯过的低级错误。
我们公司做的是一款基于商旅出行预定的企业商旅管理产品，差不多2年前，火山接到了这样一个需求：
需求描述：为我们机票产品增加一个审批的功能，保证企业员工的每一次差旅出行都在经过领导审批之后再进行，让公司的差旅支出更加可控。
审批，这是一个企业级的管理软件中非常常见的一个功能，我们不妨先暂停一下，假设你是接到这个需求的产品经理，你将怎样完成这个项目？
思考1分钟，计时开始……
想必现在你已经有一个大概的思路，那么，火山是怎样做这个项目的呢？这个需求其实在我刚开始接手产品的时候就一直在提，但是由于种种原因就一直没做。在正式启动项目之前，我跟我当时的领导简单描述了一下我的想法：
审批有两种做法，即：行前审批和出票审批，前者是出行前先生成一张审批单，审批通过之后再订票；后者是在订票的时候生成一张审批单，领导审批通过之后再出票……
如此云云之后，我给领导的建议是以“事前审批单”的方式来做这个审批项目。我的领导当时刚空降到我们公司，大约40来岁，是一个智商奇高同时也比较自负的人，有比较强的技术背景，但没做过产品，之前从事的并不是这个行业，在大致在听了我的思路之后，表示这个需求并不复杂，很简单的，你按照你的想法去做就好了。
由于客户、销售、运营、老板各种场合提了很多次，大致的需求我也都了解，所以我也就没再做需求调研，我直接按照事前审批单的方式上手开始做这个项目。先是花了2天的时间梳理业务流程，然后是花了差不多3个星期的时间画网站原型，在这中间跟我们开发经理简单沟通过一些技术方案。在包含了无数交互动画的网站原型画完之后，我还是觉得不够出彩，为了在我的新领导面前表现一下，我又花了1个星期把详细的PRD写了出来，试图一蹴而就，把交付给领导检验的项目成果做得更漂亮一点。
终于，一个月之后，到了给领导交付成果的时候了。我叫上了我的领导，召集业务需求方、开发经理一起，开始了第一轮需求评审。首先评审的内容是流程，我打开我的visio，开始讲解我的流程：“当用户选择好一个航班，点击“预定”的时候，系统按照用户所选的行程，生成一张审批单……”
“审批怎么会是从预定是开始 “我话还没说完，领导直接打断我的话，说道：“审批应该该是从下单时开始才对呀！”
“没有，我的做法不太一样，您先听我把话说完……” 我解释道。
“你不用往下说了，你这种做法肯定是错的！”我领导从座位上站起来，也不正眼看我，拍打着投在墙壁上的投影说。”审批怎么可能是从预定开始的呢，没有这种做法……”
“我的做法跟您的想法不一样！”做了一个月的项目，新领导连讲完的机会都不给我，还在那么多人面前一通骂，让我也有一点情绪激动。“您能不能先听我把话说完，不要一上来就劈头盖脸一通骂……”
“火山，你先别着急，我知道你的意思，你的意思是先做一个审批单，审批通过之后再走后续的预定的流程对吧？那种审批做起来可能比较麻烦一点，但是我们这次只需要做出票审批就可以了。”参会的业务见气氛不太对，一边安抚我的情绪，一边解释道。
“在我印象中，审批应该也是从下单开始的。”半天没有发言的CTO也发言了。
之后，也不知道是因为赌气还是因为被大家说服，我慢慢放弃了争辩，开始闭嘴听大家的想法……不仅没有得到新领导的认可，我也没有得到老领导CTO甚至业务方的认可，对于这样的结果，虽然从感情的角度来说，我的确很难接受，但是从理智的角度来说，我已经逐渐意识到：无论我的方案是否具备可行性，但毫无疑问的是，从一开始我的方向就已经错了，我把自己狠狠地坑了一把，因为这个方向性的错误，导致我辛辛苦苦花了一个月时间做的整个项目方案都得推翻重做！
什么叫事倍功半？这就是活生生、血淋淋的例子！
为什么会有这样的结果?火山在这个项目中犯了那些错？我们不妨再稍作暂停，回想一下，在你的工作过程中是否也有过类似的经历？我的这段可以作为反面教材的经历对你是否有一些启发？
思考1分钟，计时开始……
火山复盘
这个项目做下来，其实火山犯了很多错，例如没有充分地沟通，缺少需求调研等，但如果做项目的方法得当，这些错误实际上都是可以在做项目的过程中得以修正的，但是我并没有修正掉，因为我还犯了另外一个致命的错误——妄图一蹴而就！
一开始，领导可能并没有给出明确的方向，而我没有跟领导寻求明确的指示，这可以说我在沟通上犯了明显的错误。但是如果我没有妄图一蹴而就，在绘制完流程图之后把流程图给领导看一看，请示一下，领导可能在项目一开始就已经给我把问题点指出，那么，我后面花了一个月时间完成的产品方案，也就不必推翻重做了。即便流程没有能够第一时间确认，但是如果我在画完原型图时不妄图一蹴而就，先跟领导请示一下，那么我就不用浪费那么多时间为一个错误的产品方案撰写那么详细的PRD文档了。如果一开始就纠正了方向，由于做法更简单，或许我的项目早都可以结项了。
现在再回过头去看我刚开始做产品那段经历，这样的低级错误我似乎犯过不止一次。有时是因为希望希望能给人眼前一亮的感觉，也有时是因为想要偷懒而省去需求评审，还有时因为自认为简单就不需要沟通，我时常都抱着这样一种一蹴而就的做事方式，说到底无外乎是为了省一些中间环节的沟通时间，殊不知看似相仿的产品功能，产品设计的方式方法可能变化万千，很多优秀产品都不是生来就在一个正确的轨道上的，而是在设计的过程中根据多方讯息和实际情况逐步修正而成的，也没有哪个项目是产品经理可以一气呵成而不需要任何调整的。正所谓与“欲速则不达”，为了省一点沟通的时间而采取一蹴而就的做事方式，往往适得其反，不但时间不会花得更少，反而可能会花2倍、3倍甚至更多的时间。
做得慢，我们还可以通过勤加练习提高工作效率，但是如果方向做错了，做得越多也就意味着错的越多，相应的返工的成本也就越高。没有什么比推翻重来更影响产品经理工作效率的了。小项目可能影响不大，但是对于比较大的项目，因为如果一开始选择的方向就错了，那影响就难以估量了。所以，现在你明白为什么说一蹴而就是影响产品经理工作效率的大敌了吧。
那么，我们产品经理在做项目的过程当中，该如何避免出现类似的错误，把这种风险降到最低呢？作为一名在这方面给自己挖坑过大坑的过来人，我的建议是：遵循产品设计的必要流程。对于比较大的项目，除了前期充分的需求调研之外，在做项目的过程当中，在一些关键性地节点上，还需要与关键的需求负责人保持密切的沟通，要尽可能及早的发现并修正方向性的问题，具体的操作细节总结起来就是：
需求调研阶段——深入调研并确定项目范围
项目启动阶段——与业务需求方、技术负责人、关键领导人一起确认主体业务流程
产品设计阶段——与业务方展开2-3轮需求评审，确定网站原型
提交开发阶段——与开发、测试进行PRD评审，确认功能细节
创业公司大多主张快速响应，简化流程乃至于没有流程的。但是时间长了，团队规模扩大了，做的项目多了，慢慢地我开始体会到流程的重要性了。
关于产品设计有哪些流程，特别是创业公司需要哪些必要的产品设计流程，我也是颇有心得的，关于这一点，我会在后续的推文中做专门的分享。感兴趣的小伙伴可以关注我的微信公众号”PM火山”的后续推文，敬请期待。
