理想总是好的，可现实总是残酷的。你有过每个周六都加班，每晚都加班的经历没?你有项目完不成，接二连三申请延期发布的经历没?你有过遇见过你委以重任，但他却误了你事的同僚没?如果你工作了一段时间，又恰好又有带过小队伍的经历。我想你应该也遇到过这些问题中的一个或几个吧。

　　我当然也遇到过，一回是将一个很重要的功能组件重写的任务分派给一个新的团队成员，给予了我能给的最多资源，并将其他任何任务，可能的干扰源我都给挡了。但结果呢，开始我还满怀希望，因为他非常自信，也不断的给我好消息，比计划更快更好。但时间过去一半也就是约两个月后，痛苦开始来了，他创建了一个新的分支，因为接口变了，无法和其他组件集成构建，而这一切我之前竟然不知道。但离版本发布已经只有2个月时间了。这还包括测试。而该模块功能上都还只完成一半的样子，而且完全抛弃了原有做法。更惨痛的是两个星期后他离职了，面对不能集成，功能不全的半成品真是欲哭无泪。最后版本发布时，此过程中代码仅作参考，而使用旧代码修改版本，预期的一些功能没有，预期的效率提升没有，还加班一段时间。这也是我的软件开发历程中最大的遗憾。

　　事后，我总结了该次技术事故的教训，但没有及时发贴。现在做一下简单的总结，如何避免此类事故的发生。

　　一、认识问题

　　在将较大的模块分配之前，必须确保模块主人明确了需求，了解了问题。很多程序员有一拿到问题立马动手的冲动，此时你至少应保证他看到了所有的问题。此步绝对不能省略，你不能假设他自己会去找需求，他能找到需求。你也应该将你对需求的认识，你从全局上的观点传递给他。

　　二、搭架子

　　在甩手出去的工作，尤其是较重要的模块给一个不了解的人的时候。必要的模块架构设计是不能少的，这个时候你可以了解他的思路;讨论中提升设计的质量;更重要的是可以从整体的角度评判设计是否合理，是否可以和其它模块较好的工作。同时还可以减少模块开发人员的困惑，减少独自摸索的时间。

　　三、分解工作

　　在架构设计的基础上，将工作分解开来，独立出来一段一段做。分解时最好和开发人员讨论，他在细节上可能会比你更清楚。

　　a. 工作项的大小。从经历来看每个工作项1-2周比较妥当，时间太长不利于管理时间，也较难准确预估。太短又太细，而且有些事情又没那么容易做完做好，此外还可能涉及其他方面的修改。很多人习惯做完任务就不管了，也没有足够的时间测试，调整。

　　b. 工作项的独立性。必须保证每个工作项的独立性，可以单独开发，单独集成。每一到两周将代码集成编译并做简单的集成测试(保证主体不受影响，新增功能有效)。

　　四、及时跟踪设计，时间，代码

　　先说设计上的跟踪，在新成员刚参与时。可以要求必要的设计文档，如类图，核心部分的序列图。再就设计与程序员讨论我们现有的设计样式，使设计与已有设计有一定的相似性。并可借此机会培养新成员的设计水平和设计方法。此讨论可以多讨论一些OO，设计模式什么的。不一定要用，但要有用的准备和用于不用的判断。

　　时间上的跟踪，主要是每周的周会，周会上可以依照总的时间安排和工作进度一起简要讨论，让大家心中有底。此外还有每周的工作安排和回顾，新成员可以要求写细点，每周要有两到三个检查点，及时跟踪。出现问题可以及时发现。

　　代码上的跟踪，主要是要求在最新代码上开发，保证有交互的组件可以正确编译。此外新成员要在开始一段时间对代码进行Review，保证编码符合规范。模式和已有代码一致。

　　另外就已有组件的修改，可以要求逐步改进，使用桥接或其他方式逐个替换进新的模块。

　　很晚了，先就想到这了，欢迎大家提出好的想法。到时我再抽时间补充完整。