一文实践项目管理

项目管理能力

这里只介绍项目管理,不涉及到项目集、项目组、运营领域

采用基于过程的方法的项目可以将以下五个过程组作为组织结构:
▶ 启动。定义一个新项目或现有项目的一个新阶段,授权开始该项目或阶段的一组过程。
▶ 规划。明确项目范围,完善目标,为实现目标制定行动方案的一组过程。
▶ 执行。完成项目管理计划中确定的工作,以满足项目需求的一组过程。
▶ 监控。跟踪、审查和调整项目进展与绩效的一组过程,该过程识别任何计划需要变更的领域,并启动相应变更。
▶ 收尾。正式完成或结束项目、阶段或合同时所执行的过程。
变更成本

一、启动

收集需求

收集哪些需求

收集信息。有时,可以通过发现更多信息(如进行研究、争取专家参与或进行市场分析)减少不确定性。进一步的信息收集和分析何时会超过获得额外信息的益处,认识到这一点也很重要。

在此阶段,提出问题以帮助为项目奠定基础,例如:
利益相关者是谁?
客户或顾客的目标是什么?
该项目的目的和使命是什么?
团队的可衡量目标是什么?
该项目试图改进什么?
这个项目需要什么时候完成?
该项目需要哪些技能和资源?
该项目的成本是多少?有哪些好处?

启动时可能你需要写项目章程
项目章程是由项目启动者或发起人发布的,正式批准项目成立,并授权项目经理使用组织资源开
展项目活动的文件。它记录了关于项目和项目预期交付的产品、服务或成果的高层级信息,例如:
uu项目目的;
uu可测量的项目目标和相关的成功标准;
uu高层级需求;
uu高层级项目描述、边界定义以及主要可交付成果;
uu整体项目风险;
uu总体里程碑进度计划;
uu预先批准的财务资源;
uu关键相关方名单;
uu项目审批要求(例如,用什么标准评价项目成功,由谁对项目成功下结论,由谁来签署项目
结束);
uu项目退出标准(例如,在何种条件下才能关闭或取消项目或阶段);
uu委派的项目经理及其职责和职权;
uu发起人或其他批准项目章程的人员的姓名和职权。
项目章程确保相关方在总体上就主要可交付成果、里程碑以及每个项目参与者的角色和职责达
成共识。

收集方式

KJ 方法

指示

  1. 安排一次小组会议和一个房间。你需要至少 5 名参与者才能产生足够多的想法。

  2. 选择主持人。该主持人负责构思设计挑战。

  3. 参与者提出多种想法并将它们写在便签上。

  4. 收集想法便签,打乱顺序,然后分发。任何人都不应该得到自己的想法。

  5. 主持人将想法记录在活动挂图上,然后朗读出来。在此阶段,任何人都可以要求澄清提出并记录的任何想法。将想法分类(将便签贴在墙上或白板上)。最多 10 个组!

  6. 投票选出最佳创意,这样每个小组都有明确的获胜者。讨论这些见解。

  7. 个人对想法拥有所有权,并负责在规定期限内实施或进一步开发每个想法。

笔记

虽然可以讨论所有事项,但不允许辩论或批评想法。

输出

设计解决方案的起点以及行动和方向的优先级列表。

下一个

将 KJ 方法与实际概念和原型方法相结合来实现您的想法。

输出

在这里插入图片描述

二、规划

知识领域项目管理过程组启动过程组规划过程组执行过程组监控过程组收尾过程组
4. 项目整合管理4.1 制定项目章程4.2 制定项目管理计划4.3 指导与管理项目工作
4.4 管理项目知识
4.5 监督项目工作
4.6 实施整体变更控制
4.7 结束项目或阶段
5. 项目范围管理5.1 规划范围管理
5.2 收集需求
5.3 定义范围
5.4 创建WBS
5.5 确认范围
5.6 控制范围
6. 项目进度管理6.1 规划进度管理
6.2 定义活动
6.3 排列活动顺序
6.4 估算活动持续时间
6.5 制定进度计划
6.6 控制进度
7. 项目成本管理7.1 规划成本管理
7.2 估算成本
7.3 制定预算
7.4 控制成本
8. 项目质量管理8.1 规划质量管理8.2 管理质量8.3 控制质量
9. 项目资源管理9.1 规划资源管理
9.2 估算活动资源
9.3 获取资源
9.4 建设团队
9.5 管理团队
9.6 控制资源
10. 项目沟通管理10.1 规划沟通管理10.2 管理沟通10.3 监督沟通
11. 项目风险管理11.1 规划风险管理
11.2 识别风险
11.3 实施定性风险分析
11.4 实施定量风险分析
11.5 规划风险应对
11.6 实施风险应对
11.7 监督风险
12. 项目采购管理12.1 规划采购管理12.2 实施采购12.3 控制采购
13. 项目相关方管理13.1 识别相关方
13.2 规划相关方参与
13.3 管理相关方参与13.4 监督相关方参与

选用项目模型,即选定哪种方法

规划过程三大审计

成本计算

还应该包含质量管控成本,与项目有关的质量成本 (COQ)

  • 预防成本。 预防特定项目的产品、可交付成果或服务质量低劣所带来的相关成本。
  • 失败成本(内部/外部)。 因产品、可交付成果或服务与相关方需求或期望不一致而导致的
    相关成本。

质量保证

适用于本过程的数据表现技术包括(但不限于):

规划实践

V1决定里程碑包括:
选定技术方案
每个阶段时间
对项目采用绝对估算
根据项目类型确定交付节奏
给每个部分赋予责任人

V2优化计划:
将质量融入项目和产品的规划和设计中。
为多种结果做好准备,初始解决方案不可行或无效时有可用的备份或应急计划。

v3尽可能细节
创建工作分解结构(WBS)

  • 适当的细分:WBS 的每一层级应细化到便于管理和控制的程度,但不要过度细分,否则可能导致管理复杂度增加。
  • 可交付成果:确保每个工作包(WBS 的最小单元)都能产生明确的可交付成果。
  • 团队协作:不同的任务可以分配给不同的团队成员,根据其技能和专长进行合理分配。

WBS 词典

活动清单

示例一个算法需求

WBS

  1. 项目启动
    1.1 项目计划
    1.2 团队组建
    1.3 需求分析
  2. 需求分析与设计
    2.1 需求收集与分析
    2.2 系统设计
    2.3 算法设计
    2.3.1 算法选择
    2.3.2 算法优化
    2.3.3 算法验证

WBS 词典示例

工作包 2.3.2: 算法优化

  • 工作包名称:算法优化
  • 工作包编号:2.3.2
  • 描述:优化选定的算法以提高其性能和准确性。
  • 范围:包括优化算法参数、改进算法结构、减少计算时间等。
  • 可交付成果:优化后的算法模型、优化报告
  • 主要活动:
  • 分析当前算法性能
  • 确定优化目标
  • 进行参数调整
  • 测试和验证优化效果
  • 资源需求:算法工程师、计算资源
  • 责任人:算法团队负责人
  • 估计时间:2周
  • 估计成本:$10,000
  • 依赖关系:依赖于工作包2.3.1算法选择

活动清单示例

活动清单:工作包 2.3.2 算法优化

  1. 活动名称:分析当前算法性能
  • 描述:对当前算法的性能进行分析,找出改进点。
  • 责任人:算法工程师
  • 估计时间:2天
  1. 活动名称:确定优化目标
  • 描述:根据分析结果,确定优化目标,如提高准确率或减少计算时间。
  • 责任人:算法团队负责人
  • 估计时间:1天
  1. 活动名称:进行参数调整
  • 描述:通过调整算法参数,尝试不同配置以优化算法性能。
  • 责任人:算法工程师
  • 估计时间:5天
  1. 活动名称:测试和验证优化效果
  • 描述:对优化后的算法进行测试,验证其性能改进情况。
  • 责任人:测试工程师
  • 估计时间:2天
  1. 活动名称:编写优化报告
  • 描述:总结优化过程和结果,编写优化报告。
  • 责任人:算法工程师
  • 估计时间:1天

选定哪种方法

分别定义如下(对于整个项目,没有必要使用单一的方法。为达到特定的目
标,项目经常要结合不同的生命周期要素。预测、迭代、增量和/或敏捷方法的组合就是一种混合方法。即同时使用多种方法或不同生命周期选取不同方法)
在这里插入图片描述
u 预测型生命周期。这是一种更为传统的方法,提前进行大量的计划工作,然后一次性执行;执行是一个连续的过程。
u 迭代型生命周期。即画多个原型直至客户满意再开发,这种方法允许对未完成的工作进行反馈,从而改进和修改该工作。
u 增量型生命周期。这种方法向客户提供各个已完成的,可能立即使用的可交付成果,通常是为了让客户马上看到效果。
敏捷生命周期。这种方法既有迭代,也有增量,便于完善工作,频繁交付。

敏捷方法

敏捷开发中的相应工具和实践

  1. 产品待办事项列表(Product Backlog)

    • 类似于WBS,产品待办事项列表是一个包含所有需要完成的功能、改进和修复的优先级排序清单。每个条目(通常称为“用户故事”)都是待开发的功能或需求。
  2. 迭代/冲刺待办事项列表(Sprint Backlog)

    • 迭代待办事项列表是从产品待办事项列表中选出的要在当前迭代(通常为2-4周的时间框架内)完成的任务。这个列表细化了具体的工作项(通常称为“任务”),类似于传统的活动清单。
  3. 任务板(Task Board)

    • 任务板是一个可视化工具,用于跟踪当前迭代中的任务状态。通常分为“待办”、“进行中”和“已完成”等列,帮助团队成员实时了解工作进展。
  4. 用户故事(User Stories)

    • 用户故事是描述功能需求的简短陈述,通常采用以下格式:“作为[角色],我希望[功能],以便[价值]”。用户故事可以细化成更小的任务,以便更好地管理和执行。
  5. 看板(Kanban)

    • 看板是一种帮助团队管理工作流程和提高效率的工具。它通过可视化工作进展,限制进行中的工作量,确保团队能够高效地完成任务。

三、执行

四、监控/项目进度管理

每日站会

团队成员利用每日站会对彼此做出小的承诺,发现问题,并确保团队工作顺利进行。从这样的问题得出的答案能够让团队自我组织,并让团队成员为完成之前和整个迭代中承诺完成的工作承担彼此的责任。
为每日站会规定时间盒,不超出 15 分钟。团队以某种方式“过一下”看板或任务板,而团队中的任何人都可以主持站会。

在基于迭代的敏捷中,每个人都轮流回答下列问题:

  • 上次站会以来我都完成了什么?
  • 从现在到下一次站会,我计划完成什么?
  • 我的障碍(或风险或问题)是什么?
    上次站会以来我都完成了什么?

示例:

技术员A:自上次站会以来,我完成了用户认证模块的开发,并提交了代码审查。

从现在到下一次站会,我计划完成什么?

技术员A:今天,我计划修复在代码审查中发现的用户认证模块中的几个小问题,然后开始工作在用户权限管理模块上。

我的障碍(或风险或问题)是什么?

技术员A:目前没有遇到障碍。如果在处理用户权限管理模块时需要更多的需求细节,我会联系产品经理。

基于流程的敏捷有一种不同的方法,可以将注意力集中在团队的产出上。团队从右到左对看板进行评估。问题包括:

  • 我们还需要做些什么来推进这一工作?
  • 有人在做看板上所没有的事情吗?
  • 作为一个团队,我们需要完成什么?
  • 工作流程是否存在瓶颈或阻碍?

示例:
我们还需要做些什么来推进这一工作?

技术员A:我们需要完成用户认证模块的代码审查,尽快将其合并到主分支。

有人在做看板上所没有的事情吗?

技术员A:没有,我的工作都在看板上记录了。

作为一个团队,我们需要完成什么?

技术员A:我们需要优先处理用户认证模块的合并,以便后续功能的开发可以顺利进行。

工作流程是否存在瓶颈或阻碍?

技术员A:目前代码审查的速度有些慢,可能需要更多的审查人手,以确保不影响整体进度。

站会也会有常见反模式

  1. 状态报告会议的反模式:
    描述:站会(Daily Stand-up)变成了状态报告会议,团队成员逐个汇报他们的工作进展,像在向上级汇报一样。
    问题:这种做法违背了敏捷方法中的站会原则,站会的目的是为了团队沟通和协作,而不是单纯的汇报进展。
    优化:让每个人都轮流主持。站会应该简短高效,强调团队成员之间的沟通,识别和分享障碍,确保团队协作顺畅。

  2. 问题发现与解决的反模式:
    描述:团队在站会上发现问题,但不在站会上解决,而是仅仅记录下来,留待后续的会议解决。
    问题:如果在站会上不及时解决紧迫的问题,可能会延误解决问题的时间,影响项目进度。
    优化:在站会上应该快速识别并记录问题,但对复杂问题应创建专门的会议进行详细讨论和解决,以避免站会过长。

关键节点回顾

团队成员可以决定在这些关键时刻进行回顾。回顾针对定性的(人的感觉)和定量的(衡量指标)数据,然后利用这些数据找到根源,设计对策,并制定行动计划。项目团队可以采取许多行动事项来消除障碍。
来自团队的一位促进者引导团队通过一个活动对所有改进事项的重要性进行排序。完成对改进事项的排序后,团队为下一次迭代选择合适的数量(或者在流程基础上增加工作)

  1. 团队可以通过分配足够的时间学习受益

  2. 需要了解他们的工作产品和工作过程。例如,有些团队在完成工作时遇到困难,团队可以计划用充足的时间组织回顾,以此收集数据、处理数据、再决定之后要尝试的实验做法。比如定期代码优化

  3. 在时间允许的情况下,团队可以进行列表中的下一个改进。团队选择改进时,要决定如何衡量结果。然后,在下一段时间内要衡量结果,以验证每个改进成功与否。

采用监控指标
常见的方法为,注意替代衡量指标(如完成百分比)不如经验指标(如已完成功能)更有用,以下两类图我感觉是挺有用的。
在这里插入图片描述

在这里插入图片描述
在这里插入图片描述

误用度量指标
尽管存在用于测量绩效的度量指标,人们可能会扭曲测量指标或专注于错误的事情。范例包括:
▹ 专注不太重要的度量指标,而不是最重要的度量指标;
▹ 专注于做好短期测量指标的工作,而以牺牲长期度量指标为代价;▹ 为了改进绩效指标,开展易于完成的无序活动。

五、收尾

项目或阶段行政收尾必要活动

为达到阶段或项目的完工或退出标准所必须的行动和活动

  • 确保所有文件和可交付成果都已是最新版本,且所有问题都已得到解决
  • 确认可交付成果已交付给客户并已获得客户的正式验收
  • 确保所有成本都已记入项目成本账
  • 关闭项目账户
  • 重新分配人员
  • 处理多余的项目材料
  • 重新分配项目设施、设备和其他资源
  • 根据组织政策编制详尽的最终项目报告

为关闭项目合同协议或项目阶段合同协议所必须开展的活动

  • 确认卖方的工作已通过正式验收
  • 最终处置未决索赔
  • 更新记录以反映最后的结果
  • 存档相关信息供未来使用

为完成下列工作所必须开展的活动

  • 收集项目或阶段记录
  • 审计项目成败
  • 管理知识分享和传递
  • 总结经验教训
  • 存档项目信息以供组织未来使用

为向下一个阶段,或者向生产和(或)运营部门移交项目的产品、服务或成果所必须开展的行动和活动

收集关于改进或更新组织政策和程序的建议,并将它们发送给相应的组织部门

测量相关方的满意程度

复盘与成长

每个项目结束后都要做两件事,一件事是复盘,一件事是庆祝/奖励优秀成员。复盘方法

  1. 项目回顾会议(Post-Mortem Meeting)
    会议安排:在项目结束后的一周内安排全体项目成员参加项目回顾会议。

讨论内容:
成功之处:识别并讨论项目中取得的成功和亮点。
挑战和问题:探讨项目中遇到的挑战和问题,分析其原因。
改进建议:针对识别出的问题,提出改进建议和措施。
2. 经验教训总结(Lessons Learned)
文档编写:将项目中的经验教训记录在案,包括成功经验和失败教训。即经验登记册
分享与存档:将经验教训文档分享到项目管理知识库中,供未来项目参考。
3. 团队成长计划(Team Growth Plan)
技能提升:根据项目中发现的技能缺口,制定团队培训和技能提升计划。
技术培训:例如针对新技术或工具(如FastAPI、Jenkins)的深度培训。
软技能培训:如沟通技巧、时间管理、问题解决能力等。
个人发展计划:针对每个团队成员制定个性化的发展计划,帮助他们提升专业能力和职业发展。
4. 过程改进计划(Process Improvement Plan)
敏捷流程优化:评估Scrum框架的应用效果,提出改进建议,优化敏捷流程。
工具和方法改进:评估项目中使用的工具和方法(如CI/CD、自动化测试),优化其应用。
风险管理:回顾项目中的风险管理过程,提升风险识别和应对能力。
5. 持续改进机制(Continuous Improvement Mechanism)
定期回顾:设立定期项目回顾机制(如每季度一次),持续监控和改进项目管理流程。
反馈循环:建立有效的反馈机制,确保团队成员可以随时提出改进建议。

最终形成团队wiki

向上复盘
财务测量指标可能包括(但不限于):
净现值 (NPV);
投资回报率 (ROI);
内部报酬率 (IRR);
回收期 (PBP);
效益成本比率 (BCR)
达到商业论证的非财务目标;
完成组织从“当前状态”转到“将来状态”;
履行合同条款和条件;
达到组织战略、目的和目标;
使相关方满意;
可接受的客户/最终用户的采纳度;
将可交付成果整合到组织的运营环境中;
满足商定的交付质量;
遵循治理规则;
满足商定的其他成功标准或准则(例如过程产出率)。

项目风险管理

好的项目经理就是能巧妙应对各种变化,可以通过风险登记册去定义风险。
在这里插入图片描述

识别风险

即可能出现原始项目带来的次生风险

常见风险

如何增加项目韧性
  • 较短的反馈循环:快速适应变化。
  • 持续学习和改进:不断优化项目。
  • 多技能组合团队:团队成员具备多样化技能,同时拥有各领域专家。
  • 定期检查和调整:识别并抓住改进机会。
  • 开放和透明的规划:让所有干系人参与。
  • 小规模原型法和实验:测试新想法和方法。
  • 新思维和工作方式:灵活运用创新方法。
  • 平衡速度和需求稳定性:设计高效流程。
  • 组织的开放对话:促进沟通和协作。
  • 理解过去经验:从历史项目中学习。
  • 多情景预测和准备:为各种可能情况做好准备。
  • 推迟决策到最后责任时刻:增加灵活性。
  • 管理层支持:获得高层支持和资源
项目变更怎么办

先确定优先级

项目需求就是模糊的怎么办

当可能出现多个结果时,会出现情景模糊性。例如,有多个选项解决一个问题时就会出现情景模糊性。解决情景模糊性的方法包括渐进明细、实验和使用原型法:

  • 渐进明细:这是一个随着信息越来越多、估算越来越准确而不断提高项目管理计划详细程度的迭代过程。
  • 实验:通过精心设计的一系列实验,可以帮助识别因果关系或减少模糊性。
  • 原型法:通过测试不同解决方案所产生的结果来减少模糊性。

强力技能

管人更多的涉及到软技能,这与硬技能不同,几乎速成不了。这需要更多时间或生活彻底教会这里面道理。但也许以下有些方法可以受到启发,从而建立起更多的思考。

威尔金斯,L.(2021 年)。
潜移默化:如何与不同于你的人建立真正的(心理上安全的)关系

卢克曼,J. 和弗洛里 O. (2019)。
转变领导范式:从一揽子解决方案发展到解决复杂性问题

领导者个性
领导者的个性很重要。一个人可能具有很强的领导力技能,但随后可能会因给人留下自私自利或不可信赖的感觉而削弱其影响力。
根据《道德与专业行为规范》项目管理界最重要的四项价值观的基础:
▶ 责任;
▶ 尊重;
▶ 公平;
▶ 诚实

哪种领导风格有效
有效的领导力会借鉴或结合各种领导力风格的要素。根据文献,有各种各样的领导力风格,从专制型、民主型、放任型、指令型、参与型、自信型、支持型到共识型等。在所有这些领导力风格中,没有一种领导力风格已被证明是公认为最好或得到普遍推荐的方法
在混乱无序的时刻,指令型的行动比协作型解决问题更清晰、更有推动力。对于拥有高度胜任且敬业员工的环境,授权比集中式协调更有效。当这些高级经理的优先事项发生冲突时,中立的引导要比提出详细建议更有帮助。有效的领导力技能是可以培养的,也是可以学习和发展的,从而成为个人的专业资产,为项目及其干系人带来收益。高绩效项目显示出一种持续改进的普遍模式,该模式直至个人层面。项目团队成员通过增加或实践各种技能或技术的组合,以加深领导力智慧,具体方法包括,但不限于:
▶ 让项目团队聚焦于商定的目标;
▶ 阐明项目成果的激励性愿景;
▶ 为项目寻求资源和支持;
▶ 就最好的前进方式达成共识;
▶ 克服项目进展的障碍;
▶ 协商并解决项目团队内部以及项目团队与其他干系人之间的冲突;
▶ 调整沟通风格和消息传递方式,使之与受众相关;
▶ 教练和辅导项目团队成员;
▶ 欣赏并奖励积极行为和贡献;
▶ 为技能增长和发展提供机会;
▶ 引导协同决策;
▶ 运用有效对话和积极倾听;
▶ 向项目团队成员赋能并向他们授予职责;
▶ 建立勇于担责、有凝聚力的项目团队;
▶ 对项目团队和干系人的观点表现出同理心;
▶ 对自己的偏见和行为有自我意识;
▶ 在项目生命周期内管理和适应变革;
▶ 通过承认错误,促进快速失败/快速学习的思维方式;
▶ 就期望的行为进行角色示范。

领导模型

支持型。 支持型 PMO 担当顾问的角色,向项目提供模板、最佳实践、培训,以及来自其他项目
的信息和经验教训。这种类型的 PMO 其实就是一个项目资源库,对项目的控制程度很低。
uu控制型。 控制型 PMO 不仅给项目提供支持,而且通过各种手段要求项目服从,这种类型的 PMO
对项目的控制程度属于中等。服从可能包括:
nu采用项目管理框架或方法论;
nu使用特定的模板、格式和工具;
nu服从治理。
uu指令型。 指令型 PMO 直接管理和控制项目。项目经理由 PMO 指定并向其报告。这种类型的 PMO
对项目的控制程度很高。

研究显示项目经理可以采用的多种领导力风格。在这些风格中,最常见的包括(但不限于):
uu放任型领导(例如,允许团队自主决策和设定目标,又被称为“无为而治”);
uu交易型领导(例如,关注目标、反馈和成就以确定奖励,例外管理);
uu服务型领导(例如,做出服务承诺,处处先为他人着想;关注他人的成长、学习、发展、自主
性和福祉;关注人际关系、团体与合作;服务优先于领导);
uu变革型领导(例如,通过理想化特质和行为、鼓舞性激励、促进创新和创造,以及个人关怀提
高追随者的能力);
uu魅力型领导(例如,能够激励他人;精神饱满、热情洋溢、充满自信;说服力强);
uu交互型领导(例如,结合了交易型、变革型和魅力型领导的特点)。

指令型
控制型
支持型

在敏捷开发中这种角色更普遍,导注重为团队铺路,让团队尽其所能,鼓励组织以不同方式思考

使项目团队在可能的情况下进行自组织,并通过向项目团队成员提供适当的决策机会来提高自主性。服务型领导力行为包括:
▶ 消除障碍。识别瓶颈问题并提前给团队排除,如资源协调,技术攻克
▶ 避免分心。服务型领导者会使项目团队免受内部和外部分心之事影响,这些分心之事会使项目团队偏离当前目标,时间碎片化会降低生产率,因此使项目团队免受非关键外部需求影响有助于项目团队保持专注。比如在开发过程中若需要大量文档,服务型领导可能会去自己去写,从而让其他成员专注于开发
▶ 鼓励和发展机会。服务型领导者还提供相关工具和鼓励,让项目团队保持满意度且工作富有成效。了解激励项目团队成员个人的因素,并想方设法奖励他们的出色工作,这有助于使项目团队成员保持满意。

如何使团队绩效更高

适当压力有益发展

员工激励。 项目经理还需要了解“学生综合征”(即拖延症)和帕金森定律,前者指出,人们只有在最后一刻,即快到期限时才会全力以赴;后者指出,只要还有时间,工作就会不断扩展,直到用完所有的时间。

提升员工技能

增加质量管控,比如定期代码review
开展培训计划,若无预算就是内部分享计划即可
创建内部wiki

如何招聘

  • 聪明和高效是必备条件:与应聘者谈谈他们做过的事情。询问他们最令人印象深刻的项目和最大的成功。具体来说,询问他们平常一天是如何安排时间的,以及上个月他们做了什么。深入研究某个特定领域,询问应聘者实际上做了什么——成功的项目很容易让人将功劳归于自己。询问他们将如何解决你遇到的与他们面试的职位相关的问题。
  • 让人们试镜而不是面试:在雇用某人之前,请她和你一起工作一两天;你可以在晚上或周末这样做。如果你正在面试一名开发人员,请她为一个真实但不重要的项目编写代码。对于公关人员,请她撰写新闻稿并确定要向其推销的记者。只需让此人签署一份承包商协议并像普通承包商一样为这项工作向他们付款即可
  • 雇佣你喜欢的人:你是否愿意在周日来办公室,因为你想和这个人一起玩?喜欢和你一起工作的人对于正确的公司文化非常重要。

如何使团队氛围健康

随着个人的胜任力和承诺不断演变,领导风格会经历从指导到教练到支持再到授权的变化,以满足个人的需要。
团 队 中 的 每 一个 人 都 要 努 力 展 示 更 多 的 主动 性 、 正 直 、 情 商 、 诚 实 、合 作 态 度 、 谦 逊 和 以 不 同 方式 沟 通 的 意 愿 , 才 能 促 进 整个团队的携手共进。

冲突管理
  1. 先倾听,识别对方想表达的重点
    如果你是一直想说服别人,那双方态度会演变得很激烈,首先就还是得注意自己言语不要过激,语速也不能太快以免加速这种紧张局面。确保沟通还在比较平和环境。

  2. 共同寻找未来可行的解决方案
    若自己已经无能为力觉得对方坚持己见,那就经验观察来说,妥协通常比争吵损害要小得多。

沟通
文档能力
谈判

团队成员之间的谈判旨在就项目需求达成共识。谈判有助于在团队成员之间建立融洽的相互信任的关系。

激励
外部激励

即薪资待遇,但一旦员工已经达到一定水准那这可能不会再增加它的幸福感

内部激励

成就
▹ 我觉得我的工作对取得总体成果做出了贡献
经常表扬好的工作。拥有奖励产出的文化。

权力
▹ 我感到自己受到赏识

归属
▹ 我对我的项目团队的合作方式感到满意

团队建设

团队建设是通过举办各种活动,强化团队的社交关系,打造积极合作的工作环境。
团队建设活动既可以是状态审查会上的五分钟议程,也可以是为改善人际关系而设计的、在非工作场所专门举办的专业提升活动。

商业敏锐度

项目经理应时刻关注行业的最新发展趋势,获得并思考这一信息对当前项目是否有影响或可用。
这些趋势包括(但不限于):

  • 产品和技术开发;
  • 新且正在变化的市场空间;
  • 标准(例如项目管理标准、质量管理标准、信息安全管理标准);
  • 技术支持工具;
  • 影响当前项目的经济力量;
  • 影响项目管理学科的影响力;
  • 过程改进和可持续发展战略
  • 24
    点赞
  • 11
    收藏
    觉得还不错? 一键收藏
  • 打赏
    打赏
  • 0
    评论

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包

打赏作者

北丐安全

你的鼓励将是我创作的最大动力

¥1 ¥2 ¥4 ¥6 ¥10 ¥20
扫码支付:¥1
获取中
扫码支付

您的余额不足,请更换扫码支付或充值

打赏作者

实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值