离岸经营的启发（二）分拆软件业务

高居软件界前列的巨匠们相信，一切问题可以由技术或技术人自己解决。于是，该由需求分析师搞掂的问题，需要开发人员“拥抱变化”，该由测试人员搞掂的问题，需要开发人员“测试驱动开发”，该由技术管理解决的问题，需要开发团队“自组织”，该由文档工程师搞掂的事，需要开发人员“编写高可读性的代码”。

但现实的问题是，大量软件项目中，无论团队多么优秀，最终都会延期、不合格、转手甚至宣告停止。

现在国内软件外包流行两种模式：项目外包、人力外包；项目外包，目前大多数技术型的公司缺乏业务高手，无法驾驭整个项目的需求实现程度；人力外包，服务商可以采用自身的管理体系、客户关系来操纵项目进展，相对而言也可以比项目外包组建角色上更完整的团队。后者的模式很像在软件开发教科书上描绘的模式：客户公司组成顾问团、研发公司带上开发团队，还有产品经理、用户体验师……大家克服一个又一个的困难，遇上一个又一个不可思议的问题，最后期限到达，项目延期或正式上线（延期一般都是99.9999...%）。软件工程因此发展起来了，各种各样的过程改进、规范完善又到自组织的敏捷团队，但起码到目前，软件项目，it's always been the same old story.

看看离岸经营是怎么做的吧！需求分析师、系统架构师的位置设在客户总部，各个开发团队位于全球任何一个提供比较优势的程序员生活的城市；用文档阐清需求和设计约束，各个开发团队进行编码、测试然后交付清单和文件。在这里，很多时候需求依然是不明确地，变化的，但有专人和时间去做调研并且——比我所知的任何地方都高效和高质量。

离岸经营带给我们的启发是，从管理（宏观）而非团队内部（微观）入手去解决问题。想想吧，这仅仅只是一个开发团队而已，你无法得到更多。如果你是只想着利益的老板，这正是你重新审视赚更多钱方式的机会；如果你是一个只想着忽悠的经理，我建议你要么改进要么走人，因为问题就出在你那儿；如果你是客户，也可以想想这些年你的付出所得是否成正比。

需求、设计、开发、测试、交付、维护，软件项目所涉及六个业务范围，软件工程所研究和提供的仅仅只是调节六大模块交互的时间与顺序，采用什么样的方法论并不重要，重要的是正确的人坐到正确的位置。根据业务范围拆分软件项目为五至六个业务模块，制定模块之间的协作策略（文档、工作流），然后挖掘自己最有价值的业务，其它的进行外包——日本人就是这么干的，如果那么多对日外包的程序员能转换一下立场，我们会从中受益。

本文在开初就说了，我们更多的是需要模仿和学习，因为在这个行业，有太多值得我们模仿和学习的现成的东西；在能够解决开发中一系列难题之后，欢迎在行业中有更大目标的技术人投入到宏观视角和管理视角上来看待我们的处境，这里没有“为国内软件业创造一个美好的环境”的口号，而是去解决我们自身技术所不能解决的问题。