我从事过多年的对日软件项目的开发，经历过从ＰＧ到ＳＥ、从代码编写到外部设计的成长过程，在项目开发的各个工程阶段的总结和分析中常常能听到一个声音“经验不足”；这个看似合理的理由影响着很多项目的质量和生产率。本文拟通过对一些常见的“经验不足”或被称之为“经验不足”的现象进行分析、来探讨一下在项目开发过程中如何重视“经验不足”的问题，并以此来提高生产率。
从项目启动、外部设计、到代码编写、测试等各阶段，对于项目的ＰＭ到ＰＧ的各个角色的担当者来说，都可能因为自身对项目的某些特性的内容缺少相关的工作经历、或由于工作时间短使得某种能力的沉淀不足等，造成项目开发过程中的错误产生，后续为解决缺陷而投入更大成本［1］，最终造成项目的生产率降低，甚至还有可能发生项目延期的风险。
一、各工程阶段的“经验不足”的现象及风险分析
1
工程阶段：提案/预算
角色：PM PL
经验分类：技术 管理
常见现象：
对开发语言不熟练，规模估算不准确
·短时间内无法深入理解系统要求,对项目难易程度判断失误
·当前项目和参照基准项目的异同认识不足, 设定的生产率指标误差大
·参照基准项目的生产率指标的准确度不够（前期项目统计方法有不足之处）
影响归类：
项目规模估算 项目工时预算
2
工程阶段：外部设计
角色：PM PL
经验分类：业务 技术 管理
常见现象：
管理者对单个机能业务理解不够、或逻辑实现复杂度的认识不够［3］
·管理者自身能力过强（判断为易），和担当者（判断为难）对难易度的判断存在较大的偏差（能力差距认识不足）
·管理者对团队成员的业务能力、技术能力、做事风格、品性等不够了解，没能把合适的人安排去做合适的事，未能达到人员产出效率最大化（管理经验不足)
·管理者发现项目存在某种风险（例如：人员体制或能力不足、成果物质量差、进度延迟较大等）时未能及时采取有效措施解决（风险管控经验不足）
影响归类：
工作安排 工作进度 团队士气
3
工程阶段：外部设计
角色：SE
经验分类：设计 调查
常见现象：
没有做过外部设计的经历，甚至做内部或详细设计的经历都很少、或仅限于有设计书修正的经历（未有纯新设计的经历）
·在项目设计的不同时点进入，对本项目的知识积累速度和深度存在很大差距（途中进入者对项目的很多规则、设计方法、业务积累都会有缺失），相对于前期进入者来说是经验不足的
·对复杂逻辑的理解存在困难，对原系统的处理流程、详细逻辑实现的调查存在困难（相关经验积累不足）
·缺乏求知欲，面对设计内容的指摘，当调查费时间或自己觉得有难度时，缺少冲劲，甚至有时将问题的解决转嫁给评审者（归根到底还是能力不足、信心不足的表现、当然态度方面也可能有待改善）
·缺乏经验分享的意识、经验交流的积极性（好的设计思路、设计细节、共同的逻辑处理方法、错误解决对策等的分享和交流是能快速提高大家的能力和设计质量的，这也是经验积累的一种快速有效的方式）
影响归类：
设计书质量 工作进度 工作能力
4
工程阶段：内部设计 详细设计
角色：SE
经验分类：设计 调查
常见现象：
PG初次参加设计工作
·对设计内容及逻辑的理解能力差、业务的掌握及熟练程度低
·套用设计模版或参照其他详细设计来做成新的详细设计时，对参照设计没理解到位时，容易产生潜在设计缺陷
·对外部设计知其然而不知其所以然，容易产生潜在设计缺陷
·缺乏经验分享的意识、经验交流的积极性（例如:对于一些特定设计逻辑的实现方法、复杂逻辑实现讨论、程序性能设计经验的交流和学习）
·缺乏成熟的调查经验（调查方法、观点、范围判断、结果的整理、结论的提炼）
影响归类：
设计书质量 工作进度
二、为什么说＂经验不足＂会影响软件开发的生产率
在软件开发过程中，＂人的因素＂、“问题因素”、“过程因素”、“资源因素”等都会影响软件生产率。
人的因素：开发部门的人员规模和经验
·问题因素：问题的复杂性和设计约束或需求更改的次数
·过程因素：开发周期（各工程阶段的衔接）、人员配置波峰波谷（时间、数量、岗位）、使用的分析和设计技术、应用的开发语言及评审的过程。
·资源因素：开发工具（使用方法）、硬件和软件资源
西汉·刘向《战国策·秦策五》：“诗云：‘行百里者半于九十。’此言末路之难。”，在软件项目开发中普遍出现过“临近任务预计的结束期限，还有很多工作没有完成，造成前工程阶段挤占后工程阶段的开发时间”，回过头来再看所谓完成的百分之九十的工作量，有一个问题给大家：项目进度真的到了百分之九十（90%）吗？为什么越临近结束期问题越多？项目为什么老是延期？这些都值团队的每一个成员去思考，让我们一起来分析一下软件项目进度延期的关键因素，从这一个角度来看看“业务、技术、管理等”经验不足会不会成为导致我们在规定的期限内没能完成预定目标的一个因素。
那时候，家中虽说有了电视机，但节目频道就这么几个，按几十下的遥控器，节目频道就又重新来过。而且看多了，也就厌了。
1、项目进度计划本身不合理
估算是否准确：
是否是估算团队而非某个人估算的结果，是否参照了匹配度高的历史数据。
·关键资源和关键路径的安排是否合理：
尽量减少关键资源安排在非关键任务上，在进度计划安排上应该适当安排10%～15%的余量，处理突发事件。
·项目中的资源是否充分利用：
有的人一直忙碌不停，哼着小曲＂时间都去哪儿啦＂；有的人是脉冲性的，一阵子忙一阵子闲；有的人则在唱＂我的心在等待，永远在等待＂。人力资源不能充分利用，会带来团队成员之间的不平衡从而进一步影响生产率。
2、团队的问题
必须承认项目中每个成员的价值，充分的尊重每个成员，让其发挥出自己的价值，只有个人价值的最大化加上协同效应，才能保证达成项目的生产率的目标。
·项目管理者：
好的项目管理者可能占到项目成功的一半以上的因素（勇于担当、有很强的责任心、领导能力、识人善断、技术上一专多能、有业务或技术上的号召力和说服力、项目经验丰富（有成功的经验也有失败的经验）、有较强的沟通、组织技巧等特质）。
·人员技能（业务和技术）：
如果项目管理者认识到团队人员业务或技能不足，那就要妥善安排（对大家都欠缺的技能，统一培训；对于个别技能的不足，安排师傅帮带，使其技能尽快达标；对于新员工，应该加强评审和检验，以免输出质量太差导致后期代价昂贵的返工）。
·责任心：
假如我们以最大的恶意来揣测，有些项目有些成员是抱着完成任务的心态来工作的，责任心不强、敷衍了事，导致产出质量低下，带来大量返工。
·沟通和分享：
项目组必须建立起有效的沟通渠道，使成员间能够快捷顺畅地进行沟通和经验分享，在一些项目中，同样的错误常常重复发生呢？为什么大家开会的时候都不太愿意发言和分享值得分享的东西呢？其中有一个很重要的原因就是“发言就是给自己找事”，90%的场合都是谁分享，谁负责起票、整理说明资料等（项目忙的时候这些都得加班去做），慢慢的大家就没有积极性了，自己管自己的事了，团队的事让领导操心去吧。
3、风险管理
对项目推进过程中可能出现的风险有清醒的认识，要提前采取应急措施，比如因各种原因使得进度晚了，想着２个月后体制会缩减，就让大家坚持坚持，结果只能是大家干活累、心累、大量加班导致出错概率增加。
4、质量因素
时间和质量是项目中的两个互相矛盾的因素，现实项目中常出现评审的指摘多、后期测试问题多，ＢＵＧ修改和回归测试等花费了大量的时间［1］而导致某个工程阶段或项目的延迟，只有尽可能早的发现问题，采取措施，才能在时间和质量之间取得平衡。
5、需求变更
实际项目中，变是唯一不变的真理，对于项目团队，频繁的、大范围的需求变更和调查简直就是噩梦，不但会增加工作量而且往往会破坏既有安排，如果一味地按紧急的事优先做、调整或延期既有安排，很多人慢慢就变得消极了“活永远是干不完地、没必要那么拼”，工作积极性下降，效率开始下降，工作安排的准确度也会下降。减少变更带来的影响，降低波动带来的风险和工作量，降低质量风险、降低变更成本，是我们在项目管理中应该重视的。
三、能否改善各工程阶段的“经验不足”,降低项目风险，提高软件项目生产率
1
工程阶段：提案/预算
角色：PM PL
经验分类：技术 管理
改善的思考：
历史数据的收集和统计：
在每个项目的开发过程中(从开始到结束)，对项目规模、生产率等进行统计和分析，为以后的项目提供参考
判断当前项目的难易度或复杂度系数［2］
※按下表(参见表2-1)各项求平均值
·根据历史项目整体的(参见表2-2)或项目阶段(参见表2-3)的平均生产率，结合难易度来矫正项目预算规模、估算工时等。
难易复杂度估计表(表2-1)
影响因素
非常低
低
正常
高
非常高
软件要求的可靠性／提案信息完整性
0.8
0.9
1.0
1.25
1.5
数据库（规模或关联性）
0.8
0.9
1.0
1.25
1.5
业务复杂程度
0.8
0.9
1.0
1.25
1.5
开发时间限制的紧急程度
0.8
0.9
1.0
1.25
1.5
开发人员的开发经验
0.8
0.9
1.0
1.25
1.5
应用领域的开发经验
0.8
0.9
1.0
1.25
1.5
开发环境的使用经验
0.8
0.9
1.0
1.25
1.5
程序语言的使用经验
0.8
0.9
1.0
1.25
1.5
需求定义的明确程度／解析既有系统的难易程度
0.8
0.9
1.0
1.25
1.5
所采用技术的成熟程度
0.8
0.9
1.0
1.25
1.5
甲方／协力方／乙方的人员构成比例对乙方的不利程度※
0.8
0.9
1.0
1.25
1.5
※例：［１：２：８］比［１：２：１０］更有利于乙方，作为乙方来说在人员构成比例这个因素来看，难易度可往变低的方向考虑。
历史项目整体生产率对照表(表2-2)
项目
规模
（实际）
工作量
（实际）
平均
生产率
难易度评估
初次（估算）
难易度评估
终回（实际）
A
300
288
1.04
1.0
1.25
B
1000
1086
0.92
1.25
1.25
※单位（规模：KLOC、工作量：人月、生产率：KLOC/人月）
※上表数据并非来自真实项目（从外部设计到内部结合测试）
历史项目阶段生产率对照表(表2-3)
阶段
工作量
平均生产率
复杂度系数
概要设计/既有系统解析
30
10
1.0
外部设计
68
4.41
1.25
内部设计
-
-
1.0
详细设计
30
10
1.0
单体开发
70
4.28
1.0
内部结合测试
90
3.33
1.25
运维
-
0.8
1.25
※单位（工作量：人月、生产率：KLOC/人月）
※上表数据并非来自真实项目
2
工程阶段：外部设计
角色：PM PL
经验分类：业务 技术 管理
改善的思考：
管理者有时候看到的只是一些表象的东西，业务逻辑的复杂度等很多时候不是那么直观就能判断准确的，应该和团队成员多沟通，多尝试去相信别人判断（即使不准确,大家在经验积累方面也会有所收获的）。
·俗话说，三个臭皮匠赛过诸葛亮，对于复杂或重要的问题可以利用小组的力量和智慧来解决，但是小组的人数值得商榷，会议人多了，很多人就不爱发言了；有时候可以采用会议之前３～５人为一组讨论，会议中汇总小组结果再和大家一起讨论，这样能得到更为满意的结果，达到真正的共同参与共同进步；频繁的开会会花费一些时间，但是项目的初期，“磨刀不误砍柴工”，能在讨论中积累经验和知识。
·管理者发现项目存在某些风险（例如：人员体制或能力不足、成果物质量差、进度延迟较大等）时，该加人就应该加人，而不是一味地盼着挺过这个月下个月就轻松了，对日开发项目的主动权一直都不在我们手上，特别是大项目，很多你想不到的作业在等着你（比如上游有变更、指摘或缺陷的类似调查等）。
·项目大或项目忙的时候，要特别重视团队的凝聚力和向心力，一个有战斗力的团队一定能产生１加１大于２的工作成绩的。打个比方：每人每天少浪费１０分，１人１月就少浪费３．３小时，４８人的团队就少浪费１个人月。平时团队工作之外，可以多组织一些团队活动（比如聚餐等），大家感情更好了，多分理解了，干起活来自然协调性就更好，工作效率也会提高。
·好的教育方式或平台很重要，对于大的项目，适当的教育成本是必要的，比如说组建协调小组，收集大家的问题点（包括指摘和缺陷等）、知识点、收集并整理大家提出的建议（如果这样的话以后分享经验和提出想法的积极性一定会得到改善）、共通性的设计内容、准备教育资料、定期组织教育会议，这样可以避免大家犯同样的错误，共享大家的经验，提高大家的水平。
3
工程阶段：外部设计
角色：SE
经验分类：设计 调查
改善的思考：
态度和积极性很重要,缺经验不怕，怕的是不知道还不愿学，不愿沟通和讨论，当你刚进一个新项目时，你就是一张白纸，有的东西看似你懂，做出来也不一定符合该项目的规约，所以再忙该学的项目的基本规则、范例、上游接口等还是必须努力去了解的，掌握了才会事半功倍。（在进度管理上适当的预留一些时间也是必要）
·多交流或讨论，正所谓三人行必有我师，也许在一次和别人不经意的谈话中，就可以迸出灵感的火花；开会时要多发表自己的看法（无论对错）；被评审者指摘时，应该让其给你当面讲一讲想法和思路，而不是别人怎么指你就怎么改，要力求做到“知其然知其所以然”，这样能力的提升才会更快。
·调查是提高能力很快的一种作业类型,能让自身的知识和方法得到积累，但要有‘语不惊人死不休’的执着追求，以执着精神去发现问题并找出答案。
4
工程阶段：内部设计 详细设计
角色：SE
经验分类：设计 调查
改善的思考：
弄明白外部设计与详细设计的区别及关联关系：外部设计包括组成模块及层次结构、模块的主要功能、数据库结构等；详细设计主要是采用“伪代码”等描述方式对各模块的功能转变为精确的、结构化的过程描述等。
·上手之前，可以找些有代表性的外部设计和详细设计来对照理解为什么详细设计要这么写，两者在描述和细节上有什么区别。
·着重研究一些重要的逻辑实现方法，比如Break处理、循环处理（第一条和最后一条数据处理的特点）、游标处理、模块中逻辑处理流程图等。
·套用别的设计内容的时候，不能生搬硬套，必须弄清楚两者的本质区别，才能改写出正确的设计内容；套用出错是常见的一种质量问题的直接原因。
·对外部设计内容要努力做到知其然知其所以然。
·调查可以分成几步去做：首先弄明白调查的目的，方针，观点、范围；其次选用好的调查成果物（或模版）作为参照，使用合适的命令（如grep）辅助调查，缩小影响对象范围（用EXCEL公式等工具提取结果）；再对每个对象的具体设计内容结合调查方针等细化或提取影响逻辑点；最后理顺处理流程归纳结论。
四、各工程阶段的“经验不足”对策规范化
No.
分类
关键词
资源／主题
方法／课题／说明
1
教育
经验分享和传承（磨刀不误砍柴工）
１～５％的工时作为学习和教育预算
自我学习和发表
·问题点深究和剖析
·小组会议讨论（１０人以下）、
·重点内容文档化并复用
2
自我管理
目标管理能力
细化每天的生活与工作目标
失败：不在于目标没有达成，而在于没有目标
·成功：不断地提出目标，不断追求目标并实现目标
3
自我管理
自我反省管理能力
及时地反思自己失误之原因
面对没有达成的目标、评审者的指摘、程序缺陷的发生，不断地检视自己的不足（包括工作态度和积极性），找出直接原因和根本原因及对策
4
储备
技术和代码储备
提炼设计、代码和测试用例等，做成标准化实例
将标准化实例整理成不带固定客户信息的实例，纳入“共享经验管理库”，供以后项目参照
5
储备
团队
储备
团队
建设
增强团队的理解能力：让团队成员充分理解工作任务或目标（而不是按预计工时强加于人）
·培养团队的责任能力：在团队中鼓励共同承担责任，培养团队成员的责任心，遇到问题，首先要从自己身上找原因
·提高团队的沟通能力：建立平等的沟通渠道，鼓励成员就问题、现状等进行充分沟通，激发思维的碰撞
·提高团队的凝聚力：定期组织团队聚餐或团体活动（全员参加才有实际意义）
6
储备
数据
收集
计划数据和实际数据分开管理
项目开发过程中要收集真实的工时（指实际作业花的时间，而不是从客户处拿到的工时）、规模、质量、难易度等相关数据，避免使用历史项目的“计划数据”来估算下一个新项目。
（※工时收集时，作业内容必须统一标记，不可随意拆分和合并或添加）
（※难易度最好细化到每一个作业（同一作业不同的人去做，它对应 的难易度是不一样的），总体的难易度可以按规模加权平均）
7
设计
外部、内部、详细设计
作业
流程
努力钻研系统或机能的业务需求或业务处理流程
·设计书的模版的统一和标准化
·制定数据库表设计指导方针(各项目的类型定义、特定通用项目的值设定方法的统一、各表的履历追踪项目的统一等)
·对个表或文件及项目等的名称或ID或类型等建立统一的数据项目对照表，以供参照和查阅
·以帐票系统来说,先设计帐票输出接口,从后往前逆向考虑,来决定需要什么样的输入接口
·根据输出接口要求,结合方针和数据项目对照表等来完成各个机能的数据库表设计和各机能逻辑处理设计（输入表的检索条件、各种属性情报补充、输出项目编辑等）
·各数据库表和输入输出文件的日常维护处理设计（数据保存备份、定期的删除处理、各种接口文件备份、日志文件维护等）
8
设计
外部、内部、详细设计
风险
处理
遇到复杂逻辑处理，列举各种可能方案，择优实装，如多表关联检索：调查输入表的数据种类和特点→提出可能实现方案→在真实数据库环境中模拟实现来验证可行性→根据试验结果调整方案→小组会议审议
·设计评审质量问题：对问题进行分类→对严重的有代表性的问题让做成者分析直接原因和根本原因→提交给评审者审议→调查做成者的其他设计（或项目其他成员的设计）中有无类似问题→必要时以会议形式全员展开
参考文献
［1］百度文库：软件研发行业参考统计分析数据
（https://wenku.baidu.com/view/fea841ddb14e852458fb5786.html）
［2］豆丁·张俊光等：软件项目平均生产率实证研究
http://www.docin.com/p-1472168630.html）
［3］知乎·梅晴光：不懂技术如何判断一个页面的开发复杂度
（https://zhuanlan.zhihu.com/p/23234579）
论文点评
第一次以论文的形式提交，写了很多开发一线的感受，相信这些感受都是在多年工作中的切身体会，切肤之痛而产生的感想，能够让忙碌的生活暂时停下脚步，回过头望一眼，静下心来想一想，思考一下我们平时工作中值得挖掘的内容，是我们这次论文征集的初衷。
文章围绕主题，分析了经验不足在各个工程阶段所经常发生现象，又阐述了生产率和项目开发无法顺利进行所涉及的原因要素，最后表明了改善经验不足和提高生产率的一些办法和对策，描述了开发过程当中涉及的很多工作，实际上已经超出了题目所关注的内容，从项目开发的多维度，总结了自己工作中的经验教训，并且提出了改善对策，可以看出进行了认真的思考，难能可贵。可贵之处有以下几点：
题目所提到的经验不足，与其说是项目开发上的问题，不如说是人生的一大课题，没有一个人生下来是有经验的，这与每一个人的成长是一个道理。提升经验的办法只有两条：自我实践与学习。其中，自我实践起决定作用，学习起辅助作用。
先说自我实践，每个人一生都要经历许多事情，经历过了就增长了经验，每个人都一样。但是增长经验有快有慢，有多有少，其核心是遇到了事情动不动脑筋思考。早年间我们招聘有一个重要考评标准，是举一反三、触类旁通，就是这个道理。遇到的事情是否能够从中“榨取”尽可能多的对自己有用的东西，才是快速提升自己的关键所在，所以需要在工作当中不断思考。
再说学习，学习的本质是从前人中的牛人和身边的牛人中汲取别人的经验，以弥补自己在实践中还没有取得的经验，使自己成为有经验的人。也就是要从书本文档和周围人的身上，学到东西。
文章阐述了很多这方面的现象、分析与对策，例如强调要重视组织大家开会交流沟通，重视一定程度的培训，通过文档的标准化和复用，解决经验不足问题，提升生产率。
文章提到“要努力做到知其然知其所以然”，这一点很重要，这个思路是说要通过现象看本质，了解本质才能掌握事物的规律，才能总结出对今后有用的经验来。反过来讲，只通过表象是总结不出经验的，很多人做事就是所谓狗熊掰棒子，最后没有剩下多少有价值的内容。类似与我们上学时的题海战术和搞明白原理这两种学习方法，题海战术只能应付一时的考试，无法提升经验，即无法提升你今后解决问题的能力。这其实也是我们公司所面临的一个大问题，有相当一部分人不求甚解，这就会造成长时间的经验不足。
文章提出了要重视收集历史数据，并且提出了具体的收集方法，收集历史项目的难易度、生产率，以及其对照关系，这是最有价值的，其思路就是要总结以往的经验，为今后的项目提供帮助。这也是我们公司非常缺乏的工作，经验不仅要存在经历者的头脑当中，还要提升出组织级的资产和财富。文章不仅给了很好的思路，而且还给了具体的实施办法，值得组织级采纳，这部分非常精彩。
文章引用了一些文献，这也是很好的做法，反映了作者对一件论述的严谨思维。所谓论文就是在我们生活中有了一些体会时，对某些事情还没有想得很清楚，这时参考一下别人的著作，结合自身的实践反复印证，明确提出自身观点的过程。认真地做论文，绝对是给自己提升的好办法，因为要提出自己的观点，就要有深入的思考过程，平时是很难有这种机会的。
作为第一次论文活动，相信大家也没有经验，只要是经过了认真思考的都是不错的，感谢这些作者们开了一个好头，以此促进全体员工走入一个积极思考的阶段，论文虽然还存在很多不足，比如要明确定义自己讨论的主题，要围绕主题内容展开论述，要通过现象明确本质，要从本质得出结论，其间要有清晰的逻辑因果关系，像计算公式一样能够推算得出，最后明确自己要阐明的观点等，但是作为第一次，我们已经有了一个很好的开端，并且在第一次的论文中也能够阐述出很多有意义的内容，相信通过大家的努力，一定能够形成积极思考的氛围，不断取长补短，相互学习，快速高效的提升我们的经验，定会提升我们开发的生产率。
未经书面允许不得转发转载