一个项目的完成，靠的不是一个人的单打独斗，而是团队的集体努力。协调各方不是件易事，项目经理的工作就显得格外重要。怎么样才能做好项目管理？本文作者基于自身工作经历，对这样的一个问题提出了自己的一点思考，希望对你有帮助。
就像是百年老树盘根错节的地下根系，在普通用户所能看到的琳琅满目的商品背后，是电商系统错综复杂的后台系统。
电商后台系统，由商品、订单、库存、支付、会员、促销、内容、评价、采购、财务、WMS、物流、风控、客服等等子系统组成，阿里、京东等大厂更是将其发展成了中台事业群，涵盖搜索推荐、共享业务、基础交易、数据等多条线部门。
庞杂的架构也代表着：电商后台项目不仅要梳理清楚系统之间的关联逻辑，有时还要组织跨部门跨条线的团队协作，加剧了项目管理的复杂度和难度。
“第一性原理”是网络产品经理常用的思维模型，意即看透事物的本质，要把事物分解成最基本的组成，从源头解决问题。
回归到项目管理工作，本质上是在约束的时间和范围内，集合有限的资源完成项目目标。
项目管理依据开发方法不一样，呈现出不同的侧重点，目前常见的开发方式有瀑布式和敏捷式开发，瀑布重方案，按计划推进；敏捷重迭代，小步快跑，方案没有全盘捋清也可以先做起来。
当拿到一份项目管理任务时，项目经理可以先从结果推导：需要在什么时间完成什么任务？
跟因数分解同理，WBS就是将项目按照一定原则，分解成一项项任务，再将任务分解成一项项工作，最后将工作分配到具体的个人。
一方面，任务必须100%拆解且拆解越细越好，越细代表着项目经理对项目有着越高的把控能力，抗风险能力也就越高。
另一方面，每一项任务和工作都要具体到明确的责任人，每一位小组成员都需对自己在项目中承担的工作做到心中有数。
在电商研发项目中，系统模块之间往往存在着深刻的逻辑依赖和时间依赖；但是产品经理/方案设计者往往只对自己负责的模块很了解，对其他模块细节并不是很清楚，有时甚至不能在方案阶段完全识别到对其他模块的依赖。
针对模块依赖的梳理，项目经理可当作团队粘合剂将项目组成员聚集到一起进行全流程设计的具体方案PRD的评审，在充分的沟通中，加深小组成员对项目整体逻辑的认知能力。
如果有遗漏的依赖关系，在识别到后项目经理也要积极争取资源，赶工达成目标，一个没留神，很可能就是项目延期。
系统依赖也是项目经理设计的具体方案并行或串行的依据，多项任务并行可压缩时间，但需投入更多资源；多项任务串行会拖长项目周期，但资源会相对轻松。项目经理可平衡时间和资源限制进行项目计划设计，促使项目按期完成任务。
项目经理不是具有实权的管理者，一个不小心，不是被怼就是延期，所以在“管理”过程中，需要更加多的借助技（xin）巧（ji）和手（sheng）段（ji）。
项目中的“人”，并非只有冲在一线干活的产品小姐姐研发小哥哥等干系人（A），还有对项目目标直接负责的责任人（B）、以及不直接参与项目但对结果关心的利益相关人（C）。
对于干系人A明确具体到不能再具体的目标、任务和时间，拿着小皮鞭或者捧着一颗卑微的心，推动执行；
对于责任人（B）要重点关注，责任人左右项目的方向和进展，如果责任人停滞不前，那么整个团队将会失去方向；
对于客户、领导等利益相关人（C），要做的是预期管理，不要轻易承诺项目范围以外的交付成果，不要让C抱有超越实际的“期望”也是项目经理的工作内容。
值得注意的是：一个项目涉及到的利益相关方往往是分布在不同岗位的——既有客户、业务等贴近市场和用户的岗位，也有产品经理这样既懂市场也懂技术的岗位，还有研发、测试、架构师这样偏后端、非常技术化的岗位，沟通时面对不同相关方注意区分不同的业务语言、传达对方逻辑体系内关心的核心诉求。
有时业务和研发明明说的同一件事，但在表达上使用了不同的术语和思维，就容易说不清扯半天；再者业务觉得很简单的功能，在技术上可能就是实现不了或者要付出较大成本导致ROI很低，也需要项目经理在其中弥合多方的认知差距。
此外，规范的流程机制可以帮助项目高效运作，日会、周会等定期会议是项目开展过程中常用的手段，尤其是敏捷开发项目中，经常以每日站会的形式快速同步、对齐各方进展和问题。
项目经理也能够最终靠项目周报，里程碑报告等形式把控进度，强化项目目标、里程碑进度在小组成员心中的印象。
电商后台系统繁重复杂，且系统间互相依赖，跨团队、跨条线、跨模块执行项目是很常见的现象。
每个成员、每个团队、每个系统模块又都有自己的需求和任务，或者并行支持多个项目，并不能够确保全力配合你所管理的项目。如果项目组成员各行其是，以己为重，那么很难按时完成项目交付上线。
因此，在项目小组成员（主要是指干系人A和责任人B）之间达成共识目标非常重要。
何为共识目标？可以将其理解为一种团队精神——向着同一个目标前进的团队凝聚力。
凡有项目开发经验的人都知道，项目过程总伴随着很多问题，完全不出问题、产品还大获成功的“完美项目”根本不存在。更重要的是，如果小组成员无法从宏观、整体的角度去思考自己所负责的模块，必将引发内部的设计冲突。因为很多问题从单模块视角出发得出的结论与整体视角出发得出的完全相反。
围绕目标作战的项目成员不会像这样各自为战，相反的，他们就像一个命运共同体，“每个成员都有站在产品总负责人位置思考问题的习惯和行为表现”。
任务被团队分解，但目标依旧完整。在这样的团队里没有“我的想法”，只有“更棒的想法”，没有立场，只有理性判断。他们也会就某个问题展开激烈辩论，但那只是为追求“更好的方案”，而不是为捍卫自己的观点。
这样的团队里也没有“你的问题”，只有“项目共同的问题”，成员间彼此认可和信赖。他们相信各自能做好分内的事情，但也会在某环节遭遇瓶颈时积极贡献自己的力量，一起想办法处理问题。当内部模块间发生冲突时，他们也能及时跳出自己的角色去讨论，运用相对思维更全面地审视问题。
团队统一目标，不是产品经理或者项目经理说一句“我们要做这个事！这个事情很伟大！”就能得到成员的认可。
统一目标更多来自于成员对项目价值的认可，包括项目需求的合理性、项目流程的规范性、项目经理的领导力、小组成员的配合度等各方面的约束。
让每一个小组成员认可项目目标，紧紧围绕目标作战，清楚自己在什么时间应该做什么样的事情，交付什么内容，你就拥有了一支强战斗力的团队。
当然，项目之中难免也会有难以沟通的成员，或者确实沟通了但难以达成结论的事项，如果你真的遇到了这样棘手的事情，那就勇敢地升级吧！一定别排斥升级。
毕竟对没有实权的项目经理来说，升级可是解决复杂问题常用且必要的有（mian）效（si）手（jin）段（pai）。
项目管理计划贯穿整个项目生命周期，包括项目目标、项目范围、项目成本、项目资源、关键里程碑、沟通汇报机制、项目风险、项目成果交付物等关键要素，反映出来的是项目组成员（重点研发团队）可控的、按计划的、保证质量的交付过程。
项目中所有交付物的关键时间节点，可以称为里程碑节点。比如什么时间完成需求沟通和方案梳理，什么时间进入和完成开发，什么时间进行联调测试，什么时间进行UAT验证，什么时间项目正式上线交付等等，都需要项目经理制定计划。
项目执行一般具备渐进明细。说人话就是：时间越临近，要完成的任务越清晰，风险也就越少。
项目经理能借助Gantt甘特图这个工具，不断细化当前的任务规划，结合WBS对近期的任务目标、资源、节点等要素做出清晰的规定，时间远一些的则可以相对模糊，但要保证关键里程碑这一粗维度的规划。
随着项目持续进行，项目经理还需跟进项目进度：小组成员做到哪了？什么时间完成？能不能按时完成？这些都是你要关心的问题。
So……项目经理在制定计划后，跟进进度的过程也是不断解决（tian）问题（keng）的过程。
工作数年，越发觉得任何一份工作既有体现价值感和成就感的一面，也有一地鸡毛、琐碎不堪的一面。
项目经理这份工作，相对来说不是一份容易体现价值感的工作：你在项目中明明做了很多工作、很多沟通，但又非常像什么都没做——方案是产品写的，开发是研发做的，那么，你呢？
但当你协调资源解决了一个又一个难题，完成一个又一个项目交付上线，得到客户一个又一个满意的答复，还是会觉得这份工作有价值。
重要的是：里程碑是按期完成的，系统是平稳的，产品是好用的，客户是满意的，项目是成功的。
