项目管理流程

个项目管理的流程分为这么几个阶段:

项目启动——项目计划——项目执行和监控——项目收尾

在整个项目的运转过程中,从最开始的来自领导的战略规划启动了项目,到前期的项目计划、需求转化与中期的项目执行和跟进,以及后期的项目收尾总结会,每一个环节都有产品经理的身影。尤其是在初创公司,产品经理大多数的时间也担任项目经理这样一个角色。所以对于初创公司的产品们来说,了解项目管理的大致流程,合理分配资源就显得更加重要了。

项目启动

在项目管理过程中,启动阶段是开始一个新项目的过程。启动信息技术(IT)的项目,必须了解企业组织内部在目前和未来主要业务发展方向,这些主要业务将使用什么技术及相应的使用环境是什么。

启动信息技术(IT)的项目的理由很多,但能够使项目成功的最合理的理由一定是为企业现有业务提供更好的运行平台,而不是展示先进的IT技术。

每个项目在一个阶段完成后,进入下一阶段之前必须要顺利的通过前面一个阶段的阶段关口控制。要将本阶段的关口控制文件或关口控制审批做好。随着项目不断地向前推进,项目的投入将越来越多。因此,每个阶段都要进行阶段性的审核或检查。上一阶段控制关口提供的文件将是下一阶段的启动文件。

一般意义上的项目启动是在招投标结束了,合同签订之后。

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

  • 为什么要立项?
  • 项目目标是什么?
  • 项目的相关人员都有哪些?
  • 怎么立项?

为什么要立项?

这个时候,作为产品经理的你需要去了解这个项目的来龙去脉,最好的方式是和你的上级或者BOSS沟通,因为他们掌握的信息量远远比你大且比你多,所以通过和他们沟通再加上自己理解,就能够对项目立项的原因有一个清晰的认知。当然,有时候项目立项,可能就是产品版本的定期迭代,这个时候产品经理对为什么要立项恐怕是比谁都更清楚了。

项目目标是什么?

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

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

项目的相关人员都有哪些?

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

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

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

怎么立项?

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

这个时候,项目相关的文档其实应该已经完成了,因为只有当详细的产品需求文档有了之后,开发团队才能估算项目时间及里程碑等。也有另一种情况,那就是项目本身包括了需求分析阶段,所以详细的需求文档是在立项之后才开始进行调研和撰写。不管怎么说,明确的产品需求和详细的需求文档,都是项目得以顺利进行的基本前提保障,所以,产品经理的规划能力、撰写文档的能力在这个时候就显得尤为重要了。

项目计划

在项目管理过程中,计划是最复杂的阶段,项目计划工作涉及九个项目管理知识领域。在计划编制的过程中,可看到后面各阶段的输出文件。计划的编制人员要有一定的工程经验,在计划制定出来后,项目的实施阶段将严格按照计划进行控制。今后的所有变更都将是因与计划不同而产生的。也就是说项目的变更控制将是参考计划阶段的文件而产生的。

完成了项目的启动,接下来就要开始进行项目计划了,所谓的项目计划,其主要工作就是工作任务分解,任务优先级安排,资源、工期、成本估算,以及风险计划和沟通计划等。

工作任务分解

  • 将任务分解到不能再分为止
  • 让任务的粒度足够细

工作任务分解,在项目管理中也有专门的术语叫做“工作分解结构”(WBS),指的是以可交付成果为导向对项目要素进行的分组。它其实归纳和定义了项目的整个工作范围,从项目目标开始分解,逐层下降,每下降一层,代表对项目工作的更详细的定义。

产品经理在每一个版本的迭代规划中,都需要从产品需求池中捞一些比较重要的需求出来放到项目需求里来,这正好符合敏捷开发的思想,饭是要一口一口吃的,项目也是一样,不可能一次性把所有需求都搞定。所以,我们需要通过一个版本一个版本来完成,在做版本的工作任务分解的时候,一定要将任务分解到不能再分为止,任务的粒度一定要细,如果太粗,则很有可能会出现一些任务被忽略,从而影响整个项目的进度和计划。

一般的工作任务分解方法有:按照产品的物理结构分解、按照产品的功能模块进行分解、按照实施过程来进行分解、或者是按照项目的地域分布等。比较常用的是按功能模块来进行分解,再结合产品的实施过程来进行分解。

这里需要注意的是,分解任务的过程中,需要将任务给描述清楚,否则团队成员会不太明确自己究竟要做成什么样子或达到什么样的目标才算任务完成。

项目的工作任务分解,其实也可以运用我们之前提到过的MECE原则去进行检查,工作任务必须全面、清晰、细分,任务责任需要到人,每一个子任务都能够估算工作量和工期。

任务优先级安排

对分解后的任务,排列先后顺序,并利用甘特图工具以及Teambition团队协作工具。

需要留意功能本身在逻辑上的先后顺序,达到计划呈现,可管理工作进程的目的。

任务分配好了,但总有轻重缓急之分。项目里的优先级排序,就是需要产品经理去识别项目任务清单里的各种任务的相互关联和依赖关系,并根据自己对需求优先级的判断,来对项目里各项任务的先后顺序进行安排和确定。

通俗地来说,产品经理要定义的就是先做哪些任务,后做哪些任务。其实这个时候往往又会用到我们在需求管理中使用到的工具KANO模型,通过明确任务的重要度和紧急度来梳理任务的优先级,优先处理的是重要又紧急的任务。

在处理任务的优先级安排时,有另一个非常重要的点需要明白,那就是有些任务与任务之间,存在着前置后置关系,只有在完成了一项任务的时候,我们才能开始下一个任务。所以在规划优先级的时候,需要把这种情况给考虑进去。

计划呈现

很多项目管理的书籍都推荐使用甘特图来进行项目进度计划的制作和呈现,一般都是通过微软的Project、OpenProj等专业软件进行绘制,还可以通过这些专业软件直接查看项目的关键路径。也有一些产品经理或项目经理直接使用Excel来制作项目进度计划表,毕竟他们对于表格的操作熟练程度已经足够驾驭一个项目的进度计划制作。

执行和监控

在项目执行阶段是占用大量资源的阶段,此阶段必须按照上一阶段定制的计划采取必要的活动,来完成计划阶段定制的任务。在执行阶段中,项目经理应将项目按技术类别或按各部分完成的功能分成不同的子项目,由项目团队中的不同的成员来完成各个子项目的工作。在项目开始之前,项目经理向参加项目的成员发送《任务书》。《任务书》中规定了要完成的工作内容、工程的进度、工程的质量标准、项目的范围等与项目有关的内容,《任务书》还含有项目使用方负责主要人的联系方式及地址等内容。

变化管理

技术性项目中问题最集中的方面就是缺少对具体变化的管理控制。要解决这个问题,需要在项目的各方面启用有效的变化管理流程。

解决方法可以很简单,例如被项目团队、项目主办方、相关方认可的流程图。这提醒了项目人员,变化在被接受之前会进行细致地考察,并且提高了变化提案的门槛。审查变化提案的时候,要注意该提案是否对变化有清晰到位的描述。如果变化提案的动因描述得不清不楚,该提案就要打回去,并且要求对变化所带来的益处进 行定量评估。对于那些仅局限于技术解决方案的变化提案,要多打几个问号,因为提案人也许不能全面地判断问题。如果变化提案过多地关注问题的解决,而不注重 实际问题,打回去并要求关注具体的业务形势。

最后,如果不接受某变化提案,一定要做到有理有据。而且,对项目时间、成本、精力等其他相关因素所受的影响,进行合理的估计。

风险控制

通俗地来说,风险就是发生不幸事件的概率。任何一个项目都有风险,这就好比任何一次手术都有风险一样,风险其实是无处不在的,是一种不以人的意志为转移,独立于人的意识之外而存在的事物。

我们先来看看常见的一些风险来源有哪些:

客户没有参与项目

如果你们公司的一个项目恰好是给客户做的一个定制产品,但是在项目启动、计划和执行的阶段,都没有客户的参与,客户只是在最开始的时候给了一份文档,然后在项目收尾的时候来进行验收,中间没有丝毫地参与到项目中来,那么客户一旦发现最后的成果和自己当初设想的需求相去甚远,结果就会变得非常糟糕。客户有可能因此就不同意验收项目,要求项目团队重新返工开发,这个时候造成的工作量及时间的损失、及对相关事件的影响则是不可估量的。

需求不明确或不完整

产品经理的需求说明文档出现不明确或不完整的情况,项目出现风险的概率也会比较大,因为项目的开发成员都是围绕着需求设计文档来进行开发、测试的,如果产品经理能够随叫随到,和开发及时讨论清楚需求,则还能挽回一定的损失;而如果是异地开发,则整个项目便会比较悲催。

项目计划的不合理

项目没有如期完成,很有可能本身项目计划就是有问题的。比如说,团队成员的分工不合理、工期安排的也不合理(一般3个月才能完成的任务,非得要求1个月之内要上线)、资源没有配置到位、工作任务的分解没有细化没有责任到人(这样就会导致项目组的团队成员对自己的任务不太清晰,即使分解了,没有指定到人,也会发现影响项目进展)、还有一个就是任务的优先级安排的不合理,导致后面任务的完成受到影响等。

团队成员的精神状态

一个项目能不能如期按时按质地完成,其中最主要因素还是人的因素,因此团队成员的精神状态也是影响项目成败的风险之一。如果项目成员都如Scrum敏捷开发中提到的团队成员一样,都是自发组织和管理,参与项目的积极性比较高,项目风险就会大大降低。如果项目成员工作态度有问题,互相之间经常推诿任务责任,经常互相埋怨,那么项目的成果则很令人担忧。

领导变更

这里的领导变更,主要是指项目开发到中途,领导突然说这个需求不对,应该朝另一个需求方向开发,那么我们就称之为领导变更。这里的变更,大致分为两种情况,一种是不太伤筋动骨的,也就是只是小的需求修改,不涉及底层架构的重建;另一种呢,则是产品的规划和定位不够清晰,导致修改起来比较伤筋动骨,一个需求方向的改变,就可能让开发重新搭建后台架构,前端很多页面也得跟着修改。当然,有时候产品经理也常常会犯这样的错误,就是中途变更需求,这就要求产品经理在项目策划的时候就把需求都想清楚,尽量减少项目开发到一半需求突然变更的情况。

技术风险

这里说到的技术风险,指的是项目的开发组成员,他们在用代码实施项目的过程中,会发生一系列意想不到的情况,比如开发去做一个从来没有做过的功能,这个时候可能需要先进行技术调研,可能最后的结果是光光是调研事件就话费了一两个礼拜,留着开发的时间几乎仅剩无几。比如说网站挂了,一处理就一天时间进去了,原先手上的项目就只好拖延一天。

质量管理

质量管理提供了另一套搭建项目结构的流程,保证项目领导提出的工作要求一个不落地执行到位。项目质量的标准分两类:行业内实行的全球质量标准,公司或项目独有的质量标准。

如果你的公司实行或接受了质量标准,要注意该标准对你和你的团队有何要求。具体而言,这些标准会包括ISO 9000标准或六西格玛。进而确定质检清单、质控流程及相关要求,并将其与你的项目规划进行整合。项目必须遵守的书面步骤、报告、评估,对团队成员是强有 力的推动,让大家步调一致。标准比你的临时要求更有效。

质量管理流程还能将项目要求与客户心声联系起来。不管你说什么,只要是在传递客户或用户的要求,你都要加以强调。市场调查、标杆分析、客户访谈都是评估和记录用户需求并确定项目要求价值的好工具。

问题管理

项目开展过程中问题的出现不可避免。在项目初期,在资源、工期、优先事项等其他方面为项目的问题管理确定流程。争取让团队支持及时发现、跟踪、解决问 题的流程规定。建立跟踪流程,记录当前问题。问题记录信息包括:问题描述、问题特征或表现(用于沟通)、开始时间、责任人、目前状态、预计结束时间。

处理待解决问题的流程很简单,包括列出新问题的流程、定期复查待解决的问题、处理老问题的方法。对于没有太多组织管理权的项目领导而言,问题跟踪流程 的力量在于让其把握了问题状态和进度的实时信息。一旦问题责任人承诺了问题解决的时限,你可以任意公布问题解决过程中的变数。不管问题责任人是本项目成 员,还是其他项目或部门的成员,谁都不乐意随时将自己的大名置于人们质疑的目光中。问题清单的公开使得掌握该清单的人获得一定的影响力和控制力。

收尾

项目的收尾过程涉及到整个项目的阶段性结束,即项目的干系人对项目产品的正式接收。使项目井然有序地结束。这期间包含所有可交付成果的完成,如项目各阶段产生的文档、项目管理过程中的文档、与项目有关的各种记录等。同时通过项目审计。

在项目的收尾阶段中的主要活动是,整理所有产生出的文档提交给项目建设单位。收尾阶段的结束标志将是《项目总结报告》,收尾阶段完成后项目将进入维护期。

项目的收尾阶段是一个项目很重要的阶段,如果一个项目前期及实施阶段都作的比较好,但是在项目的收尾阶段没有重识,那么这个项目给人的感觉就象虎头蛇尾的工程一样,即使项目的目标已达到,但项目好像总没有完结一样。所以一个项目的收尾是非常重要的,项目的收尾做的好,会给项目的所有干系人一个安全的感觉。项目的收尾还有一个重要的事情,就是要对本项目有一个全面的总结,这个总结不仅对本次项目是一个全面的总结。同时,也是为今后的项目提供一个成功或是有失败经验的案例。