规范定义不明确与二次变更所引起的思考

 

 局方关于IAGW的规范，实在是定义得不清晰，几份不同的规范之间，也存在诸多相互矛盾的地方，在项目启动测试之前，在编写测试案例的过程中，我们发现了很多关乎核心业务流程的问题，有很多关键点，都提了出来，部分问题跟开发商量之后解决了，部分模糊的问题按我们的理解去实现，而不能解决的问题或疑惑则通过PSO向移动咨询。 不过，我们的问题，迟迟未得到回复，更新后的规范出来的时候，项目已经开发完毕，测试也将近尾声了。

新规范所定义的业务流程与原规范存在不少的差别，明确回复了我们的疑问，可是，我们的实现却与规范存在比较大的差异，编写案例时提出的问题大部分都需要重新修改与测试，无疑增加了大家的工作量和项目的成本。这几天，开发跟我抱怨，又要多花很多时间去修改代码了，测试何尝不是又需要多花很多时间去测试，不管是测试还是开发我们的计划都被打乱了。这真的不是我所愿意看到的，正是因为担心会出现这样的情况，在项目启动之前，我花了很长的时间去研究规范，也发现了问题并将问题提了出来，作为测试，能做的都做了。可是，却不能避免被动的局面。

这些天，我一直在思考，是什么原因造成了现在的局面？如此被动如此庞大的改动是否本来可以避免的？在规范不明确的情况下的项目应该怎样开展？规范出来之后，在我们人员空闲的情况下，项目肯定是要启动的，不管规范明确与否。规范不明确的情况下，问题我们已经发现了，对问题的解决一方面可以由经验丰富的项目经理识别并确定解决方案，另一方面向制定规范的局方咨询确认问题的本质。我们的确对问题进行了讨论，只是，我们的识别错误了，解决错误了；错便错了，只能怪我们不够敏感，只能怪我们太自信自己的判断，在以后，的确是应该更加谨慎、更加深入去研究问题的本质与解决方案。咨询，我们也的确是咨询了，而且在前期也催了三次，只是，回复的时候项目已经接近尾声，这样的回复也没意义了；如果，我更加积极催PSO帮我们联系局方尽快回复，或者PSO主动催局方尽快回复，或者我们直接联系局方相关规范的负责人，或者由项目经理直接去沟通，那结果是否就会因此而不一样呢？还是说，不管是怎样，局方修订规范就是需要那么长的时间，不管我们采取何种措施，结果都是一样？如果真是这样，我们的项目是否应该启动？

不管怎样，问题已经发生了，也许本应该可以避免，也许本来就避免不了，不管是否可避免我不想将责任深究到个人的身上或去抱怨，但是，应该引起团队或管理层的注意，再碰到类似的问题的时候我们应该如何去面对如何去处理，毕竟，规范或需求不明确的项目，在中国的IT界比比皆是。

 

PS：后来跟局方相关规范负责人交流的过程中，他问我：“为什么就你们这么多问题，别的厂家都没问题？”当时，我的第一反应就是，规范本身就有问题叫我们怎么不会有问题？不过，我没有这样反问局方负责人，而是依然平静地跟他阐述问题的所在，当然，不存在问题我肯定不会打搅你，既然是有问题我肯定也是理直气壮。这位负责人，后来也意识到规范所存在的问题，不知道是因为我在电话里自始至终平和的语气和笑声感染了他还是别的原因，最后，我也听到了他的笑声，非常的好听，还有他对我们对规范所提出来的建议的感谢，让我给他的印象打了一个不低的分。因为，自己错了之后敢于承认错误的男人才是真正的男人，懂得笑和感谢的男人才是真正的可爱。下次，如果有机会见到他，一定要告诉他笑得很好听，以后多点笑着跟别人交流；也要告诉他，正是因为他的笑和感谢，让我走出了与局方人员打交道的阴影。

PS的PS：没有问题的厂家肯定有问题，不知道他们怎么去实现、测试的时候能否通过？或者，我们本身在这方面太有经验，反而是被我们的经验误导了？

PS的PS的PS：突然想起曾经在一本书上看到的一句话，拿起电话的时候请微笑，虽然别人看不到你的笑容，但可以感觉到你的笑声。