此外，即使彼此沟通的版本正确，也不代表修改正确。因为修改第 100 行的程序代码之后，可能影响第 50 行的程序代码运作；或是修正后的独立组件 A 却导致组件 B 的运作错误。而且，当系统越庞大、分工越细、开发小组数目越多时，这种版本乱象愈发恶化。

事实上，「版本混乱」可说是所有开发者最头痛的问题，所以它是建构完美开发环境所必须解决的一大问题。解决这个问题只有两种方法：一是非常地细心，二是利用自动化版本管理工具。你可以要求每位开发成员都「非常非常细心」，也可以藉助工具；何者比较可行，高下立见。

多点分工管理

由于系统运作环境日趋多元、项目计划也趋复杂，软件分工的情况十分常见，因此目前软件项目大多由不同小组合作完成，所以完善的分工管理也是建构完美开发环境的要件之一。

除了同一地点的小组分工外，目前还有一个趋势是「多点分布式分工」，就是切割一个项目成好几部分，分别交给不同小组，在不同地点同时进行开发，最后予以整合。这种分工法的优点是可以培养不同专长的开发小组，避免 double efforts ，失去分工意义，同时也可以节省总开发成本。

「多点分工」的情形已经越来越普遍，如果再加上前述版本混乱的问题，可能会让管理者一个头两个大。唯一的解决方法就是建立一套考虑到所有细节的「标准作业规范」，然后严格要求所有成员都切实遵循，没有通融空间。或是利用工具将「标准作业规范」定型为所有开发成员的「工作环境」，而且是处于自动执行的模式，如此一来，大家就会在潜移默化下自然而然的遵循了。

瑕疵追踪管理

软件开发过程中一定会出现各种小错误、 bug 及许多无解的问题等，这些东西通称为瑕疵。我们无法要求瑕疵永远不发生，而是应该做到追踪管理瑕疵，使它不至于影响开发过程与结果。

追踪瑕疵要从发现源头开始。一般而言，瑕疵的「回报」可能来自各个地方，包括经程序人员发现、测试发现、客户发现、最终使用者发现等。瑕疵从发现到最后修改完毕，可能透过许多工具或各种程序。

例如，客户打电话抱怨一个程序问题，客服人员在「口头」上了解与接收问题后，将状况写成一张「便条纸」交给客服经理，客服经理再用「文书软件」把它整理成「文件」， Email 给项目经理，项目经理用「电子表格软件」填好一份电子表格再交给分析人员 ….. 。以此类推，结果最终是完全变质。

这就是用不同平台（纸张与计算机）与不同工具（文书、邮件与电子表格）处理同一件事的情形。它会造成两个现象：一是很容易在转换过程中出错，因而制造出新的问题；二是这个过程根本无法有系统地加以追踪与管理。这些都不合乎标准作业。

正确的方法应该是让「瑕疵追踪管理」成为贯穿开发流程的环节之一，而且它应该与开发工作处于相同平台，并且可以自动比对与验证产品。例如，当客服人员接收一个问题后，就应该进入上述系统，跟着开发流程一起走，才能进行追踪与管理。

安全管理

在软件开发过程中，每个阶段都会制造各种类型的产出物（包括文件、程序代码、执行档、报告等），这些产出物有不同层级的保密或安全顾虑，所以需要严密的管理。

安全管理分成内部层级管理与外部层级管理两种。内部管理主要针对不同成员与不同数据的存取权限进行规范与管理，此处应该留意二件事：一是设定正确的修改与只读属性，防止数据破坏；二是妥善管理不同项目之间的数据存取，避免机密漏洞。

外部管理则分成二种，第一种是与协力厂商、供货商或委外开发者的存取管理，这些厂商需要读取你的档案，也会制造各种产出物，所以当然要管理存取权限。第二种则是与客户之间的存取管理，其中数据保密尤其重要；客户对关于他的资料都会要求保密，特别是牵涉到智慧财产权时，对保密的要求更高。所以项目管理人员在开发过程中必须设计一套能令客户信任放心的作法。

建立自动化的开发环境

后端管理与前端「生产」工作不同，后端管理存在目的主要是要解决问题，尤其面对五花八门的「人为问题」。所以最好的方法，应该是让后端管理达到最大可能的「自动化」，使他们随着前端工作的进展「自动执行」，为前端工作提供一个完美的开发环境。