如何正确拆解项目管理问题？
“项目管理”这个老生常谈的事情，一直以来都是产品落地的大问题。工欲善其事必先利其器，要想产品按时交付，顺利产出，必须对项目进行监控和管理。
项目管理是一门专业的学科，研究其的方法论各有千秋，但最终还是围绕两个关键点：人和事。
产品按项目也分为不同性质的类型，一类是项目型产品，一种是自导型产品，所谓项目型指特定的企业或政府通过公开的方式进行项目招标或认领，从起草项目标书至项目完成，以招标方的主要需求和既定方案为核心展开的一系列项目活动，最后的产出品是为项目型产品，此类产品针对性强，通用性低，且周期时间会明确出限定范围。而自导型则是由公司内部发起，为满足公司业务发展或提高增效或降低成本或支撑利润的标准类产品，此产品基础功能适用性较高，面对对象丰富不局限，有很大的拓展空间或预留改造空间。
不管是哪类项目，都一样需要项目组配备对应的资源，包括人力、设备、时间、空间、资金等基本要素。
常见的项目流程包括：制定章程——限定范围——计划管控——成本管理——质量核准——风险预案——结项收尾。
小而轻量的互联网公司喜欢采用敏捷开发，小步快走，低成本试错；而中不溜的企业则因为自身规模或产品的构造模式的限制，不得不以项目的形态作为团队衡量输出的一个标准。
然鹅，非传统项目型的企业，在信息化转型的过程中，并非所有产线都具备项目经理这一重要而又业务精深的专职人员。此类工作，常常由产品经理担任。
所以为什么，我们可以经常听到，产品经理也要懂项目管理。实际上，除了因为缺少专职人员，部分对项目管理的了解不能容易陷于停留项目的表层，仅了解其流程最终无法保障项目的质量是否达到预期目标，因此对业务的深浅也要有一定的要求。另外即使有项目经理这一角色，他手上多个项目在并行时，难以协助产品重点推进该产品线的进度和管理。所以，产品经理和项目经理倒是像相互协作的两兄弟，相互配合、协作。
但是，问题难就难在，如果没有项目经理而有产品人员担任的时候，大多产品无权也无责过问项目成员的安排和进程，仅靠人品或个人魅力只会消耗个人的情绪和工作负余。以下有几点建议：
- 组织立项会议时，邀请相关利益方加入，特别是技术团队的老大和产品团队的老大，以及双方的老大大，让其明确授权，包括调配资源、管理团队、进度汇报收集的权利。如果老大无暇参加此会议，则需要书面声明或者邮件周知相关人员，由谁负责或担任此类工作。不要看似简单，其实在很多流程不够规范的公司内，职权是界定不清的，导致相关人员不同程度的甩锅与拖延无责的心态继续摸鱼，另外，群聊记录的口头声明是不可靠的。
- 项目汇报的管控，时间为一周一次或一周两次为宜，记录的内容需包含现阶段人员的一周按日程格子记录的开发进度，以及状态是否正常、延期、完成率的百分比。如有备注要声明人员的具体情况，比如请假、临时任务、其他事项等等，补救措施是调休加班、往后期延或是提前完成不需调补等说明，确保跟上开发计划。进度每周抄送一次项目组成员，利用大众的监督施加适当的压力与责任，而不是产品经理一人对一个技术团队。
- 明确制度，赏罚分明，一旦计划确认完毕，执行者在执行过程中除特殊情况，否则不可随意修改，有明确的赏罚制度，也有一定的奖励制度，但是奖励需要公司层面才能决策的，所以不一定都有，所以部门内看能否通过其他途径给项目成员奖励。奖金的激励一定程度上会促进成员的积极性，赏罚能够规制约束项目成员，否则立不立项、能不能如期完成对成员来说无关痛痒，急的说不定就是产品经理自己。
- 营造参与感与成就感，不管是谁，当做出了一款产品并得到他人的夸赞时，内心的成就感是不言而喻的，是对自己付出的犒劳和自我追求的认同感。所以项目过程中，要确保项目成员能够从中获得自己想要的一些东西，经验也好、金钱也好，赞许或评选鼓励也好，都是可以促进成员的积极性。很不好的是如果都是产品经理一个人在孤军作战，那么项目是真的很难推动，把相关的权益和责任让不同的人员负责，才是对资源的最好分配。
- 项目计划分配，不同的项目计划模板各有不同，细到什么程度因不同公司决定，但是工作任务一定要拆解开来，WBS（工作分解结构）是最常用的一种方式，大化小，小成无。将整体项目划分为不同的工作包，由长期解构为短期，这倒是挺贴合产品经理日常思考模式的，整体——拆解——分析——执行——完成，WBS能直观快速的表现出对每个阶段的任务点及目标，协助清晰的按照计划进行，也便于快速查找问题。
- 风险控制，风险一般包括定性风险和定量风险，此部分比较偏知识论，经验有限的人员常常对风险不能做好全面的预判，高级产品也是因为在项目中不断的总结，避开了遇到过的坑坑洼洼。所以，在项目结束做好总结中或吸取以往项目的经验的维度，是风险控制的初级识别的一个重要方式。其次，可通过头脑风暴，组织项目成员在负责的模块所会碰到的潜在问题，以及产品经理和其他部门对接时的可能性事件，如流程变更、人员离职、需求变更等等，列出表格，预留解决的时间。定量的话是指风险不确定但可被量化，书本的定义是对每一风险发生的概率及其项目目标产生的影响，以及项目整体风险的范围进行数值分析。这类分析通过发生概率的大小而有针对性的采取不同的措施进行规避。
- 需求变更，作为需求发起人，又作为项目监控人，这样的事情简直让人左右为难，一边需要项目如期完成，一边又需要变更增加开发量。当然，需求不是你想变，想变就能变的，往往因为公司层面的硬性要求、领导紧急下发的必要性需求、验收时与初期需求不符、影响核心利益的或市场政策的变化，如产品商标变动、个人信息隐私保护法的推出等等不确定因素，导致项目过程中需要及时的做出调整，调转方向。项目不同进行阶段的变更对项目的风险和影响是不一样的。变动涉及的范围也是不一样的，以不涉及流程变动为例的变更：
影响程度：立项前<立项未开发<立项已开发<开发完成<测试<验收，时间越长，风险成本越大。
- 项目立项后，开始进入开发之初，此时提出变更风险较少，项目计划可以随之调整。
- 进入开发阶段，技术和产品之间会反复确认需求点，到了相应模块时，在前后端技术确认好（不可遗漏任何一边），进行调整，在开发计划中加入变更事项，重新安排计划。
- 开发完成或测试阶段时，这时候提出变更，技术肯定已经有自己的小脾气了，本来已经完工，剩下来就是改改bug等验收了，秃头的毛终于可以减速了；何耐产品经理又贼兮兮的来了，此时耐心的沟通及表明变更的必要性是非常重要的，我们常用领导来说事，但是假如站在领导的立场，恐怕也会在心里小声嘀咕‘常常拿我说事，这个人工作能力不怎么样呀’。所以搬出领导的事情不能过于频繁，毕竟这也可能是最后一张底牌了，久而久之，领导心里就有了对产品人不满意的自我暗示，而，暗示是会固化的且不易消除。
所以怎么办呢？对此不敢说必须有见成效，毕竟项目管理也有百来年的历史了，专家们都没琢磨透呢，只能说通过自己的经验分享一下。
马斯洛的需求原理越来越多人熟知了，但终归还是太泛，请大家吃一顿好像也不能弥补对个人情感的需求，且我是做不来的，毕竟与生俱来的冷场王。所以又还是寻找中规中矩的方式推动了，如（客观地）让项目相关人明白需求变动的原因及重要性，阐明需求的内容和寻找最小变动的可执行方案，计算出潜在价值或改动可带来的收益，会议也是必要的，私下通知没有支撑力。（主观）让他们知道产品是站在他们角度去想问题的，一起吐槽吐槽变动的来源但又无可奈何的态度。
需求变动是真的很常见，而产品经理本身就需要过滤需求，把控项目，大的变更也是有可能中断项目的，所以不能忽视这一点。产品在市场部和项目管理部中间本就是左右为难，除了是个需求传话筒的工具人，我想，更要在其中发挥自己的主观能动性，没有什么产品提出马上就能做出来的，好的产品值得等待，而项目过程所花费的时间和精力就是我们的等待，但是这个等待值不值得，只有市场才能验证。
本文作者 @漂浮柠檬核 。
版权声明
本文来自互联网用户投稿，文章观点仅代表作者本人，不代表本站立场。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如若转载，请注明出处。如若内容有涉嫌抄袭侵权/违法违规/事实不符，请点击 举报 进行投诉反馈！
