文档详细讨论了软件交付质量和生产率中存在的问题及其原因，包括需求和技术的不确定性，以及人员水平和职业化差异。针对这些问题，提出了多种可能的解决方案，如强化沟通、明确质量标准、客户参与、及优化开发流程等。最终强调了职业化培训和团队合作的重要性，以提升整体软件项目的质量和效率。

1. 2010年4月23日
Site: http://sempsalon.wikispaces.com/
Email: semp.salon@gmail.com

2. 主题讨论
• 组织遇到的问题
– 软件交付质量无法满足期望或远不如竞争对手
– 软件生产率无法满足期望或远不如竞争对手
– 项目需求、技术等不确定因素大
– 软件工程师开发习惯差异大，导致任务完成质量参差
不齐
• 原因
• 可能的解决方案

3. 交付质量
Site: http://sempsalon.wikispaces.com/
Email: semp.salon@gmail.com

4. 原因分析
• 贝尔：国际性项目
• 电信行业项目需求变更少，多有国际标准可依据
• 但面临有解决方案的变化；
• 软件缺陷，项目周期长，验证测试占项目周期超过1/2,
• 项目涉及多国时，沟通有效性差（层级过多）；有时甚至
牵涉到硬件环境的变更；最终大集成时发现问题
• 子项目项目经理对项目细节了解不够；
• 缺少进度度量，任务优先级、权重的评价标准；
• 开发人员解决bug的时间占工作时间4-5成；

5. • 可鲁电气：
• 开发团队又是测试团队，对质量控制元素的监控模糊
• 有些“质量”问题，实际上是其他因素（例如：习惯，体
制，流程等）
• 公司机制问题，销售不懂业务接下的单子无法完成。
• 验收标准不清楚
• 客户不成熟，规范性不够：客户协作/分期交付

6. • 世范：
• 内部人员对质量管理的理解有差异；
• 项目计划仅由项目经理根据个人经验完成：建议
计化由下向上制定，项目经理负责汇总，计划是
一份项目组的commitment。
• 电子政务项目：
• 与客户原有操作习惯有大差异时，导致客户对系
统质量评价降低；
• 领导层的质量意识决定了该公司的质量导向。

7. 解决方案
• 可鲁电气：
• 质量标准的定义（内部的、面向用户的）：与用户达成共
识（目标一致性）
• 开发过程与客户紧密互动（如用户参与，阶段性确认等）
• 质量标准衍生出质量控制点
• 阶段评审（需求，实施方案，阶段成果等）
• 日本：每两周与客户沟通，把客户要求带回来，但沟通有
原则；驻场开发，沟通有效：关键要分析哪些是当期要完
成，哪些可以二期、三期再完成的。
• 应用软件与用户要密切互动

8. 可能的解决方案
• 客户尽早加入，参与决策
• 开发人员对业务的理解
• 对远不如竞争对手来说，某种程度上说不可比，
就项目来说比较的基准没有。就产品来说，可以
通过不同客户的评价来评定。
• 新人：培养计划，公司内部有培养机制

9. 生产率
Site: http://sempsalon.wikispaces.com/
Email: semp.salon@gmail.com

10. • Infosys,过程流程改进
• HP，PSP/TSP
• 时代光华，企业标准
• 电装，流程改进
• 中远，开发部的管理

11. 问题
• 项目抱怨人力资源不够，但管理层觉得并没有那么忙
• 与其他公司做过比较，生产率有些高蛮多，经验不足导致了生产
性低；经验积累需要时间；
• 行数计算非常困难，且行数与工作量之间没有很明确的关系；
• 实施了CMMI，但是对质量和效率上的提高不大；
• 流程没有理顺，透明和电子化；

12. 可能的解决方案
• 生产率LOC/Hour，FP/Hour去除重用、自动生成
• 按照项目类型、项目规模、工程阶段和项目整体来计算生产率
• 执行多次FP估算(需求、设计阶段）
• 组成FP估算的专家，来估计FP
• 更多的利用重用（按照业务、按照技术等），并且使用Incentive
program来激励人员提供重用；
• 不同的Tools来提高自动化；使用Excel宏工具将设计书直接生成
基本代码；
• 使用减少返工（更好的评审、培训）来提升生产率；

13. 可能的解决方案
• 建立FP和代码行统计的标准，保持一致;
• 应用PSP/TSP, 减少测试时间
o 质量得到提高，生产率没有很大变化，可能是由于学习曲线导致的
o 质量得到提高，生产率感性上得到提高
• 引入自动化的工数统计工具，按照WBS汇报工数，区分管理工
数和非管理工数
• 尝试了Lean，通过process mapping来找出value和waist; 发现交
流和知识的转移是主要的浪费。可以关注在knowledge
management、retainment, continuous learning;

14. 可能的解决方案
• 度量由商业需要来驱动；
o Why measure?
o What measure?
o When/How measure?
• 进度和质量（Agile和PSP)
o 挣值/功能
o 质量计划（产品和过程指标），当发生问题的时候，可以有足
够的数据支持分析
• CMMI and PSP/TSP and Agile

15. 不确定因素
Site: http://sempsalon.wikispaces.com/
Email: semp.salon@gmail.com

16. 原因——需求不确定性
原因 需求不确定性
• 客户本身的原因
o 不同层面客户目标不同
o 拍板的人不是最终用户
o 需求来源于第三方
• 体制原因
o 政府（国企）年度预算制度
o 规划与实现的失衡
• 市场原因
o 市场的快速变化
• 企业内部
o 销售急功近利——过度承诺
o 传统开发模式下开发人员离客户太远
o BA的能力不够，引导与理解不足

17. 原因——技术不确定性
原因 技术不确定性
• 技术不确定性
o 定位（目标、范围）不确定
o 新技术的风险
o 外部技术的不确定性
o 技术方案会随对系统的了解而变化

18. 可能的解决方案
• 需求的不确定性
o 需求的签字确认？？？
o 通过技术的灵活性弥补（通用框架、产品运用）
o 原型法、迭代方式开发
o 分阶段交付
o 项目前期核心开发人员参与
o 定期让用户参与原型评审
o 产品化（细分领域、通用）
o 开放API，鼓励用户或第三方参与客户化开发

19. 可能的解决方案
• 技术不确定性
o 技术选型中采用POC
o 技术原型开发
o 延迟决定
o 利用外脑

20. Site: http://sempsalon.wikispaces.com/
Email: semp.salon@gmail.com

21. 人员的差别 1– 水平和能力的差别
• 原因
– 预算有限，招聘的人不可能都是最强的
– 工作分工，Junior的人员和Senior的人员分别完成项目
中的不同工作，形成互补，使生产率趋于合理
– 一件好事，Junior的人员以Senior的人员为目标和方向
，反而可以更好的促进团队
– 因此希望团队人员的水平是有梯度的，能够帮助团队成长
• 可能的解决
– 结对、流程和机制、导师、评审

22. 人员的差别 2 – 职业化的差别
• 原因
– 学校刚毕业的人员往往并不职业化，国内的高校并不具备相关课
程
– 没有足够的职业培训机构
– 一个团队中总有相对职业化和相对并不职业化的成员
• 可能的解决
– 职业化程度高的人员的带领
• 资深的成员需要得到他人的信任和协助
• 这种信任来自于他的职业化表现和工作的结果，并不取决于他工作的
年限
• 所谓“职业化”是以结果导向的，他们往往能“把事情做好”，他们
总有一些好的方法
– 有一个好的导师是培养人员职业化的重要因素

23. 解决的可行性？
• 可能的解决
– 对于人员的职业化要求根据不同的行业，要求不同的
要求
– 未被污染的人员是否能够被快速的训练成为职业化的
人员 – 速成班 + Mentor的方式？
– 短期项目人员不够，外包是一种方式，但是外包公司
可信吗？ （职业化训练）
• 印度为什么能做到？训练有素！
– 高校？职业培训机构？是否可以纳入这些训练？
• 总结
– 不主动、没意识-〉主动、有意识
– 职业训练、职业人员的带领、机制的制约、文化氛围