前言??
本文是关于一篇名为「作为产品经理，如何做好项目管理？」的文章的记录总结。之前对项目管理一直没什么很在意，也没怎么很了解。现在公司重点指出这部分的重要性，所以就根据自己的想法写了一些总结和对公司日常工作的一些建议。(当年我似乎是对项目管理一窍不通，感觉这篇文章很厉害就记下来了)
一、敬畏之心
敬畏之心
在平常的工作中，经常会需要对某个需求和功能的完成评估一个大概的时间，而这个时间大多数都是开发的时间加上测试的时间，然后加上一些缓冲的时间。有些时候我们对项目的进度过于乐观，觉得肯定可以按时完成任务，而很多时候又对项目的进度不太乐观，觉得肯定是完成不了。
针对这一问题，我比较赞同文中的一句话产品经理应该用一种“悲观”的视角看待项目，用乐观的途径和手段去解决问题。悲观的视角看待项目的进度，完成情况，但是要以乐观的心态和途径去解决问题，争取早日完成，不打折扣的完成。
开发预估的时间一般来说都会留有余地，但是给产品的时间就只能是在余地中收尾，争取开发做完事情的时候，产品可以把一些收尾的工作也提前搞定。对于项目管理来说，产品的任务也算是项目管理中的任务，和开发任务属于同一级别，所以请不要忘记自己的产品任务也需要估算时间哦！
二、产品&项目的异同
产品&项目的异同
产品的工作和项目经理的工作不一样，要去了解这部分的差异是什么，当项目没有项目经理的时候，产品经理必须切换角色去承担这一角色的时候，那么了解项目经理和产品经理的差异对以后的工作展开是具有很重要的意义的。
三、项目环境决定成败
项目环境决定成败
项目环境涉及到项目生命周期，项目治理环境还有项目的过程资产，在平时的产品工作中，我们对项目的生命周期没有严格的定义，都是以迭代来走，当然最近采用2周一个小迭代的工作方式后，对项目管理这一块确实有了很大的提升。
项目的治理环境涉及到分工和人员分配的问题，核心点是产品经理要照顾全局，从项目角度去看，什么东西让什么人做，什么模块用什么方式做才最有效率。界定清晰每个人职责和权限，让大家各司其职，同时对相关人员的头衔，奖励和一些心理类激励的东西也需要考虑到。
四、合适的人与靠谱的计划
合适的人与靠谱的计划
启动项目之前一定需要开启动会议，最好找到相关的利益相关人员在场，同时也可以考虑向上级借力。要做好心理准备就是，项目中总会有人很消极，也会有人很积极，怎么去引导那些消极的人，怎么去规避积极的人受到消极影响这也是项目经理的重要工作之一，平时作为产品的时候可能没有考虑太多，但是如果要涉及项目管理，那么就要考虑这方面的东西。
找到合适的人组建了团队之后就要学会基于“用户故事”来分解项目任务，例如善用TAPD的功能，将项目的任务以”用户故事“的模式拆解进去，让开发人员或者是测试人员知道一共有多少个故事，一共有多少的任务，然后才能更加准确的估算出项目的时间，双方达成共识之后朝着一个目标前进。
除以上之外，还有一个很关键的东西需要在会议上讲清楚的就是项目的边界，可以理解为项目的目标范围。我们开会的时候需要有会议目的，有一个共同的方向，除了方向之外我们还要界定项目的范围，这个在产品工作中也会遇到，但是对产品来说，可能就是多耽误一点时间或者是拖到下一个迭代做完而已；对项目管理来说，没有严格的项目边界其实是很危险的，很有可能一个项目越做越大，越来越不可控，然后导致团队人员逐渐失去斗志，导致项目的失败。
补充： 这一点我最近深有体会，从去年年底开始做了一两个新的需求，结果需求的边界一直没有确定，需求不断地扩张，导致为了兼容各种用户场景，平衡大家的使用情景等。一个需求做了几个月，而且做完了之后改动太多，文档也没有及时更新，自己用的时候还有很多逻辑不确定，还需要联系开发看代码才能知道最终的业务逻辑是怎么样的。算是给自己上了一课，同时也对项目管理多了一份敬畏心。
五、项目节奏和潜在的风险
项目节奏和潜在的风险
作为产品经理来说我们更多的是考虑到产品能不能完成，能不能满足用户的需求，能不能向业务部门交差，所以我们对项目的潜在风险更多的是做好计划，怎么样用另外一种办法也能达到目的，解决问题。
而对于项目经理来说，他们考虑的是做这个项目的风险是什么，人员够不够？资源够不够？时间足不足？范围定了没有？所以这个时候我们需要去切换角色，会看到不一样的点。
例如制定合理的计划，恰当的控制节奏，仔细推敲清楚项目中潜在的风险和一些不确定的点，同时要保证物尽其用，工作安排要饱和。在关键节点上要有真正的输出，需要一步一步去把控进度，这样才会有更多的主动权去规划下一个迭代和接下来做的事情。
我们还需要有一个掌控全局的意识，在项目启动时候或者过程中，要经常与团队人员进行沟通，传达一些项目的危机，风险和成果等。让所有的成员有一种参与感，同时也要尽量满足大家的成就感。这个东西可以在项目启动的会议中进行，明确目的，同时拉大家“入伙”：
??
讲清楚项目的价值、背景，需要的资源和进度，影响的范围以及可能的风险。把所有好的结果画一个大饼给所有人，把所有坏的局面提前讲清楚给所有人。
六、期望与权力
期望与权力??
项目的第一件就是设立一个需求变更机制（如果你还记得之前谈到的项目启动会，项目经理一定要借助这个会议让项目的所有相关方知悉这个流程）。
许多人都会怕流程，怕繁琐的步骤，怕按部就班的死板限制了自己的自由和思维，当时更多的时候我会怕没有流程，没有章法，什么都可以乱来，最后所有的东西都要返工，都要重来。所以制定规则和流程是痛苦的但是也是必须要做的。
作为项目经理，制定的规则决定了项目是否能顺畅地进行，同时也决定了当意外出现，当风险出现的时候，项目是否可以不偏不倚地继续前进。
作为产品经理需要拒绝需求，这是我们经常会做也懂得要做的事情。作为项目经理则需要制定规则，让需求的口子从产品到开发，而不是业务直接就到了开发手中。同时也需要制定需求评审的制度，意外出现的解决制度等等。
结合日常的工作，我们公司经常会出现 做了这个功能，但是久而久之，却不知道这个东西到底是为什么而做的？业务不知道，产品不知道，开发也不知道。 这是对开发资源的浪费，也体现出了项目管理的不到位。
所以我们的暂时的处理办法是让业务写需求申请书，但是这个东西的效果是否真的有效或者是作用力是否大呢？从几个月的使用情况来看，效果好像并没有想象中的美好。那么这一个问题就是我们需要去解决的，也需要去探索的地方。
就目前来说，我个人比较偏向于使用在线工具或者协同工具来管理这些提出的需求，但是我也不能保证这就是最好的办法，但是起码我们得要敢于尝试，不是吗？
??
任何需求，都必须记录在案，甭管是否执行，需求的第一个动作就是备忘，第二步才是决定是否执行。一定要专人负责需求的梳理，跟踪和进度的反馈。
关于需求的记录，在平时的产品工作中我基本上可以做得挺好，这也算是产品经理现在潜移默化的一种技能了。但是对于文档的管理和记录，目前公司的项目团队对这一块似乎并没有做的很好。这种情况出现的很大情况是：
相关负责人文档意识不够强烈，没有这方面的很深刻的认识。文档的撰写不够优雅，不够舒服，大家都文档的认知是惧怕的，是冗长繁琐的，自然就不愿意写。没有人看，没有人赏识，没有人认同的文档，那么写出来就没有价值，久而久之并没有激情去写了。文档的更新和认知不统一，文档也算是项目的成果之一，但是大家似乎并不认可文档的重要性和项目的结果是同等的。总结
以上是针对项目管理那篇文章进行的一些观点梳理和自我总结，其中还有部分内容落实到了现实的工作中，所以行文有点自由，并没有按照特别的章法来进行阐述。
结合现实的工作和自我对项目管理的认知，我认为有以下几点是公司团队需要重视和注意的地方：
文档意识的提升，大家都知道文档重要，那么它有多重要，每个人放在心里的权重似乎不太统一。
项目干系人意识，项目的完成是需要大家的努力的，那么成就属于所有人，风险也属于所有人，并不是一切责任都是项目经理或者是产品经理承担，而是所有干系人一起都要去面对的，这是我们目前所欠缺的。
团队奖惩模式，团队之间可以有竞争，团队内部也可以有竞争，对表现出色的人进行奖励，对表现不佳的人就进行勉励。让项目成员拧在一起，提升大家的参与感，有助于项目的进展。
风险意识，项目的实施不一定百分百成功，但是也不那么容易失败，很多时候我们更多的是看到项目的成果而忽视了其实过程也许也是失败的，我们本可以做的更快，更好，人员分配更加好。对用户角度或者是产品角度，这是成功的；对于项目管理的角度，也许这是还有很大提升空间的。
项目经理和产品经理的关系是一种重叠且可能有所冲突的关系，但是作为新时代的产品经理，学习新的理念和新的知识去应对新的变化应该是必须要做的。所以当我们总是强调自己要切换视角去从用户角度看待产品问题的时候，是不是可以考虑一下，切换视角从项目经理的角度去看待项目的管理的问题呢？
后记
目前我正在学习PMP当中的内容，但是我却也陷入了一种知识的诅咒，我忘记了产品经理和项目经理的那种分界线是怎么样的，忘记了我只是一个产品经理的时候我是怎么看待项目经理的，忘记了我当时是怎么理解项目经理的工作内容的。
庆幸这篇文章留了个底，也给了一个新的启发。我18年到现在为止，看了几十本关于产品的书籍，但是我依然觉得下笔无神，章法不严，思路不畅，陷入上面提到的知识的诅咒。
看到这里，你有没有想打开你的收藏夹，拿些东西出来用用呢！
END
