环境、现状与反思

1 我们今日的窘境

1.1 环境

　　我们所处的环境是一个追求“革命性技术”的业界。公司追求着多、快、好、省地解决问题的捷径，管理者关注的只是软件进度、发布版本、成本和利润，在他们背后，软件缺陷已经埋了下来。专注代码质量的程序员往往不受青睐，因为他们思考的更多，在开发进度方面往往不尽人意。当项目负责人无法评估或不关注代码质量时，客户只会得到一堆调试不良的代码。

1.2 人才流失

　　今天的程序员大多数都不会长期从事某一种技术，这与收入紧密挂钩。程序员会倾向与转型为更高收入的技术队伍，或者退出IT业。随着市场供求关系，各个阵营市场占有率，利润等多种因素左右着程序员的收入。即便是在某个技术上十分出众的程序员，面对经济上的现实差距，也无法抵抗金钱的诱惑而转投其他技术队伍。现在的市场，不再尊重那些资深从业者，而是迎合“现学现卖”的投机者。归其根本在于，对代码质量的低要求，使得技术硬手无用武之地。

1.3 系统交互复杂

　　今日的信息化系统已经不能由独立的公司或软件产品承担，而是趋于多公司，多平台的相互协作与交互。现实的挑战就是，更大的系统，更多的平台，更繁琐的流程，更复杂的整合需求，以及更多的标准。

1.4 技术快餐

　　与之前不同，现今的开发者更为大胆。他们敢于将未经验证的新技术应用与产品或项目。开发者可能经过短暂的学习（一周或者几天）就将学到的并不熟练的技术应用于项目，之后的风险全部转嫁的测试或者客户身上。而此后也不再对这些新技术继续安排学习。程序的可靠程度和可维护性大大降低。

1.5 产品团队不堪重负

　　与项目不同，产品的代码版本及分支路线更为复杂，其生命周期更长。当你进入某个产品项目，你很可能面临的是，缺失或低质的项目文档，多种风格并存的代码以及潦草的少的可怜的注释。那些最先搭建系统的前辈可能已经离职，开发团队组成也许已经经过几代，你听到的最多的是抱怨。面对那些延期的bug和新的需求，没人通晓这些堆积如山的代码，牵一发往往动全身。阅读和理解代码占据工作的大部分，面对客户的各种要求往往不堪负重。

2 一些成功的经验

2.1 提高代码质量 

• 改进QA流程 多数QA仅仅依靠大范围的人工测试来评价项目质量，即多数公司的QA依靠的是测试团队。理想情况下，大范围的测试并不会有很高的错误检出率。（如果你的团队，每次发布版本，你们的新建和重新打开的bug数量仍然很高，我只能说你们的公司尚处于软件作坊阶段，真正成熟的团队，是不会允许交付测试团队一堆调试不良的代码的，即便是在赶工时。）检查缺陷最有效，同时也是检出率最高的方法，就是——代码审查。因此，必须在计划阶段，就为代码审查预留时间，以便让开发人员参与进来。
• 激励手段 在绩效结构中，应该与质量、进度、复杂度等挂钩，而不是单纯地只看进度。
• 测试每一个关键里程碑 理想情况下，测试每个版本，测试用例做到100%的覆盖率。但现实中，出于时间、成本等因素，测试不可能细化到边边角角。但对每个里程碑进行全面回归测试是最低的要求，这样软件的bug更少，开发团队更能受到激励（例外是测试报告不尽如人意）。
• 乐观的对待错误 不要把测试当成是对代码的鸡蛋里面挑骨头，不要埋怨为什么测试现在才测试出之前某个版本的缺陷。PM一定要避免开发团队和测试团队之间的相互指责。
• 要求清晰、简洁、明清的测试报告 测试报告应该言简意赅，不要过于追求样式华丽，技术型文档能够用一句话说明白就别啰嗦。
• 使用缺陷核对表 “缺陷核对表”我也想不起它的出处了，也或许是我的主观创造，但从项目实践角度讲，“缺席核对表”能够有效降低缺陷数量。下列显示了一种简单的缺陷核对表：

　　这份表格是否好用，在于其更新的频率与用户群。它能够帮助PM及时发现bug集群，并可以通过例会或邮件打预防针，防止缺陷核对表上的bug蔓延。

2.2 为人才流失做准备

• 注重文档的积累并注重代码注释和编码规范
• 推动团队内部的交叉培训
• 在某些共识的环节上推动自动化
• 建立健全的雇员框架

2.3 一些成功的系统整合经验

• 组建跨职能团队 公司各个智能部门都有义务参与进系统整合，通过关键用户来平衡各部门的需求。
• 制定合理的进度计划 PM能够顶住压力，制定现实的计划，而不是通过削减范围或质量来迎合公司。
• 认真评估资源 很多项目需要外部开发人员参与，所以需要对这类资源进行能力评估，以便合理安排进度。
• 并行上线 在新系统没有通过最终审核之前，请保证旧系统的良好运作，同时维护好旧系统的数据。
• 做好打持久战的准备 不同于制作网站或OA，整合项目牵扯到更多的需求，更复杂的系统和业务流程，因此，请做好需求频繁变更以及打持久战的准备，并让团队了解现状，防止团队因为长时间的开发和过少的里程碑而形成挫败感。

2.4 有效降低产品的维护成本

• 创建并维护文档 文档如代码一样是宝贵的组织过程资产。虽然敏捷软件开发注重可以工作的代码，但是，也不能打着敏捷的旗号来抵制文档。一些必须有的文档，比如：需求说明书、软件规格说明书、开发计划、设计文档、测试报告、变更控制等，需要纳入到配置管理中去，并且在维护过程中进行同步。
• 严格遵守编码规范 编码规范必须在项目组内部达成共识，所以开发人员必须严格遵守，有条件的推荐进行自动化的编码规范审查。
• 做好配置管理 请参考本人博文 SVN与SCM。
• 推动自动化 推动测试、发布、代码审查的自动化。
• 推动交叉培训 不要等到人员即将离职才分享他的经验，要在工作间隙，利用暗时间，推动团队形成交叉培训的习惯，使关键技术不会局限在单点。
• 快速处理产品问题 对于延期的bug要尽快处理，越晚处理，其修复成本越高，一旦开发者离职，让其接任人员来修复这些延期bug则有些强人所难。
• 对新技术提高警惕 评估新技术带来的风险与收益，选择那些满足企业宏观目标的技术，尽量不要在高风险项目上引入未经实践的技术。对于技术探索项目，范围不要太大，而且，一次不要引入两个以上的新技术（也有保守的公司，规定技术探索项目，只能引入一个新技术点），以便能有效地评估收益和影响。在引入新技术的过程中，一般用1/3的项目时间快速学习和吸收，用1/3的的世界培养团队自立，最后1/3的时间让团队成员完全掌握。
• 完善项目管理 建立完善的项目管理流程，能够形成以客户为中心的，有完善体系的产品团队，即有效地协调需求、开发、测试、质管、实施等不同资源，快速应对来自不同客户的需求。

2.5 让团队成员参与项目管理

　　如果团队成员没能参与项目管理，则项目管理将大打折扣。为了让团队的每位成员都参与到项目管理中去，有以下建议：

• PM需要从团队成员角度思考某些问题 PM需要理解和接纳程序员的某些工作风格和激励因素。
• 适度的授权 对有能力的成员授权，不仅能提高其积极性，也能让PM能专注于其他业务。
• 常开会，开小会 经常与成员沟通，了解项目现状，但不要开那种冗长的会议。
• 对于团队性决策力求达成共识 PM不要以权压人，对于如编码规范这类影响较大的规定，需要促成团队成员的共识，而不是自我的独断专行。如果PM搞独裁，那团队成员也会玩非暴力不合作。
• 在员工入职培训时强调项目管理 在入职培训课程中，明确项目组的各种规定，流程以及工作各种辅助管理软件的使用。

3 IT治理

　　IT治理就是要明确有关IT决策权的归属机制和有关IT责任的承担机制，以鼓励IT应用的期望行为的产生，以联接战略目标、业务目标和IT目标，从而使企业从IT中获得最大的价值。

3.1 IT治理成败20条

10条有效运用资源的方法：

1. 针对IT治理价值，与开发者保持坦率的沟通，解决其中问题而不是压制言论。
2. 组建公司级跨职能IT治理委员会，保证治理顺利推行，保证技术体现客户最大利益。
3. 建立量化指标，利用公认的指标评估治理进度。
4. 保证IT基础设施各部分的透明。
5. 将公司IT治理策略延伸到外包商。
6. 建立能表现业务目标的全景视图。
7. 将IT治理视为促进企业成长的基石，利用奖金引导员工的正确行为。
8. 对公司员工和团队内跟不上变化，相关技能欠缺等等迹象多加注意。
9. 在软件开发周期的每个环节都实施IT治理，以防留下盲区，导致差错。
10. 推进自动化，但不抛弃人工评审流程。

10种白白挥霍资源的行为：

1. 未经解释就强制推行的官僚流程。
2. 架屋叠床的监督层级。
3. 无人能懂的报表。
4. 被隔离于代码之外的开发者。
5. 仅限于单个部门的努力。
6. 企图一切尽善尽美的紧张神经。
7. 仅在一两个方面实施IT治理的开发流程。
8. 缺乏跟踪IT管理的支出和效果评估。
9. 重复创造的策略。
10. 对IT治理资源充足程度的盲目自信。

3.2 衡量IT治理和相关投资成效的10个问题

1. 管理层是否支持和实施IT治理？
2. 开发者是否参与其中？
3. 是否是公司的主动战略行动？
4. 是否增加了企业透明度，使部门和员工权责分明？
5. 是否让引入新技术和企业合并时的基础设施融合更加容易？
6. 能否帮助员工改进行为？
7. 是否给所有干系人提升价值？
8. 能否做到极尽精益和高效？
9. IT基础设施可否随时抽检，而保证没有问题？
10. 是否减少了软件缺陷？

4 杂谈——终结IT业七大流言

1. 信息技术是精确的科学 现实是， 建立应用依靠的是程序员的代码，而编码是一门艺术，程序员是匠人，信息技术同样需要工艺。
2. 下一个版本能解决这些问题 软件开发商的常用伎俩。
3. 开箱即用 企业级软件往往很难达到开箱即用，这往往是软件厂商的吹嘘。
4. 代码文档完善 现实是，开发人员被进度和变更压榨了120%的时间，无力维护文档。
5. 文档说明一切 文档质量参差不齐，有时不得不聘请外部顾问。
6. 团队不需要“黑客”和“牛仔” 前者指那些擅长安全技术的人员，后者则指那些技术强硬但特立独行的人员，他们的共同特点是技术过硬，工资不菲。其实开发团队中如果有掌握安全技术的成员，能使你开发的系统更安全；而如果能驾驭牛仔，他将能帮助团队冲破围城。
7. 最大的安全威胁在公司外部 现实是，绝大多数攻击源自公司内部。

参考文献：

　　《差错 软件错误的致命影响》