第一次了解到 PM 这个词，还是在北京的时候，那个时候的 PM 不用太懂技术，只用懂产品，提需求就好了。2年前来到杭州，再一次听到 PM 这个词，刷新了我对这次的认知，原来这里的 PM 是指项目管理，一般产品型需求由技术（后端）来承担，主要职责是与业务连接，把控技术方案，把控项目进展。
什么是 PM
第一次了解到 PM 这个词，还是在北京的时候，那个时候的 PM 不用太懂技术，只用懂产品，提需求就好了。2年前来到杭州，再一次听到 PM 这个词，刷新了我对这次的认知，原来这里的 PM 是指项目管理，一般产品型需求由技术（后端）来承担，主要职责是与业务连接，把控技术方案，把控项目进展。
为什么要做一次 PM
在做业务型研发的时候，我了解到的项目，除了大促相关的需求，一般的产品型的需求都是由后端来承担 PM 的角色，主要的原因是后端一般专门负责一个业务线，而且业务逻辑比较重，一般后台的设计和业务的设计结合会比较紧密，各个域之间的调用在后端处理会比较多。业务需求过来的时候，首先会是业务找到后端，然后后端会提供一个大致的技术思路给到业务，需要前端的时候前端可能仅仅是支持的作用，这个时候前端会比较尴尬。慢慢的，如果不是太主动的前端，会把大部分精力放在思考技术的实现，很容易把自己当成一个资源的角色。这种现状，会慢慢的吞噬前端作为产品研发中所需要的商业sense，业务的思考度也不会有全面的提高。
我是怎么尝试的
为了改善这个现状，我计划以自己为出发点，开始承担一个复杂产品项目的 PM 。
确定需求痛点。 在之前的一个「新品」项目中，从项目有idea开始，我便参与进去与 产品经理 一起去梳理业务现状，梳理有哪些问题，这个时候其实正是研发去了解业务痛点、需求的最佳时机。这个时候，我了解到新品没办法拿到公域流量、没有心智是最大的两个痛点，这两个痛点在后面的一些技术点决策中起到了非常的作用。在这个环节你可能会碰到几个问题：
a. 业务是否更懂业务，也就是研发只是技术实现？我觉得并不是，只是站的角度不一样而已。业务需要的是实打实的业务指标，但并不一定会抠产品的细节。但是研发和产品不会忽视掉这些点。另外业务在某块领域深耕太久了后可能会产生某种思维定式，但研发和产品对业务大多都是经过1个研发对多个业务的场景，所以往往能协助业务跳出这些圈。讨论技术方案。 在经过一轮需求 pk 之后，业务诉求基本上是达成了一致，这个时候各个域的研发就需要参与进来讨论方案。前端还是会比较特殊一点，主要原因在于没办法了解一些业务系统的实现，这个时候就需要沟通和学习了，这确实弱点，但并不是致命的问题。但前端会有优势的点在于复杂交互场景的情况下，前端能比较清楚的从用户视角看一个个行动点的流向，然后和交互一起讨论出用户体验最好的方案，并且在讨论的同时思考技术可行性。在这个环节你可能会碰到几个问题：
a. 在一个项目里，如果不是 PM 的角色，各个技术同学其实都是资源/支持方，他们思考的问题永远都是站在各自域的角度思考技术/业务问题，很少会有 PM 站在整个项目的角度全局的思考问题，因此你一定要及时提出风险确定资源、项目排期。技术方案经过review之后，就需要确定资源、排期了。有人会认为这些事情是 PD 的职责所在，但我认为项目是否能上线还是取决于技术的实现，因此 PM 一定是要主动参与进来，毕竟还需要你来砍掉那些 ROI 非常低（bu kao pu）的需求。你可能会碰到几个问题：
a. 其他角色基本都是支持方，非常有可能出现以资源紧张为由没资源支持的情况。这种情况，尽量是通过证明业务的价值来说服对方进行资源的重排，但基本上是没太大作用，原因是各个域基本上都会对自己手头的业务进行一轮评估，都有自己的优先级。如何让其他团队最高优先级支持自己域内并不太重要的项目？这几乎是不太可能的。所以，这个时候还是非常考验 PM 的情商。在互不妥协的情况下，大家往往会想到向上抛出问题，让老板们来决策。这样的做法，一般能行得通，从历史的项目来看，这也是以领域、职能划分团队最不愿使用但最有效的方法了。
b. 永远都会赶不上业务的期望时间点。这是你一定会碰到的问题，如果没碰到，说明业务还没完全想清楚。这时候最开始我们get到的痛点就非常重要了。以痛点来决策大小子需求是否要支持。项目测试。项目测试虽然是测试同学的责任，但实际上 PM 要主动承担起各种细节的 review ，有时候测试同学不一定能够考虑到所有方面，在写 TC(test case) 的时候，PM 也要参与进来，相互补位。
最后想说的
PM 一直不是那么简单的角色，很多人都会不满意项目成果被 PM 拿走的现状，这其实是一个可以继续讨论的话题；怎么判断 PM 在某个项目里的重要性，我觉得「成员黏度」会是一个非常好的判断标准。项目成，且成员都愿意继续和 PM 做第二期，那么这个 PM 就是一个好 PM 。