创建出色的项目团队
-
招募需要的人
- 角色和负责的工作
- 架构师: 组织并指导整个系统的开发,包括测试系统
- 开发人员:设计,编写产品代码
- 测试人员: 设计,编写测试,包括测试代码
- 技术文案: 设计,编写产品文档
- 业务分析师: 收集,编写需求
- 发布工程师: 设计,编写,维护系统包括与系统相关的任何脚本
- 项目经理: 组织项目工作
- UI设计师或固件开发人员
- 角色不一定由不同人担任,没那么清晰。关键要有能够胜任工作的人无论他们一人担任几个角色
- 项目经理没有吸引,招募或淘汰团队成员的权力,很可能失败
- 角色和负责的工作
-
形成团队的凝聚力
- 项目经理不应该是唯一负责形成团队凝聚力的热呢
- 帮团队形成一体的最佳方式就是让他们在一起工作。大家目标一致,彼此承诺完成相互依赖任务,采取协商好的工作方式。制订一些只有共同工作才能完成的目标来形成凝聚力。
- 好工具让团队有好的发挥:好的软件管理配置系统和缺陷跟踪系统可以带来很多好处;它们都要满足最低要求
- 团队发展的五个阶段:项目经理促进团队经过这些阶段。但必须花时间留意项目风险和问题,与团队不断沟通
- 组建期:刚形成的阶段
- 激荡期:团队开始共同工作并彼此试探的时候
- 规范期:团队或项目经理可以让彼此就大家的行为意见一致
- 表现期:更加紧密协作时
- 中止期:项目完成
-
让组织配合你的工作
- 项目经理要让职能经理知道:团队成员要先对项目负责,而不是对职能经理负责
- 以项目经理的方式管理职能团队:
- 开发人员来自不同的职能团队,并只向其职能经理报告。会形成彼此间隔,不得不使用阶段生命周期
- 用管理工程的方式管理项目,每个职能经理领取一些功能或者一系列需求,并使用跨职能团队完成项目;或尝试找一小组各种人员一起,按功能进行开发
- 管理矩阵式项目团队:每个人有自己的职能经理而且还有共同的项目经理
- 成员的职能经理有时会让下属参加多个项目,让职能经理明白,多项目会带来延迟
- 跟职能经理说好,谁负责给团队成员反馈和指导。项目经理要担起这个责任
- 职业发展要有职能经理提供。要跟职能经理分清楚,哪些人负责与团队成员讨论什么样的话题
- 管理跨职能项目团队:了解每个人工作方式提供有价值的反馈,并对他们进行指导
-
对必需的团队规模了如指掌
- 不要多于9人:大规模团队之间关系并不紧密,可能已经创建了事实上的子小组,可以给子小组指定技术带头人
- 作为项目经理要树立权威而不是等着别人给你权威
-
知道何时应该加人
- 项目刚启动,项目经理应尽快加入需要的人手。每次人员变动都会对团队工作效率产生影响
- 项目中期,加人要小心。记住布鲁克斯法则
- 项目快结束时,避免新增人手除非:项目延迟已不可避免,且当前人手无法完成项目
-
成为出色的项目经理
- 提升人际交往技能:如何与人打交道,对于项目成败很重要
- 倾听技能:倾听团队成员的言谈,从中了解项目状态
- 谈判技能: 项目经理要争取资源,交换资源和信息
- 写作技能:能够编写计划,让每人都理解计划并做出妥协
- 以目标为导向:帮助大家把注意力都放在项目目标上
- 了解和尊重相关的工作人员
- 能够应对信息不足的状况并且做出决策
- 能够管理细节
- 解决问题的技巧, 识别哪些问题当前必须解决,哪些可以推迟以及如何解决。三种备选方案原则
- 辨别,寻找进度的障碍,并消除它们
- 提升人际交往技能:如何与人打交道,对于项目成败很重要
-
提升功能性技能
- 项目中的问题以及如何解决问题,项目经理不需要知道具体细节,但要了解问题和解决方案的专业知识,帮助更好的做出决策
- 不懂技术的经理,不要试图掩饰自己技术的不足。敢于承认找技术强的人来帮忙
- 理解不同的生命周期模型,知道哪一种最适合项目
- 能改安排项目的日程规划
- 能够估算任务,并指导其他人完成任务估算
- 知道如何评估风险,管理风险
- 清楚如何度量项目状态,以及如何报告项目状态
- 知道如何处理已完成和未完成的工作,可使用速度图表或者挣值
-
提升领域专业知识技能
-
理解收集需求和排序的方式,知道如何了解设计是否完成,如何评估技术风险和日程风险,知道软件配置管理系统的作用以及如何有效使用,还得知道测试人员能提供什么样的信息。从不同的审核活动中选出最适合项目的审核活动
-
项目经理不是必须知道如何完成这些任务,但应知道如何组织项目各项活动,促使上述任务的完成
- 不必成为项目技术专家,但应了解开发用到的技术和团队用到的流程,以了解风险
- 项目经理越了解产品的技术,越了解开发中的产品,就能做出更好的决策或指导团队做更好决策
- 避免两种极端:一无所知的项目经理和想成为架构师的项目经理
-
项目经理要具备问题空间域和解决方案空间域的专业知识
- 问题空间域专业知识:理解项目要解决的难题; 解决方案空间域的专业知识:理解系统如何利用解决方案来解决项目问题
- 项目经理要快速获得对领域的理解特别是需求包括需求排序相关的问题,还要知道解决方案空间有关架构的部分
- 没说项目经理要亲自阅读或是编写代码(或是测试),懂得多更有效管理项目
-
提升工具和技术的专业技能
-
- 知道何时该全身而退
-
什么样的组织不适合你
- 不能选择团体成员:无法雇人也无法让不合适的人离开
- 出席会议变成行政任务
- 出资人会威胁: 命令与控制的环境而不是协作
- 出资人坚持认为人们都应该同时处理多个任务,而且不愿意做出改变,(多项目)
- 别人想让你承担开发相关的工作
- 团队成员多于三人,不会有闲暇时间
- 项目经理编写代码没有管理项目,没有管理风险
- 管理项目,帮大家看清目标,移除障碍,监控进度,是没有时间从事技术工作的
- 管理层强制切分项目工作:职能兼项目经理,高层将项目组织成相互隔离的部分比如开发,测试
- 所有项目在启动时都面临资源不足: 不能改变项目,根据驱动因素,约束因素和浮动因素来重新组织,资源不足的情况先,项目会失败
- 总是听见人们说你没法融入团队
-
什么样的团队不适合你
- 对于管理项目需要的信息了解不足,可从以下信息来考量
- 知道团队如何工作吗?了解工作流程吗?
- 明白项目试图解决什么样的问题吗? 不理解就无法帮大家创建有用的发布条件,无法随着项目进度评估发布条件
- 管理层非要给团队施加帮助,可无法拒绝
- 无法让管理层远离团队,就等于无法帮团队移除障碍
- 敢于做团队的挡箭牌,让管理层的”帮助”落到你身上
- 对于管理项目需要的信息了解过多
- 技术丰富能做到不管技术而全心全意管理项目很难
- 不能放下架构和设计的工作,因而无法集中精力管理项目就得做出选择,无法兼得
- 对于管理项目需要的信息了解不足,可从以下信息来考量
-
什么样的产品不适合你
- 不具备解决方案空间域的专业知识而且团队其他人也没具备足够的技术深度,无法了解技术上的风险
- 如果必须管理项目,采用敏捷生命周期,短迭代
-
总结: 项目风险越大,团队的多样化应该越高; 提升多方面技能:人际交往技能,功能性技能,领域技能还有非技术技能; 知道何时应该离开