前言

Github：https://github.com/HealerJean

博客：http://blog.healerjean.com

本文抄自：https://www.jianshu.com/p/dbc4adf2d186

简称	全称	翻译	说明
PM	Product Manager 、Project Manager	「产品经理」或 「项目经理」
R&D	Research and Development engineer	「研发工程师」
FE	Front End Engineer	「前端工程师」
DBA	Database Administrator	「数据库管理员」
QA	QA Engineer	「测试工程师」

什么是主 R

主 R 职责：架构合理性的把控、对项目质量的把控，对项目进度的把控、对项目风险的把控

主 R 能力：业务理解力、技术能力、团队影响力、跨部门沟通协作能力。

项目一般分为以下几个阶段：需求分析 -> 方案设计 -> 开发 -> 联调 -> 测试 -> 上线 -> 上线后评估

一般称呼一个项目的整个负责人为主 R，成为一名合格的主 R，其实就是要把整个项目生命周期的中的事情都做好就行，看着这句话很简单，但是实际上在实时的时候，可能就没这么容易了。这里我针对每个阶段要做的事儿都做一下阐述

总结就一句话：在不同的时间点，满足不同的人对不同的事儿的诉求。

一、需求分析阶段

需求分析阶段，我们要搞定的人是是业务方和 pm

1、诉求和收益

这个阶段我们需要弄清楚业务方的真正诉求是什么（即做这个事儿的背景），要搞清楚 pm 的产品是否真的能满足业务方的诉求。

同时我们还要多问一句，做完这个事儿， 我们如何评估做这个事儿的效果，这个事儿是不是真的有意义或者有做的价值。

如果不合理，那需要评估到底应不应该做 ，如果 主 R 认为这个事儿压根不应该做，这个时候需要做的事情就是说服 PM 不应该干这个事儿 ，如果 PM 很坚决，这个时候，需要找 主 R 的 leader ，让 主R 的 leader 去评估，去决定这个事。

2、需求对齐

这个阶段我们一定要把需求揉碎了看，想清楚每个细节点，跟 pm 和业务方确认清楚这个是不是真正是他们想要的，只有大方向理解一致了，最后的结果才不会出现太大偏差。

我在刚开始做主 R 的时候，由于需求分析阶段没有做好（ 我理解的和 pm 理解的压根不是一回事儿），从而做出来要彻底返工。因此在这个阶段一定要多沟通，把要做的事儿确定好。

3、产品方案合理性

作为一个开发人员，有必要去关心产品的方案是不是合吗？有必要了解那么深的业务吗？

我的答案是：有这个必要，非常有必要，我们是开发人员，不是一个代码翻译官，如果连业务都不理透了，你何谈架构，未来又如何迭代，更夸张的说，面试的时候，你聊什么？，拿什么忽悠面试官

我以为，开发人员应该比 pm 更了解业务，并且不断能协助 pm 提出一些更有价值的东西，更合理的东西。

二、方案设计阶段

这个阶段我们要搞定的人是和我们配合的前端，后端人员，

1、代办解决

再需求分析阶段，可能在需求评审中存在代办事项，或者由于细节点评估不到位存在了代办事项，那么，在方案设计阶段就应该解决，而不是到了开发阶段，到了开发阶段，如果代办没有解决，或者发现了新的代办，那就需要每日报告风险。

2、细节掌握

方案设计阶段，我们需要对比系统现状，分步想出实现需求的各个要素，这个过程中可能会不断的找 pm 确认一些细节点，直到整个方案出来为止。如果觉得方案不太尽如人意，或者思路不太清晰，可以找你的 leader 协助给你一些指导性的建议。

3、排期

确认好方案之后，我们需要搞定几个时间点，前端，后端开发何时开始，何时联调，何时提测，qa 的排期及上线时间，提前要出这几个时间点是很重要的，避免出现多方开发完了，结果有某一方说还没排期的尴尬情况发生。

三、开发阶段

开发阶段，这个阶段每个开发都很熟悉，那么这个阶段我们要搞定的人是谁呢，是我们自己以及配合我们做项目的各个业务方开发。

1、主线梳理

有一个问题，估计大家也很常见，就是在做一个需求的时候，要不要把改这块代码涉及到的主线逻辑，以及所有其他支线细节都梳理一遍，因为也是一个比较花时间的操作。

我的答案是：有必要。每次需求做的时候，把所有主线及支线逻辑都梳理一遍，这样会加深自己对自己系统的理解，同时有时候会发现系统某个地方是不是有什么问题，能刚好在梳理的时候及时发现并处理，而且如果对主线都不了解，怎么认为自己改动是没问题的呢。

2、进度跟进

我们需要在几个时间点去确认项目各个业务方的开发是否按部就班的进行着，一般是项目三分之一的时间点，需要跟进一下各个业务方进度是否如期进行，项目一半时间的时候再次沟通是否正常，项目联调前一天再次确认是否能如期进入下个阶段。

3、及时沟通

如果在这个过程中哪个环节进度不佳，要及时沟通原因，这个时候就需要自己多去了解一下对方的一些实现方式之类的，一起协商一下解决方案以保证项目如期进行（这个沟通过程相当重要，是我们不断成长的最主要因素，因为不断跟各方沟通，我们会不断了解对方的一些思维方式及实现方式，不要怕因为自己不懂就不去沟通，不去问，是只要自己不懂的 ，就要多问，直到搞懂了。慢慢的就会发现我们懂的越来越多，认知边界也越来越广，跟各方配合起来也越来越得心应手）。

这个时候有可能很多时间都耗费在了协助其他人解决问题上，那我自己的时间是不是有可能 delay 呢？

在初次跟别人配合的时候，可能确实很难，并且想搞清楚问题在哪，如何解决确实会花费大量的时间，那么我们要做的就是在前期时间预估上给自己多预留一些 buffer，一般需要预留出 20% 的时间 buffer 以应对这样的事儿。

虽然前期会很难，当每次都这么协助别人处理好各种问题的时候，我们会对各个不同环节的理解就越来越深（前端，其他业务方的业务等等），对自己的沟通能力和技术能力都会有很大提升。

四、联调阶段

这个阶段要搞定的是联调的前端后端人员，这个阶段要搞定的几个时间点就是联调过半及提测前一天。

当联调出现问题的时候，一定要主动协调各方解决问题，从协调的过程中，你会了解到不同人的做事儿方式，也会了解到你自己系统的边界能力以及可能以后会出现的问题，这些都是比较宝贵的经验，长久积累下去，会形成质变的。

在这个过程中，有时候会碰到一些边界不太清晰的问题，会出现一些你做或者我做都可以做的事儿，这个时候，沟通的双方最好将利害关系讲清楚，首先以肯定的态度认可这个事儿是双方都可以做的，然后看对方做的话代价及成本多高，综合考量之后，再协商出一个合理的结果，有时候适当的牺牲自己的一些时间去承担这个事儿得到的可能是长远的一个收获。

在这个阶段我们重点关注的时间点是联调的进度是否符合预期，必要时候需要采用每日组会花几分钟让大家都知道现在的问题以及需要解决的问题。

五、测试阶段

在这个阶段，需要我们应该更主动的跟 QA 同学做配合，以保证项目的一个质量。这个阶段要搞定的几个时间点就是测试过半及提测前一天。

测试阶段，我们需要提前将测试用例进行评审，指出测试用例中不满足要求的地方，以保证测试的覆盖程度，这同样是对自己的一个考验，需要考虑清楚整个系统做完之后，哪些地方是边界，哪些是重点要测试帮你把关的地方，哪些细枝末节测试可能没有考虑到。

六、上线阶段

配合 QA 进行回归验证，PM 验收

上线阶段，我们需要按照我们的上线步骤（不仅仅是自己的，是相关所有前后端的上线步骤），一步步发布上线，同时观察线上服务日志看是否有问题，上线之后，可以在隔离的环境对结果进行一些正确性校验，以保证上线的功能是没问题的。

七、上线后评估阶段

这个阶段要观察上线后的效果，看是否符合预期，如果没有，那么就需要反思是什么原因导致的。

这个过程是对我们做的事儿的一个检验过程，是一个对自己肯定的过程。

八、总结

总的来说，在上面所列出的这些步骤里，每一个步骤都做到极致的人，我认为，他的见识，对系统的理解，对边界的判断，对时间的预估，对周围人的理解都会是一个上升的过程，那么当积累到一定程度之后，质变只是一个必然的结果了，成长为一个合格的主 R 也是一个水到渠成的过程了。

阶段	搞定的人	确认时间	确认点
需求分析	业务方、PM	业务方和 PM 要求上线的时间	需求理解是否一致
方案设计	自己、配合方	开发起始时间、联调时间、提测时间、QA测试时间、预计上线时间	代办是否已经解决
开发阶段	自己、配合方	开发三分之一时间、开发过半时间、提测前1天	开发进度是否正常
联调阶段	自己、配合方	联调过半时间、提测前1天	联调进度是否正常
测试阶段	QA	测试过半时间、上线前1天
上线阶段	自己、QA、业务方、PM、配合方		上线是否有问题
上线后评估	自己、QA、 业务方、PM、配合方		线上运行是否符合预期