任何软件项目，都有四个重要的维：people、process、product和technology。为使项目能顺利进行，软件经理必须充分发挥这四维的作用。下表是对这四维的总结。
表1-1软件开发中的四维
维度
如何优化
People
l为团队挑选胜任称职的成员
l选择合适的团队结构
l使用恰当的人员激励措施
Process
l采用标准的软件工程实践，避免开发过程失控
l做好风险管理
l为项目选择合适的生命期模型
l形成良好的质量保证机制
l选择客户导向的开发方法，使开发的产品真正满足客户需求
Product
l较准确地估算productsize（产品规模）和effort（工作量），以便制定出现实的进度安排
l采取恰当措施防止软件开发过程中productsize或productscope失控
l为产品设定合理的productcharacteristic（如内存占用、稳定性、可靠性等）。
Technology
l选择恰当的、能确实提升生产率的工具（包括新的编程语言、新的开发实践、新的代码库等）
一个软件进行的软件项目应该遵循如下的4点策略：
1.Avoidclassicmistakes.（避免典型错误）
2.Applydevelopmentfundamentals.（采用软件开发的基础性实践）
3.Manageriskstoavoidcatastrophicsetbacks.（管理风险，以避免灾难性的结果）
4.Applyschedule-orientedpractices.（采用面向进度的实践）
这4点策略可以用下图来形象地表示。
这4点策略就像是4根支柱，共同支撑起一个成功的软件项目。尤其是前面3点策略，是每个软件项目高效进行的关键。
迈克尔·杰克逊曾唱过：“孩子，一个坏不要坏了整筐苹果”。但在软件开发领域，一个坏苹果是可以毁掉一筐苹果的！软件经理必须记住：一个软件项目只要犯了一个典型错误，就会滑向慢速开发的深渊；要实现快速开发，就“必须”避免所有的典型错误。
软件经理怎样做到避开这所有的典型错误呢？使用“典型错误列表”。
最佳实践：典型错误列表
1.以表2-1作为初始的典型错误列表。
2.从投入到某个项目的第一天起，每天在下班之前检查一遍典型错误列表，反省自己或团队有没有犯典型错误。如果有，思考一下怎么改变。
3.在每个项目结束之后，分析总结在项目中所犯的典型错误。如果是典型错误列表中不存在的，把它加入到典型错误列表中，供下个项目使用。
表2-1典型错误列表
典型错误
解决办法
1.Underminedmotivation.（挫伤积极性）
激励开发人员，详见第10章。
2.Weakpersonnel.（人员不能胜任）
招聘可胜任的人员，详见第11章。
3.Uncontrolledproblememployees.（对问题员工失去控制）
尽快处理问题员工，详见第11章。
4.Heroics.（英雄主义）
团队领导或成员对自身能力过于自信。
客观认识自身能力，避免盲目自信。
5.Addingpeopletoalateproject.（向已落后进度的项目增加人员）
不向落后进度的项目增加人员。如果实在要增加，可增加行政人员，帮助技术人员处理杂务。
6.Noisy,crowdedoffices.（办公环境拥挤嘈杂）
营造安静、整洁的办公环境，详见第10.3.1节。
7.Frictionbetweendevelopersandcustomers.（开发人员与客户之间产生摩擦）
维持良好的客户关系，详见第9章。
8.Unrealisticexpectations.（不现实的预期）
进行准确的软件估算，制定合理的进度计划，详见第7章和第8章。
9.Lackofeffectiveprojectsponsorship.（缺乏高层对项目的有效支持）
请求高层对于项目的支持。
10.Lackofstakeholderbuy-in.（干系人没有全身心投入项目）
请求干系人的全身心投入。
11.Lackofuserinput.（缺乏用户介入）
在软件项目的全过程都重视用户反馈，详见第9章。
12.Politicsplacedoversubstance.（玩弄政治）
实施有效措施保证项目和团队成功高于个人成功，详见第11章。
13.Wishfulthinking.（充满想象）
根据主观愿望而非客观事实对项目状况进行判断。
破除一厢情愿的想象，把项目执行落到实地。
14.Overlyoptimisticschedules.（过于乐观的进度计划）
15.Insufficientriskmanagement.（风险管理不到位）
进行充分的风险管理，详见第4章。
16.Contractorfailure.（外包承包方违约）
有效管理外包项目的风险，详见第16章。
17.Insufficientplanning.（项目规划不到位）
完成有效的项目规划，详见第3.1.1节。
18.Abandonmentofplanningunderpressure.（在压力下放弃项目规划）
在压力下更要坚持规划，但需要根据项目进展状况及时调整和重新规划。
20.Shortchangedupstreamactivities.（走样的上游任务）
草草完成需求分析、概要设计和详细设计。
认真进行需求分析、概要设计和详细设计，并进行technicalreview。
21.Inadequatedesign.（低劣的软件设计）
进行高质量的软件设计。
22.Shortchangedqualityassurance.（走样的质量保证）
取消designreview、codereview和testplanning。
任何时候都不放松对软件质量的要求，详见第3.6节。
23.Insufficientmanagementcontrols.（管理控制不到位）
加强对项目majormilestone和miniaturemilestone的管理和监控，详见第3.1.2.1节。
24.Prematureoroverlyfrequentconvergence.（过早或过于频繁地开展项目收尾工作）
不要过早或过于频繁地开展项目收尾工作。
25.Omittingnecessarytasksfromestimates.（项目估算中遗漏必要的任务）
把项目估算中易遗漏的任务列于显著位置，防止遗漏，详见第7.2节。
26.Planningtocatchuplater.（试图赶上进度）
进度落后之后，不要试图赶上进度，而应该根据项目新的状况重新制定进度计划，详见第7.3节。
27.Code-like-hellprogramming.（地狱式编程）
项目采用急就章式的、自由散漫的、“代码写到哪儿算哪儿”式的编程模式。
绝对避免急就章式的编程，任何代码必须经过严格的质量保证措施，详见第3.6节。
28.Requirementsgold-plating.（需求镀金）
项目的需求规格书中具有用户不需要的、复杂的需求。
不要在需求规格书中加入用户不需要的需求。
29.Featurecreep.（功能蔓延）
项目进行过程中频繁出现需要变更（requirementchange）。
采取措施防止功能蔓延，详见第13.2节。
30.Developergold-plating.（开发人员镀金）
开发人员为了学习新技术而给产品加入用户不需要的功能。
不要为了让开发人员学习新技术而加入不需要的功能。
31.Push-me,pull-menegotiation.
软件经理一面批准了进度拖延，一面又向拖延的项目中加入新的需求。
在项目已经拖延的情况下，必须稳定需求，不再加入新的需求，详见第15.1.3节。
32.Research-orienteddevelopment.（研究导向的开发）
把软件研究（如新算法）当成工程项目来做。
不在软件工程项目中搞软件研究。
33.Sliver-bulletsyndrome.（银弹综合症）
项目把解决进度问题的希望寄托在单独某一种新实践、新技术或新开发方法论上。
破除银弹综合症，详见第14.2节。
34.Overestimatedsavingsfromnewtoolsormethods.（过高估计了新技术或新方法带来的收益）
对新技术或新方法带来的收益有较理性的认识，详见第14章。
35.SwitchingtoolsInthemiddleofaproject.（在项目进行期间更换开发工具）
持续使用久经考验的旧工具，详见第14章。
36.Lackofautomatedsource-codecontrol.（缺少自动化源代码控制）
必须使用自动化源代码控制系统。
最佳实践：SourceCodeControlSystem
给整个项目乃至整个公司选择一个sourcecodecontrolsystem。这个sourcecodecontrolsystem可以是商业软件系统（如ClearCase，Perforce等），也可以是免费软件。只有在sourcecodecontrolsystem就绪之后，才开始启动你的项目。