如果反馈能做到实时，下面就是实践。在新的产品研发开始的时候，我与技术人员产品经理会一起先把概念模型画下来，因为一个团队有很多的角色，包括架构师、开发、US、甚至外包人员，不同的角色怎么确保理解的一致，最后明白如何做自己的工作。你怎么确保这份活动基于统一的理解，没有共识就比较容易出现鸿沟。把概念模型画下来就是为了现实上的例子，可以很简单，我们有什么业务对象，他们之间关系是什么样，把这些东西画下来，大家基于一份共识去做各自的活，这个鸿沟会少一点。
3. 基于产出的质量，定义完成，以终为始
我自己是研发出身,研发质量产出是什么？就是需要建立条目化，短周期之内可以交付的东西，这个是产出，第一个产出是代码，尤其在软件行业，代码占了80%的产出，怎么把代码写对，就是第三个维度。
代码质量有一个心法叫做定义完成；
举个例子，很多程序员你问他这个Story做了没有，他给你的答案是什么？度量BUG是为零，程序员做完之后交给QA，QA告诉开发有没有BUG。你的QA下一道工序是我的客户，我应该告诉你有没有BUG或者有多少个BUG，而不是反过来。
需求质量也是很重要的产出；
你要保证你的产品经理做的需求是不是符合，是不是条目化，是不是按照优先级，你是不是做最重要的事情。你有三个团队，每个团队都在按照优先级来做事，但是三个团队是不是有统一的优先级，很多团队是没有做到的。
有些需求你不做用户会不高兴，但是你做了也不会很高兴，就像我们的实践一样，项目大的时候不做实践会很惨，但是做了项目也不一定会成功。
工作中当你问程序员说这个做完没有，很多程序员告诉你90%完成，或者完成了但是没有测，或者有几个BUG，或者需要重构一下，这种心态是不好的，但是没有反馈。
我们叫做以终为始，用户故事只有两种状态，只有完成和没有完成，没有但是，没有完成你要把它完成掉。程序员会说这个做了90%，然后去做下一个故事，结果是没有一个可以工作。而我们倡导的是把一件事情全部做完，才做下一个。
4. 过程质量，拆
有这样一句话，如果你用同样的方式去烤面包只会得到相同的面包。
过程质量就是写代码的质量，这个心法就是拆，拆成小的东西，拆成一个可交付的东西，其实写代码也是需要拆的。
举一个例子，很多程序员写代码，一天下班的时候代码还没有编译，我们写代码方式应该是这样,很多程序员写代码是东写一点，西写一点，这个意味着什么？没有透明度，他不知道写哪一个，这样的过程想代码质量好是不可能的。
总结
我们已经讲了四个维度的质量，价值和成本，可很多团队的人没有办法控制价值的部分，有些人却可以。我们是一个技术负责人，产品都不是我们能控制的。你要考虑定制权在哪里？影响权在哪里？你能控制的东西就是你的成本，你不能控制的地方就是你不能提供的。
谁为质量负责?如果开发工程和QA之间出现问题，最后辛苦开发出来的功能，用户抱怨难用，就是价值和质量出现了问题，现在分工越来越细，在很多团队集中在某一层，比如程序员关心写代码，不关心价值和产品，产品经理只关心价值，不关心技术实现，这些鸿沟会影响整个质量。