在京东，我是怎么做项目管理的

互联网小虾米 2023-07-24 23:51:50

如果要用一个字来形容电商后台系统——杂。

如果要用一个词来形容电商后台系统——复杂。

就像是百年老树盘根错节的地下根系，在普通用户所能看到的琳琅满目的商品背后，是电商系统错综复杂的后台系统。

用户购物时轻轻点一下，就是后台系统之间源源不断地逻辑校验和信息流转。

电商后台系统，由商品、订单、库存、支付、会员、促销、内容、评价、采购、财务、WMS、物流、风控、客服等等子系统组成，阿里、京东等大厂更是将其发展成了中台事业群，涵盖搜索推荐、共享业务、基础交易、数据等多条线部门。

庞杂的架构也意味着，电商后台项目不仅要梳理清楚系统之间的关联逻辑，有时还要组织跨部门跨条线的团队协作，加剧了项目管理的复杂度和难度。

项目延期、成本超支、业务方不满意？

辛辛苦苦沟通规划出来的产品“中道崩殂”？

跨条线团队之间、业务产品研发之间相互扯皮推诿、互相抱怨的情况时有发生？

你想带领项目组乘风破浪，殊不知有多少沟通对象正在兴风作浪。

那么，我们应该如何做好项目管理？

一、项目管理是做什么的

“第一性原理”是互联网产品经理常用的思维模型，意即看透事物的本质，要把事物分解成最基本的组成，从源头解决问题。

回归到项目管理工作，本质上是在约束的时间和范围内，集合有限的资源完成项目目标。

其核心要素有三点：资源、时间、产出，三要素协同共建，构成项目整体。

项目管理依据开发方式不同，呈现出不同的侧重点，目前常见的开发方式有瀑布式和敏捷式开发，瀑布重方案，按计划推进；敏捷重迭代，小步快跑，方案没有全盘捋清也可以先做起来。

本文以传统的瀑布式开发为例进行说明。

二、从三要素来看项目管理

1. 成果——要做什么事儿？

项目成果就是项目的交付物。

当拿到一份项目管理任务时，项目经理可以先从结果推导：需要在什么时间完成什么任务？

在项目管理工作中，经常使用工作分解结构WBS（Work Breakdown Structure）来拆解任务。

跟因数分解同理，WBS就是将项目按照一定原则，分解成一项项任务，再将任务分解成一项项工作，最后将工作分配到具体的个人。

一方面，任务必须100%拆解且拆解越细越好，越细代表着项目经理对项目有着越高的把控能力，抗风险能力也就越高。另一方面，每一项任务和工作都要具体到明确的责任人，每一位团队成员都需对自己在项目中承担的工作做到心中有数。

在电商研发项目中，系统模块之间往往存在着深刻的逻辑依赖和时间依赖，但是产品经理/方案设计者往往只对自己负责的模块很了解，对其他模块细节并不是很清楚，有时甚至不能在方案阶段完全识别到对其他模块的依赖。

针对模块依赖的梳理，项目经理可以作为团队粘合剂将项目组成员聚集到一起进行全流程设计方案PRD的评审，在充分的沟通中，加深团队成员对项目整体逻辑的认知能力。

如果有遗漏的依赖关系，在识别到后项目经理也要积极争取资源，赶工完成任务，一个没留神，很可能就是项目延期。

系统依赖也是项目经理设计方案并行或串行的依据，多项任务并行可压缩时间，但需投入更多资源；多项任务串行会拖长项目周期，但资源会相对轻松。项目经理可平衡时间和资源限制进行项目计划设计，促使项目按期完成任务。

2. 资源——都有哪些人？

项目中最核心的资源是人，人构成团队。

没有实权，团队成员不服管？

部门需求大过项目需求，没资源给你排期？

一个功能谁来做扯半天，你不推产品之间就不再沟通？

做项目管理，首先是做团队管理。

项目经理不是具有实权的管理者，一个不小心，不是被怼就是延期，所以在“管理”过程中，需要更多的借助技（xin）巧（ji）和手（sheng）段（ji）。

技巧1：充分沟通

项目中的“人”，并非只有冲在一线干活的产品小姐姐研发小哥哥等干系人（A），还有对项目目标直接负责的责任人（B）、以及不直接参与项目但对结果关心的利益相关人（C）。

对于不同的利益方，当然要“看人下菜碟”。

对于干系人A明确具体到不能再具体的目标、任务和时间，拿着小皮鞭或者捧着一颗卑微的心，推动执行；对于责任人（B）需要重点关注，责任人左右项目的方向和进展，如果责任人停滞不前，那么整个团队将会失去方向；对于客户、领导等利益相关人（C），要做的是预期管理，不要轻易承诺项目范围以外的交付成果，不要让C抱有超越实际的“期望”也是项目经理的工作内容。

值得注意的是，一个项目涉及到的利益相关方往往是分布在不同岗位的，既有客户、业务等贴近市场和用户的岗位，也有产品经理这样既懂市场也懂技术的岗位，还有研发、测试、架构师这样偏后端、非常技术化的岗位，沟通时面对不同相关方注意区分不同的业务语言、传达对方逻辑体系内关心的核心诉求。

有时业务和研发明明说的同一件事，但在表达上使用了不同的术语和思维，就容易说不清扯半天；再者业务觉得很简单的功能，在技术上可能就是实现不了或者要付出较大成本导致ROI很低，也需要项目经理在其中弥合多方的认知差距。

此外，规范的流程机制能够帮助项目高效运作，日会、周会等定期会议是项目开展过程中常用的手段，尤其是敏捷开发项目中，经常以每日站会的形式快速同步、对齐各方进展和问题。

项目经理也可以通过项目周报，里程碑报告等形式把控进度，强化项目目标、里程碑进度在团队成员心中的印象。

技巧2：培养团队精神

电商后台系统繁重复杂，且系统间互相依赖，跨团队、跨条线、跨模块执行项目是非常常见的现象。每个成员、每个团队、每个系统模块又都有自己的需求和任务，或者并行支持多个项目，并不能保证全力配合你所管理的项目。如果项目组成员各行其是，以己为重，那么很难按时完成项目交付上线。

因此，在项目团队成员（主要是指干系人A和责任人B）之间达成共识目标非常重要。

何为共识目标？可以将其理解为一种团队精神——向着同一个目标前进的团队凝聚力。

《腾讯产品法》中有这样一段描述：

凡有项目开发经验的人都知道，项目过程总伴随着各种问题，完全不出问题、产品还大获成功的“完美项目”根本不存在。更重要的是，如果团队成员无法从宏观、整体的角度去思考自己所负责的模块，必将引发内部的设计冲突。因为很多问题从单模块视角出发得出的结论与整体视角出发得出的完全相反。

围绕目标作战的项目成员不会像这样各自为战，相反的，他们就像一个命运共同体，“每个成员都有站在产品总负责人位置思考问题的习惯和行为表现”。

任务被团队分解，但目标依旧完整。在这样的团队里没有“我的想法”，只有“更棒的想法”，没有立场，只有理性判断。他们也会就某个问题展开激烈辩论，但那只是为追求“更好的方案”，而不是为捍卫自己的观点。

这样的团队里也没有“你的问题”，只有“项目共同的问题”，成员间彼此认可和信赖。他们相信各自能做好分内的事情，但也会在某环节遭遇瓶颈时积极贡献自己的力量，一起想办法解决问题。当内部模块间发生冲突时，他们也能及时跳出自己的角色去讨论，运用相对思维更全面地审视问题。

团队统一目标不是产品经理或者项目经理说一句“我们要做这个事！这个事情很伟大！”就能得到成员的认可。统一目标更多来自于成员对项目价值的认可，包括项目需求的合理性、项目流程的规范性、项目经理的领导力、团队成员的配合度等各方面的约束。

让每一个团队成员认可项目目标，紧紧围绕目标作战，知道自己在什么时间应该做什么事情，交付什么内容，你就拥有了一支强战斗力的团队。

技巧3：勇敢升级

当然，项目之中难免也会有难以沟通的成员，或者确实沟通了但难以达成结论的事项，如果你真的遇到了这样棘手的事情，那就勇敢地升级吧！一定不要排斥升级。

毕竟对没有实权的项目经理来说，升级可是解决复杂问题常用且必要的有（mian）效（si）手（jin）段（pai）。

3. 时间——什么时间完成？

搞定目标和资源，就可以按计划开展项目了。

项目管理计划贯穿整个项目生命周期，包括项目目标、项目范围、项目成本、项目资源、关键里程碑、沟通汇报机制、项目风险、项目成果交付物等关键要素，体现出来的是项目组成员（重点研发团队）可控的、按计划的、保证质量的交付过程。

项目中所有交付物的关键时间节点，可以称为里程碑节点，比如什么时间完成需求沟通和方案梳理，什么时间进入和完成开发，什么时间进行联调测试，什么时间进行UAT验证，什么时间项目正式上线交付等等，都需要项目经理制定计划。

项目计划需要得到全体项目组成员的认可，也需要满足业务方的期待和要求。

项目执行一般具备渐进明细，说人话就是时间越临近，要完成的任务越清晰，风险也就越少。

项目经理可以借助Gantt甘特图这个工具，不断细化当前的任务规划，结合WBS对近期的任务目标、资源、节点等要素做出清晰的规定，时间远一些的则可以相对模糊，但要保证关键里程碑这一粗维度的规划。

随着项目持续进行，项目经理还需跟进项目进度，团队成员做到哪了？什么时间完成？能不能按时完成？都是你要关心的问题。这个过程中，还需要加入风险识别机制，有没有出问题？会不会延期？什么，接口没有现成的，要重新开发？什么，需求优先级不够，项目要顺延开发？什么，测试用例不完整，测试环境没对齐？什么，联调订单跑不通，问题出在了哪里？

So……项目经理在制定计划后，跟进进度的过程也是不断解决（tian）问题（keng）的过程。