How to be a good Project Manager?
昨天X上看了宝玉哥(@dotey)的一则post，大概讲的是他一起合作了一段时间的一位工作能力超棒，有口皆碑的PM离职了。全篇整理了怎么从优秀的PM身上找出他们的闪光点，还有如何向他们学习。
文章我读了两遍，第一遍读的时候我想的是现在正在合作的校企项目中企业方的项目经理，坦白来说这个项目双方都不是很愉快，或者说表面上挺愉快的，暗地里波涛汹涌。第二遍读是今天，今天stacey愁眉苦脸的，和我说她正在负责的比赛，团队里的两个小伙伴在疯狂开摆，感觉和她们一点关系都没有似的。我一边安慰她一边在思考到底怎么样才算一个优秀的管理者。回家以后立马找了宝玉哥的推文，重读一遍，收获很大，刚好博客的talks栏目好久没更新了，囤了一大堆主题，所以趁着这个话题我也蛮感兴趣的，做一个整理。
Intro
遇到过两个不熟悉产品的PM，在同一个项目中。这个项目是一个产学研项目，涉及到三方协作：校方、公司A部门，公司B部门。合作逻辑是这样的：公司A部门和B部门的共同leader拉通了A部门和B部门的合作。大致内容是A部门想让B部门在他们的云服务的运维系统中添加一些可视化能力。B部门找到学校（也就是我们），合作。
本来写了一堆Intro，但是看了看发现都是吐槽B部门的PM，想想算了。对于一切事物择优录取就好。
Concept
提炼几个Key Points和我的切身感受吧
熟悉产品
熟悉产品是一个PM最基本的技能之一了吧，遇到过一个完全不了解产品的leader（说实话我也很好奇他到底是怎么当上这个leader的）。熟悉产品这是对一个PM最最基本的要求了，不然需求过来了都不知道怎么排期，也没法对产品后续的发展作出一个好的规划。我甚至觉得好的PM要具备一些提前预知产品走向和决策的能力，就像科研人需要拥有科研嗅觉一样，我也在很努力地学习这一点。
处理需求优先级
在产品的发展过程中，会有很多突然“加塞”的需求，如何**合理无痛**地处理这些需求的优先级则是彰显一个PM能力的时刻了。如何让一个团队拥有很好地所谓“抗加塞”能力，工作有条不紊地进行是非常非常难的。因为有时候需要拒绝，有时候需要和需求方battle，甚至面对一些非常紧急的需求，如何传达给员工，如何合理地排期，如何**无痛加塞**都是管理的艺术。
加塞的需求可以分个类，
紧急：尽量第一时间处理，没什么好说的
功能性需求：
默认放在下一阶段（原文为Sprint），需要和提需求的人做好沟通很重要，要表达清楚发布流程，以及可能对当前工作flow造成的影响。（PS：沟通真的挺重要的）
技术债务与性能优化
优先级较低，在阶段性排期时，需要安排20%-40%的时间来处理技术债务以及优化工作。
这点是非常值得学习的，对我来说就是定期找人CR，或者组员间相互CR。定期汇报与评估等等
大领导空降加塞
这种情况是最难handle的，事实上我遇到的最多也是这种情况，基本上公司和老师打个招呼，说需要加某某功能。校方说得好听点是合作方，说得难听点就是个臭干活的（hh:P）。所以在这种时候就会出现很多空降加塞，而且更恐怖的是一些不太懂技术的加一些看起来很简单但是由于历史架构等原因根本完不成的需求。
做法：
- 要先搞清楚他们紧急加需求的原因是什么？ 然后要让领导们清楚这样临时加塞所造成的影响是什么，比如会让系统不稳定，会影响其他正在进行中的计划，或者其他影响。
- 最后如果领导坚持要加塞，没必要正面对抗，可以找PM或者其他领导一起协商，实在不行就给加塞上。
没必要正面对抗！确实想到之前我没有办法处理这种情况的时候都会产生非常强烈的抵触情绪，然后就会演变成言语冲突，正面对抗。现在想想还蛮小丑的，下次需要想想办法沟通一下了。
但是我不同意实在不行就加塞上这个说法，因为加塞上意味着责任转移了，如果“实在不行”，我认为需要表达为什么不行，一直掰扯到这件事情能够找到一个合理的解法后，再加塞。
提前计划
再有就是这个PM对于新产品功能，有很好的计划性，能提前协调好资源，在将需求交给开发时，UI/UX设计、后端API这些都已经准备好了，各种细节也通过文档和多次会议反复确认完成，开发人员只要按照产品设计文档、UI设计文档、API文档去开发就可以，不需要开发自己去反复确认。
一个项目的排期是必须的，也是极其重要的。但是”在将需求交给开发时，xxxx全部准备好“这个是非常重要的。事实上这点我早在大三参加服务外包创新创业大赛的时候就有体会到，前期准备是非常重要的。一个还没完全理清楚思路，没有充分准备就开始的产品，干得再多也只是给团队徒增债务罢了。所有的债务后面都需要一项项偿还（血的教训）。
制定计划的时候不仅要考虑到项目的总体交付目标，还需要考虑到每一位项目组成员的情况。过紧的计划会导致产品发布后期团队无力，疲惫堆积严重，而过松的计划也会导致这点。这就需要PM有一个合理排期的能力，这是一项不可或缺的职业素养。
Addition
下面是原推中没有出现的内容，但是我认为一个PM必须要具备的内容。不是说原文落了这些points，因为可能以下这些品质是最最基础的品质。只是我想记录在这里
找到团队的意义与个人的意义
最最重要的一点，尤其是在没有步入社会，还是在学校的朋友们在带领团队做比赛/做项目/写论文的时候要时刻思考的一点。
就是：这个项目能为 他/她/你/我 带来什么？这个项目对他们的意义是什么？
这是一个很重要的点，和社会上工作不一样，工作了有钱拿，不工作就会失业。再怎么没有意义，钱也是意义。但是在学校不一样，往往大家在学校参加项目的目的都是能够增长自己的见识。那么试问如果让一个成员每天对着电脑copy&paste，谁愿意接这个活？
就我而言，在我给组员布置任务的时，我都在想以下几个问题：
(1) 会不会太难了？｜ 如果一项工作难度太大，会打击自信心，也会让接下来的一切工作都失去活力
(2) 做不完我能不能兜底？｜ 这个问题影响着我会不会挨老板批，所以我一般会要求定期做个汇报看看进度，如果走上正轨了就会减少汇报次数
(3) 这个任务他/她能收获什么？｜这个问题放在最后，但是是最重要的一项。组员一般是本科生，那么就应该思考除了成果的挂名之外，还能不能收获一些技术上/其他能力上的成长。
今天和Stacey讨论这个问题的时候，我又有了一点新的看法。她说她一直带不好团队，她的协作总是不愉快，导致她总是很难过，怀疑自己。我告诉她这和她这个人一点关系都没有，也和她解释了协作不愉快的原因。
期间我说了一句话：在学校里当PM，让团队成员各司其职不是一项任务，而是一个目的，一个结果，怎么理解这句话呢？在学校参与项目，很容易碰到摆子，更可恨的是他完成了你布置的任务，表面上各司其职了，但是完成任务的质量非常糟糕，到头来还得PM自己来擦屁股，（但是我遇到的组员都很棒，我爱他们！）。那么各司其职这时候就不是要关注的点了，而如何让每个人都更多地付出，更好地各司其职才是PM要做的，因此各司其职是一个我们追求的结果，管理的目的目标，而不是项任务。
避免压力向下蔓延
承担部分压力，并且避免压力向下蔓延是一个PM该做的，这是我的切身体会。如果一个PM一挨批，就对着其他人发火。一有紧急任务自己不排期直接定个ddl让所有人拼老命往前赶，那这个团队出来的成果也是糟糕且充满戾气的。
责任
本文不想吐槽任何人，但是没有责任感，遇到困难就踢皮球，遇到成果就抢着要，干活不见人，催人第一名的PM，反面教材。
Outro
希望自己能早日成长为一个好的leader，并且有朝一日能够拥有一款属于自己的好产品，加油🚀