1.      代码检查

这可能是目前最急迫的工作！因为从最近Stockholm项目的检查工作（包括翻译和功能两方面）中，还真发现2005年开发ODMS（也是当年APJ最大的一个项目）存在不少编码问题，比如说Hardcode、对象未释放等老问题，说明我们对编码标准的执行还很不够。其实，5月份还委托TownGas项目组对JPSS和BMIS也进行了一次Code Review，也发现在代码组织、层次关系、数据库操作方面存在一些问题，所以安排一次公司级的大检查是完全必要的！

已经决定， 9月下旬将对全公司刚刚完成的项目（如MFC Phase I、IRMIS、SIF、SIM Phase I等）以及正在进行的项目（如CAS、MFC Phase II、SIM Phase II等）进行互查，之前要求各个项目组在9月中旬开展自查。为方便自查与互查工作，9月上旬将讨论并确定代码检查的准则和清单。

2.      Common Library的建设

如果说代码检查是当务之急，那么Common Library的建设则更加具有战略意义。凡是从事过开发工作的人都不否认Common Library的建设对一家软件公司发展的重要性。APJ的Common Library的建设，从2003年开始也历经了几年时间，但始终没有达到大家的期望。今年我们应该横下一条心把这件大事情做成！

为此我们还改变了之前“开发→培训”的模式，为“设计→讨论+培训→开发”的模式。这样一方面使设计尽可能满足众多项目要求，而且集众家所长；另一方面通过设计讨论的过程对每位参与人员（项目负责人必须参加）进行了非常深入培训，可以在实践中更好执行标准。

但在实际执行当中还是有新问题出现，就是参与人太多、且各有各的想法，拖慢了Common Library建设进度。所以还恳请大家献计献策、推进Common Library建设。

3.      项目估计、工作量、效率

一般情况下，我们所作的项目估计与客户期望的进度是存在差距的。之前的做法大多是“质量屈服于进度”，想尽办法也只是为了满足客户的进度要求。但实际上，这已经埋下了后患。为了解决这个问题，争取合理的项目时间是必要的！

但如何才能说服客户制定更加合理的开发计划呢？我想事实胜于雄辩，我们应该基于已有的项目经验向客户提供更多的数据，比如人工生产率（代码产出率）、功能点的复杂度（低、中、高）以及预估的代码行数（不同的复杂度代码行数不同，但相同复杂度的功能点代码行数在一定范围内浮动，根据生产率可以预估工作时间）。这样客户不接受也不行。

其实这样做还有一个好处，就是让每位同事的工作也透明起来，一个人做了多少功能点、复杂程度如何、代码量多少，方便对个人工作能力评价。

但说实话，如何确定功能点和复杂度，目前我们还没成体系，需要一定的时间去研究、探讨，也希望大家积极献计献策。

时间过得好快，转眼就八月中旬了！年初制定的那些质量改进目标，目前执行如何，也应该有个中期总结了：

质量目标1   积极参与到项目的前期分析与设计中

执行情况1   ARisk、MFC、CAS、AMCM都已经做到，但SIF、SIM却没有做到，所以还需要继续推进：一是要保证我们有合适的人才可以承担分析设计工作；另一方面要向客户积极争取分析设计的工作任务。

质量目标2   前期设计工作要包括测试用例的设计

执行情况2   由于进度计划的问题，目前各个项目都还没有实现，希望可以在8月开始的几个项目（比如CAS、AMCM、MFC Phase II、SIMS Phase II等）落实。

质量目标3   开发期间的测试以项目组为主、测试组为辅

执行情况3   今年开始的所有项目都已经开始这样做，比如CAS就为项目组预留了一定系统测试时间，由项目组自己执行。SIM之前也有这样的安排，但受一些客观原因限制实现得并不好。希望8月开始的几个项目继续改进。

质量目标4   合理安排设计、编码、测试的时间

执行情况4   今年开始的所有项目都已经开始这样做，比如CAS就为项目组预留了一定系统测试时间，由项目组自己执行。SIM也有这样的安排，但受一些客观原因限制实现得并不好。希望8月开始的几个项目继续改进。

质量目标5   执行持续的技术培训

执行情况5   有很好的计划，但执行效果并不怎么样。7月开始的新员工培训，能够吸引人的课程并不多，所以还需要从课程安排、授课准备、课堂互动等多个环节进行改进。

质量目标6   公司级知识库的建设

执行情况6   一直拖到6月才开始，但进度缓慢，目前连第一项工作“菜单”还没有完成，一定要抓紧了！

质量目标7  真正落实项目负责人制

执行情况7  这个已经实现。7月推出了张志鹏、赵晓冰、古煜中、湛旭东、刘玉祥等5位PM分别负责MTR和HKCG的相关项目，统一由公司新任命的CSO David Fung进行工作指导。

质量目标8   设立公司级质量奖励

执行情况8   这项工作还没有开展。要尽快落实评定标准。

OMIS项目进度是非常紧张的！但说实话，安排的人手也不少，光项目组本身就有10人，还从其他项目组以及测试组借调了不少资源。如何使用好这些人员，变成非常重要的一个课题。

一般情况下，我们会根据每位成员对系统的熟悉程度以及自身的技术能力来安排工作任务。但前面也说过，OMIS中的ODMS是早在2005年开发的系统，当时的开发人员基本都已经被调整到其他项目组或者离开APJ，目前项目组中熟悉ODMS的人很少；这也就意味实际可以调用的合适资源并不多。但客户并不这么看！他们认为给你了有10几个人呢，即使对系统不熟悉，但人多力量大，也是可以配合到进度的！所以，当客户发现有Delay时，常常会质问：怎么不安排某某做什么？某某现在做什么？……

我把客户设想的这种工作安排方式称为“液体安排”，也就是说把我们每位工程师设想成液体，可以随意、到处流动，哪儿有空隆就往哪儿安排。说实话，一开始我也是有诸多牢骚的！但仔细想想，也不是没有道理。我们共产党不是就提倡“哪里需要就去哪里”吗！况且客户也不是不明白事理；如果真是由于对系统的不熟悉、或者受相关工作的影响不能完全达到计划，客户一定愿意协商新的办法。

既然这样，我们就要改变一下以前在工作安排上的思维和方式：

首先，不要再一味排斥客户的“液体安排”，特别要作好项目组成员的思想工作；

其次，在项目开发过程中，通过项目会议、代码走查、交叉测试等方式，尽可能安排项目组成员多了解整个系统而不是单一功能，为今后的工作安排留出更大空间；

最后，如果由于客观原因确实无法实现客户期望的“液体安排”，要尽早提出，与客户协商解决办法。

        早在1989年，著名管理学家彼得·德鲁克就在其著作中这样描写，“任何企业中仅做后台支持而不创造营业额的工作都应该外包出去，任何不提供高级发展机会的活动与业务也应该采取外包形式”。

        ITO和BPO是目前软件外包领域的两大主要业务领域。ITO主要包括编程、测试等软件开发工作；而BPO则是指企业将自己辅助甚至关键的业务系统委托给专业服务公司，由专业服务公司按照双方协定的要求为企业提供相应的服务，比如银行业务数据处理、企业呼叫中心、人力资源管理等这样的关键业务系统。由于将这些关键业务流程外包的价值远远超过简单的软件编码外包，所以往往认为ITO是外包的第一个阶段、而BPO是第二个阶段。

        目前，KPO（Knowledge Process Outsourcing, 知识流程外包）的时代已经来临。顾名思义，KPO介入比业务流程外包更为高端的知识工作的外包。这包括在知识产权的研究和工作、产权和财务、analytics、市场研究和数据管理和规定制订等。例如，法律文书处理、会计事务处理等等。预计KPO将被视为第三代外包流程——现在开始正逐渐成为现实的、主流的外包选择之一。之前其他的外包方式相比，KPO最具吸引力的地方在于知识套利，涉及外包更高技能的流程，而不是在于降低成本的潜力。在金融领域，KPO已经被用于处理信用评分，损失抑减估算和欺诈分析等工作。

        正是基于以上的发展趋势，国内的软件外包公司都期待实现从ITO到BPO跨越。随着越来越多的企业进军日本外包市场，传统的ITO市场已经陷入恶性竞争的困境。与此同时，欧美BPO业务开始出现向中国转移的趋势。一个是要求不高、利润稀薄、过度竞争的市场，一个是要求严格、利润丰厚、空间巨大的市场，这种跨越对任何企业都将是一种诱惑。
 

        据说印度正在往第三阶段：KPO，转型。 预测全球到2010年，KPO的市场会到170亿美金。其中印度接120亿美金。印度的从事kpo的人员也会从目前的2万5千人发展到25万人。 
 

在（一）中谈的主要是对一个项目、一项工作的重视程度。不可否认，它会直接影响到产品和工作的最终交付质量。

但在日常工作中，手头的项目、工作往往不止一个，都同样重视就等于都不重视，这时候需要我们对这些项目、工作进行区分，鉴定他们各自的优先级别（Priority），重要的先做，次要的后做。这与我们Issue Log、Action Log、TD中记录的缺陷是一样的，一定要把重要的、紧急的问题或缺陷先完成了，再去修改那些不紧要、可以等等的问题或缺陷。

然而在现实工作中，不少同事总是先把那些级别标记为L的改了，然后才开始改标记为H的问题和缺陷。一个重要原因，就是那些标记为L的问题和缺陷很好改，花不了多少时间。但不要忘了，再少的时间也需要时间；积少成多，时间也许会占用不少呢！所以不要让这个坏习惯影响到给客户的交付。

也许有的同事会强调，有些问题是相互关联的，一定要先改了某个级别为L的、才可以去修改级别为H的。我没有作过统计，但经验告诉我，那种情况并不多见；许多问题仔细拆分一下，并不是那么强的关联。如果真是很强关联，那么和可户说一下，把那个有关联的、级别为L的也改为H的，不就行了！所以，很大程度上，还是我们的思维和习惯在作怪。

OMIS系统，就是去年MTR和APJ都投入了大量人力的PI-8002项目，它包括ODMS、LPM、OPD、SOM等四个子系统。除了ODMS是之前2005就开发的（去年完成了一些Enhancement），其余3个都是在2008年重新开发的（0PD在2005年也开发过一个版本，但去年作了较大修改，所以也认为是重新开发的）。今年项目组的主要工作就是在去年版本的基础上不断完善，从而可以得到一个可以为更多用户使用的Product版本。

这样也就很容易了解OMIS当前的主要工作：一是作好多语言处理，二是尽可能发现目前系统中存在的问题并将其修正过来。单从这两项工作来说，难度和挑战性都比去年小了许多，而枯燥性相对增加，很容易让人丧失新鲜感、忽视其工作的重要性。不说别人、就说我自己，也是把这个项目归入维护一类，认为项目组按部就班去做就好了，应该不会有太大的问题。所以在开发资源、测试资源、设备资源方面，都没有特殊关照。

但就在7月中旬接到MTR通知，要求我到MTR与Eric（MTR ITSD7个系统经理中排名非常靠前）、Olivia（直接负责OMIS的系统经理）、Michael（负责与APJ协调的MTR系统经理）、Vincent（MTR SQA Manager）等人协商OMIS的工作安排，以确保在规定的时间内交付有质量的产品版本；如果需要，优先确保在OMIS项目上的资源投入，并要将结果直接汇报给Daniel Lai（MTR CIO）。在7月最后一周里的两次重要会议（PMG和PSG），也都拿出了相当时间来讨论、部署这个项目。可见，在MTR眼里，这个项目的重要程度是非常高的，与我们APJ的认识有着天壤之别！

其实MTR的道理很简单，OMIS现在是一个产品，不象以前的项目时只有港铁自己使用，目前需要提供给全球的客户使用（今年11月2日将在瑞典的斯德哥尔摩投入运行，之后还会有墨尔本等地用户，当然也包括众多的国内客户，比如深圳、沈阳等），其质量代表了港铁形象，是绝对不能出差错的！

明白了这个道理，我就必须领导我的团队作出合适的调整。首先7月23日以来，每天我都会拿出相当的时间来处理OMIS的事情，和项目组一起商量解决办法；其次，我和要跟SQA和测试组协商，如何调配资源对OMIS项目进行独立测试；要跟其他项目组协商，是否可以调配有经验的人员对OMIS进行Code Inspection；要和南方软件检测中心合作，对OMIS进行第三方检测……所有这些，还要监督执行的情况。但产品是出自项目组的，真心希望项目组成员能够明白这个道理，重视起这个项目，认真对待分配的工作，真正把有品质的产品交到用户手中。

想对APJ每一位工作人员多说一句，是否我们都能够把自己的工作看成是在为下一个环节使用者（可能是客户，也可能是我们内部的同事）提供产品，其质量代表着自己的形象？如果大家认同这点，就希望项目组交给测试组的代码是有质量的，而测试组交给客户的是更加有保证的！

提出这个问题，十有八九会回答“工作忙”！

想想平时的工作，确实也够忙的，搞不好就要九十点才回家，等吃完饭、休息一下就十一、二点了，也该洗洗睡觉了，哪有时间还写什么博客。但阿东的一句话提醒了我，“文化是需要培养的，公司的高层必须重视并带头才行”。没错，如果自己总是以“工作忙”为借口而放松了公司正在推行的博客工作，那又怎么好要求其他同事呢？难道其他人就不忙了吗？

突然想起了《Issue Log》，里面有一列“Priority”，是说所有的问题都有轻重缓急之分，在时间紧张的情况下，我们应该优先解决级别高的问题。其他工作也是一样，在时间不够用的情况下总应该紧最重要的事情！如果能够把写博看成一项工作，而且是级别较高的工作（公司正在推进企业博客文化，级别还真不低），那么就应该优先完成这项工作。

对于大多数的开发人员来说，解决《Issue Log》里的Issue的确更加紧迫一些，因为客户在催；但不可能天天都在解决Issue，总有相对可以安排写博的日子。更何况，如果你的博客是关于如何达到客户要求、解决技术问题的，那意义可比你解决一个问题大多了！所以，我在这还是要呼吁一下，大家尽量每周写一篇博。我自己也是，可以在博客中说说过去一周工作中发生了什么问题，我们应该如何改进这些问题。

除了工作忙，还有一个答案也是大家经常提到的，让我们写那么多博，有什么好处呀？

这是一个很正常的话题。记得六月中旬我和陈总到武汉出差，办完公事，我就带他到当地非常有名的“亢龙太子酒轩”吃饭。时间已经是晚上八点多钟，对内地城市来说，已经是较晚的吃饭时间了。但我们到了的时候，还是有许多人在排队，我们拿到的好是52号……陈总纳闷了，为什么这么晚还有这么多人宁愿排队也要在这吃呢？饭菜就那么好吃？其实酒店的出品确实还是不错的，但也不至于八点多钟还那么多人排队。仔细看看排号单，发现一行小字：“感谢你的耐心等候！此次你的全单可以享受八折”。不敢说这就是大家排队等候的主要原因，但对留住客人肯定起了很大作用。想想我们的博客工作，既然还处于起步阶段，是不是可以有一些激励措施而让大家自觉把其列入日常工作、并且还是级别较高的工作呢？大家都可以提提。

时间很快，已经过去半个多小时了，好在我完成了公司交给我的这个工作。习惯成自然，争取每周在这里和大家见面。

（2009年7月12日）