项目管理修炼之道
2017-01-18 16:46:19 0 举报AI智能生成
读书笔记 项目管理
作者其他创作
大纲/内容
第9章 保持项目节奏
在项目中使用持续集成
开发人员用一两个小时编写一段代码，对其进行编译，测试，复查，构建，运行冒烟测试，并验证做出的改变不会破坏现有系统代码，再将其签入到代码库中。持续集成就这么发生了。
为构建创建自动化冒烟测试
按功能实现，而不是按架构
首先实现具有最高价值的功能
按功能调试
按功能测试
邀请团队成员相互复查工作。
复查的形式并不重要，结对编程（pair programming）、伙伴复查（buddy review）、同行复查（peer review）、走查（walk-through）、正式代码检查（formal code inspection）都可以。
准备重构
通过用例、用户故事、角色和场景来定义需求
分离需求与GUI设计
尽可能使用低保真度的原型
小结
□项目经理可以邀请团队成员考虑这些实践，不过你不能强迫他们采纳这些实践。□如果项目经理即使尽全力也只能选择一个实践，推荐选择持续集成。□项目经理采纳和调整的实践要有助于保持项目的节奏，允许项目提高启动和结束的速度。
第10章 管理会议
发现并摧毁浪费时间的会议
避免不需要你解决问题的会议
绝对不要举行多人参加的顺序式进度报告会议
举行下列会议
项目启动会议
如果章程已经编写完毕，那就跟大家一起把章程过一遍吧。这可以帮助大家看到如何开始复查工作成果
发布版本规划会议
如果项目经理管理敏捷项目，会主持一个发布版本规划会议，而不是项目启动会议。发布版本规划可以让每个人（包括团队成员、出资人、客户）看到你对于项目进展的规划。项目经理会规划出希望一个迭代交付哪些功能。项目经理会在迭代之间对产品待办事项列表重新排序（参见16.6.2节），细节会有变化。
进度报告会议
每日站立会议
团队成员在一起，耗时不超过15分钟。每个人都站着
□我昨天完成了什么？□我今天计划要做什么？□我面临哪些障碍？
适用敏捷开发
一对一会议
目的，了解项目进度
如果项目经理管理的项目使用顺序式或迭代式生命周期，或者处于增量式生命周期的早期，你应该与团队每名成员进行每周一次的一对一会议。
通过可见的方式了解进度
通过电子邮件，从团队成员那里获取每周进度报告
电子邮件进度报告模板
工作成果。几段简短的话（每段两三句话），报告过去一周完成的工作。未来的里程碑。任务描述 规划完成日期 预计完成日期 实际完成日期有些项目由于发生外部事件，团队成员的工作会有变化。对于这样的项目，可以在右边加上另外一列：估算变更次数。障碍。团队成员写下导致不能完成工作的障碍。而且希望能从这个列表产生行动计划。
每周向团队报告进
向管理层报告进度
项目团队会议
目的
解决问题而不是项目进度
会议提纲
主要里程碑检查
本周遇到的问题
现有障碍？
其他话题
回顾以往行动
未决事项
迭代回顾会议
迭代尾声，团队会向产品负责人展示工作成果
项目回顾会议
□你可以判断一次会议对你是否有价值，是否值得花费你或者任何团队成员的时间。□要像逃避瘟疫一样，逃避顺序式进度报告会议。□观察会议进程，看看是不是能够满足每名参会者的需要。
第11章 创建并使用项目仪表板
测量风险
项目团队花费过多时间进行测量，从而影响正常工作；人们不认真对待测量；测量人，而不是项目。
使用多维度的测量来评估项目进度
使用速度图表跟踪日程安排进度
如果项目采取按功能逐个实现的方式，中所示的速度图表可以很好地指示出团队的项目进度，而且它还能告诉项目经理剩余多少未完成工作。
可以按照下面的步骤来绘制速度图。将所有的功能汇总，得到项目的全部功能数。开发完一个功能，就将已完成功能数加1，并减少剩余功能数。如果必须在项目进行过程中添加新功能，就得把这些额外的功能加入到全部功能数中。即使这些功能的规模并不齐整，速度图也能有所帮助。
图表
X轴
日期
Y轴
功能数
3条曲线
剩余功能数
已完成功能数
全部功能数
使用迭代内容图跟踪总体进度
□使用速度图和迭代内容图作为首选。□数据是工具，不是目的。要记住，图表应该为你服务。□如果无法获取需要的数据，项目经理就遇到了比数据更严重的问题。先解决这个问题吧。
第12章 管理多地点项目
□如果团队没有分布在同一楼层的10米之内，这就是一个多地点团队。□相对于管理坐在一起的团队，管理多地点团队要花费更多时间，还需要更多的项目推进技能。□如果项目经理无法构建起与远程团队的信任关系，项目就不可能成功。
第13章 在项目中集成测试
TDD遵循流程
1.开发人员（如果是结对编程的话，就是一对开发人员）针对某个尚未开发的新功能创建一个测试。这个测试应该失败，因为功能的实现代码还不存在。
2.然后开发人员加入能够使测试通过的最简单的实现代码。
3.开发人员重新运行测试。如果实现代码能够通过测试，开发人员就重构以简化代码。如果代码无法通过测试，开发人员会继续修改代码。在修改时，开发人员会重构代码，使其变得更简单、运行更迅速、维护更简单——这都是为了防止发生技术债务。
4.随着开发人员继续工作，他们会运行所有的测试，以保证不会引入问题，使得回归测试不能通过。开发人员会继续遵循这个循环过程，直到所有的功能全部实现。
使用一流的测试人员
QA与测试有差别
QA是指质量保证，这是流程改进和流程度量活动。
QA小组或经理具备如下特质
有权有钱，能够为开发人员提供必要的培训
有权解决客户的投诉，或是有权推动客户投诉的处理，特别是在产品下一版本的需求优先级排序过程中。
□有权、有能力修复缺陷。□有权、有能力编写或重写用户手册。□有能力了解客户需求，并据此设计产品。□有能力根据多个项目度量产品开发过程，对比结果，并解释这些结果——而且不会因此被解雇。□有能力了解当前产品开发过程，并有权对其进行修改。QA经理或小组也许不会直接干这些工作，但是他们有能力安排相关的人力和工作。
□如果项目经理有在项目中集成测试的规划，你就可以做到。□使用TDD，可以提升产品的设计和代码的质量。□可以考虑在项目中使用测试连续体系。
第14章 管理工程
工程管理
定义
工程管理：协调多个子项目或是一系列项目，以达成特定的业务目标。
项目管理是战术上的。项目经理的职责是完成自己手上的项目，而不会考虑其他进行中的项目。但是工程经理的职责更注重战略性，因为工程经理要协调多个子项目或是一系列项目。工程经理必须时刻将工程的战略业务目标牢记在心，而且要保证每个项目都遵循这个目标。如果目标发生变化，工程经理还得（与相关项目经理）决定各个项目要做哪些调整。项目经理会完成具体的调整措施。
制定工程规划
工程规划模板：
□综述□功能□工程需求□工程目标□市场评估和推广计划□销售计划□投资回报率和产品生命周期□日程综述□人员安排曲线□培训计划□服务/支持计划□其他计划
管理风险列表
管理项目经理
以交付物为准绳
建立信任
管理异常情况
审查仪表盘
风险列表
创建工程仪表板
□工程管理需要从战略的角度看待产品，不能仅从战术角度去看。□工程经理要确保自己能够明确看到所有项目的进度。□要想清楚哪些度量方法适用于你的工程。
第15章 结束项目
指导项目走向完成
继续收集缺陷相关数据，避免缺陷升级和降级的游戏
排定已知问题，并告知客户修复日期
规划回顾
目的是要回顾项目的进展过程、人们有哪些经验教训、他们在这个项目中工作时的感觉如何。经过用心设计和推进的回顾，可以为下个项目节省好几周的时间。
步骤
准备阶段
收集数据
深入讨论
行动决策
结束回顾
规划庆祝
取消项目
也是一种结束项目的方式
□将精力放在中期里程碑上，很容易引发“穿越沙漠综合症”，一定要避免这种情况。
□在项目结束时，一定要做回顾，即使已经在项目中进行过中期回顾也要如此。
□如果项目经理必须取消一个项目，那就取消吧。要取消得彻底，不能半途而废。
第16章 管理项目组合
管理项目组合
构建项目列表
评估每个项目
定性评估
回答以下问题
□这个项目与其他项目之间是什么关系？□实施这个项目的战略原因是什么？□完成这个项目有哪些战术上的收益？□为了使项目成功，我们是否提供了足够的资金？□为了使项目成功，我们是否提供了足够的人力？□我们是否知道这个项目成功的标准？
定量评估
□何时可以看到该项目的财务回报？□该项目的收益曲线是什么样子？□该项目的客户获取曲线是什么样子？□何时能见到该项目的当前客户保持率？□期望的客户增长曲线是什么样子？□何时能见到该项目降低运营成本？□期望的运营成本曲线是什么样子？
指定关于项目人员和资金的决策
对项目排序
按排序安排人员
□使用产品待办事项列表，不管你采用什么样的生命周期模型。□制定项目组合，以从视觉上了解所有项目的情况，不管这些项目是在进行中，还是刚做计划。□学着如何说“不”
项目管理修炼之道（罗斯曼）
第1章 启 动 项 目
定义项目经理
职责
负责向团队清晰说明完成的含义，并带领团队完成项目的人。完成，是指产品符合组织对这个产品的要求，也能满足客户使用这个产品的需要。
定义项目目标
每个项目都是独一无二的
发现当前项目的独特之处
管理项目的关键驱动因素、约束和浮动因素
理论
关键驱动因素
需权衡的不仅仅是“铁三角”
项目的“铁三角”
时间
成本
范围（或质量）
理想状况下，关键驱动因素应该只有一个，约束应该只有一个，而浮动因素可以有四个。
如果项目有一个关键驱动因素、两个约束、三个浮动因素，那它的成功几率还是不小的。浮动因素越多，项目就越容易管理。
约束
选出重要性高的2-3项
浮动因素
一个项目至少要有三个浮动因素
怎么找
0、理解项目背景
1、写出客户的期望
客户想要什么（功能集合），他们期望何时收到交付物（发布时间），可交付物的质量如何（缺陷等级）
功能集合
功能齐全
发布时间
质量
产品缺陷率
项目成本
人员配备
工作环境？
2、写下项目约束
环境是什么样子的？能否灵活安排团队的位置？必须遵守什么样的流程？手下的人有哪些？他们能做什么？预算有多少？这些约束是可以改变的（一般只有项目出问题的时候才能改变）。约束决定了项目的规模（还有持续时间和质量）。
与客户或出资人讨论项目约束
3、识别出项目成功的必要因素
经验
受到过多限制的项目难以逃避失败的厄运
项目经理自己做决定
决定项目的关键驱动因素
可以使用项目优先级决定出来
应对喜欢过多干预项目的出资人
预测未来
使用与上下文无关的问题
□项目要怎么样才算成功？□为什么想得到这样的结果？□这种解决方案对你来说价值何在？□这个系统要解决什么样的问题？□这个系统可能会造成什么样的问题？
理解质量对于项目的意义
了解摩尔的鸿沟
编写项目章程，共享现有决策
项目章程模板
远景
需求
常见需求：要在某个特定日期到达之时发布某些功能
目标
目标与需求不同，项目并不一定必须交付它的目标
几类目标举例
产品目标也许包括这样一些需求，它们已经被设定好优先级，但是不承诺在当前发布版本中完成。
性能标准之类的目标，对它们的要求会高于一般需求
“在产品交付时，要将未解决缺陷的数目从50个减少到40个”
目团队要解决某些特定的技术债务
“增加产品的自动化冒烟测试所占的百分比”
“减少项目的耗费时间，以提升组织的敏捷性”
成功标准
围绕客户能基于完成的产品做什么给出的定义。成功的标准并不涉及缺陷，而只关注能力
□要包括功能1、2、3，这样我们的产品就可以打入目标市场了。□要提升产品性能，再测出相关数值，这样我们就可以将其与竞争对手的产品进行对比，并编写新的市场营销材料了。□客户不需要访问我们的网站，就可以打开安装包、加载软件。□在第一季度发布。
ROI（投资回报率）估算
□每个项目启动时都要有章程。□对项目章程的反复修改要有心理准备。章程不一定完美，它的意义在于帮助整个项目团队进行规划活动。□要知道“质量”的意义以及项目的驱动因素。这样随着项目的不断推进，项目经理和团队才可以作出正确的决策。
第2章 规 划 项 目
使项目足以启动的规划
经验式规划
先做少量规划，再根据实际过程中收集到的信息反馈来影响未来的规划，这样做具有很高的可行性。
项目有太多的风险和不确定性，想在一开始就把一切都想好势比登天。从规划开始，每隔几周再重新规划，无论采取何种生命周期管理项目，都得做好反复规划的准备。不要创建完美的规划，只要这个规划在被（很快）替换之前具备可行性就可以了。
开发项目规划模板
产品意图
简单描述产品，为什么公司要开发这个产品，它能为公司带来哪些效益，等等。
借用项目章程的远景
历史记录
说明之前任何已知的技术债务
发布条件
要详细列举出项目产品的关键可交付物。
“要是不那么做，我们还能发布产品吗？”
同项目章程
项目组织
要明确说明团队在项目中的职责分配
日程总览
主要里程碑
如有beta测试或是早期的客户发布版本，要把这些作为里程碑对外说明。
7月1日\t\t项目启动。7月15日\t\t向露辛达展示Web界面的原型。（待续）7月30日\t\t向露辛达和厨房职员们展示厨房界面的原型。8月15日\t\t内部交付Web和厨房界面。8月30日\t\t向露辛达挑选的5个客户交付早期版本（beta测试）。9月1日\t\t开始beta测试。9月30日\t\t结束beta测试。10月30日\t\t系统上线，包括所有的客户订单和厨房的界面。
以矩阵的方式给出项目团队的不同运作方案
人员配备（人员曲线）
需要多少、何种类型的人员
建议日程
至少要将排名前十的风险记录在案
制订发布条件
为产品是否可以发布提供一些客观的评判标准
(1) 确定当前发布最重要的因素，这样可以将监控发布条件的活动贯穿项目始终。
组织的需要？
客户的需要？
通常
日常安排
功能特性
低缺陷率
(2) 草拟发布条件
发布日期、足够好的软件、一个已经完成测试并由两个客户验证通过的特定功能。
在草拟发布条件时，要在纸面上注明“草案”字样。
举例
□所有代码必须针对所有运行平台编译并构建。□没有高优先级的bug。□所有未解决的bug和临时解决方案都要记录在版本发布说明中。□所有计划好的测试都要运行，要保证通过率至少为90%。□在最后三周内，未解决缺陷的数目要不断下降。□在发布之前，功能X要由开发人员完成单元测试，由测试组完成系统测试，由客户A和客户B完成验证。□准备6月1日发布。
(3) 让发布条件符合SMART原则：确定的、可测量的、可达成的、相关的和可跟踪的
(4) 获得项目团队与高层管理人员认可。
□在发布日期之前，我们是不是必须满足这个条件？□要是我们不能在发布日期之前满足这个条件，会发生什么？□如果不能满足这个条件，我们的产品或公司是不是会因此而承担风险？人们的安全感是不是会因此被破坏？
在必要时变更发布条件
要跟团队确认为什么无法满足条件。
向管理层解释无法满足条件的原因。
□项目规划是在不断进行的，这只是开始。□为项目团队、出资人和项目经理自己制订发布条件，以明确定义“完成”的含义。□项目规划不必完美无瑕，但是它必须存在。
第3章 使用生命周期组织项目
理解项目生命周期
生命周期是项目经理和团队组织产品开发的方式。定义需求、设计、开发、测试以及与这些工作同时进行的过程
要讲求实效——将风险记在心间，选择的生命周期要有助于识别项目风险，帮助项目经理交付成功的产品。
生命周期类型
顺序式
迭代式
增量式
敏捷
在项目中寻求反馈
了解敏捷生命周期
大规模项目需要组合使用多种生命周期
管理架构风险
尽早实现几个可以考验架构承受能力的功能。我喜欢用不超过三周的时间来实现这些功能。
□在组织项目时，使用任何生命周期或是多种生命周期的组合，都可以让项目踏上成功之路。□不要怯于创建反映你自己项目实际情况的生命周期。“完美的”生命周期只是模型而已，你是生活在现实世界中的。□阶段-关卡流程或瀑布式生命周期，只有在确定使用它可以获得成功时才使用，而不是不经思考，上来就用。
第4章 安排项目日程
注重实效的项目日程安排
前期规划活动耗费的时间要尽量少
只要产生的规划足以让项目启动就可以了。用一个小时制订项目章程，再用一个小时完成项目规划，日程安排的草案也用一个小时完成。
项目日程安排技术
1.自顶向下式
2.自底向上
3.由内及外
4.哈德逊湾式启动
5.短期迭代
和团队一起，用黄色便利贴安排项目日程
基于可交付物的规划
按可交付物安排日程，而不是按功能
□用低技术含量的工具开始安排项目日程。如果真地需要相关软件工具，过后再转换数据。要注意不使用“大型可见图表”或“信息辐射器”所带来的成本。□按可交付物安排日程，而不是按功能。□要有以迭代的方式安排日程的准备。一次完成的项目时间表，其作用根本无法对得起花在上面的时间。
第5章 估算工作
实用的项目估算方式
1.通过对比历史数据进行估算
2.通过Delphi和宽带Delphi方式进行估算
每个人（小组专家）都写下来自己的任务列表和时间估算，同时注明自己对项目的预设条件
复查，看看哪些任务可以同时进行
把估算时间加在一起，得到项目的整体估算
问题
有可能估算过低
3.何时不应相信团队的估算
4.小心顺序式生命周期的估算陷阱
陷阱：从一开始就估算整个项目
5.使用自信心范围进行估算
6.使用日期范围进行估算
7.使用三个日期：最佳状况、最有可能、“墨菲”日期
8.在估算时分开考虑任务的大小与持续时间
9.规划扑克
10.在估算前用试探性开发收集数据
用里程碑切分项目
用可交付物作为里程碑，不要用与功能相关的活动。
使用基于可交付物的规划来安排任务
将里程碑（或迭代）的结束安排在一周之中的某天
提示：将里程碑（或迭代）的结束安排在一周之中的某天
你们能够不做哪些事情
能够以“不做哪些事情”的方式思考是很重要的特质，以“能做哪些事情”的方式进行管理
有些人身背多个项目时无法估算
团队中有身背多个项目任务的成员，这个项目必然会延迟。而且项目经理都无法预测会晚多久，因为你不知道这些人能在你的项目上投入多少时间，甚至很难知道这些人在项目需要他们的时候，能否真正在场。
多任务会浪费20%到90%的时间
主动安排人们进行多任务
对于项目中只是一时需要的人员，可以让他们以周为单位来切换项目。或者，也许团队成员可以进行结对。项目经理让一对开发人员参与两个项目。
使用波浪式规划
波浪式的规划就是一个持续不断而且很详细的日程安排，只覆盖几周的时间。完成了一周详细工作安排之后，可以再继续安排一周详细的工作。使用四周的波浪式规划，四个星期的详细工作安排就在其中，不多也不少。项目经理也不会浪费时间去规划了解不充分的事情。
决定迭代的持续时间
尽可能使用“小石子”进行估算
用户故事就是“小石子”
□绝对不要提供确定的项目结束日期。□任务越小，估算起来就越容易。□寻求估算的准确性，而不是精确性。
第6章 识别和避免日程安排游戏
给我一块石头
当“投资人”希望项目能更快交付，但是不告诉你何时需要或为什么的时候，就会玩“给我一块石头”游戏。
实践
制订排好优先级的产品代办事项列表
逐个实现功能。如果能够让出资人了解更多的项目进程，他们就不会那么纠缠截止日期了。
使用短小的时间盒（持续时间少于四周），这样出资人就可以看清项目进程。如果你每隔几周就能展示出项目的有价值的进展，截止日期就没那么重要了。你可以开始讨论何时实现哪个功能，他们对质量的要求又是什么。
“希望”是我们最重要的策略
拒绝女王
把灰扫到地毯下面
幸福日期
屁股着火
分散注意力
日程等于承诺
项目日程是对于团队何时到达哪个里程碑、何时完成项目的最佳推测。日程安排并不是预言，仅是猜测而已。但是有些项目经理的出资人会将这个猜测视为承诺
项目总是在变换目标
我们必须拥有这个功能，否则就完蛋了
我们不能说“不”
日程小鸡
90%完成状态
我们马上会变得更快
□日程安排游戏总是会发生的。项目经理的工作就是要识别它们，然后管理项目，让项目仍然可以取得成功。□绝大多数情况下，人们玩这些游戏都不是出于恶意。□即使没有恶意，日程安排游戏还是会拖项目后腿，使其停滞不前。
第7章 创建出色的项目团队
1.招募需要的人
项目经理也许没有雇佣新人的权力 ，不过项目经理一定要能识别团队需要的人才和技能。
2. 形成团队凝聚力
帮助团队形成一体的最佳方式就是让他们一起工作，而不是去参加什么团队拓展活动。如果大家有同一目标，彼此承诺完成互相依赖的任务，而且采取商定好的工作方式，这就是一个团队。如果希望团队凝结在一起，那么就帮他们制订一些只有共同工作才能完成的短期目标。
好工具让团队有好的发挥
软件配置管理（SCM）
缺陷跟踪系统（DTS）
团队发展的5个阶段
组建期
团队刚刚成形的阶段就是组建期
激荡期
当团队开始共同工作并彼此试探的时候，就进入了激荡期
规范期
一个项目章程中规定好的、令人信服的共识，可以让团队进入规范期
表现期
当大家更加紧密地协作时，团队就能进入表现期
中止期
项目完成，这个团队也就完成了历史使命，进入中止期。
3.让组织配合你的工作
用管理工程的方式来管理项目，可以得到更好的结果
每个职能项目经理领取一些功能或是一系列需求，并使用跨职能团队来完成项目
对必需的团队规模了如指掌
多于6人的团队总是会自动拆成几个小组，但是项目经理一个人最多还是可以管理9个人的团队。如果团队成员多于9人，根据可交付物，项目经理需要一些技术带头人或是其他项目经理的协助。
4.知道何时应该加人
改变人员构成，团队会至少因此退回到振荡期阶段，甚至有可能到组建期。如果雇佣新人，团队的整体工作效率会下降几个月的时间，除非项目经理专门指定一个“伙伴”来辅导新人。
如果项目刚启动，项目经理应该尽快加入需要的人手。每次人员变动都会对团队的工作效率产生影响，所以应该尽量一次性将人员配备整齐，避免成员变更降低工作效率。
如果项目进入到中期，加人就得小心。要记住布鲁克斯的法则：向进度落后的项目中增加人手，只会使进度更加落后。
5.成为出色的项目经理
要想成为出色的项目经理是有要求的：为了与团队一起工作，你要提升人际交往技能；为了了解和管理项目的风险，要提升或维护足够的技术能力。
技能
人际交往技能（非技术素质、偏好和技能）
倾听技能
谈判技能
写作技能
编写计划等
以目标为导向
了解和尊重项目相关的工作人员
能够应对信息不足的状况，并且做出决策
能够管理细节
解决问题的技巧
项目经理要识别出哪些问题当前必须解决，哪些问题可以推迟，以及如何解决问题。
“三种备选方案原则”是说：一种备选方案是陷阱，两种备选方案是两难的困境，提供三种备选方案就可以让相关人员开始考虑真地该怎么做了。
辨别、寻找进度的障碍，并消除它们
功能性（技术）技能
对于项目中的问题以及如何解决这些问题，项目经理不需要知道二者的具体技术细节，但是如果一点都不了解问题和解决方案的专业知识，项目经理就很难做出好的决策。
不懂技术的项目经理，不要试图遮掩自己技术上的不足。要敢于承认自己的不足，雇佣聪明的人，而且可以在了解项目的技术点时咨询这些聪明人。如果项目经理能够坦诚表明自己的弱点，并表示出学习的意愿，团队是愿意帮你成功的。
理解不同的生命周期模型，知道哪一种最适合你的项目。
能够安排项目的日程规划。
清楚如何度量项目状态，以及如何报告项目状态。
知道如何处理已完成和未完成的工作，可以使用速度图表或是挣值。如果没有上面这两种度量方式，要能理解软件配置管理系统中的数据和代码的状态。
领域专业知识
工具和技术上的专业知识
6.知道何时该全身而退
□项目风险越大，团队的多样化程度就应该越高。□提升多方面的技能：人际交往技能、功能性技能、领域技能，还有非技术技能。□知道何时应该离开。
第8章 掌 控 项 目
掌控项目的节奏
打断项目正常节奏的常见问题
□不知道先要完成哪些需求。□允许项目的需求收集阶段持续过长时间。□允许GUI随时发生变化，而GUI相关人员在项目中不知该如何是好。□没有架构的整体描述，不知道各个部分如何构成。□无法及时向项目中加入必要的人员，使得他们很难取得成功。
举行中途回顾
为需求排序
项目中有太多的高优先级需求，以至于中优先级的需求根本无暇顾及，更甭提优先级低的需求了。这一大堆的高优先级需求也根本无法区分先做哪个。
给需求排序吧。从1开始，为每个需求分配唯一的数字。这样人们就能了解团队会什么时候处理哪些需求了。即使不按照功能逐个实现，你也可以按照排序的顺序来实现功能。
方法
建立评估条件
□功能对架构的影响。□估算的实现时间。□该功能对于特别重要的客户的重要性。□特定人员实现或测试该功能的可行性。
用时间盒限定需求相关的工作
如果项目中必须有明确的需求阶段，就用时间盒限制它。否则，需求分析和定义过程就有可能占用整个项目的时间。
将迭代限制在4周或是更少的时间内
如果迭代效果不好，提示：用一分为二的方式减少迭代持续时间
使用波浪式的规划和日程安排
创建跨职能团队
跨职能团队的工作效率更高
跨职能团队具有多样性
根据项目的风险选择生命周期模型
保持合理的工作时间
使用“小石子”
管理干扰
管理缺陷，从项目初就开始
“项目当时累积的缺陷使得我们无法达成最初2个月的截止期限”
在项目进行过程中，很多团队对缺陷都采取放任自流的态度。直到项目快结束了，他们才会认真考虑如何管理缺陷。
如何影响别人
记住问题不是你一个人的。项目经理有时会认为自己必须提供所有的建议和解决方案。并非如此。在项目中，发布日期、功能集合、缺陷水平，每个人都对这些有责任。不要认为一个问题就是你自己的。你有责任让团队解决问题，而不是强令他们如何解决。
思考你能为组织带来的价值。一旦明白了自己的价值，你就可以想想这些价值对于别人的意义了
发现其他人或团队的驱动力
建议项目经理和负责的人（或团队）共同面对问题。这可以让项目经理能够友善、开放地接受他人的建议和想法。
倾听团队。团队会告诉项目经理他们要怎么样才能达到最高的工作效率。
在讨论时，给他人思考的时间。在推行你自己的想法时，要允许别人认真思考和质疑这些想法。有些人可能需要多一点时间来提供有价值的反馈。
不要固执己见。如果你借助影响力，以协作方式工作，别人就能改善你提出的解决方案。
□作为项目经理，你要带头考虑使用或调整哪些管理实践。□评估项目的问题，然后根据这些问题来判断使用或调整哪些实践。□要寻找可以建立和维持项目节奏的实践。
0 条评论
回复 删除
下一页
