先附上一个链接《当接手一个新项目的时候，产品经理应该做些什么（一）》，在这篇文章中，朴老师说了如何从业务、构架这个层次来对一个新项目的思考。

然而，过了两周后，我在这件事上又有了新的认知。

产品经理必然要关注如何解决事情，也就是说我们要完成一项工作，要以怎样的流程来做。其中，我们要面临的是需求的解决方案，以及团队的解决方案，甚至是老板、用户、甲方等等的解决方案。

如果我们单单仅考虑怎么完成需求，那么我们势必不能很好的完成工作。在这当中，我们还要综合考虑一切的外部因素，也就是全局观，或是叫战略统筹能力。而且，我们还要考虑所面临的风险，以及积极的应对措施，这都是我们必须下足功夫去思考，一步步去打磨的，没有时间的历练，这种能力很难直接获得。

经常有小伙伴问我，没人带我，我感觉没有进步。我也是不止一次的回答这个问题，究其根本原因就是你做的太少，因为你不去想，缺乏主动，但是这种话说出来，经常得罪人，也很难得到认同。所以就仁者见仁，智者见智了。

好了，废话不多说，直接进入主题。今儿我会和大家分享接手新工作的实例，关乎自身的定位以及如何拉取老板。

团队的问题

自从朴老师从上家单位跳槽，进了新公司后，对团队的理解真的是一日千里。相比人而言，需求容易解决，但是人的问题是最不容易解决的。

朴老师属于激进派一类的，做事情目的性和针对性极强，不管接手哪项工作，喜欢采用猛药简单粗暴的方式，往目标冲击。一旦团队出现目标不认同的，我便会刨根问底，如果你说服不了我，我就会按照自己意愿前行。

这就出现了两种极端的情况。有一个团队气氛很融洽，所有目标都会统一起来，有问题也会直接说出来，效率很高。另一个团队，出现各种阻塞，不管我说什么，他们一致坚持自己的想法，同样我也无法认同他们的理论，当进入开发环节，缺少沟通，最终效果很差，效率贼低。

当我发现了这个问题已经无法挽救的时候，项目团队已经临近崩溃，果不其然，最后项目停止，团队资源释放。

新的项目，引入了这第二个团队的部分成员，领导找到我希望我可以接手这项工作。于是我根据经验和领导说了团队会面临的问题，以及我希望的规划。

一、调查背景，清楚每个人的性格和关注点

如果你搞定了人的问题，那么你做什么都可以成功。但是，我们大部分人都做不到的，因为我们多从自己的角度出发。如果你习惯性的换位思考，那么你给别人留下的都是惊喜。

可我们也有能做的，我们对一个人的判断，多从言语，做法来出发，看是不是靠谱，能不能更多接触。做产品经理，不是为了和所有人都搞好关系，这一套我们不学。而是要做，怎么才能推动工作落地实现，完成目标，需要一点套路和手段。

就比如我这新接手的项目，团队成员都是清一色的老员工，项目重要程度可想而知，而且这其中还有几人和我有过立场冲突，单纯的来说需求，那根本不用想，结果肯定是不了了之。那么该怎么办。

我合计了一下，算上我7个人项目团队，其中2人属于中立，4人属于对立，因为涉及的模块很重要，一旦牵动必然伤筋动骨。技术关注实现的难度以及需求是否合理真实，性格大多比较刚，一般不肯妥协的，其中一个重要角色还对我抱有偏见。设计和测试关注逻辑和交互，以及最终的使用用户群体，性格较为和善，只要不担责任就能推行。

在这种情况下，如果我来做的话，是做不好的。因为我很清楚，所以也明确的拒绝了2次，第一次是原产品经理私下来找，第二次是老板简单提一句。

二、制定公约，引入第三方监管

到了第三次的时候，老板正式和我谈这件事情。我也知道跑不了了，一旦做不好就会被当枪使了，所以有些事情需要提前明确掉。我和老板说，我可以接手，但是我提前说明几点：

1、说明团队实际情况。团队的问题要提前说明，要告知老板会遇到哪些风险和问题。我不是很避讳的说明，我和这其中的几人有些立场不同，而且我对该功能的认知和规划，和现有的产品经理的理念不同。当前没有目标，以堆功能为主，如果是我，我会重新确定业务重心方向，完善功能的同时，做体验优化。

其次，我会相对更激进一些，会制定目标，但可能会激化团队的矛盾，因为每个人的考虑点不同，做改革就会面临这种风险。

2、引入HR或是项目经理监督。每次开会需要一个HR来参与项目，并且所有的会议纪要要抄送老板，我也会每周汇报。目的是让HR清楚了解团队问题，以便可以随时缓和团队矛盾；再不济，也可以让HR了解每个人的实际情况，到底是积极配合还是消极反对，找到领导了也有个见证人。

3、制定项目公约（责任机制）。如果项目真的要进行，我来制定的规划，所有参与人决定后，那么必须要为这个目标付出，也就是责任问题。不能当项目进入后期时，技术说有些做不了，或者没有意义实现这种话题，出现必然要追责。

确定项目时间、范围、成本。每个人要在规定时间范围内做完本职工作，明确了解自身的工作范围，以及所需的成本，如果有延期理由，那么必须要提前告知产品或是HR，以便重新规划项目的路径。

确定会议制度。为了保证项目能够顺利进行，每周进行一次进度总结，在会议上抛出问题，以及一些想法提案，最后确定项目进展情况。

确定沟通方式。由于会经常出现群内发消息，不回复的现象，那么由重点的问题，无论是抄送邮件还是其他方式，大家需要明确什么在邮件中说明，什么在群内提到要回复。如果回复不及时，耽误进度，那么就得有个说明。

确定风险应对。这是个技术活，不怕做不了，就怕想不到。如果出现了没有考虑到的问题，最终的结果就是没有结果，所有人会拖会甩。因此，要多考虑可能出现的风险，一旦出现能够第一时间找到对应人响应起来。

项目公约的意义就在于要保障你的项目能够推行的下去，防止出现推诿扯皮的现象。当然你不能把自己的职责全部甩出去。公约关键的本职在于“平衡、中庸、不偏不倚”

三、获得老板支持

没有老板的支持，上面一切都是废话。没有尚方宝剑和圣旨，产品经理就必然会面临是个屁的尴尬局面。

既然老板安排了我做这项工作，那么他就是一个重要的干系人。那么就要促使他发挥职责，那么发挥什么职责呢？那就是power。

我说的可能没用，用户说的可能不是对的，那么老板说的，你就一定要照做，所以为了保证项目的推进，那么每一步的计划有必要让老板知晓。

其一是整体的规划，从宏观的角度来讲，你会怎么做，为什么做，做到什么样的效果，会给我们带来什么样的利益。

其二是当前的规划，从版本迭代的角度来讲，当前由哪些紧急的需求，我要实现哪些，哪些之后实现，实现后怎么获取反馈等等。

其三是在需求大会中，确保每个主管和参与人能够参加，提及并获取支持。最终确定的需求。

最后就是个人能力的体验，老板支持你，但是你无法达成想要的效果，你就得一直背负着这个重担。

当然如果团队中，有人还是不依不饶的，你的记录、你的反馈、第三方的反馈，这些就是你的“武器”，拿好你的武器，要不背后被当枪使了。

ok，今天分享结束了，大家有空可以找我聊聊：DY402122152