几乎每个项目都会时间紧、任务重，在形成快速反映和调整的团队之前一定会出现这样那样的问题。现在的项目几乎都是多工种共同参与才能产出，职责分工、流程因此很容易成为问题，因为时间紧、任务重而产生的问题也会很严重。昨天写了一篇关于超级产品经理的文章，其实今天要写的这个东西也和这个有关。我始终认为，每个角色都有话语权，都不应该成为工具，而项目最终的产出一定是所有人智慧的结晶。而且需要从繁杂的项目管理事务中把产品经理解放出来，让他们回归本质。
最近遇到一种情况，开发团队把开发过程中的反复、出现大量的bug等问题的根源归于需求文档，希望文档写的更详细，更确定。测试团队把bug的反复、新功能缺乏开发工程师自测等问题归于需求文档，希望文档写的更详细，更确定。现在因为还没有法务、客服、BD、市场等等其他部门的同事，因此还没有得到他们的反馈。唯一的欣慰是产品团队和设计师、前端工程师的沟通比较频繁和畅通，因此对方没有提及这个问题。在这个问题上我认为产品经理不是神，需求文档不是银弹，软件工程许多年来的问题通过产品经理解决是不可能的，通过需求文档解决更是不可能的。
对于要求产品经理全程跟踪产品，把握每个细节和过程的意见我很赞同，我认为，产品经理是虚拟团队的领导者，是项目、产品的CEO。还能有谁更清除产品的所有细节？如果产品经理不去全程关注谁回去关注？管理一个产品就要管理它的方方面面，管理它的前世今生。
对于加强流程的建立，加强评审机制的意见我也很赞同，流程很重要，多成员、多角色的项目中流程很重要。每个人的思维和意识都是有局限的，每个人的经验和能力也是有局限的，我们中间的所有人都不是天才，没有人可以完全的独当一面、力挽狂澜。任何产品都需要不同工种同事的讨论、建议甚至是拍砖，这样才能汇聚大家的智慧，帮助产品经理完善产品的细节。
对于细化文档的意见我也很赞同，文档很重要，虽然有很多比文档更重要的东西，但文档还是很重要。我们的每次思考、每次讨论，每次会议、每次变更都要体现在文档上。我们每个人的脑子都会遗忘，俗话说好记性不如烂笔头子说的就是这个道理。通过语言的表达根据时间、表情、语气的不同会产生信息传递的偏差。产品的复杂性决定了需求的复杂性，自身的逻辑性和环境内其他部件之间的关联等内容让我们不得不采用结构化文档的方式来记录。文档在一些时候也可以提高交流的效率，特别是一对多的时候。文档也可以是一个存档式的东西，后续版本的需求变更要依据它，项目成员更替也需要它。
但………………
产品经理不是万能的，应该解放产品经理，现实的情况是产品经理要做很多事情，完全和我之前提到的“超级产品经理”的情况相反。和管理层沟通，领会公司的策略和方向。和用户沟通，满足用户的需求。和各种角色的同事沟通，领导大家一起出力。关注公司内外的资源，做项目管理，保证资源，保证沟通，保证进度，保证结果。靠产品经理一个人大权独揽，什么都干，显然是不行的。我觉得靠谱儿的办法应该是有专职的项目经理，别以为这个时候项目经理会闲得慌，专职的项目经理应该很忙。而产品经理的主要关注点应该回归到产品要满足的需求上面，充分考虑和调研用户的需求，做充分的数据分析和行业观测，保证产品路线协同公司的发展规划。说到底，就是我觉得应该解放产品经理，不让他们兼职做项目经理的事情。
流程对项目本身也会起到负面的影响，互联网上的应用要求快速决策、快速开发、快速响应。要求产品团队及时调整、及时变更、及时应对。要求技术团队做敏捷开发，做快速响应，不断重构。使用快速原型的方式活其他更灵活的方式进行迭代式开发，而不是采用传统的瀑布式的项目开发方式。我希望项目团队中的每个人都是产品经理，每种角色都贯穿于产品的生命线。产品经理只是个“主事儿”的而已，产品经理决定做什么，其他角色决定怎么做。
文档是问题的一部分而不是解决问题的一部分，写文档只占产品经理工作的很小一部分，产品经理更多的工作是在思考和沟通。一个产品从无到有，在产品经理的脑海中逐渐成型，经过和不同角色人员的沟通不断的完善，最终通过撰写的文档体现出来。撰写文档相对简单，占用的人力资源也少。这就像系统设计往往需要较多的时间，具体编码的时间相对较少。
靠产品经理来试图解决软件工程这么多年的问题是不可能的，产品经理撰写的需求文档无法解决项目延期的问题、无法解决软件维护复杂的问题，无法解决成本过高的问题。难道产品经理写个80
页的详细需求文档就可以放假回家了码？产品就可以完美开发了？用户就喜欢了？公司就挣到钱了？其实文字只是沟通方式的一种而已，要充分利用这种沟通方式但也不能过于依赖。产品经理要写多少文档才可以？市场需求文档、产品需求文档，会议纪要，方案，策划，规范，文档文档还是文档！产生更多的文档肯定不能更好的解决问题，达成项目的目标。
我相信写个80页的文档不会有几个人会仔细的看，那么这个文档给谁看？给领导看？给开发工程师看？给设计看？给前端工程师看？给客服看的？给法务看的？给商务看的？给市场看的？他们要看的、能理解的东西一致吗？产品经理写的需求文档能满足所有的需求吗？一定不能满足。这时候就需要短平快的去通过各种方式去沟通，包括文字、图像和语言。
另外就是我一直坚持的一个观念，产品经理的人力资源无法预估！开发可以根据产品需求文档预估，根据页面数、产品复杂程度、安全级别等内容进行人力预估，测试可以以开发时间的一半来预估。但产品经理的工作如何预估？答案是没有人可以预估。但现实是领导总会对产品经理的人力资源做预估，或者产品经理迫于某些压力自己做人力资源的预估。这样的情况很普遍，但是需要改变，给产品经理一个相对宽松的环境来工作。
| 
