《万年老大难，沟通与协调》中，我讲过一个案例——甲方要求更换新logo，却被整个项目组硬生生地忽略了。验收的时候，客户副总大发雷霆，导致接口人吹毛求疵，不仅验收没通过，还增加了一堆有的没的修改意见。

大多数管理者对这类事件的解读，是管理缺失。比如，没有识别清楚工作依赖关系，没有做好沟通协调的计划，没有执行也没有监控。可问题是，这个案例涉及了销售人员、项目经理和工程师，一组人华丽丽的都忘了，难道就是管理缺失这么简单吗？又是什么，导致了这个管理缺失呢？

答案毫无疑问，是意识。

因为所有人在意识上，都不认为改logo这等“小事”需要纳入到管理的体系中。所以，在管理行为上出现了集体缺失，最终导致了尴尬的结果。你可能会说，那好办，让大家加强管理意识嘛。可这句话怎么落地？

一方面，我们不能不管理；另一方面，又不能事无巨细地管。因此，能让客户满意的这个程度，就是管理效率与灵活性的平衡点。

那么问题来了：

Q：怎么才能让客户满意？

A：满足客户的需求。

Q：客户的需求都有哪些？

A：除了软件本身，还包含服务。

服务是指为他人做事，并使他人从中受益的一种有偿或无偿的活动。不以实物形式而以提供劳动的形式满足他人某种特殊需要。

百度百科《汉语词语》

这个定义很宽泛，我并不想把“软件即服务”的这个观点拿出来做文章。我想讨论的服务，特指服务活动的产出，它是一个特别的产品种类——一种无形的、不可存储的产品。

举个🌰说明一下。

软件交付后的培训，是为了让客户具备使用软件的知识和技能。如果培训已经执行，但是客户仍然不会使用，就是培训服务的产出——使用软件的知识和技能没有被交付。在这个例子中，客户想要的产品有两个。一个是软件本身，它被交付了。另一个，是使用软件的知识和技能，这个产品没有被交付。这就是服务的产品属性。

之所以要谈服务的产品属性，是希望服务意识不要被仅仅当作是一种意识形态。

因为绝大多数技术人员的思维是理性的，会习惯性地痴迷于软件开发的“专业度”所带来的满足感。而服务意识如果没有产品属性，就会被感性地对待，变成一个空壳，而没有实质作用。

在服务意识以及服务的产品属性之下，我们再来看软件项目。

售前阶段，我们通过提供技术沟通、商务沟通这两项服务，最终通过方案、报价，向客户证明，我们的匹配度更高（服务的产品属性），从而赢得项目。

需求阶段，我们跟客户有大量的实物产品交互，比如各种需求说明书、确认函……无论这些是否是合同约定的验收物，都只是过程产物，而非客户最终需要的软件产品。这些过程产物并不会对客户构成实质性的约束。因为客户在这一阶段，要的是乙方通过提供需求开发、需求管理的服务，产出全面、真实的需求及其迭代。

也就是说，如果客户不知道、不清楚需求，有问题的不是客户。反倒是乙方，在这个时候，应该思考如何改善需求开发和需求管理的服务，才能让客户在这一阶段需求的服务产品（即全面而真实的需求及其迭代）得到满足。

这个观点，并不是要跪舔金主爸爸。还是那句话，当各种各样的办法都走投无路的时候，就该换个思路了。带着服务意识做需求，把对客户的专业性鄙视转化为专业性引导。既能满足技术人员的专业满足感，又能满足客户的服务需求。而获取到全面而真实的需求，也将为软件的生产和交付创造有利条件。

生产阶段，包含的设计、编码和测试。这个阶段我们跟客户的交互，主要是实打实的软件产品，这些都是客户的直接需求。

验收阶段、上线和售后阶段，跟需求阶段类似。这两个阶段，软件产品已经生产完成，客户需要的是验证其在测试环境和真实环境中的运行情况，并解决相应的问题。因此，这两个阶段服务的产品属性都十分明显。

在IT项目的完整阶段中，只有售前和生产两个阶段是关注产品的；剩下的三个阶段，都聚焦在服务上。没有服务意识，我们便只会把关注点放在生产阶段的软件产品上，而忽略了与之相邻的两个服务属性的阶段。这样交出的软件产品，必然无法满足客户的需求，也算不上是高质量的软件产品。

让客户得到一个软件产品，是交差，而得到一个高质量的软件产品，才称得上交付。我们一贯主张项目管理的质量导向。质量不仅包含产品的质量，还包含项目中我们提供的服务的质量。交差与交付，差的就是服务的质量。