产品经理应该怎么做？？

这段时间工作上产生的压力大部分都和产品相关，一方面是产品的设计个人认为存在很大缺陷，另一方面就是伴随着产品而来的项目流程不够完善，或许是因为存在一些无法摆脱的困难。

产品的功能设计，准确地讲应该叫需求设计。产品的需求设计应该是任何一个项目的灵魂，因为最终呈现给用户的不是开发人员使用了如何先进、高级的技术，而是实实在在的一个又一个实用、贴心的功能，这个问题不仅仅在IT行业是这样。建筑行业与IT行业有很多相同的地方，比如盖楼，如果没有前期的设计图纸，想盖一幢坚固、实用、美观的大楼是不可能的，而且如果设计本身就存在缺陷，想盖一幢坚固、实用、美观的大楼也是不可能的。但IT与建筑又不同，那就是需求变更在IT行业是家常便饭，甚至贯穿于整个项目的始终。所以在IT行业，虽不要求在开发之前就100%地确定需求，但至少整个大体框架应该有个定型，包含哪些大的功能块，每个功能块之间的相互关系，本期项目最晚在什么时间截止等等，这些应该是每一期项目都要事先仔细权衡、确定的东西，对以产品设计为主导的公司来说更应该如此。但事实是什么样的呢？

以新版产品的上线为例。09年4月24号收到关于新版产品上线需求的邮件，到09年5月15日上线，一共有13个工作日，需求里面只有3个需要更新的页面。然而，在上线前一天的下午下班之前一个小时，产品经理突然打电话说需求有变动，之前做的两个页面不用了，另一个页面也要稍作修改。也就是说，总计3个页面，有2个取消，剩下的一个还要修改。看似是一个小小的改动，但改动的比例却又近乎是100%。更进一步说，之前10多个工作日，从页面设计，到页面切割制作，再到开发完成，测试完毕，所有相关的工作人员所有的工作成果就在那个电话拨通之前全部作废了。

事情到此还远没结束。接下来，产品经理说剩下的那个页面正在重新设计，但是第二天下午的上线是确定无疑的，所以在上线之前必须要完成所有的工作，而且还是在当天晚上要完成。于是，协商所有与本次更新相关的页面设计人员、页面切割制作人员、开发人员、测试人员，当天晚上回家之前必须完成各自的工作任务。但当开发人员问产品经理什么时候能给拿到页面进行开发的时候，产品经理说不知道，只说了一句“尽快吧”。换句话说，页面在进行设计的时候，制作、开发、测试无事可做，只能等待；制作人员切割页面的时候，开发、测试还是无事可做，还是等待；静态页面完成，进行开发的时候，制作人员还不能离开，因为还要确保套用之后的页面不会出现问题，于是在开发、测试完成之前制作人员无事可做，而此时已经没有时间再让测试人员先测试静态页面然后再转交给开发人员，所以此时测试人员依然无事可做；当测试人员进行测试的时候，制作、开发人员还是在等待，因为随时会有bug产生，有页面的、也有程序的。

假设上面的分析真实地发生了，那么可以看到，整个过程中有多少人的时间被无情地浪费掉了（虽然那不是上班时间）。浪费时间是一方面，由于是加班，大家都在拼命、着急地往前赶，都想早点下班回家。“忙中出乱”，即使不出乱，质量也肯定会大打折扣。产品经理承诺半个小时可以把静态页面交给开发人员，但开发人员心里清楚，1个小时都不一定能有结果。做过静态页面的人应该都知道，看似一个简单的页面，真正要把它切割完毕，还要兼容不同版本的浏览器，兼容老版本的样式，其实是一个非常艰巨的工作，而且又是在这种着急的状况下，别说半个小时、一个小时，有时候半天都不一定能搞定。

上面的分析实际上并没有真实地发生，因为开发人员不愿意等下去，还因为这样的事情不是第一次发生。产品经理这个时候与开发人员之间有一个交流，大概意思就是他希望开发人员能体谅大家的工作，事情闹到这个地步也不是他能掌控的。

而更富有戏剧效果的是，第二天上午开发人员早早地完成了页面的开发，就等着下午进行上线更新了。结果，到了下班时间也没有人通知执行上线更新，产品经理说有可能不上线了，真的是让人哭笑不得，此时开发人员是不是应该暗自庆幸一下头天晚上没有留下来加班呢？

整个事情暴露出了几个问题。第一，新版本上线应该说是一个很重大的事情，无论它是正式版，还是beta版，甚至它是alpha版。不能说上就上，说不上就不上，这不是小朋友在玩过家家，即使外人不知道我们内部到底发生了什么。提前半个月就做了准备，结果在最后时刻功亏一篑。难道说上新版本这个事情就没人能做主吗，还是能做主的人只是头脑发热、拍拍脑袋就做出一个上线的决定，然后再头脑发热、拍拍脑袋就说不上线了？？如果真的是如此，那么这个做主的人真该被拍拍脑袋了！说了就要做到，否则就不要说，至少不会被人瞧不起！

第二，关于更新的需求问题。三个页面的需求从开始产生到上线前一天那么长的时间都没人说要改动，结果都已经完成开发与测试了，才说要发生变更，这个需求到底是怎么做的，半个月之前干什么去了？难道连一个大的框架都不能确定？到底谁可以决定具体的需求？是我们的产品经理，还是我们的“客户”？

第三，从产品，到制作，到开发，再到测试，这样的一个流程谁能做主？产品经理说更新就更新？产品经理起主导作用？难道没有、还是不需要一个具体的规章来约束这样一个工作流程？不管什么时间、什么地点、什么状况，说干什么就干什么？

第四，相互合作、相互理解，并不是盲目地妥协。大家都在强调团队合作，但到底怎样才是合理的合作，到底什么样的团队才可以称之为“团队”？当主要的问题已经不是合作能解决的时候，还拿出相互理解这样的说词，个人觉得这是无知，同时也给自己和别人带来了更多的麻烦，进而让整个“团队”出现裂痕。

 

关于需求设计的另一个问题就是需求文档的撰写。对以需求文档为导向的团队而言，规范、精细、准确的文档无疑对项目的顺利进行起到很重要的作用。而我们的需求文档是个什么样子呢？有的产品经理写文档，只列出一个提纲，而没有详细的描述，甚至同一个概念、同一个功能在多个地方的表述都不一样。在最近的一个项目中，从开发人员拿到文档的那一刻起，文档就一直在修改，直至项目结束，从未停歇过。而把最终的需求文档拿出来一看，至少有一半的需求是开发人员在开发的时候提出来的，基本上都是细节问题。

而这带来的一个问题就是，后期开发过程中因为需求的反复变更而带来的产品经理、测试和开发人员之间进行沟通所增加的时间，比初期产品经理写一份内容详尽的需求文档所花的时间更多，甚至是成倍的增长，而且相关沟通人员越多，这个时间就越多。而我们每一个项目的时间都卡得很死，时间很短，这势必又引出另一个问题，就是整体质量上不去，表面上看似功能实现了，但有很多隐患都无法预估，甚至连测试人员也都测不出来，因为开发延后，他们的时间也相应地缩短。所以，问题有时候都是一环套一环的。

举一个比较有意思的例子。有一次，测试人员提出了一个问题，于是提交给产品经理，产品经理说马上更新到文档里，并向开发人员打了招呼。开发人员查看了TFS里面需求文档的状态，已经被那个产品经理“签出”。但是，在随后的半个月时间里，开发人员多次查看了需求文档，但需求文档的状态一直是“签出”，一直是那个项目经理，试问这是什么样的工作状态呢，什么样的工作态度呢？？

上面所说的是需求问题，下面再说说产品经理的专业能力。产品经理，我认为应该是宁缺毋滥，不能因为缺人手，什么水平的都招进来充数，其实任何职位都应该是这样。而到了产品设计这个职位上，更应该严格把好关，因为上面已经说了这个职位所做的工作是灵魂，起到了决定大方向的作用。花1000块可以请一个便宜的产品经理，那么请5个产品经理，开销是5000，但他们5个人因为经验的不足设计出来的产品有很多毛病，还不如花5000块请一个真正经验丰富的产品经理，别说是5000，10000都值得。我想这么简单的道理大家都是明白的。

开发过程中，我遇到最多的一个问题就是“用户体验”。关于这个词，我是在参加工作后不久才认识到的，实际上这个话题已经是个几十年的老话题了。虽然我对什么是好的用户体验无法给出一个答案，但是我从产品经理那里得到的所谓的“用户体验”完全超出了我作为一个用户所能接受的程度。有的产品经理或许就是比别人多用过一些网站，就忽悠别人声称自己深刻把握了用户体验，而实际上他连真正的互联网是什么都还没搞清楚。有的产品经理设计出来的功能根本就是东拼西凑，完全没有自己的东西，看这个网站这个功能挺好，就吸收进来了。但他只看到了这个功能的表面，而为什么需要这个功能，这个功能到底好在哪里，吸收进来对我们的帮助有多大，吸收进来之后是照搬原样还是加以改造，他根本不知道，甚至都不去想。结果就是，他设计出来的东西是个四不像，可以看到很多网站的影子，而且综合出来的东西完全失去了用户体验，非常不好用。抄袭本来就是一件很龌龊的事情，虽然从某个角度来说，“抄袭”也可以学到点东西，但是盲目地抄袭绝对设计不出好产品。再退一万步讲，就算是抄袭，起码也要抄出个样子，能汇百家之长为己所用，用对了、用好了，那也算是功德一件，也算是有能耐，如果连抄都不会，就更不配做一个产品经理。

举一个最简单的例子，html标签里面有一个label元素，它有一个for属性，我想很多搞Web开发的人都知道这个属性的作用。开发人员把这个功能做进去了，结果产品经理说不需要这个功能。就算产品经理不懂技术，不懂html，不知道label标签，不知道它有个for属性，也不知道这个for属性的用途，那么这个属性所表现出来的应用效果他总应该知道吧，如果连这个东西都没见过，他有什么资格来谈用户体验呢？？这个问题最初是由测试人员发现的，然后通知了产品经理，开发人员向测试人员解释了这个问题，但测试人员没理解，本来也打算向产品经理解释的，但是之前已经碰到很多这类问题，解释也是枉然。所以，这个功能最后就去掉了。说实话，去掉这样一个功能对开发人员没什么工作量，甚至这个工作量都不值一提，但是它对开发人员的积极性的挫伤却是巨大的，因为有可能导致开发人员以后只开发需求文档写明的内容，而不会吃饱了撑的多管闲事，去做那些吃力不讨好的事情。而如果一个开发人员无法发挥他的能动性、他的创造力，那他的工作就和农民工一样没什么差别（俗称“代码工人”），区别就是一个在室外劳动，一个在室内劳动，而且都是体力劳动。

上述问题还引出了另一个问题，那就是产品经理不仅仅是要用过很多网站，作为互联网行业的产品经理，还要知道一些最基础的技术常识，比如上面所说的html常识。不仅仅是产品经理，还有测试人员也需要去掌握。掌握这些知识，不仅仅是为了提高自己的工作能力，同时也有助于产品经理、测试人员和开发人员之间更好地进行沟通交流，从而提高整个团队的工作效率。而具体到如何去学，我想就是每个人自己的事情了，当然开发人员可以对他们的成长起到一定的帮助作用。我们常说程序员需要不停地学习，一天不学就会落后，其它职位又何尝不是这样呢？

“细节决定成败”，这句话我们经常听说，也算是名言警句了，我们的团队能走多远，能做出多好的产品，看看这些产品经理就知道了。

还有，我为什么要把需求看得这么重要，个人还有一个想法，那就是凡是产品经理提出来的需求，不出意外，开发人员都可以做得出来，也就是说技术上的局限性不是特别大，最多就是不同水平的开发人员实现起来的优雅程度不一样，所用方法的好坏不一样，性能的高低不一样，而这些对于最终用户来说差别不是特别明显，甚至他们都体会不到。相反，产品设计得好不好，用起来是否方便，最终用户有着决定权。还是那句话，需求设计是灵魂！

 

         说完了需求设计本身，再说说需求的审核问题。我不知道我们的需求文档是否有审核这道关，如果没有，那就意味着每一个项目都由一到两名产品经理负责，他们写完文档就提交给开发。如上所说，我们的产品经理本身就存在很多问题，如果没有审核，他们会把自身的问题传递给随后的开发人员。如果有审核，那我们的审核程序到底都审核了什么，是不是只是看看大框架没问题就OK了？总之，有没有审核我不知道，但是到了开发人员这里出了问题的确是实实在在的。

         为什么要说审核？对于我们的产品经理来说，他们还没达到大拿的那个级别，他们设计的产品有缺陷，不能把带着缺陷的产品交给用户使用。所以，设计的功能是否有必要，是否照顾了用户的使用习惯，用户体验性好不好，与之前老版本的兼容程度有多大，这些功能在项目结束的时间点能否做完，这些问题都要仔细掂量、认真考虑、有所取舍。如果招不到经验丰富的产品经理，那么可以集众人的智慧，通过多个产品经理的讨论、交流设计出一个产品。同时，开发人员的建议与意见也很重要，因为开发人员有着很多产品设计人员不具备的能力与洞察力。于是，这么多人来设计一个产品，就需要一个有决策权的人物，他可以从众人的建议中筛选出有用的信息并加以整合，最后作出一个决定。而这个时候的结果即使不能令所有人满意，但至少它是一个经过慎重考虑的结果，而不是草率的决定。

 

接下来是页面UI设计与静态页面的制作。这一块对开发人员来说基本没有什么压力，即使是页面制作人员与开发人员会有直接的沟通，但到目前为止也没有出现过什么大问题。但在与UI设计人员和制作人员交流的时候发现，他们其实也很累，也经常被压得喘不过气来，其中最重要的一个原因就是时间紧，而时间就是下面我想说的另一个问题。

 

我们现在经常是时间走在项目之前，不管什么项目，先定死一个时间，然后再对项目进行具体安排。而且很多情况下都是时间紧，项目工作量极大，这或许也是我们为什么疯狂招人的原因。看似招人可以解决问题，但实际上这只是一个假象。因为随着人员的增加，沟通成本会成倍增加，再加上不同人员之间水平的差距，这个成本还会更大。由此又会产生之前说过的问题，表面上功能完成了，如期上线了，但又是以牺牲产品的质量为代价。我觉得这是一个很大的问题，为什么不是根据项目的大小来定结束时间？看看大家最近的状态，每个人都承受着巨大的压力，经常加班，都在抱怨，而加班并不是工作能力问题，而是时间太少。难道只有这么去做项目，才能体现员工对公司忠诚，才能说明员工有责任感？非要等到累死个人状况才能有所改观吗？一个不关心员工的公司不值得员工为之卖命。

而因为时间紧，产品质量不高，就势必在产品发布之后不停地做优化。就以最近的一个项目为例，半年来，这个产品已经更新到了第三个版本了，而且每次都是改头换面，我还从来没见过一个好的网站在如此短的时间内进行如此频繁的改动，用户会怎么想？这个月刚适应这个操作，下个月就变样子了？甚至有时候明知道产品有缺陷，还硬要推出去，理由是上线之后再慢慢优化。这是做事情的正确态度吗？这叫为用户着想吗？我看是为自己的绩效考核增添砝码吧！！

 

产品经理经常说这样一句话：“这也不是我能决定的”。那我就要问“谁能做主？”这么大的一个公司难道没有人能做主？说到底我们就是一个做项目的公司，可能很多时候很多事情也的确由不得我们，但是我想问公司真的努力去为自己争取了吗？为自己的员工争取了吗？一个公司能在多大程度上掌握自己的命运，将决定着这个公司能走多远！

接下来是有效沟通的问题，就举一个座位安排的例子吧。到目前为止，我对全公司的组织结构安排还不是很清楚，或许是因为人太多了吧，而且有的部门与本部门工作没有交集，更无法去了解。和本部门同在一层楼的兄弟部门我不知道是做什么的，但可以肯定的是，他们和我们的交流基本没有，而和我们交流频繁的产品部门却被安排在了其它楼层。虽然公司为每人配置了电话机，也的确方便了沟通，但是这种方式始终没有面对面的交流效率高。所以，现在的情况是，需要面对面交流的时候，都是产品部门的同事爬两层楼到我们这一层。另一个问题是，有的时候本来应该找产品部门解决的，因为要打电话，于是有的开发人员觉得麻烦就不找了。

和网站相关的还有一个问题，就是网站的内容。一直都觉得咱们现在的内容与我们的产品本身所具有的价值不相符，内容太低俗。

关于产品，有的开发人员开玩笑说，要转行，去做产品，这样可以去折磨人，至少比被人折磨要好。可见，产品对开发人员的打击有多大！

 

最后一个问题是关于我们这个开发团队最近发生的一些变化。随着整个公司最近在人员规模上的急速膨胀，我们部门的人员也在增加。新人进来了，都还没来得及交流，就投入了紧张的工作中。而在之前项目中执行的规范、流程等等“繁文缛节”好像也逐渐地被遗忘，定期培训与交流也没有了，再加上工作忙，压力大，整个团队给人的感觉是没有生气，士气低落。

 

以上说的这些抱怨，并不是要针对某个人，毕竟人无完人，我也不会认为自己就比别人更NB。之所以要说出来，原因只有一个，我希望我们整个团队能成长起来，能做出好的产品，能让我们每个人在每个项目结束的时候，虽然很累，但还是能会心一笑，对程序员来说，那是一种收获，是一种幸福，这样就对得起自己了！

就写这么多吧，这些纯粹是发牢骚，就当是把心事说出来了，至少这样心里会好受一些！