如何管理ERP项目?
【 信息化】在大型 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 调配。 最后,他虽然没有接受我的建议,但有沟通总是好的。开发模式与文化的转变比导入新产品和技术还难。