在阿里，我如何做好技术项目管理？

“

在技术公司、尤其是互联网公司，技术人员作为 PM（项目经理）是非常常见的。

图片来自 Pexels

有些同学得心应手，有条不紊，能得到清晰稳定的预期结果；有些同学则在过程中遇到各种闹心的事，最后不是项目上不了线，就是带着问题或各种人员的不满硬上。

当然这两种都是比较极端的结果。理性思考下，这里面有没有规律在？今天，阿里高级开发专家墨玖和你聊聊，如何做好一个技术项目的 PM。

目标分析

对于任何事情要有清晰的目标才能精确把握，如何做好一个技术项目的 PM？首先我们看到这里面目标最起码应该是：如期交付有质量保障的项目产出。

这里有几个需要我们注意的结果关键词：

• 如期交付（守时守信）

• 质量保障（保质保量）

• 项目产出（完整结果）

当然还有最重要的因素：人+过程。阿里有句老话叫做：没有结果的过程是放屁，没有过程的结果是垃圾。

所以，项目管理也是一样。我们既要结果，又要过程，当然，还要这里面人舒服 。

这里我们再总结提取下目标：

• 项目目标：如期交付（守时守信）、质量保障（保质保量）、项目产出（完整结果）。

• 人员目标：舒服、有成就、有成长。

• 过程目标：风险控制、信息同步。

接下来我们就按照项目的生命周期来看看以上目标要怎样才能更好地达成。

目标达成

项目启动

项目启动重要点是需求宣讲，俗称画饼拉人。任何一个项目都会有既定的目标和预期，但是这个目标大家认不认？如何衡量结果好坏？做完后有没有成就感？

这是项目后续成败的关键。所以你需要思考好这些东西，才能和大家宣讲、才能拉人干事。

不然人家都不知道你要干啥、干了有啥好、为啥要（卖力）给你干。作为项目 PM 的你定义好项目目标、衡量结果（ROI）、人是尤为重要的 。

这里提几点建议和思考：

• 目标：你为何要做这件事？

• 目标：你的目标有没有足够明确？有没有清晰的大图？

• 目标：做这件事的意义是什么？

• 结果：你有没想清楚这个目标的关键因素，核心指标是什么？

• 结果：有没有附加的影响和因素？是好的还是坏的？

• 人：你自己是否足够清晰能够完成项目的重要因素？尤其是大的项目 top-down 的思考。

• 人：你能为大家提供什么来确保顺利的分工配合？越俎代庖、撒手不管都是不可取的。

• 人：这个项目需要哪些人？哪些角色？他们核心关键是哪些？

• 人：参与这个项目的同学能得到什么？失去什么？共赢吗？

• 人：参与的同学的成就感在哪里？

当你思考和整理好以上这些东西，才能做好项目（需求）的启动和宣讲。目前我们很多项目的组织方式，是由多个角色完成的。

常见的方式是运营或业务或产品做了项目中的一部分或所有，然后到需求阶段再由技术同学跟进后半段。

这个角色有多人共同分担并不冲突，重要的是我们要配合默契、衔接得当、相互补位，拿到共赢结果。

工作过程中我见到过激情澎湃的 KO，也见过稀里糊涂到直接开车，所以生活（工作）还是需要一些仪式感。注意做好这些点，项目后面会顺畅很多。

需求评审

一般需（hua）求（bing）宣（la）讲（ren）完毕后，很快会进入需求评审阶段。这里是需求细化，明确重要节点。

作为一个项目 PM 你必须要做到小需求了如指掌、大需求合理拆分 。这个阶段最好是个时间段而不是一个时间点。

尤其是对于互联网，我们讲究的是快速，节约大家时间。你有必要提前深入介入，了解需求逻辑和范围。

这里会遇到如下几类问题：

①需求（描述或意义）不明确、理解不一致

解：不要牵强、不要害羞。描述不清楚的讲（写）清楚；意义不清楚的增加解释。

PM 都要搞清楚搞明白，这样你才能够在中后期答疑解惑环节，节约信息同步成本。实在不行就回到最开始的目标上去：意义在哪里？

②关键人员没拉到位

解：这个其实我们经常会遇到，原因也有很多。事前列好人员信息版(可以放心里)是一个很好的习惯，我个人习惯用钉钉群公告+云雀 Note 页。事中则需要补救和充分沟通了，还好我们的同学都很能相互理解。

③需求范围膨胀

解：这个问题也是我们项目中常见导致项目最终崩溃的原因。所以你是需要提早接入需求的，最起码要比评审早。

确认好项目的人员投入数量、投入度，确认好本次重要目标和次要目标。适当的时候要做需求拆解，不要做超量（加班也可能搞不定）的计划。不要做好好先生。你要清楚你的职责是如期交付有质量保障的完整结果。

除以上问题外，对于大型的跨团队的项目可能当下是无法详细看清全局的。这就需要大 PM 在这个时候量力而行尽早分拣分派、划定二级责任人。

在互联网公司，需求评审过不过一般都会提到需求沟通和宣讲。所以，需求评审一般是 PM 认同了项目目标和意义的，这个要特别注意。

所以具有 PM 角色的你（们）要更多的做配合需求拆分细化、答疑解惑；而不是一堆问题瞎怼（这可以发生在宣讲或再靠前）。

这里我提下几个重要的点：

• 需求评审要提前做好信息充分公开有会议邀请，关键人员要拉到位。

• 评审后关键参与人明确自身工作目标和职责。

• 重要信息、问题和困难收集。同时做好信息公开同步。

• 重大设计、困难单列单独跟进。

完成以上后，项目人员也基本铺开了。接下来更多的需要并行。

项目排期

评审完毕后紧接着的就是再次的资源盘点和目标对焦，简要的 Recheck 确保补齐。

这时 PM 根据各负责角色工作评估做出简要排期和项目需求+参与方核对各方诉求，确定最终版本。

这里也会遇到几个问题：

• 排期时间过长。

  解：拆分、加人、分阶段。建议最小工作单元评估最好不要超过 2 人日 。

• 其他项目排期冲突。

  解：分析是产品节奏冲突还是人员（资源）冲突，确认好各自目标再共同协商总体排期。

• 重要阶段未给足充分时间，如设计阶段、系统联调、冒烟、测试、内测等经常忽略项。

  解：提前协商沟通好。

最后，项目排期要和各参与同学沟通清楚投入度和时间节点。

一定要明确几个重要的时间点：设计评审、测分评审时间、提测时间、产品验收时间、发布时间（如果客户端还要根据不同端特殊情况分开列出）。同时排期过程中可能遇到的并行风险、人员资源风险及时对外同步。

设计+测分评审

设计之于项目隐患+后期扩展、测分之于项目质量风险的意义，技术同学想必都是非常清晰明确的。这不仅仅要求项目 PM，对于核心的系分、测分设计人员也提出严格要求。

务必保证：

• 重要流程有图、有文字、有用例覆盖。

• 重要设计方案、测试方案要提前沟通讨论评估风险和影响。

• 需要考虑资金、安全、性能、风险的，单列 To Do List+Check List。

• 重要设计影响对外同步。

对于技术型的 PM，最好满足其中一项：

• 项目中的核心设计者。

• 业务 Owner 或核心。

这里主要是考虑到技术项目 PM（实在不行要有核心设计人员）对于业务定型、技术定型在业务中后期的影响着实太大。

此阶段开始作为过程跟踪重要手段需要有常规的项目日报和风险提示了。建议对于工作日小于 20 人日的项目可以不用每天发项目日报，有风险及时同步即可。

超过的最好每日有项目详细进度， 根据项目复杂度不同粒度可以精确到单人负责的模块。重要的是过程跟踪+问题及时反馈解决。

研发过程

研发过程中一般大家精力都会集中在各自项目负责模块上。同时对于我们这种互联网公司，变化又是家常便饭。

这里有个原则是信息跟踪和同步评估要充分。可能涉及到排期调整的，要及时沟通和调整。也要注意风险和项目范围把控。

这时你可能会有如下帮助：

• 项目空间任务列表（aone 有批量功能）

• 排期进度表（云雀）

• 需求变更实录表（云雀）

• 人员负责表（云雀）

• 风险跟踪列表（云雀或 aone）

• 过程进度日报：模块进度条百分比、当日工作主要内容、风险同步与处理。 

• 重要逻辑影响对外同步（如表逻辑、业务逻辑变更的，需同步对应使用方）。

冒烟+联调+提测

大家都知道大多数的线上技术问题都可以在测试阶段提前发现。而 PM 要思考的是测试前我们能做什么？

提测前的冒烟、联调包含了必要的单元测试、功能测试和部分集成测试。尤其是对于多系统联动的项目冒烟和联调的质量直接影响到测试效果和线上问题量。

这里 PM 一定要提前沟通评估安排好时间控制和冒烟联调节奏，有必要的话集中闭关+小阶段目标设定可以实行 。

同时对于复杂的项目由于整体节奏和工作压力等原因参与人员很容易陷入自我流程和模块逻辑里。

在联调阶段作为 PM 最好能设计出几个经典业务场景作为联调目标，对项目的整体质量做提早把控。

重要项目特殊建议：

• 全量（70%+）含凭证冒烟。

• 流程覆盖设计+测试执行（PM）。

• 闭关联调+分模块分阶段联调半日目标进度。

• 独立的项目联调环境准备。

• 关键链路的日志标要求。

无论是作为核心开发还是纯 PM，此阶段都需要主动去检查项目的研发交付程度。包含但不限于主业务流程、特殊分支逻辑等。

你可以根据项目重要程度复杂程度来判断是否需要精细化。同时此阶段也很容易暴露缺失或错误逻辑。

我个人做法是小型项目自己设计场景 Case 走；大型项目联合核心研发测试一起设计场景 Case；同时注意对产品交互和 Demo。

测试

项目到了测试阶段大部分的开发工作已经基本结束了。我们这里讨论一种场景是开发测试由不同人员执行。

测试 Bug 要督促做到日清，不能日清的需要有原因跟踪。本阶段一般也是 Code Review 集中阶段。

PM 应直接或间接的对于关键链路设计、流程日志记录、编码规范要着重把关。

同时产品发布+回滚方案在本阶段要做准备了。一般来说每个团队发展到 2 年后都会有比较规范的发布计划模板。

这里我们着重提及几点 PM 要注意的事项：

• 安排处理好项目测试环境，确保稳定性。

• 安排各系统 CR 节奏，并跟踪反馈。

• 安排发布计划讨论和准备。制定并总结初步发布执行计划（单点对应明确责任人）。

• 安排讨论确定版本限制兼容方案。

• 安排准备线上功能开关和灰度方案。

• 重要项目要有发布预演。

• 预发和线上不隔离的系统要注意单独考虑预评估发生测试风险。有必要的给出操作步骤。

产品验收

一般情况测试完成后就到产品验收环节了。这个过程有些同学可能就直接不问或者任凭产品验收结果做最后的质量兜底。

这是极为不可取的，原因是一般的产品验收最多只会跑到整体项目 Case 的 30% 不到，越是大越是复杂的项目这个比率越是低。

产品验收的目标是检查产品功能完整性、产品体验，而对 C 的线上用户几乎会全方位无死角覆盖。

所以这次是你产品（功能）细节问题的最后一次机会。考虑到项目成本+收益+重要程度，对于特殊项目需要单独的组织参与人员设计并执行内部验收，以确保多人更大范围的产品检验。 

这个事情有两个重要意义：

• 项目产品信心建立。

• 项目产品功能体验 Review。
  

一般性的准备，我这里也列举下：

• 产品验收 Check List。

• 验收环境准备。

• 验收数据准备。

• 验收问题列表。

• 变更列表（云雀或 aone），此时的改动要特别注意变更风险和范围评估。

• 数据、BI、埋点验收准备。

• 产品验收数据收集（可选）。

项目发布

在以上阶段都完成后，就到了项目发布的最重要阶段。在准备好发布计划的前提下，要注意多系统联动的发布时间节奏、依赖控制、风险控制、线上验证等把握。

严格执行发布流程和回滚方案的同时，注意以下几点：

• 提醒系统发布前中后检查，建立通知机制（发布群）。

• 系统发布要注意 API 变更、数据及表结构变更等对线上逻辑的影响评估。（一般预发布已经做了）

• 发布后的线上检查，特别注意检查本身会否影响线上功能和数据。

• 最好做到发布功能有开关+线上白名单。

• 复杂项目的发布一般会选在晚上，但同时要做好分班跟进计划。

• 发布完、线上验证完毕后，项目发布邮件及通知同步要到位。

复盘总结

互联网公司，唯快不破。再快的产品功能发布也需要回到我们最初的本源，目标有没有达成？所以回到我们项目起初制定的目标和衡量标准，需要有个目标达成总结。

重要的点提及下：

• 项目目标衡量数据统计。

• 过程优缺点复盘，扬长避短（非所有项目）。

• 较为成功的项目要及时安排庆祝（仪式感很重要）。

其他的补充

互联网公司有个很大的挑战就是，项目节奏压力。同时通过以上我们也可看到想要做好一个项目是需要付出很多的，有很多东西都是默默地背后的。

项目也好，产品功能也好。都是人做出来的。再牛逼的业务宣讲、再清晰的目标设定、再精细流程把控最终都逃不过人这个核心的落脚点。

作为 PM 你要时刻反思：

• 真正的业务诉求是什么？

• 项目有没有偏离轨道？

• 这个人跟你做项目能不能得到成长、成就？

• 他有没有被你推到了墙角？

• 你是否能观察判断到可能的风险并最好规避、次之解决？

• 你会否会因为一个项目，一场仗而得到一批干将？

这是除了项目结果以外我们需要思考的。不仅仅是业务或技术，这是为了走的长远、是准备未来。

关于数据变更（结构+数据）：包含表结构变更、数据格式变更、数据内容变更等在细分阶段要同步 BI（其他数据使用方），项目验收前要再次确认。

作者：墨玖

编辑：陶家龙、孙淑娟

出处：转载自微信公众号：阿里技术（ID：ali_tech）

精彩文章推荐：