成功的开始|做好项目管理(成功的项目管理应该具备哪些条件)

成功的开始|做好项目管理(成功的项目管理应该具备哪些条件)

项目是指受限资源条件下需要完成的任务,项目管理则是在达成任务过程中所开展的各项辅助活动。需要我们明确的是:在项目各阶段应该做什么呢?有哪些技能、工具、方法能够帮我们更好的管理项目,避免走弯路呢?结合以往经验与行业大佬对话,整理出项目管理相关知识。希望能帮到你。

一、什么是项目管理。

什么是项目管理?项目管理在管什么?如何做好项目管理?

网上有很多解释,但大意相同—–项目管理是为了加速项目进展,完成项目目标而发明的一套统筹资源的方法论,

项目的规模大小、复杂程度、涉及角色等情况都存在一定差异。其实项目管理更需要有一种意识,需要通过对自身的环境、资源的观察和思考来选择合适的工具和正确的方法,将项目中复杂的事情梳理起来,不断形成清晰明了的方案,然后一步步的去执行,化整为零,最终让大项目落地。

优秀的项目经理与项目管理一定是高效协调各方资源、反馈及时、调整迅速。同时可以做到让参与方在整个项目过程中张弛有序、愉快合作、最终实现产品项目的效益最大化。

二、项目规划

项目规划作为初始化阶段,主要对项目章程等框架性的内容进行梳理和确认。至少要包含:明确方向、明确目标、明确机制、组建团队。制定里程碑计划。

1、明确方向

项目要做什么东西?要使用表格进行梳理,会让整个项目所有的待办事项看起来更清晰。能避免扯皮,也能根据目的评估优先级。

2、明确目标

项目的目标是什么?。我们不能保证自行推演出的目标就是客户想要的。有的项目看重质量,有的项目要快速上线,有的项目要较低的成本……

所以项目目标需要和客户确认清楚,同时注意不是客户说什么就是什么。需要充分考虑资源的配置情况,制定的项目目标应当符合SMART法则(具体的、可衡量、可达到、相关性、有时限)

3、明确机制

可能会包括沟通机制、协同机制。每个公司与团队沟通风格不同。机制并不相同,如:

沟通之前:先做准备、盘清资源、知道什么重要?找谁要?

沟通时:不卑不亢、说事实、说老实话。

沟通成功:用心做事

沟通失败:别丧,踏实做事、观察局势,等待机会

项目结束:主动回馈、个人复盘。

4、组建团队

谁负责:负责执行和协调整个任务的角色。如产品经理、UI、研发、测试、运营等人员。

谁批准:对任务负全责、对进度进行监督的角色。如项目经理

咨询谁:在任务实施的中提供指导意见的人,一般是受项目影响的部门或个人。如业务、运营部分的同事。

告知谁:当阶段任务完成时需要被通知的人员。如上级领导或客户。

5、制定里程碑计划

其实就是在什么时间点完成什么节点/动作。将目标拆解成一系列行动,并在这些行动敲定优先级,里程碑就是优先级里面最高的那几个行动。

有一个清晰合理的里程碑计划很重要,但同样重要的是一个好的规划,如果连自己想要什么都不清楚,制定的里程碑计划跟形同虚设没什么区别。

三、项目执行

规划成功后,需要制定一个全面、详细、贯穿项目全部阶段的整体执行计划。项目执行是项目团队的行动指南,因此要充分考虑到项目的复杂性。

一个能够被执行的项目应包含以下几点:需求管理、任务分解、信息同步

1、需求管理

需求池的需求总是超过我们的预期的,需求也并不是越多越好,建立需求池的目标也不是一定要把需求做完,时间有限、资源有限、意味着我们要优先完成程度比较高的场景。

从项目规划和目标出发对需求进行管理并不是从功能出发进行管理,一方面通过目标确定某个周期内的需求方向,并因此能够标记出需求的优先级,另一方面拆解到粒度更细的范围内的目标让我们有条不紊的大步前进。

但同时,我们需要根据用户的影响度适当对目标进行调整,同时也对需求优先级进行调整。

2、任务分解

事要一件一件做,可根据项目组内成员构成和能力来进行任务分解,在产品项目中任务分解一般按照功能模块分解相结合的方式。任务颗粒度不能太粗,会看不见细节,把控容易遗漏;太细则过于繁琐,增加管理成本,且无必要。

3、信息同步

我们每天都在和项目组内同事、业务方、运营部门等不同角色的干系人打交道,沟通如此轻松,信息传达如此顺畅,为什么还要特地强调“信息同步”呢?

1、降低项目风险:

团队中不同角色的认知是不同的,信息同步可以让大家达成共识、充分准备,降低项目风险

2、为团队合作提供调整空间:

项目在不可逆的情况下,信息越早公开,挽救的可能性越大。

3、用里程碑事件保留证据:

留痕留痕,拒绝口头承诺、口头传递,即使是面对面交流,也要做好需求记录,经签字确认后进入开发环节,避免后续扯皮。

四、处理能力

从项目经理角色来看,需要做到危机处理、冲突处理、氛围处理、直面情绪等不同纬度的能力

1、危机处理

既然已经发生,那么结果是什么?既然已经发生,损失是什么?

先算清楚帐,回答上述问题,而不是任由情绪在脑中乱冲乱撞,发生危机后第一目标是处理事故,进行纠偏,任何与当前结果无关的事情暂不考虑,如“怼天怼地 指责 谩骂 不能起带头作用”

盘清楚事实比立即行动重要得多,事故需要被解决,只会口头说说而无法付出实际行动的项目经理、负责人是失职的。

2、冲突处理

不同的人员组合在一起,难免会产生摩擦。在职场中也是常见的事情。我的建议是:

1、解决冲突的目的是产生结论,并非扩散情绪

2、创造无负担的表达管理的氛围

3、实事求是,对事不对人是一切的前提

4、理性看待,就事论事,保持职业操守。

适当的冲突可以提高组员对标准的坚持和对项目的严肃程度,适当的冲突是有利于互相监督的,也有利于问题被更全面的考虑。

因此,不要害怕冲突,而是有智慧的运用冲突。

3、氛围处理

建设和管理团队是项目经理工作中重中之重。

人不是机器,精神状态对工作质量起到重要作用。不要让组员一直做迫在眉睫的事情,否则会产生疲惫感、消极感。可以通过一定的方式提高积极性,避免消极、推诿、埋怨等负能量。

提高积极性重点在于了解对方的个人诉求,将诉求和项目结合从而打动对方。团建也不一定是聚餐,或许下午的一瓶饮料也能产生凝聚力……

4、直面情绪

面对计划的事故、人员的性格差异。没有情绪是不可能的,有情绪才是人类的真实反应,可能会沮丧、愤怒、失望。但作为项目负责人,处理事故、冲突、且不能带着情绪工作是基本功。

接受已经发生的一切,调整心态,请勿保持上头状态,否则大概率会进入越做越挫,重复犯错的愚蠢境地。

五、过程监控

项目的所有阶段都在监控范围内。监控的作用在于跟踪、审查、调整项目进展是否偏离计划,如果偏离则及时识别变更和控制变更。为了监控真正起到作用,除了高度的风险意识之外,也需要多样的监控方法辅助。

方法和工具包含但不限于:日站会、项目例会、项目进度表(甘特图)、项目进度看板、项目日/周/月报、定期反馈报告……

随着项目的开展,监控清单不仅包含“制定计划 – 风险控制”的内容,也要及时识别新的风险项。监控内容繁多,应重点关注:整体监控、变更管理……

1、整体监控

整体监控负责全面监控项目的执行是否存在偏差。如果触发风险项,立即按照“风险控制”的计划处理。理论上的监控项有很多,根据项目的实际情况进行选用。比如采购监控、质量监控、时间监控和……

  • 范围监控:确认执行的范围是否符合原计划,不能出现多做、少做、做错等情况。范围变化严重影响各项资源、进度、质量。
  • 预算监控:核对各项预算(资源)的分配和使用情况,是否符合在预定的计划内。

确认异常后,首选是拉回原计划,如果拉不回来需要针对性的处理。

常规处理措施比如:增加人员、增加投入时间(加班)、调整人员、调整工作方法和工具,实在不行就降低要求(缩小项目范围、降低质量要求)。

2、变更管理

不论基于什么原因,不断变更必然导致项目进度的失控,所以需要建立一套规范的变更管理机制,从而使项目变而不乱。

唯一接收入口:任何人都可以提出变更需求,但必须指定一个人做为唯一的接收人,一般由产品经理担任。避免到处是口子,无法统筹全局。

评估变更影响:接收后要严格评估变更对项目的影响,没有定论前的变更不能进入执行阶段。执行人不接受任何非产品经理的变更需求。

变更及时预警:评审通过后更新计划阶段受影响的文件,时间、资源、成本等……重点是及时和相关人员同步变更情况,进行预警。

五、项目收尾

项目收尾是项目流程的最后环节,也是项目的紧要关头。项目完成情况如何,数据验收是否需要补充,后续行为是顺延还是暂时搁置,项目结果与处理情况要及时同步给项目组其他成员,增强成就感。

1. 验收成果

在程序开发完成后就可以开始验收成果。由多角色参与,从各自的角度围绕产品进行测试验收和上线准备。比如:

研发:自行进行单元、集成测试,如有bug可及时在研发团队内部处理。

测试:根据测试用例测试环境进行测试。发现、分析、跟踪bug,并提交测试报告。

产品:需求清单的功能实现是否完整;交互反馈和视觉是否符合规范;产品文档是否更新(需求文档、操作手册…)

验收通过后除了安排产品上线,还需要释放资源和文件归档——释放项目资源,比如项目人员可以投入其他的工作;把项目相关资料进行整理归类,作为档案封存。

2. 项目复盘

通过复盘来发现项目中存在的问题,针对问题找出原因并提出解决方案,从而提高后续项目的质量。

在项目跑起来的过程中,我们一开始的目标是什么,是否有完成以及完成的情况如何,这是复盘过程中优先级别最高的一个问题。

是否有遇到问题/危机,当时是怎么处理的。如果重做一次有没有更好的解决方案,是否能梳理出一个更好的答案,方便以后快速解决这类的问题。

经过项目复盘,不仅要沉淀知识经验,更要利用和分享经验。通过建立起学习型组织,帮助团队得到共同的成长。

六、写在最后

产品规划:就像是海上的灯塔,不能乱打一气;

需求文档:一定要尽可能详细,拒绝无原型的需求评审;

技术方案:是整个项目的灵魂,这块多投入时间绝对不亏;

项目排期:有里程碑、有buffer,排期需包括线上灰度和项目验收时间;

Code Review、测试Case:一个都不能少;

上线方案:要预知风险,为线上的稳定性保驾护航。

最重要的是团队能够构建一个学习型组织,及时总结项目经验,并将经验运用到后续的工作中去。如此才能促使团队成员得到不断成长

相关新闻

联系我们
联系我们
在线咨询
分享本页
返回顶部