1. 如何开展项目跟踪与监控 详细�0�3
� 2011-1-30 TPCA SEPG 5 了解项目跟踪与监控的目的 了解CMM中对项目跟踪与监控的要求 了解项目跟踪与监控的要素 了解项目跟踪与监控的方法 2011-1-30 TPCA SEPG 6 需具备项目管理知识 需掌握软件项目计划技能 需掌握项目估算知识 需掌握风险管理知识 2011-1-30 TPCA SEPG 7 部门经理 项目经理 技术管理经理 SQA人员 2011-1-30 TPCA SEPG 8 共计:0.5 天 详细安排 00:05 课程介绍 00:25 项目跟踪与监控的目的及意义 00:10 CMM中的项目跟踪与监控 00:10 项目计划是项目跟踪与监控活动的依据 00:15 软件项目跟踪与监控的六大要素 00:50 如何进行项目的跟踪与监控 00:00 参考资料 00:05 问题&反馈 Total: 2 hours 2011-1-30 TPCA SEPG 9 词汇表 域值：跟踪项的标准（可允许）偏差范围（上下限）。 2011-1-30 TPCA SEPG 10 图例—为什么要进行项目的跟踪与监控 2011-1-30 TPCA SEPG 12 项目管理中的常见问题 无法确定项目进度，项目经常延期�6�1 项目进展到什么程度了？�6�1 是否按计划完成？还有百分之多少未完成？ 无法控制项目费用，经常超支�6�1 项目费用是否在按计划执行？�6�1 目前项目是超支还是节余？ 无法控制项目风险，有可能导致项目失败�6�1 项目中存在问题吗？�6�1 项目中的风险都消除或降低了吗？ 2011-1-30 TPCA SEPG 13 项目管理中的常见问题(Cont.) 无法确定项目的规模，不知道项目规模的变化�6�1 项目有多大？�6�1 项目规模比前一阶段变大还是变小了？ 无法确定项目资源是否够用和可用�6�1 项目资源是否充足？�6�1 已有的资源都可用吗？ 无法确定工作量�6�1 我到底做了多少工作�6�1 项目的工作量有多少？ 2011-1-30 TPCA SEPG 14 产生问题的根源 无计划 计划不完整 计划不合理 没有做项目估算 没有评估项目风险 没有制订跟踪与监控策略 跟踪与监控策略不合理 没有做跟踪 没有根据跟踪措施采取相应的行动 。。。 2011-1-30 TPCA SEPG 15 解决问题的最佳途径 制订合理的项目计划 进行项目估算 在项目计划中确定合理的项目跟踪与监控策略 在项目开发过程中根据跟踪结果不断调整和优化项目计划 在项目开发过程中根据跟踪结果不断调整和优化项目的跟踪与监控策略 2011-1-30 TPCA SEPG 16 项目跟踪与监控的目的及意义 目的：通过项目的跟踪与监控活动，及时反映项目的进度、费用、风险、规模、关键计算机资源及工作量等情况，通过对跟踪结果的分析，依据跟踪与监控策略采取有效的行动，使项目组能在既定的时间、费用、质量要求等情况下完成项目。 意义：�6�1 是计划执行的保障�6�1 是项目经理工作的重要依据�6�1 是项目成功的保障 2011-1-30 TPCA SEPG 17 回顾：项目跟踪与监控的目的及意义 项目管理中常见的问题有哪些？ 为什么会产生这些问题？ 如何解决这些问题？ 项目跟踪与监控的目的是什么？ CMM —CMM对项目跟踪与监控的要求 2011-1-30 TPCA SEPG 19 CMM-项目跟踪与监控 简介：�6�1 CMM2级的一个关键过程区域—为了提供项目活动和状态的可视性。�6�1 监视项目活动，采取控制措施�6�1 以项目计划为中心—项目计划是前提 用项目计划作为跟踪与监控的基础 必要时修订约定�6�1 偏差=>纠正措施“设法使接近” 2011-1-30 TPCA SEPG 20 CMM-项目跟踪与监控（Cont.） 目的：�6�1 提供足够的实际进度可视性，使得当项目的实际执行情况与计划发生重大偏离时管理者能够采取有效的行动。 包括：�6�1 跟踪，评审�6�1 基于实际情况的调整 进度确定：�6�1 比较规模、工作量、费用、进度�6�1 在项目结束和在选定的里程碑处 2011-1-30 TPCA SEPG 21 CMM-项目跟踪与监控（Cont.） 目标：�6�1 目标1：针对软件计划跟踪实际结果和执行情况。�6�1 目标2：当实际结果和执行情况与软件计划发生重大偏差时采取了纠正和措施以使其与计划相符。�6�1 目标3：受影响的组和个人对软件约定的更改达成了一致。 2011-1-30 TPCA SEPG 22 CMM-项目跟踪与监控（Cont.） 约定：�6�1 约定1：指定了一个项目经理对软件活动和结果负责。�6�1 约定2：项目根据一个书面的组织方针管理软件项目。 2011-1-30 TPCA SEPG 23 CMM-项目跟踪与监控（Cont.） 能力：�6�1 能力1：存在一个被批准的书面的软件开发计划。�6�1 能力2：项目软件经理清晰地分配了软件工作产品和活动的负责者。�6�1 能力3：为项目跟踪工作提供了充足的资源和资金。�6�1 能力4：软件经理接受过管理软件技术和人员方面的培训。�6�1 能力5：一线软件经理接受过软件项目技术方面的定向培训。 2011-1-30 TPCA SEPG 24 CMM-项目跟踪与监控（Cont.） 活动：�6�1 活动1：一个文档化的软件开发计划被用于软件活动和沟通状态的跟踪；�6�1 活动2：根据一个文档化的过程修订项目的软件开发计划。�6�1 活动3：高级管理者根据一个文档化的过程评审组织外部的个人和群组提出的软件项目约定和对软件项目约定的变更。 2011-1-30 TPCA SEPG 25 CMM-项目跟踪与监控（Cont.）�6�1 活动4：软件工程组和其他的软件相关组的成员得到被批准的影响软件项目约定的变更的通知。�6�1 活动5：跟踪软件工作产品的规模，并在必要时采取了纠正措施。�6�1 活动6：跟踪项目的软件工作量和费用，并在必要时采取了纠正措施。�6�1 活动7：跟踪项目的关键计算机资源，并在必要时采取了纠正措施。 2011-1-30 TPCA SEPG 26 CMM-项目跟踪与监控（Cont.）�6�1 活动8：跟踪项目的软件进度，并在必要时采取了纠正措施。�6�1 活动9：跟踪软件工程技术活动，并在必要时采取了纠正措施。�6�1 活动10：跟踪项目中与软件费用、资源、进度和技术等方面的风险。�6�1 活动11：记录软件项目的实际度量数据和重计划数据。 2011-1-30 TPCA SEPG 27 CMM-项目跟踪与监控（Cont.）�6�1 活动12：软件工程组定期针对软件开发计划进行技术进展、计划、执行情况和问题的内部评审。�6�1 活动13：根据一个文档化的过程在选定的项目里程碑举行确定软件项目完成情况和结果的正式评审。 2011-1-30 TPCA SEPG 28 CMM-项目跟踪与监控（Cont.） 度量：�6�1 对软件跟踪与监控活动进行度量并用于确定其状态。 2011-1-30 TPCA SEPG 29 CMM-项目跟踪与监控（Cont.） 验证：�6�1 验证1：高级管理者定期评审软件项目的跟踪与监控活动。�6�1 验证2：项目经理定期或事件驱动地评审软件项目的跟踪与监控活动。�6�1 验证3：软件质量保证组评审和/或审计软件项目跟踪与监控的活动和工作产品并报告结果。—项目计划及项目控制策略是有效的进行项目跟踪与监控的基础 2011-1-30 TPCA SEPG 31 项目计划定义了项目跟踪与监控的内容 进度 费用 风险 规模 关键计算机资源 工作量 其他 2011-1-30 TPCA SEPG 32 项目计划定义了项目跟踪与监控的策略 跟踪的范围 跟踪频度 跟踪项偏差计算公式及域值 数据的收集方式 偏差的处理措施 2011-1-30 TPCA SEPG 33 回顾：项目跟踪与监控的依据 项目跟踪与监控的依据是什么？ 为什么说它是项目跟踪与监控的依据？—跟踪与监控所关注的要素 2011-1-30 TPCA SEPG 35 六大要素 要素一 进度 要素二 费用 要素三 风险 要素四 规模 要素五 关键计算机资源 要素六 工作量 2011-1-30 TPCA SEPG 36 要素一 进度 进度是反映项目进展程度的一种指标 进度一般用任务完成百分比表示 通过对项目进度的合理安排和控制，可以使项目按计划有序的进行 不合理的进度计划不利于项目的实施和跟踪 不进行进度控制可能导致项目延期，违反项目开发合同或失去市场机会 2011-1-30 TPCA SEPG 37 要素二 费用 费用即项目开发过程中所产生的花费 费用一般用货币表示（如美元、人民币等） 过低的费用估算会使项目无法完成 过高的项目费用会使软件产品成本过高，从而失去市场竞争力 不对项目费用进行跟踪与控制可能会使项目费用超支 2011-1-30 TPCA SEPG 38 要素三 风险 风险是有可能影响项目进度、费用、质量等一系列事件的集合 风险是一种可能，是不可预知的 风险是可预测的 风险是可规避或降低其危害程度的 不对风险进行评估、跟踪与控制有可能导致项目失败 2011-1-30 TPCA SEPG 39 要素四 规模 规模是表示项目大小的一种指标 规模可用多种方式表示(如UCP、KLOC、 FP等) 规模决定项目的工作量、费用、周期和项目人员安排 不对项目规模进行跟踪与监控就无法对项目的费用和工作量进行重新估算 2011-1-30 TPCA SEPG 40 要素五 关键计算机资源 关键计算机资源：软件组织内部构成软件项目开发环境的、潜在需求量可能会超出其实际供给量的、可能在软件开发过程中成为软件项目风险的、公用的计算机资源。如对公共网络的连接需求数，对公共服务器存储空间的需求量等。 2011-1-30 TPCA SEPG 41 要素六 工作量 工作量是指完成某项任务所花费的人力 工作量一般可用人.时、人.周、人.月等表示 工作量会影响项目成本 不对项目的工作量进行跟踪与控制可能会增高项目成本 2011-1-30 TPCA SEPG 42 回顾：跟踪与监控的六大要素 项目跟踪与监控的六大要素是什么？ 什么是风险，为什么要进行风险控制？ 为什么要对项目的进度进行跟踪与控制？—项目跟踪与监控方法 2011-1-30 TPCA SEPG 44 项目跟踪与监控的本质�6�1 计划（估算）�6�1 收集实际数据�6�1 比较实际值与计划（估算）值的差异�6�1 重新计划（估算），修正偏差计划（估算）比较重新计划（估算） 2011-1-30 TPCA SEPG 45 第一步 制订项目计划 估算项目规模 计划项目进度�6�1 确定里程碑�6�1 确定阶段�6�1 计划项目任务 估算项目成本 评估项目风险 评估与确定项目的关键计算机资源 估算与分配项目的工作量 2011-1-30 TPCA SEPG 46 第二步 确定项目跟踪与监控策略 确定跟踪与监控的范围�6�1 规模�6�1 进度（关键路径，所有路径）�6�1 费用（所有费用，设计费、折旧费等）�6�1 工作量（按核心工作流，按明细任务等）�6�1 风险（前五大风险，前十大风险，所有风险）�6�1 关键计算机资源�6�1 其他（技术进展，需求状态，基线状态等） 2011-1-30 TPCA SEPG 47 确定项目跟踪与监控策略（Cont.） 确定每个跟踪项的跟踪频度�6�1 规模（每周、每月、每阶段、每里程碑等）�6�1 进度（每天、每周、每月、每阶段、每里程碑等）�6�1 费用（每周、每月、每阶段、每里程碑等）�6�1 工作量（每天、每周、每月、每阶段、每里程碑等）�6�1 风险（每周、每月、每阶段、每里程碑等）�6�1 关键计算机资源（每周、每月、每阶段、每里程碑等） 2011-1-30 TPCA SEPG 48 确定项目跟踪与监控策略（Cont.） 确定数据的收集方式�6�1 明确每项跟踪数据的提供者�6�1 明确每项跟踪数据的接收者�6�1 明确使用的工具（数据库、电子表格等）�6�1 确定收集途径（自动工具、邮件、在例会上陈述等） 2011-1-30 TPCA SEPG 49 确定项目跟踪与监控策略（Cont.） 确定每个跟踪项的偏差计算公式及域值�6�1 规模（（当前实际规模-上次估算规模）/上次估算规模；±10%， ±20%等）�6�1 进度（（当前实际进度-计划进度）/计划进度）；±5%，± 10%， ±20%等）�6�1 费用（（实际费用-预算费用）/预算费用）；预算±10%， ±20%等）�6�1 工作量（（实际工作量-计划工作量）/计划工作量；±10%， ±20%等）�6�1 风险（见《风险管理计划》）�6�1 关键计算机资源（有/无，充足/不充足，最低数量等） 2011-1-30 TPCA SEPG 50 确定项目跟踪与监控策略（Cont.） 确定偏差的处理措施 每个跟踪项的偏差超出域值下限时应采取的措施，超出域值上限时应采取的措施�6�1 规模�6�1 进度�6�1 费用�6�1 工作量�6�1 风险（见《风险管理计划》）�6�1 关键计算机资源（资源不足或不可用时应采取的措施） 2011-1-30 TPCA SEPG 51 第三步 在项目过程中进行跟踪 在项目进行的过程中，根据项目计划中定义的频度和收集方式收集项目的跟踪数据 2011-1-30 TPCA SEPG 52 第四步 分析跟踪数据 利用实际跟踪数据和计划（估算）数据、偏差计算公式计算偏差率： 实际值 – 计划值�6�1 偏差率 = ——————————— X 100% �6�1 计划值 2011-1-30 TPCA SEPG 53 第五步 采取行动 根据跟踪与监控策略，对发生的偏差采取相应的行动：�6�1 一般情况下，若偏差超出域值范围，应对规模、工作量、费用进行重新估算，应重新调整项目进度、重新计划项目任务、重新分配工作量。�6�1 对于风险应按《风险管理计划》执行。�6�1 对于关键计算机资源应重新调整资源计划。
2. 如何做好计划跟踪项目
当你预期的那一天，也许是害怕的那一天，终于来到了：从工程师的队伍里你被提拔到了软件项目领导或者团队领导的位置。这也许就是你选择的职业道路，或许你不太情愿，将就尝试一下。无论在哪种情况下，你都可能缺少工程学科、人员管理以及领导能力的相关教育。 这需要更多的领导能力和管理（它们不是一回事），而不能象Dilbert（译注：著名IT漫画主角）那样简单地和老板对抗了。当你考虑新的目标时，请考虑下面的活动计划列表。一次就抓住了每个亮点，这是不可能的。但是这份建议说明可以帮助你将注意力放在可以提高你和你的团队绩效的活动上。 建立优先级 作为经理，首先要做的、最重要的事是你需要有意识地建立优先级。当你仍陷于繁重的软件开发活动中时，你需要一套新的职责。过多的经理新手不能抗拒技术的吸引而陷于此类活动，这将导致项目组的其他人员想要获得经理的帮助时，却得不到帮助。 有成效的领导知道他们首要的任务是为其他组员提供服务。这些服务包括训练和指导、解决问题和冲突、提供资源、建立项目目标和优先级、提供适当的技术指引。要使每个组员都能清楚的知道，你总是可以帮助他们。我发现将自己定位于为被我监督的人工作是非常有意义的，而不是相反的。在你所作的事情中，对于组员要求你帮助他们这件事，应该具有非屏蔽中断的优先级。 第二重要的，是使你的客户满意。作为一名经理，没有直接的能力使客户满意，因为你已不再是作为个人提供产品和服务完成这点。相反，你必须建立一种环境，准许你的组员最大程度上满足客户的需求。经理提供了强有力的方法，有效地提高客户的满意度。 第三重要的，是为你的项目工作。因为也许还有其他许多技术上的项目，或者其他经理的请求帮助，诸如为指导委员会工作。当这些和二个高级别的发生冲突时，都要准备推辞掉。 很明显，使其他经理满意的事情是你最不重要的事情。在一个有秩序的组织里，如果你在三个以上的重大环节上获得了成功，其他的经理都会很激动的。我们并不都能很幸运地工作在一个良好的环境里，但一定要对你任务单上排在最前面的工作任务努力尽到最大的责任。集中精力有效地、快乐地、尽可能地帮助你的组员，不要将精力放在使你上司满意的上面。 分析你的技能差距 除非你已经为新位置做好了准备，否则相对于你当前的领导能力和管理技能，你会感到一些差距。出色的技术背景或许是你被选为领导角色的一个因素，但是你要想干得出色，你需要更多的技能。针对别人的评论和项目，真实地列出你的长处和短处，然后减少差距。 软件人员并不以令人满意的人际关系技能出名。你会希望增强处理人际关系的经验：解决冲突、说服以及灌输想法。你也不得不处理包括招聘、解雇、商谈计划表，以及在你的办公室里评论某人业绩使其伤心落泪等一些事务。 我发现从一堂倾听技能课开始我的管理职业是非常好的。当作为个体提议人，积极地将我们自己的技术议程提交小组时，我们经常对此感到非常惬意。有效的管理要求更多的合作和善于接受的人际关系方式。要花点时间学习如何（何时）巧妙地引导自己的自然判断。倾听技能课提供了一种交流机制，我已经发现在许多场合下都很有用。 接着，到讲台的另一侧，提高你的演讲能力。如果你真的不适应公开场合的讲话，学习戴尔．卡内基的课会有帮助的。你会发觉，通过这样的培训获得的经验，以及获得提高的交流能力，都可以帮助你更好地适应将来的工作。 作为项目领导，为了计划和跟踪项目，以及当需要项目回退而采取修正措施时，你有责任调整其他人的工作。参加项目管理的培训课，阅读一些有关项目和风险管理的书籍和文章。参加项目管理学会，阅读其月刊--PMNetwork。SEI的软件能力成熟度模型对于软件项目计划和项目跟踪提供了很多有用的建议。建立优先级的能力、控制有效果的会议、清晰的交流，对于你，作为一名经理的绩效将会有实质上的影响。 定义“质量” 几乎每个人都会认真地对待质量问题而且都希望生产出高质量的产品。然而，对于软件的质量含义，没有一个统一的定义。传统上的软件质量观点和“足够好”的软件观点有着激烈的争论。为了帮助小组走向成功，需要花一些时间和你的组员、客户共同探讨质量的含义。 这两种阵营在思想上经常不会有相同的定义，可以很容易的就不同目的开展工作。关注交付计划的经理对于想正常地检查每行代码的工程师会不耐烦的；认为可靠性非常重要的客户对一个带有很少使用但带有很多bugs的特性的产品是不会满意的；一个很好的GUI也许会让用户厌烦，因为用户已经熟记了如何有效地使用前一个版本的产品。 为了更好的理解客户对软件质量的看法，在Kodak，我的小组曾经邀请了我们的客户和他们的经理就这个议题在一个开放的论坛展开讨论。这个论坛是很有意义的，那些使用我们产品的人有着自己的理解，通过讨论，我们可以知道我们制定质量的思路有哪些和他们是不相符的。明白了不同，就可以使你集中精力，照顾客户的最大利益，而不是使开发人员获得最大满意。 软件质量的传统描述包括要与说明书一致，满足客户的需求，代码和文档没有缺陷。“六个∑质量”（six-sigmaquality）这个流行词，建立了一个非常高的尺度，用于监测失败的频率和密度。但它不适用于如快速产品交付，可用性，充足的特性集，已支付价钱的交付意义这样的质量尺度，。对于我们生产和购买的产品，我们总是热衷于尽可能涵盖所有的这些质量特性，然而，妥协总是必须的。 在一个项目的需求阶段，我们制定了包括十项质量属性的一个列表，如效率，协同性，正确性以及宜于学习，我们认为这对于用户来说是最重要的。我们请客户关键人物代表小组以1到5的尺度评估每项属性。一旦我们决定了哪些属性是最重要的，我们就可以设计并实现这些目标。如果你在了解了对于客户的质量含义并在设计实现质量属性的过程中没有麻烦的话，而且客户对质量属性表示满意，那你是很幸运的。 在众多关注的质量说明中，我曾听到过一个：“客户回来了，但产品没有”。和你的客户、开发人员一起对每一个产品都确定适当的质量目标。一旦决定了，就给出达到质量目标的明确的最高优先级。以身作则，按很高的质量标准要求你自己的工作。采用这个座右铭：“力求尽善尽美，满足于优秀。” 表彰成绩 对你组员成绩的表彰和奖励，是激励他们的一种很重要的手段。除非你的小组中已经有了一种表彰程序，否则这应是你最重要的事情之一。表彰包括象征性的东西（证书，旅游奖励）以及实际的东西（电影票，餐馆礼品券，兑现奖）。在送赠品时要说一些亲切的话语：“感谢你所给予的帮助”或者“祝贺取得了成绩”。在表彰和奖励上花费很少的心思和钱，就可以获得很多的友好和将来的合作。包括客户代表，以及为项目成功做出过贡献的支持人员等等开发组外的人员也可以获得表彰。 和你的组员讨论，了解他们感兴趣的表彰和奖励的方式。使得无论大小成就的表彰活动成为小组文化的一个标准组成部分。对每位组员对其所作的工作表现出发自内心的兴趣也要给与含蓄的表扬，为消除所有影响他们战斗力的障碍尽你的力量。表彰是展示组员以及小组外的其他人的一种方式――你要知道并感谢他们为小组成功所作的贡献。 学习过去 你的小组在过去承担的一些项目有可能没有取得完全的成功。甚至在成功的项目上，我们也能经常认为一些事情我们下次会作得更好。当你进入了新的领导角色，需要花点时间了解早期的项目为什么失败，并要计划避免犯同样的错误。对于软件开发，每位经理花时间处理每种可能要发生的错误是非常困难的，学习过去的成功和失败就是个成功的开始。 可以从过去你们小组承担的一个没有经过检查评估的项目着手，不要管其成功还是失败，实施项目后的回顾（有时称作事后调查分析）。你的目标不是判定责任，而是为了在将来项目中作得更好。借此，可以了解什么已经作得很好，什么应该作得更好。在当前每个项目的主要里程碑时，通过集体讨论或公平的组织者，用同样的方式，领导小组用头脑风暴的方式对其展开分析。 另外，要了解领悟已有的软件工业的最佳准则。一个好的起点是SteveMcConnell的JoltAward获奖作品：快速开发（RapidDevelopment，MicrosoftPress，1996）的第三部分，叙述了27个最佳准则。也要避免McConnell叙述的36个常见的软件开发错误。你的组员也许反对新的工作方式，但是你的角色是作为一名领导，要确保团队一致连续地使用最佳可用的方法、过程和工具。积极促进组员之间的信息共享，这样局部单个最好的实践经验就能成为每个开发人员的工具箱的一部分。 建立改进目标 一旦你对过去的项目建立起了回顾，确立了质量对小组的意义，你就要建立短期以及长期改进的一些目标。目标要尽可能量化，所以你要划分几个简单的阶段，标明你是否采取了适当的过程朝着目标前进。 例如，如果你认定由于需求的不稳定导致项目经常延期，你可以建立一个改进需求稳定的目标，在6个月内提高50%。这样一个目标需要你确切知道每周或每月需求的变化数，清楚他们的出处，采取行动控制那些变更。这可能要求你要改变与那些提交需求改变的人的交流方式。 你的目标和阶段是软件过程改进程序的组成部分，你要使之有序。作为缺乏创造力的官僚主义的最后避难所，轻视“过程”很流行。虽然事实上，每个小组都能找到改进其工作的方式。当然，如果你总是用已有的工作方式工作，你也就不要期望你会得到比以前更好的结果。 有两个强烈的原因要求改进过程：校正问题，防止问题。确保你的改进努力要围绕着已知的或可预知的可能威胁项目成功的问题。领导你的小组找出当前正在使用的方法的长处和短处，以及项目面临的风险。 我的小组召开了一次“两段式头脑风暴”练习，来确定改进软件生产力和质量过程的绊脚石。在第一次会议中，参会者在便条上写出他们关于会议主题的想法，一个便条一个想法。组织者将他们写在便条上的想法收集上来并分组。最后，我们就会得到一打主要的分类，并将其记录到活动挂图上。 第二次会议，相同的参会者在便笺上写出解决这些障碍的思路，并贴在挂图的合适位置。进一步细化，归纳出一些详细的活动，就可以成为我们努力的一部分，清除障碍，帮助组员实现软件的质量和生产力的目标。 建立可度量和可达到的目标，便于你集中精力实现改进。要使目标具有明显的优先级，并可周期性地监视过程。记住你的目的是，提高你的项目和公司完成的技术和业务上成功，不要满足于一些过程改进书籍里提到的期望细节。要把改进的工作视为迷你项目，具有可分发、资源、计划和有责任的小项目。否则，过程改进活动将总处于比诱人的技术工作低的优先级上。 缓慢的开始 这篇文章提供了许多建议，帮助你，一位软件经理新人，带领你的小组走向伟大的成功。在日复一日新的工作压力面前，要努力保持你的头脑清醒。在长时间的塑造软件开发小组的文化和习惯上，你还是个非常重要的角色。你不必一次性都作完，可以选择跟环境最相关的的几个开始。 作为软件经理，除了项目要按时按照预算完成外，你要担负的责任还很多。你还要：领导技术人员，将他们形成一个具有凝聚力的团队；建立协同团队工作的环境；鼓励和奖赏高级软件工程师的实践应用；平衡来自客户、公司，组员和你自己的需求。 这是项重大的任务，祝你好运。
3. 项目策划书
一、策划书名称
尽可能具体的写出策划名称，如“×年×月××公会××活动策划书”，置于页面中央，当然可以写出正标题后将此作为副标题写在下面。
二、
活动背景
：
这部分内容应根据策划书的特点在以下项目中选取内容重点阐述；具体项目有：基本情况简介、主要执行对象、近期状况、组织部门、活动开展原因、社会影响、以及相关目的动机。其次应说明问题的环境特征，主要考虑环境的内在优势、弱点、机会及威胁等因素，对其作好全面的分析(SWOT分析)，将内容重点放在环境分析的各项因素上，对过去现在的情况进行详细的描述，并通过对情况的预测制定计划。如环境不明，则应该通过调查研究等方式进行分析加以补充。
三、活动目的、意义和目标：
活动的目的、意义应用简洁明了的语言将目的要点表述清楚；在陈述目的要点时，该活动的核心构成或策划的独到之处及由此产生的意义（经济效益、社会利益、媒体效应等）都应该明确写出。活动目标要具体化，并需要满足重要性、可行性、时效性
四、资源需要：
列出所需人力资源，物力资源，包括使用的地方，如教室或使用活动中心都详细列出。可以列为已有资源和需要资源两部分。
五、活动开展：
作为策划的正文部分，表现方式要简洁明了，使人容易理解，但表述方面要力求详尽，写出每一点能设想到的东西，没有遗漏。在此部分中，不仅仅局限于用文字表述，也可适当加入统计图表等；对策划的各工作项目，应按照时间的先后顺序排列，绘制实施时间表有助于方案核查。人员的组织配置、活动对象、相应权责及时间地点也应在这部分加以说明，执行的应变程序也应该在这部分加以考虑。
这里可以提供一些参考方面：会场布置、接待室、嘉宾座次、赞助方式、合同协议、媒体支持、校园宣传、广告制作、主持、领导讲话、司仪、会场服务、电子背景、灯光、音响、摄像、信息联络、技术支持、秩序维持、衣着、指挥中心、现场气氛调节、接送车辆、活动后清理人员、合影、餐饮招待、后续联络等。请根据实情自行调节。
六、经费预算：
活动的各项费用在根据实际情况进行具体、周密的计算后，用清晰明了的形式列出。
七、活动中应注意的问题及细节：
内外环境的变化，不可避免的会给方案的执行带来一些不确定
性因素，因此，当环境变化时是否有应变措施，损失的概率是多少，造成的损失多大，应急措施等也应在策划中加以说明。
八、活动负责人及主要参与者：
注明组织者、参与者姓名、嘉宾、单位（如果是小组策划应注明小组名称、负责人）。
注意：
1、本策划书提供基本参考方面，小型策划书可以直接填充；大型策划书可以不拘泥于表格，自行设计，力求内容详尽、页面美观；
2、可以专门给策划书制作封页，力求简单，凝重；策划书可以进行包装，如用设计的徽标做页眉，图文并茂等；
3、如有附件可以附于策划书后面，也可单独装订；
4、策划书需从纸张的长边装订；
5、一个大策划书，可以有若干子策划书。
4. 如何跟踪项目的管理、控制与策划
建议：
一，对项目管理的工作流程做一个清理，对工作的环节，部门间的衔接做一个梳理；
二，对单个项目做一个典型的管理计划，不同类型的项目非别理出关键节点；主要针对需要协调和交接的事项；
三，用项目管理软件编制进度计划，方便多项目的综合协调管理；
四，图表曲线等直观管理工具运用。
这些是从项目管理的角度来看的，实践中可以运用市场管理的专业要求作灵活安排。
浅陋之见，略供参考。