我在阿里做技术PM-如何做好技术pm

图片

阿里妹导读


本文作者分享了自己做pm多年的实践经验,从什么是pm到如何做好技术pm做出了详尽的解答。

前言

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

什么是pm(项目管理)

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

图片

技术pm的职责

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

图片


需求阶段

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

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

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

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


开发阶段

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

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

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

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


测试阶段

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

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

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


上线阶段

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

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

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


项目维护阶段

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

重点事项与一些技巧

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

图片


技术复杂性

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

整体方案的合理性

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

善借于物

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

图片

这里举个例子

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

借鉴历史方案

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

找领域专家咨询关键建议

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

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

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

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

这里举个例子

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

设置mini版本

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

细节方案的完备性

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

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

图片


团队协作与沟通

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

提高沟通效率

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

图片

减少私下对焦

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

寻求帮助

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

这里举个例子

图片

维持好同事关系

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

图片


时间和资源管理

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

图片


风险管理

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

风险预防

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

图片

风险识别

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

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

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

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

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

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

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

风险处理

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

低风险

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

高风险

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

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


质量控制

提测前

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

提测后

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

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

发布前后

监控对账

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

回归测试

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

线上测试数据验证

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

严控灰度比例

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

一些实操内容参考


项目启动

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

图片

图片


确认项目排期

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

图片

技术方案

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

图片

日报&周报格式

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

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

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

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

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


资损对账文档参考

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

图片


项目发布计划

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

1.对齐二方包的打包时间,避免一些域的二方包打包晚影响了其他域的发布。
2.所有同学一起拉齐需要发布的内容,记录在案,避免因为个别同学的疏忽导致部分内容漏发布。
3.发布是否有依赖,如果有依赖应该如何解决,确保好发布关系,避免发布导致线上故障。

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

图片

最后

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


云上公网架构设计和安全管理


云上公网的设计可以帮助企业更加统一、安全地管理自己的云上互联网出入口,同时可以实现统一监控运维和公网的成本优化。