[若有所悟]我看日式外包项目的运行体系
楔子
工作一年有余，一直在做对日外包的项目。我不是个偏激的人，不会因为做外包学不到精深的技术而惴惴不安；不会因为做外包学不到高超的设计技巧而唉声叹气。但是，对技术的追求，我不曾停止脚步；对软件的设计，我也不曾避而不谈。所谓“横看成岭侧成峰，远近高低各不同”，关键是你怎么看待自己，怎么对待自己。或许你在项目中担任一个开发者的角色，终日为某个模块的编码劳心伤神，但是不要固定你的视野，去思考，去总结，用与人不一样的视野去看待工作。本文尽管标题有日式二字，相信关于外包项目的运行，甚至于自主项目的运行，都有很多共通的点。由于个人能力有限，总结的内容如果有不足和错误的，烦请留言告知！
正文
从上升到理论高度的软件工程角度上看，我们可以找到一款软件从可行性分析到需求分析，到设计，到编码，到测试各个阶段的作业内容。软件工程是一门置之四海而皆准的学问，是通学。而专学，则需要我们去摸索，去实践，最后形成我们自己的思想体系。本文就笔者在工作中的实践，总结出关于对日软件外包项目的运行体系作介绍。
公司A委托公司B完成一个软件项目，这个软件项目的运行体系是怎样的呢？笔者将其分为以下十个构成部分。
一、工程周期预估
二、开发团队构建
三、汇报体系建立
四、QA&课题管理
五、工程计划制定
六、风险控制管理
七、品质控制管理
八、代码版本管理
九、文档控制管理
十、交付控制管理
下面就一一介绍每个构成部分的内容及作用。
一、工程周期预估
决定开发周期，虽然我没有接触到任何与之相关的，但是我觉得这个预估应该是由客户来决策的，不过既然是生意，也肯定却不了大领导们之间的谈判。这一部分具体的细节我还真的是一点都不知道，只是觉得肯定会有这么个阶段，只是工程周期的长短，应该是人数、生产性、时间的一个平衡点，毕竟软件开发并不是人越多越好。
二、开发团队构建
根据项目规模，开发时间估算团队人数，选择团队成员，这由管理层决定。这里的预估和选人是核心，预估需要根据规模和时间找到匹配团队人数的平衡点，而选人则是管理学的延伸了。选择一个对的项目经理也很关键，对于大型项目，应该选择一个有丰富经验的项目经理。而对于小项目，可以适当培养非项目经理的开发人员。还有就是选择开发人员，开发人员的能力与项目的风险息息相关，同时要注意项目组的新人率，高新人率即高风险。
三、汇报体系建立
我挺佩服日式项目在汇报这一点的做法，完善的汇报体系可以从上到下明了的掌握项目的进行情况。
在对日外包公司，按照报告对象不同可以分为三部分，分别是：向日方客户报告、向项目领导报告、向项目经理报告。下面就简单的介绍这三种报告。
■对日方客户报告
在我所在的项目，每一周都会有一个与日方的视频会议，同时每天也需要项目经理发日报，主要汇报三个内容：1.项目进度 2.QA（即目前存在的问题） 3.课题
1.项目进度：对日方的报告重要的是让客户感觉到项目的确在进行中，并且取得了一定的成果，这需要报告人了解客户需要什么内容，报告某一个功能用了多少行代码是愚蠢的报告。
2.QA：QA的报告是为了让客户知道我们的项目中进行中遇到了问题，如果没有QA那会更糟糕。
3.课题：课题一般是亟需解决的问题，当然也并非如此，比如项目组的教育，这也算课题，但有时也并非那么紧急，只是让客户知道我们这个超前的意识。
关于QA和课题，QA是一些零杂的小问题，比如需求说明中无法理解的问题，代码中无法理解的片段。 而课题则是更大的问题，需要花费更多的时间和精力去解决，比如项目已经开始，但是开发环境，开发平台不明等。
■向项目领导报告
在我所在的项目，没一周也会有一个自己内部的工程会议，工程会议的目的是让领导知道目前项目的进度以及问题，这里要注意的是，汇报的内容要能突出问题，比如因为某些问题 导致项目需要延期等等，这些对项目有风险的内容一定要放到汇报的最显眼的位置。
■向项目经理报告
在我所在的项目，每一天，每个开发人员都需要写日报发送到邮件列表，日报的内容主要是汇报开发个人一天内完成的工作内容，使得项目经理可以在下班前总结进度时候参考，也 有助于开发人员的个人管理。
■关于报相连
在日式公司有一种说法，叫“报相连”，即報告（ほうこく）—相談（そうだん）—連絡（れんらく）。某种意义上来说这是一种推卸责任的方法，但是却是能够控制项目风险的方法。做到报相连的核心是及时，遇到问题绝对不能拖，要立刻报告，联络，商讨对策。否则就相当于抱着一个烫手的山芋，最后山芋掉地上摔的稀巴烂，自己的手被烫伤不说，责任也得自己全权承担。如果及时将山芋烫手这个问题报告了，联络了客户，商讨不出对策后，山芋掉地上的话，那责任就由两者承担，在原则上我们就没有犯错了。同时这样做，也有效的利用了客户资源。
四、QA&课题管理
与客户之间的问答，各种问题如果没有QA&课题管理体系的话，将会显得很杂乱，可能会前两天一个人问的问题，过两天又向客户提问，这样会给人很不好的印象，所以QA&课题也是项目 管理中不可或缺的。
五、工程计划制定
在项目经历了准备阶段之后，就是制定详细的项目计划了，这是正式开发作业所依赖的根本。制定计划是比较复杂的，要考虑的面也要很全面，主要有三点。
1.生产性
2.有效人员
3.难易归类
即使是经验丰富的经理制定的计划，在未知的未来面前，也需要调整。所以，对于项目经理来说，他关注的应该是总体的进度，在遇到可能影响计划的事情时，用一句不好听的话 “拆东墙补西墙”，其实这也是常用的一招，A模块开发因为一个重大技术问题拖延了进度，那能不能通过缩短B模块的周期来弥补呢？这是项目经理应该反复权益的。
而这一方面也是我现在所未知的，需要努力学习！
六、风险控制管理
其实并没有一套严格的体系来实现这个体系，然而事实上他是融合在其他体系中的，比如报告体系，比如计划体系等等。关于风险控制是否应该单独拿出来作为 一个体系，我个人并没有什么偏好，拿出来也好，放到其他体系也好，只要做到能够即使预测风险，合理解决风险，善于总结风险就行了。
七、品质控制管理
我不得不说，日式的品质控制体系真的是很完善，但是个人感觉自己还没有完全吃透细节，况且我只是在中国的一家与日合资的公司，等到精通了他们的质量控制体系，一定要写一本书来介绍日本的软件精工。
下面简单的介绍一下我所能看到的品质控制体系中的内容。
■评审
日式项目中，从需求说明书开始，到编码，到测试，每一个环节都有评审，并且都有相应的评审记录票来记录评审中发现的问题，个人感觉这么严格的评审是质量控制上的绝妙的一招，不过也有一个缺点，就是低效率，对于紧急项目，这一套似乎不好用，所谓的敏捷似乎更是王道。
■测试
日式项目中，测试是我见过最为严密的测试，我所在的项目组，要经过严格的LT（白盒测试），UT（黑盒测试），CT，ST。对于发生大规模影响的开发，还需要进行RT（回归测试）。而每一个环节的测试用例都需要经过评审，有时还不止一轮评审，这样反复淬炼之后的测试用例才能用于测试。
■品质统括
统括，这是日式的说法，就是将各个工程阶段中所有的品质数据收集起来，来判断该产品的质量，这一点相信很多国内企业都没有这个环节。但是日式项目很重视这一点，也或许是对承接方的监督吧。
八、代码版本管理
代码管理体系其实就是一些通用的代码管理工具SVN、CVS之流，这一点上应该都差不多。但是值得我们学习的是：每次提交代码都要写上提交代码的原因以及修改代码的大概内容。
九、文档控制管理
日式公司重视对文档的管理，日方提供的资料文档，工程阶段产生的大量文档，教育资料文档，各种文档都有相应的目录存放，让人看着一点都不凌乱。
日式项目非常重视文档，及时开发人走了，找到另一批人，参照文档，项目也能快速运转起来。这也是日本软件事业得以发展的基础，试想，如果没有这些平常的积累，怎么能成就日后的伟大。这也应该是我们所欠缺的，国内的开发偏于速度，文档质量内容匮乏，导致积累少，人才断层。
十、交付控制管理
项目7月就要交付，至于其中具体的细节我也在期待中。
后记
最后写点自己在写这篇博客中想到的东西，等到有所领悟，有时间以后的博客里会写！
1.日式品质控制管理
2.日式文档设计技巧
3.日式工程汇报技巧
