软件开发不能各司其职,分兵作战。
一个庞大的,多服务,多系统的项目,可能保护多个团队所开发维护的系统,每个系统都基于面向的用户群是一致的。在系统整合过程中,涉及到多系统的数据交互,可能会产生各种杂乱的接口,服务程序依赖。一旦一个项目选择这样得处理方式,项目就会走向不确定性,项目风险就会增加。其中,任何一个服务的异常就可能造成系统的瘫痪。
打个比方,比如汽车制造商生产汽车,在生产汽车过程中由不同的团队负责不同的汽车部件的制造,有的团队可能负责发动机,有的可能负责汽车框架,有的负责车载系统,如果没有前期统一规范与设计,团结只是在负责具体功能的设计,然后进行局部测试,这可能给后期汽车组装带来极大隐患。有可能相互的尺寸规格,布线不一致导致返工。有可能强制组装,因为汽车部件的不确定带来汽车的不确定性增加。如发动机隐患概率0.1,车载系统隐患概率0.1,整个车的隐患概率就变成0.19,随着组装部件的增多,隐患概率会不断提高。当然,如果现实中存在这样得汽车制造商,早就被淘汰了。但是在软件开发商这里,这种现象应该是普遍存在,项目经理不能站在全局的角度去观察整个项目,更加偏重与局部系统的设计与实现,不同团队不能进行卓有成效的沟通或者沟通不能很好的消除存在的隐患。
要想开发出健将,稳定的系统或者系统群,应该以工程管理的方式去进行设计与资源分配,当然这也是比较困难的。
一个庞大的,多服务,多系统的项目,可能保护多个团队所开发维护的系统,每个系统都基于面向的用户群是一致的。在系统整合过程中,涉及到多系统的数据交互,可能会产生各种杂乱的接口,服务程序依赖。一旦一个项目选择这样得处理方式,项目就会走向不确定性,项目风险就会增加。其中,任何一个服务的异常就可能造成系统的瘫痪。
打个比方,比如汽车制造商生产汽车,在生产汽车过程中由不同的团队负责不同的汽车部件的制造,有的团队可能负责发动机,有的可能负责汽车框架,有的负责车载系统,如果没有前期统一规范与设计,团结只是在负责具体功能的设计,然后进行局部测试,这可能给后期汽车组装带来极大隐患。有可能相互的尺寸规格,布线不一致导致返工。有可能强制组装,因为汽车部件的不确定带来汽车的不确定性增加。如发动机隐患概率0.1,车载系统隐患概率0.1,整个车的隐患概率就变成0.19,随着组装部件的增多,隐患概率会不断提高。当然,如果现实中存在这样得汽车制造商,早就被淘汰了。但是在软件开发商这里,这种现象应该是普遍存在,项目经理不能站在全局的角度去观察整个项目,更加偏重与局部系统的设计与实现,不同团队不能进行卓有成效的沟通或者沟通不能很好的消除存在的隐患。
要想开发出健将,稳定的系统或者系统群,应该以工程管理的方式去进行设计与资源分配,当然这也是比较困难的。