场景再现
======================
结合测试:经理,这结合测试没办法测了。
          
结合测试应在客户观点上来对应测试,疏通业务流,排查业务处理逻辑正确性。
          你看看这Bug现象,太低级了,原本就应该在UT阶段消化掉的,UT阶段是不是没测试完呀?
UT测试  :我组也是严格按照流程、进度安排执行的。
按照スケジュール(进度表)UT阶段已经结束了。
结合测试:结束了,还会有这低级Bug?
UT测试  :那也不能说我们UT阶段没完呀? 太武断了吧?
{火药味越来越浓。。。。}
项目经理:呜~~~~~~~~~~~~
====================== 

现社会,往往是几个人、几个阶段、几个工作流共同运作才能完成一项工作任务。其中最重要的,同时也被人喊得最响的“TeamWork”也逐渐被人重视起来。正因工作有阶段的划分,必然会有“临界面”接触,这样一来,场景中纷争看似找到了“根源”。

“一项工作在截止日前完成,这项工作就完成了吗?”  ← (我是不是又说傻话了?)

小时候一个夏天的下午,妈妈把我叫到窗前。
“小峰,给你2元钱,买包糖回来。”
“嗯” 
10分钟之后,我拿着一包红糖跑回了家,交到妈妈的手上,然后兴高采烈地跑出去同小朋友玩耍去了。
妈妈看着手中的
红糖,哭笑不得,后来我才得知,妈妈要的是白糖

◆对我来说,我买糖的任务完成了,用妈妈给的2元钱,换回红糖,交到妈妈的手中。
◆对妈妈来说,我要是白糖 红糖对我毫无用处,这“死崽子”什么事都办不成。
→为什么会这样?如果再问我一次,那次买糖任务完成了吗?
  我会答“没有”。
  原因很简单“我买回的红糖交给妈妈,妈妈没有办法用红糖继续后续的事。
  当然了,如果妈妈当时说清楚“要白糖”,也不会出现后面的尴尬。

  但是在实际项目管理中,很多工作完成标准是很难用“白糖、红糖”等清晰词句可以辨别区分的。
  最多是PM手中
スケジュール(进度表)和担当者说的话,聪明点的管理者可能会查看一下过程文件。
 

  我是IT领域一菜鸟,标志一个项目结束,似乎要得到客户或发起人的验收。
得到客户或发起人的验收通常不是一件容易事,是用户或发起人经历 试运行、正式运行后,确认无误、能正常使用后才会在验收单上签字的,此刻才能算得上项目结束。
  可惜的是,我们只有在项目收尾时才把项目是否完成交由用户或发起者来判定,而项目中各个阶段是否完成却由自身说得算。奇怪?

  
阶段的产物否作为后阶段的“输入”被正常、有效使用 ,这才是标识本阶段是否完成的唯一标准。 (个人观点)
  单凭
スケジュール(进度表)、过程文件、成果物等实物,我真的很难在此阶段画上“句号”。因为我不确定本阶段的产物,能否作为后阶段的“输入”被正常、有效使用。

  聊到此,似乎我已经找到了
场景中纷争是非-------------UT测试没有做完。
  如果在每一个阶段开始前,对“输入”进行验收,保证其“输入”可用、有效,我想也不会出现场景中的失控。
  
  理解这一点并不难,读书至今的我们经历了数百场考试,对于涂卡答卷考试形式并不陌生。
  我经历的每一场考试,
监考官在收回答题卡时,都要确认下考号、姓名、班级、科目等核对信息
  目的只有一个“确保这些答题卡可以顺利通过评分环节,保证每一位学子都有自己真实的成绩。” 
  
当然了,无效的答题卡可以零分论处,但那是你想要的结果吗?

  
    我不确定,有没有清楚地阐述我个人的观点。
    如果你有话,请您留下来。