PM笔记（二）--项目管理

2017-08-25 本文已影响0人 TurboLHT

项目经理和产品经理本是两个相关却独立的岗位，很多人会混淆这两个岗位的工作内容。而巧的是项目经理的英文缩写（project manager，PM）和产品经理（product manager，PM）一样，同为PM，或许就奠定了这两者之间不可分割的关系。

实际上在很多没有成规模的互联网公司中，迫于团队规模的限制，产品经理往往会承担一定的（全部）项目管理职能，因此很多产品经理在做好产品管好需求的同时也要同时思考如何管好项目！那么产品经理应该如何做好项目管理呢？下面就“产品经理如何进行项目管理？”给大家带来一些我的想法和总结。

项目管理是个很大很大的话题，本人斗胆铺陈了一些粗浅陋见，并不全面，欢迎各位看官多多指教！

一：项目流程

1.开发模式

瀑布开发
瀑布开发是传统的开发方式，源头就想好了整个过程，需要输出大量的文档，缺点是周期长，速度慢，风险可预见性差，已经被互联网所淘汰了。
迭代开发
迭代开发就是经典的小步快跑，快速迭代的理论指导，开始的时候可能想得不完成，先做一个MVP模型，然后逐步完善的过程，弥补了瀑布开发的缺点。
螺旋式开发
瀑布开发与迭代开发的的结合开发模式，更加强调风险性。
敏捷开发
简单地说，敏捷开发是追求快速产出的一种方法，减少中间过程的内容，例如需求文档。

对比：
瀑布开发、迭代开发、螺旋开发是软件开发周期的模型，区分标准是过程的复杂度和最后产品的完善度。敏捷开发是多种开发方式的集合，它是一种方法，而迭代开发则是一种开发模型。

这里着重强调一下敏捷开发的核心概念：以最简单的方式快速达成目标，并在过程中及时响应外界的变化，做出迅速的调整，多次迭代，小步快跑。

敏捷开发适合小团队和创业团队，能够极大的减少时间上的成本。敏捷开发小组主要的工作方式可以归纳为：PM和RD作为一个整体工作；按短周期迭代工作；每次迭代交付一些成果：关注业务优先级；机动检查与调整。

详细介绍点这里===>>软件项目的开发模式

2.项目流程

启动期：

任何一个项目，能够被启动，从战略层面是得到了公司认同和支持的，也就意味着这个项目是要背负着实现公司的某一个战略目标而存在的。产品经理在项目启动前，有这么几个问题需要提前去了解和熟悉：

第一个问题，为什么要立项？

这个时候，作为产品经理的你需要去了解这个项目的来龙去脉，最好的方式是和你的上级或者BOSS沟通，因为他们掌握的信息量远远比你大且比你多，所以通过和他们沟通再加上自己理解，就能够对项目立项的原因有一个清晰的认知。

第二个问题，项目目标是什么？

产品经理作为项目的负责人，是一定要明白整个项目的目标是什么，然后在里面找出最核心的目标。例如有的项目是时间（越快越好，花多少钱无所谓），有的项目是钱（做慢点没关系，但是要花最少的钱）。这些都可以通过跟你的领导聊一聊得出这些信息，知道了项目目标后你需要把这个目标用准确的文字写下来。

对，一定要写下来，因为口说无凭，再一个写下来的东西才能成为所有人具体执行的方向和准则。

第三个问题，项目的相关人员都有哪些？

关于干系人，宝洁的方法论是找出PACE。P是Participant（参与者），A是Approver（审批者），C是Consultant（顾问），E是Executor（执行者）。当然，产品经理（尤其是创业公司的产品）在日常的项目工作中，恐怕不会有这么繁琐的流程，所以，也就遵循一切从简的原则。

项目相关人员，可以从这几个角度去考虑下，如哪些人或部门会受到项目结果的影响，哪些人可为项目提供资源（人、财、物）等。当然，在互联网公司，常见的相关人员也就是老板、产品经理、项目经理、项目团队（包含设计、开发、测试、运维等）及用户等。

找到了项目的相关人员后，现在你要做的就是把团队成员绑到自己的船上。你需要去了解团队里每个成员的核心KPI，也就是他们于这个项目的需求是什么，做这个项目可以给他们带来什么。如果这个项目没被囊括在这个成员的工作评价 list 里面，你需要去找他的老板沟通。根据我的经验，85%出工不出力的情况都是因为你的项目根本不会对这个成员的KPI有什么正向的帮助。当然，如果找他的老板沟通无效，还有最后一招，感情投资，请那个成员撸串、吃饭，利用感情让他帮你做好这个项目。

第四个问题，怎么立项？

通常来说，这个时候需要开一个项目启动大会。这个启动大会的目的是召集项目团队成员，成员之间初步认识一下，产品经理主持会议，然后清楚地传达项目要做什么，目标是什么，为什么要做，怎么做，谁来做等等。另外，跟所有的启动大会一样，项目的启动大会，也需要给团队成员来点鸡汤、打点鸡血。产品经理需要去统一团队的思想，明确团队的管理和运作方式，以及团队的沟通机制等，产品经理需要动员团队成员积极参与项目，并高质量地完成项目。

规划期：

1.需求收集和需求清单
这个时候，项目相关的文档其实应该已经完成了，因为只有当详细的产品需求文档有了之后，开发团队才能估算项目时间及里程碑等。明确的产品需求和详细的需求文档，都是项目得以顺利进行的基本前提保障，所以，产品经理的规划能力、撰写文档的能力在这个时候就显得尤为重要了。
2.项目分解，工时预估
拿到一个项目首先应该做的事就是将项目分解，并落实到每个人。这算是项目经理最核心的一项工作之一！
一个完整的项目可以分为产品经理整理需求和画原型，设计师画视觉草图，前端工程师的页面重构和动效制作，后端工程师完成数据接口的开发和一些功能的实现。而项目经理应该做的，就是评估各部分需要的工时，并作出项目进度计划。
3.利用工具对项目排期

排期是项目经理的一项基本能力，根据项目的大小，要用到很多种工具，但应用最多的无疑就是甘特图。甘特图就是以图示的方法将项目各部分，持续时间和时间节点形象清晰地表示出来的一种图表。通过甘特图，项目经理可以直观的知道项目是否按照计划进行或是在哪一部分出了问题。

而画甘特图的工具很多，Microsoft project、viscro、xmind都可以画，但我比较倾向使用ppt和excel画，一是使用方便，也很直观；二是大部分同事都有这两个软件。
当然这个阶段还涉及到成本的估算、质量管理规划、人力资源规划、风险管理等问题，由于涉及到的知识更加的专业，这里就不再赘述了（其实是我不太懂）！

执行期&监控期：

执行期&监控期都处在项目具体实施的阶段，这里我就将二者合并来说。

任务清单和项目周报是项目实施阶段质量监督和进度监督的重要工具。

任务清单列表：是一组当前迭代选出的任务代办事项列表，该列表由项目组成员维护，并交由测试人员监控。
项目组成员根据迭代计划对需求进行分解，将需求分解为一个个可以独立部署的任务计划，测试团队根据项目组成员给出的任务清单跟踪任务完成情况并督促开发人员提测，做到持续集成。项目组成员确保把最优资源投入到高优先级需求上。
任务分解（WBS）：作为产品经理代理项目经理，很难做好任务分解和进度评估工作，需要产品经理有一定的技术功底，能够大概知道背后的实现逻辑如何；另外你还必须充分信任开发团队，信任他们所给出的时间节点。

项目周报：是对一周项目迭代的情况汇报以及下周项目组的工作计划，另外对于项目管理过程中出现的一些问题，例如流程上的漏洞、资源的欠缺都要及时向上反馈，以便获得领导的支援，切忌报喜不报忧。

收尾期：

此阶段的工作就是测试和上线&部署、迭代总结；

上线
上线是项目开发的最后一环，这之前要经历测试（单元、黑白盒、性能）、验收环节；APP类产品还要涉及到上线应用商店的审核准备工作，以及上线后的紧急Bug修复以及运维工作！每个公司都有自己的一套标准的上线流程，尽可按照既定的流程推进上线即可，但做到这里需要提醒一点，一定要做好工程的备份和版本管理工作，便于后期的Bug修改和需求更新工作！
迭代总结

在每个迭代结束后，整个团队要聚在一起召开迭代回顾会议，识别出哪些做得好，哪些做得不好，所有人都必须发言。迭代回顾会议的目的是为了找出潜在的改进事项，为将来的改进制定计划。迭代总结是在整个项目管理过程中，比较重要的一个环节。迭代总结的重要性在于，它能如实的反映项目迭代过程中存在的一些问题，并根据这些问题进行跟踪改进。

3.关键活动

立项会
内容：明确战略目标和核心价值
目标：确定项目的可行性和价值
输出：立项书
需求评审
内容：通过评审委员会筛选收集到的需求，分析需求、对需求归类、确定需求的优先级。
目标：确定产品需求池
输出：需求清单
可行性评审
内容：评审小组对初步的产品方案进行可行性评审，主要由技术团队发现其中可能存在的问题，给出建议。产品经理根据评审小组给出的建议优化产品方案，确保进入迭代阶段时应该为当时最优的产品方案。
目标：保证产品方案的可行性
输出：产品原型和PRD
进度评审
内容：每个迭代以进度评审会作为开始，项目组成员从需求清单中挑选出高优先级需求并配合产品目标组成当前迭代的计划。项目组成员对需求进行拆解，形成一个个可独立部署的任务，并对工作量进行评估，若超出迭代周期则需要压缩工作量或移出需求。
目标：评估工作量的粒度
输出：任务清单
每日立会
内容：每日站立会议在同样的时间和同样的地点召开，会议准时开始。每日站立会议不得超过15分钟，每一个开发团队的成员都必须发言，会议中不进行讨论，发言内容需提供以下信息：昨天完成了什么？今天即将做什么？遇到了什么困难？
目标：帮助团队快速发现问题
输出：日会记录
测试用例评审
内容：产品经理或QA经理主持会议，对测试用例清单进行评估和分析
目标：确认测试用例的有效性和全面性
输出：测试用例清单（User Case List）
迭代总结会
内容：迭代总结是在整个项目管理过程中，比较重要的一个环节。迭代总结的重要性在于，它能如实的反映项目迭代过程中存在的一些问题，并根据这些问题进行跟踪改进。
目标：总结项目经验和教训
输出：迭代总结会议纪要

二：团队管理

1.角色

评审委员会
评审小组是由开发团队leader组成的团体，评审小组从系统实现的角度评估需求的合理性、可行性，对产品的设计提出建设性意见。

评审小组的职责义务：
1.协助产品经理评审方案的可行性，找出产品方案可能存在的问题
2.协助产品经理评估方案预期的工时，让产品经理心中有数
3.协助产品经理分析方案对其他模块的影响，做好跨产品线协作

产品经理：
产品经理作为产品的第一责任人，负责带领团队做出有价值的产品。

产品经理的责任和义务：
1.清晰地表达产品的需求清单（需求记录清晰，没有歧义）
2.对产品需求清单的条目进行归纳（同类需求合并，大需求拆分，前置需求后置需求归类）
3.确保开发团队所执行工作的价值（解决用户的实际问题）
4.确保需求清单对所有人可见、透明、清晰，并指示团队的下一步工作（需求清单公开）
5.确保开发团队对产品需求清单中的条目达到一定程度的理解

项目经理：
项目经理是项目进度、项目质量的监督者，负责团队的进度跟踪和质量把控，在敏捷迭代的模式中，项目经理是一个服务式的领导。

项目经理服务于产品经理：
1.清晰地和开发团队沟通愿景、目标和需求清单
2.找到有效管理需求清单的技巧
3.理解长期的产品规划
项目经理服务于团队：
1.指导开发团队自组织完成产品迭代
2.领导开发团队创造高价值的产品
3.帮助开发团队移除进展过程中的障碍
4.协助开发团队进行需求分解

项目组成员：
项目组成员作为需求的实现者，按照迭代计划完成产品需求，交付高质量的产品包。只有开发团队的成员才能创造产品的增量（产品增量通常指一次迭代交付的可用的软件包）。通常项目组成员包括：前端开发、后端开发、UX、QA、运营等人员。

2.人员管理

人员管理涉及到：人力资源规划、项目成员的培训、沟通机制的建立和维护等工作，尤其是人力资源这块的工作是非常专业化的，我就不误人子弟了。这里我着重的讲讲沟通机制和人员管理原则！

互相尊重
在项目管理过程中，你可能会遇到在项目进行到某一阶段，遇到了突发情况，项目无法正常进行下去。此时，某些项目管理者可能会使用自己的职能，直接提出解决方案，让项目成员执行。敏捷迭代的方法论中有说，团队要自组织，要尊重团队每个人员的专业能力。项目经理代表的不是他的专业能力，而是代表他所管理的这个群体的整体利益，这种情况你唯一要做的事情，就是帮他排除障碍，如果他需要讨论，你就帮助他召集相关人员讨论；如果他需要查阅资料，你就帮他准备好相关的材料。当你尊重了别人的能力，你也会收获更多的尊重和领导力。
开放交流
做项目管理，除了需要管理项目迭代，还需要管理人。员工处于什么状态，你心理是否有数，那个谁谁谁最新为什么情绪这么低落，那个谁谁谁最近为什么这么消极，那个谁谁谁最近表现还可以，那个谁谁谁最近实现的需求老是出严重bug是不是遇到了什么事情。有些事情需要项目经理主动去了解，而不是听取他人的评论，多沟通，多交流，是做项目管理另外一件重要事情。不良的风气很容易影响团队的价值倾向，我曾经在一家公司工作时，离职的时候，整个团队几乎全部解散，就是因为消极的团队氛围导致。
帮助团队成员成长
最后这一点，是我做项目管理以来，感触最深的，也是我学习到的最宝贵的经验。我所代表的是团队整体的利益，对外我是项目组的产品/项目经理，别人认可你是因为你的团队是执行力最强的团队，而别人的对你的认可来自于团队成员每一个人的付出，你无法居功自傲的说是因为你自己很牛逼。
为帮助团队成员成长，你需要做的事情是：把成员付出的努力及时的让上级知晓，做到这一点并不难，只需要在周报中，时不时的告知上级，谁谁谁在这次迭代中，花了多少心思，为项目付出了多大努力，为其争取尽可能的福利。另外，鼓励成员互相分享心得，把自己的经验与他人共享，共同成长。最后，当团队遇到问题时，你要作为第一责任人主动思考原因，而不是直接责问他人为什么没有把事做好。除了这些，帮团队争取福利，组织好的拓展活动，加强团队成员之间的凝聚力，这些都是作为项目经理力所能及的。

3.资源

了解公司对项目的总体投入情况，在战略预算框架内为项目团队争取最大化的资源和利益！
总结下来就是三件事：要钱！要人！要时间！

三：工具

1.文档

立项报告：
立项报告，是在某一项目早期，当项目条件还不够成熟，对项目的具体建设方案还不够明晰，且仅具有规划意见书的时候，对拟建项目提出的框架性的总体设想。立项报告主要从宏观上论述项目设立的必要性和可能性，把项目投资的设想变为概略的投资建议，立项书的呈报可以供项目审批方做出初步决策。

主要包含内容：项目简介；团队简介；市场分析；痛点分析；解决方案；商业模式；竞品分析......

*需求文档：

需求清单在其他的一些互联网产品团队中，也被称为需求池，顾名思义需求清单是一个用来记录各渠道来源的需求、所涉及的产品、需求的优先级、需求状态以及发布时间的一个清单。

需求清单中有几项是需要特别注意的：
描述：描述是用来记录需求的详细信息，描述中的语言一定不能产生歧义，否则会给开发团队带来困扰。
优先级：优先级决定了需求调研的先后顺序、需求开发的先后顺序，我们采用四象限的方式来定义需求的优先级。
状态：状态标记了需求目前所处的情况，需求清单应该是一个公开的清单，任何人都可以查看清单的信息，因此状态一定要跟实际情况一致，及时反映需求的进展。
提出人：提出人信息是为了方便对需求进行追溯，由谁提出的需求，后续关于该需求的变更都要及时告知提出者。

任务清单：
任务清单列表是一组当前迭代选出的任务代办事项列表，该列表由项目组成员维护，并交由测试人员监控。
项目组成员根据迭代计划对需求进行分解，将需求分解为一个个可以独立部署的任务计划，测试团队根据项目组成员给出的任务清单跟踪任务完成情况并督促开发人员提测，做到持续集成。项目组成员确保把最优资源投入到高优先级需求上。
排期表：
对项目团队的任务进行时间上规划和安排，根据项目团队的大小，排期表有不同的详细程度，通过多层级的分配将时间安排到每一个人。排期表切记要有据可循并且时间安排条理清晰。在排期表编制完成后，要和团队所有人共享，让每个人都清晰的知道自己的工作安排和时间节点。
排期表的形式并不固定，你可以使用Excel甘特图、时间看板、管理软件等工具，做到：工作量估算有据、时间节点控制精确、里程碑明确即可！
项目报告：
项目报告是对一段时间内（周or月）项目迭代的情况汇报以及下一阶段项目组的工作计划，另外对于项目管理过程中出现的一些问题，例如流程上的漏洞、资源的欠缺都要及时向上反馈，以便获得领导的支援，切忌报喜不报忧。
迭代总结报告：
迭代总结是在整个项目管理过程中，比较重要的一个环节。迭代总结的重要性在于，它能如实的反映项目迭代过程中存在的一些问题，并根据这些问题进行跟踪改进。
记录问题只是其中的一部分，重要的是作为项目经理的你有没有事后去推动改良这些事情，不然迭代总结只是一个形式主义。