1.前言

工作已经很多年了，最近受邀分享一下如何做好技术pm，所以也就有了此文。并不是说自己做的有多好，有一些实践经验分享出来和大家一起探讨一下，也非常欢迎大家指正。



2.什么是pm（项目管理）

项目管理是在有限的成本下，把控项目的质量和进度，保证项目顺利交付。成本、质量、进度之间相互制约相互影响，需要在这之中找到平衡点。并在项目执行的过程中持续关注项目的价值，推进项目价值最大化。

3.技术pm的职责

总结来说，项目pm就是在项目立项后，协调项目的方方面面，确保项目按期上线。项目pm的职责大概涉及需求、开发、测试、上线、维护五个阶段，对于每个阶段的具体职责，以下我做了一些简要说明。

3.1 需求阶段

1.需求调研前期，深入理解业务诉求，配合业务、产品完成需求的调研并完善需求，有时，可以提供给业务、产品一些建议，协助让产品需求更加完善，更加合理。

2.需求评审阶段，仔细听取产品需求，确认产品需求内容无遗漏，无不合理需求。对于各个功能点的交付难度有大概的预估，对于难度较大的非主干链路需求，必要时可以建议分迭代交付。

3.需求评审后，评估整体技术方案，确保整体方案合理完善，并协调各域完善技术方案的细化补充，并组织完成技术方案评审，锁定并确认项目排期。

4.技术方案评审完毕后，找相关开发同学确认，细化开发、联调阶段的排期，确保项目推进可控，不会出现重大延误风险。越大的项目建议越细，因为时间周期越长越容易交付延误。

3.2 开发阶段

1.项目开发阶段，及时跟进确认项目进展（重大项目最好日日跟进统计，降低风险），保证项目有序推进；识别并发现项目风险，跟进解决项目风险，确保项目可交付（需要有主动性，主动推进落地）；项目变更&风险信息及时拉通对齐，确保变更信息对各关注对象透明，必要时可以采用日会、周会、日报、周报等形式。

2.项目tc评审时，作为pm需要关注各域测试用例完整性和有效性，确保相关开发、测试无内容gap，无遗漏需求。

3.项目联调阶段，确保各域联调有序进行，对于不符合联调预期的加大关注协调解决联调问题，风险项及时跟进并推进解决。

4.项目联调完毕后，协调组织功能预演，确保项目顺利提测，重大项目建议先开发内部提前预演一遍，确保真实预演提测时不会存在较多阻塞，提测质量差，这里如果发现较多不符合预期，可以提前重点解决。

3.3 测试阶段

1.项目提测后，及时关注测试进展以及bug处理情况，确保测试稳定开展，项目bug及时收窄。重大项目可以考虑每天过bug，确保解决效率和问题拉齐。

2.项目发布前，组织发布计划评审，确保各域发布无遗漏、发布无故障风险；协调各域完善监控，确保上线后相关问题可以及时发现；协调各域梳理并完成资损对账，确保项目上线有资损问题及时发现并止血。

3.项目发布前，组织uat评审，确保上线交付功能符合业务预期，如果有gap在开发环境解决。

3.4 上线阶段

1.项目发布时，实时跟进各域发布进展，确保项目顺利发布。必要时协调开发测试在安全生产发布后，进行线上的回归测试。

2.项目发布后，协调测试同学一起进行线上回归，确保业务真实使用时无线上问题，业务顺利上线。

3.业务首次使用时，跟进并陪同解决问题，确保首次顺利使用。

3.5 项目维护阶段

项目正式运营阶段，关注业务问题、关注监控、对账，确保系统稳定，业务顺利展开。并作为业务接口人给业务同学答疑解惑。

4.重点事项与一些技巧

做好大型项目的pm，我理解主要有五方面的难点，这里和大家重点说明，分别是技术复杂性（项目越大，方案越复杂）、团队协作与沟通（跨团队协作多）、时间和资源管理（人员多、周期长）、风险管理（未知风险多）、质量控制（内容多，质量保障成本高）。

4.1 技术复杂性

技术复杂性主要体现在两方面内容，第一是整体方案的合理性，整体方案决定了后续整个项目后续是如何演进的，合理的架构方案可以让项目在后续持续迭代并高度复用，细节方案上，项目pm主要需要关注各个域是否包含了所有内容，会不会存在遗漏的，以及在方案后续扩展性的一些考虑。

整体方案的合理性

这里要考验你如何确认一个合理的整体方案，这里你需要考虑的因素有稳定性、可靠性、可扩展性等。自身需要提升知识储备，提升技术硬实力当然是必要的，但是不是人人都是各方面的高手，可以信手拈来。这里还有一些常用手段供参考，例如善借于物、借鉴历史方案、找领域专家咨询关键建议、设置mini版本等，这里具体如何实施，下面我会详细说明。这里也要避免过于扣细节导致整体方案评估的时间过长，影响项目交付，整体方案评估确认后相关同学拆解回去在细化方案。这里还有一点要注意的，如果是重要项目的整体方案设计，由于每个人都有局限性，建议在细化前都找老板过一遍，确保后续事项推进不存在返工的情况。

善借于物

整个互联网发展已经很久了，集团也是国内数一数二的互联网公司，可以说，有很大一部分的业务场景集团内都遇到过，所以这里需要优先看看集团内是否有现有的能力可以使用，如果有，在评估合理无风险的情况下，可以直接使用，不要再重复造轮子了，重复造轮子成本高、风险大、对业务额外价值也不大。有那个力气，我们可以花更多的力气去做好业务的个性化场景能力，确保业务更好更快的发展。



这里举个例子

比如说闲鱼需要做限购能力，调研发现集团现有bbq限购，也非常符合闲鱼的场景，则直接接入使用就可以了；又比如说，闲鱼需要做区域限售能力，发现集团现有的sic限售能力非常全面，足以应对闲鱼的所有场景，也是直接接入使用就可以了。

借鉴历史方案

我们开发大部分做的需求其实都是没有现成产品的，如果有的话，大部分在需求阶段产品已经评估打回了。但是相似的产品是非常多的，了解相似方案的架构以及一些痛点，可以让我们更加好的设计当前项目的整体方案。



找领域专家咨询关键建议

有些时候，你做的项目不是你的强项，且通过集团内外的相关文档也没有找到靠谱的方案。这个时候，你可以找在这方便经验丰富的专家咨询，可以让整体的技术方案更加合理。这里有一点是特别要注意的，由于每个人都有自己的工作，你去找别人咨询其实是耽误了别人的时间，所以我们需要体现我们的专业性，并且要让对方更加愿意帮助你。这里几个方式是可以参考使用的。

a.找别人咨询前，自己先有一个系统性的梳理，确保对项目和方案是有充分了解的，并且提问问题是非常专业的，不是一些低级的问题。

b.复杂的问题不建议在钉钉上沟通，钉钉上沟通效率低下，对别人耽误的时间多，可以选择语音或者直接去对方工位沟通，语音沟通的话记得提前先征得对方同意。

c.带上一杯奶茶、咖啡，一瓶饮料等去沟通，可以让对方更加愿意帮助你。受人恩惠让大家更愿意帮助别人。

这里举个例子

比如说闲鱼想做一个购物车，这里可以找业务平台的购物车同学咨询相关方案设计，也可以找各业务线购物车的开发同学咨询，由于沟通内容较多，直接找了相关同学线下沟通。

设置mini版本

如果一个方案确实是要自行开发时，在保证项目可顺利交付的同时，都是需要考虑通用性架构的，谁也不希望自己的方案是被一次使用后续无法迭代的。通用性就意味着成本，这里方案设计时可以考虑留着通用性扩展，但是不用把整体方案设计的非常复杂，可以在最初考虑一个最简洁的版本，达成业务初始的需求就可以了。我能支持系统成为一个牛逼的系统，但是不用一开始就非常牛逼。

细节方案的完备性

细节方案部分主要是由各个域开发同学编写的，这里需要确保各个域汇总后涵盖了所有需求，不存在遗漏。这里有个方式，技术pm对各域的产品功能做一个梳理，技术方案评审时确认各个功能点都被评审和评估到。

这里做一个展示示例，可以看到，下面对各域的功能点做了细化拆分，方便对焦是否存在功能遗漏，也方便工作量的评估。

4.2 团队协作与沟通

大型项目涉及域以及人员多，团队协作与沟通是无法避免的。这里需要关注在项目过程中如何提高沟通效率，并且减少一些私下对焦，如果有困难时，及时暴露问题寻求帮助。在整个项目推进的过程中，也需要维护好同事关系。



提高沟通效率

大型复杂项目涉及的业务、产品、技术同学非常多，所有沟通也非常多，如何提高沟通效率对于保证项目顺利交付非常重要，以下是我在做技术pm期间的一些个人感悟。

减少私下对焦

涉及到协同域的开发内容的，不要私下找对应域的开发同学去评估并投入开发，这种会把这部分内容不透明化，对于相关域的同学来说，也是一直处于打黑工的状态，应该快速协调产品通过需求的形式去沟通协调，这样可以让对方产品协调资源确认优先级，可以有更多更加官方的资源投入进来，保证项目的确定性交付。

寻求帮助

不同层级、不同职责上的还是有较大差异性的，如果有时候感觉事情推进困难，这种时候需要及时的向老板、向业务等寻求帮助。寻求帮助时，需要说清楚事情的背景、事情的影响、以及需要的帮助。

这里举个例子

维持好同事关系

在项目推进的过程中，维护好一个好的同事关系，可以让项目的推进更加梳理，以下是我总结的一些方法，大家可以参考。

4.3时间和资源管理

一般一个复杂的项目的时间周期非常长，由于周期长，时间多，大家对于时间和资源的管控就没有那么敏锐了，会感觉一切还来得及，到项目接近尾声了才发现来不及了有重大风险了。作为项目pm，需要做好详细的时间管理和资源安排，最好精确到每天需要完成的事项，让项目按天维度来判断是否是符合预期的，而且在事项安排上，需要做到先紧后松，这样即使后面出现了风险项目也有交付的可能，而且需要域内先完成联调，化整为零，提高全链路联调的效率。这里说一下我常用的方案，就是把各域的功能都拆分到非常细的维度，并且每个维度单独确认开发完毕和联调完毕的时间，后续每天找相关同学更新进展（让大家自己主动填写比较困难，这里建议线下一对一对焦，过程是比较累的，效果还是比较好的，勤能补拙）。

4.4风险管理

一个复杂项目，不可能前期面面俱到，保证中途不出现一点问题的，基本上没有人可以做到，但是我们可以把风险量降到最低，风险提前暴露，提升风险解决效率。

风险预防

有一些风险预防的手段，可以降低项目的风险，提升项目如期交付的可能性，具体如下。

风险识别

什么事情会导致项目有重大风险，会产生延期的，这里需要有一个判断，这里可能更多的需要多观察、多实践，根据自己、别人的历史经验发现哪些事项是可能存在较大风险的。这里是根据过往的经验识别到的高风险项，如果存在以下这些情况需要高度重视并想办法快速解决风险。

1.原定方案链路走不通的，需要修改需求重新调整方案的。

2.项目实际开发时，发现项目开发工作量远大于评估量的。

3.项目开发、联调进度严重不符合预期的。

4.评估涉及到需要新的领域投入支持的，尤其是和中台、支付宝交互的。

5.涉及到bu侧未使用能力引入的。

6.财税法未确认的内容。



风险处理

不同级别的风险处理方式不太一样，对于低风险正常推进就可以了，对于高风险需要投入比较大的精力去关注。

低风险

对于非主干链路，或者对排期影响可控的风险，正常推进即可，有必要的话，日报周报同步一下进展即可。

高风险

高风险出现，往往会对项目交付产生一些冲击的，这里需要提前让大家知晓这个事情，所以应该在风险暴露的第一时间让大家知晓这个事情，不要让持续持续的发酵和隐藏，导致最后真的无法解决。

高风险的事情需要重点投入并花较大的精力去解决，最好每日同步进展，进展中的待办事项要有deadline，确认解决时间。这里需要pm抽较大的精力持续跟进并主动去推进。如果事情遇到卡点，主要快速找相关老板协调资源，商量对策如何解决，如果确实是不好解决的，需要大家周知达成一致。

4.5质量控制

提测前

由于每个开发对可提测的标准不一样，重大项目可以考虑在提测前一两天先开发内部进行一轮预演，初步排查整个提测质量，针对不符合预期的域，重点关注推进，必要情况下安排加班或者协调资源进入等。

提测后

提测后需要关注bug的处理效率，确保提测后期bug得到快速收敛。bug尽量做到日结，这里可以考虑每天群里通晒一下未处理bug，监督大家快速处理。如果每天bug比较多，可以日会的形式每天过一遍bug，大家拉通对齐一下并快速处理。

提测后也需要把控尽快完善代码cr，之前出现过很多发布前代码cr不过调整代码导致发布后功能bug的情况。



发布前后

监控对账

项目发布前需要协调完善系统、业务监控，并补充资损对账。这是对业务，也是对开发人员的最后一层保护。部分开发同学对监控和对账不够重视，所以这里需要项目pm去check一下确保都是正确有效的。

回归测试

项目pm需要协调项目相关的正式包提前一点打出来，全部打包完毕后通知测试进行回归验证。确保验证无误后在发布，历史也有很多问题是因为打了正式包后未验证引起的。

线上测试数据验证

线上发布完后，需要协调测试同学用测试数据回归验证，线上回归可以发现不少问题，避免业务在真实使用时出问题。

严控灰度比例

线上业务正式试单后，就可以开始慢慢放量了。这里技术pm需要严格把控项目放量节奏，确保有灰度的过程，防止线上出大批量问题。

5.一些实操内容参考

5.1 项目启动

项目启动后，把项目所有相关的人拉到一个群里面，成立项目产技群，后续并把所有相关的文档信息更新到群公告中，方便大家后续翻阅。尽可能把所有相关的信息都更新到群公告中，可以为相关同学节省很多找资料的时间。

5.2确认项目排期

项目排期确认后，需要细化拆分各个子任务，每个子任务责任到人，每个子任务确认交付时间。

5.3 技术方案

技术方案需要尽可能细化，方案越细越可靠，时间评估也越准（你会说时间急，最好在方案阶段多花时间，后续开发事半功倍）。你需要评估一下，你的技术方案编写完后，是不是团队内另外找一个开发来就可以开发的。如果不是，比如花了几个架构图、流程图，你能确认你脑子里的所有东西都是准确且完备的么，你能确认你评估的时间是否合理么。

5.4 日报&周报格式

日报&周报的作用主要如下：

1.让所有人对项目的进展&风险有一个整体的认知，不要存在重大gap。（老板们再也不用问你项目开展咋样了）

2.让相关同学知晓自己存在的待办项，并通过通晒，周知老板的形式去push他解决（毕竟谁也不想背锅）。

3.让项目的重大风险被周知，更加方便协调到资源，可以更加高效解决。

在日报和周报上，需要先总后分，先说明整体进展和风险，再说分项的内容。先重点后次要，重点内容需要详细说明，并且对于待办项需要@到人。

5.5 资损对账文档参考

作为技术pm，你需要体系化的去梳理项目中可能产生资损的场景，然后push相关同学去落地。关于体系化，这里有两个建议，按维度拆分梳理会更加全面（比如先按资损角色、再一个域一个域评估）；是否所有新增资损字段均对账覆盖（对新增字段全部做一遍check）。

5.6 项目发布计划

项目发布计划主要关注几个点。

1.对齐二方包的打包时间，避免一些域的二方包打包晚影响了其他域的发布。

2.所有同学一起拉齐需要发布的内容，记录在案，避免因为个别同学的疏忽导致部分内容漏发布。

3.发布是否有依赖，如果有依赖应该如何解决，确保好发布关系，避免发布导致线上故障。

4.根据发布清单内容，可以持续跟进发布进展，及时发现发布中存在的风险，早介入早解决。

6. 最后

上面说的主要是一些流程和技巧，此外，项目pm需要有很强的责任心，业务、老板把项目交付给我们，我们是否可以尽自己所能尽的最大努力去保证项目交付，并且做到没有边界，非分内之事，也愿意多承担一些。这样即使最后项目没能交付，我们也问心无愧了。

来源  |  阿里云开发者公众号

作者  |  帆日