【管理心得之六】判定工作是否完成，标准是什么？

 场景再现

======================
结合测试：经理，这结合测试没办法测了。
          结合测试应在客户观点上来对应测试，疏通业务流，排查业务处理逻辑正确性。

          你看看这Bug现象，太低级了，原本就应该在UT阶段消化掉的，UT阶段是不是没测试完呀？
UT测试  ：我组也是严格按照流程、进度安排执行的。按照スケジュール（进度表）UT阶段已经结束了。

结合测试：结束了，还会有这低级Bug？
UT测试  ：那也不能说我们UT阶段没完呀？ 太武断了吧？
{火药味越来越浓。。。。}
项目经理：呜~~~~~~~~~~~~
====================== 

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

“一项工作在截止日前完成，这项工作就完成了吗？”  ←　（我是不是又说傻话了？）

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

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

  但是在实际项目管理中，很多工作完成标准是很难用“白糖、红糖”等清晰词句可以辨别区分的。
  最多是PM手中スケジュール（进度表）和担当者说的话,聪明点的管理者可能会查看一下过程文件。
 
  我是IT领域一菜鸟，标志一个项目结束，似乎要得到客户或发起人的验收。得到客户或发起人的验收通常不是一件容易事，是用户或发起人经历 试运行、正式运行后，确认无误、能正常使用后才会在验收单上签字的，此刻才能算得上项目结束。

  可惜的是，我们只有在项目收尾时才把项目是否完成交由用户或发起者来判定，而项目中各个阶段是否完成却由自身说得算。奇怪？

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

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

  ★

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