在大型 ERP 项目开发时，有多个子团队，每个子团队有多位工程师。昨日和某个子团队的项目经理聊天时，我强调专人负责各层开发的重要，也就是 DB、Business、UI 各有不同工程师负责，横向分割工作，而不是一个工程师负责一个功能，DB、Business 和 UI 通通一个人包了，变成直向分割，其要点如下：

• 每个工程师熟悉的技术不同，UI 需要 Ajax、Web、ASP.NET，中间层熟 Web Service、Domain Know How、DB 层熟 T-SQL 与数据库对象撰写。让每个人专精自己的技术，但不必学其他用不到的技术。


•  一层由一个人或一群人负责，可避免重复开发。因为若我写 UI，call 我写的 Business service，再 call 自己写的预存程序，其间一定会藏有许多自己开发上便宜行事的作法，但不利于别人呼叫。因此两个人有功能近似的需求时，会自己写自己用的 Service 或 Stored Procedure，而不去尝试重复使用别人已经开发的。因为找别人开发过的近似功能很麻烦，且若不合用，对方也不见得会帮我改。到最后，DB 内一大堆近似的预存程序、检视、函数，中间层服务有一大堆近似的类别、方法。若商业逻辑层或数据库层都是专人写，则该人可以防止重复开发。


• 各团队模块间，其商业逻辑或开发技术的交流较为单纯，比较能有跨团队的横向沟通，而不会彼此功能抵触却不知道。


• 每一层呼叫另一层时，就在建立标准与除错，因为某甲呼叫某乙写的服务时，就会要求标准化，并替商业逻辑除错，而非某乙任意写作。以后在模块间互相呼叫时才有可能。

    若个人开发各自功能，好像找一群人来建房子，甲负责厨房、乙负责浴室、丙负责客厅、丁负责卧室…结果每个人都砌了墙、开了门…但彼此的门对不太上，从客厅要进卧室时，一开门就撞墙了，因为两个门没有标准。我们应该要甲负责整地、乙负责砌砖、丙负责水电、丁负责装潢…等等。

    该项目经理反问，这样不好管，团队的默契也难以养成。以往哪项功能没写出来，盯那个人即可，现在某甲说某乙没写，某乙说某丙没写。我建议是应该形成团队压力，让大家知道团队进度是卡在哪层的服务，在等哪个人。

    而团队开发默契本来就是需要时间培养，分层负责开发初期的确较为混乱，不容易立刻让高手一下子就做好单支从头到尾可测试的功能，但长期而言，分工才能培养专精人才，有了合作默契与惯例后就不会混乱。项目经理也强调组织的配置是工程师 Pool，所以随时调配任一工程师可独立完成整个功能。我的建议是变成多个专业人才 Pool，就这个例子而言，是划分成 UI、AP Service、DB Pro 三个 Pool，若哪个子团队缺哪层的工程师，就由专业 Pool 调配。

    最后，他虽然没有接受我的建议，但有沟通总是好的。开发模式与文化的转变比导入新产品和技术还难。