生产链上的顾客.docx

生产链上的顾客质量保证部：杨绍鹏软件生产过程，大多数人都耳熟能详，先了解客户需求（我们通常称为业务需求），再把客户需求翻译成产品需求（我们通常称为功能需求），根据产品需求做产品设计，再通过编码把产品实现出来。那我们最后造成来的东西有没有满足用户的需求？大家一致的意见，就是控制好几个大的阶段交付产品，那这个产品的质量基本可以保证。除了评审、测试、用户体验以为，业界也并没有更多较好的办法来控制交付件的质量。从2009年开始，能讯公司开始尝试评审，那时候并没有评审制度作为支撑，评审主要由公司技术总监或副总监，再加部门经理组成。当时的出发点，也是要对各阶段交付成果进行质量控制，同时为各阶段目标达成情况提供判断依据。刚启用的时候，基本能一次评审通过的交付件是极少的，我们暴露了太多的问题。以此同时，还建立起系统测试通过不通过的准则。还尚有项目组以评审不通过或测试不通过为由作为计划延期的解释。此时的评审或测试尚集中在较小的范围内，都只是集中在少部分人手中。2010年，质量保证牵头建立公司技术评审专家库，并发布了评审制度，第一次引入了除公司领导之外的技术专家对交付工件进行评审。这个时候，技术专家的参与，对技术文档提出很多有效意见。评审的意见范围又进一步扩大了。但这些技术专家并不是客户方请来的人，他们并不代表客户，他们不需要为客户负责，也不需要对系统上线后是否让客户满意负责。我们来看一下我们的生产链，需求开发人员接触客户，摸清楚客户需求，并翻译成产品需求；设计人员根据产品需求，进行产品设计；开发人员根据产品设计，进行编码；实施人员再教会客户使用最终产品。那这个依存链就形成了：客户需求开发人员设计人员编码人员实施人员客户。这个依存链中，只要有一个人员的工作做不到位，那他的缺陷或错误就会一直往下传递，直到用户结束。一个错误的结果，会以一种正确的方式传递到最后。当然这其中的问题很多：如客户对自己需求很模糊，需求人员需求描述不清晰，设计人员草草设计，编码人员代码质量较低那我们怎么来控制呢？朱兰曾提出：“顾客不总是指组织外部而言，它也包括你工作中下一个工序的人员或小组，在产品制造或服务提供的一步一步过程中，生产链的强度是由最弱的环节来决定的。质量意味着在生产链的每一环节工作者，都知道下一环节需要什么，要确保他们能得到所要的。”在我们能讯内部，除客户服务部曾经把其他部门称为自己的顾客外，我听到的顾客基本都是最终客户，无论是生产链上的需求人员、设计人员、开发人员、实施人员。大家都说要为客户负责，但并都没有说要对使用自己工作成果的人负责。所以需求开发人员，也许从来没有考虑过是否会给设计人员带来麻烦，设计人员也没有考虑过是否会给编码人员带来麻烦。更别说理解下一环节需要什么。朱兰指出：“在产品制造或服务提供的一步一步过程中，生产链的强度是由最弱的环节来决定的。”我们的设计人员、编码人员的能力很强，需求人员的能力很弱，那这条链的强度也是弱的，我们生产的产品质量仍然很差。而同时需求人员自需求阶段结束后，通常不会接触到客户，设计人员和编码人员更是不可能接触到，那他们所说为客户负责体现在什么地方呢？其实他们的工作成果，并非直接给用户使用，而是交付下一环节。所以他们并不知道谁是自己的直接顾客，只是理所当然的认为下一环节是别人的事情。我们理解了这条链上每个环节的重要性之后，我们要问：这个环节上的每个一个人，要把自己的工作做好，可以要求自己的输入是充分、清晰、合理的吗？同时，他应该清楚谁是自己工作成果的使用者？他们有些什么要求？当然，部门之间的推诿也属于此类问题，搞不清谁是自己的直接顾客。我们再回到评审，目前各环节的评审，尚在技术评审专家，而下一环节的人员都尚未参与进去。下一环节的人员对自己的输入基本束手无策，寄期望于上一环节人员的仁慈和评审专家的严格。测试也是一样，期待测试人员来做最后质量控制也是妄谈，因为测试人员实际上作为检验人员，其作用跟评审专家是一样的，并不是工作成果的使用者。而下一阶段的成果使用者实施人员（大范围实施的时候需要，对单一单位的实施，可能并不需要）或客户应是这阶段的直接顾客，应该参与对该环节的确认。那2011年我们是否可以这样做？评审团队，由上一环节的人员、技术评审专家、下一环节的人员共同组成，上一环节的人员确保自己的交付件被正确的理解，技术评审专家对工件的正确性、规范性负责，下一环节的人员确保工件的清晰表述和可理解性。测试也是一样，针对目前开发和实施分离，可以让设计人员、测试人员和实施人员或用户共同对系统测试，设计人员确保开发是符合设计要求的，测试人员确保功能或性能是完整的、可用的，实施人员或用户确保系统是适合用户使用的，包括易用性。虽然我们很难一步登天，但我们是否有登天的意识呢？希望我