服务、合作和可信产品

标记：发表于 @ 2010年03月30日　09:09:00

 

曾经思考很久的问题。现在准备离职了，终于有时间来完成它。

 

IT企业一般很难有自己的产品，而更多的是提供服务。通过提供服务或者说服务型产品来收取报酬。

比如说一个大型的解决方案，就是是一个服务的集合。这个集合里面可以拆分成很多小的服务过程（刚在看<<需求的实践>>更证明了这一点）。

 

需求的实践中说：每次迭代周期都会得到一个可发布，可供客户使用的产品。事实上就是这样。

 

需求工程主要是开发和挖掘客户需求，并制定需求管理机制。这一个过程就会产生一个产品，就是需求。这里的需求满足明确、完整、一致、可测试性等特点。

 

对设计人员来说，这份需求就是需求工程人员提供的产品，并且是可信产品（前提是需求挖掘人员业务素质过关并具备需求挖掘的基本素质，RP也应该没问题才行），按照这一份产品来进行设计理论上是能够满足客户的需求。（当然这里排除了需求变更产生的例外，毕竟已经提供了需求管理方案）

 

开发人员根据设计人员提供的设计方案来实现，这份方案就是设计或系统架构师提供的可信产品（前提是架构师严格按照需求来进行设计，并没有曲解和加入个人因素，同时架构师也是合格的才行）

 

测试人员需要了解需求，并测试需求，需要了解架构，并测试架构，同时需要对最终的产品进行测试。悲剧的是开发人员无法提供百分百可信的产品。。。否则就不需要测试了。这里就出现问题了。

测试人员对开发人员提供的产品进行测试，但开发人员无法保证产品的百分百可信，而这就是测试的责任。测试人员通过提供测试服务，并将结果（这也是一种产品）反馈给开发相关人员。

提到反馈，就出现了合作，无疑，密切的合作可以提高产品的质量。

 

这里要提的是：服务，合作与可信产品之间，服务本来是合作的一部分，通过提供优质的服务，来达到共同完成优质的产品。优质的服务的要求就是可信产品。

 

这需要排除以下问题：

1、自上而下的优质服务：上面讲解的过程基本算是自上而下 。

2、亲密协作的优质服务：虽然开发人员无法提供百分百可信产品，但保证实现了仅该实现的部分，并不影响其他部分，修改了仅需要修改的部分并不改动其他部分，同时保证产品主要功能可以正常使用，无疑是对测试人员提供优质服务（可信产品）的一种方式。

3、多部门协作：各部门提供优质服务（可信产品），测试时建议在尽可能少改变当前环境的情况下进行测试（当然彻底的改变也需要测试）

4、决绝浮躁！