几张漫画告诉你PLM项目是如何走向失败的？

售前顾问或销售是这样描述产品的：

售前顾问或销售和项目交付团队站的立场和角度是完全不一样的，这本身就是两个比较独立的团队，售前的使命是卖出方案，于是对方案本身进行了大量的包装，通过他们精彩的描述，这个方案变得无所不能，简直是全方位多功能一体化解决方案，高端大气还有档次。

问题分析

我们的售前大部分时候是灌输的多而倾听的少，我们希望能给我们的用户提供一揽子计划，可是却忽略了，客户的认知是有限的，他们的认知提高是要有一个过程，一揽子计划还不如一个实实在在的解决当前的问题来的更有效。

售前团队应该同样站在交付团队的角度立场，合理理性去介绍产品，同时结合用户的实际情况、当前需求、制定合理的具有总体高度的建议方案。而非简单粗暴的什么都可以。

客户是这样描述PLM需求的：

客户往往对自己的需求不十分清楚，从他们的需求描述中可以获得一些关键的特征信息，仅仅可以勾勒出一个大致的轮廓，不过这个轮廓具体是什么谁也不知道。

在PLM的需求调研中，我们的客户具有以下的特点：

认为你什么都能做，他们什么也都想做！

希望一切都很智能化，凡是需要判断的都需要交给电脑，凡是要输入的希望都可以百分百防错，同时恨不得对着电脑喊一声东西就出来！

问题分析

不能把客户对需求的描述不清楚原因归结在客户身上，我们要在需求调研上投入更多的智慧，客户的认知是有限的，此时我们需要对其进行扫盲运动，把他们培养成初步的信息对等体。

在调研过程中倾听的同时要加以引导，从专业的角度，抓住关键的需求反复的沟通，以便达成清晰的理解。

业务顾问是这样设计方案的：

我们的项目经理或业务顾问，接受到客户的需求后开始变得异常的头痛，当然大部分人都不承认需求无法实现，当然也不会傻到照着客户的原始需求直接开工，于是他们开始对之前获得的需求进行自以为是的精简、把模糊的轮廓变成更清晰的目标。

问题分析

往往我们的顾问忽略了哪些是重要的需求，哪些是次要的需求，任意的裁剪并不等于精简，结果只能使得目标得以偏离；

相信我，我们辛苦熬夜编写的厚厚的专业方案书，客户往往是不会去看的。我们需要把一个复杂的问题，变成通俗的老太太都能明白的道理的能力，所以这里需要我们的顾问有很强的presentation的能力，能够让客户知道我们要做什么，从而及早的反省调整。

系统工程师是这样设计PLM系统的：

在获得方案书后，系统工程师需要对方案进行系统的转换和架构，然而，为了实现方案书中的各种固化需求，此时我们的实施顾问不为余力的编写开发规格说明书，甚至动用了大量的模块来实现功能。此时原本还算清晰的需求变得开始有点冗余，可能只是一个小感冒，却动了大手术。

问题分析

方案需求的实现应该尽可能的简化系统，能够一个模块解决的问题绝不要多个模块，能够系统配置的功能绝对不要开发，能够一个服务器搞得定的负载绝不要N多个服务器。让操作简单，界面清晰，性能稳定是实施顾问的基本职责。

程序员是这样编写代码的：

对于PLM来说，有些需求是必须要开发的，一般来说这个需求是复杂的独特的功能，大部分的程序员拿到的开发说明书中仅仅只有功能说明没有业务说明，同时大部分程序员也不关心背后的业务需求是什么，在他们眼中只有完美的代码，于是一个复杂的系统架构在他们手中开始变得简单和明了，他们花费了大量的时间在代码的动作执行上，而且不断的修补代码，有时候功能貌似很强大，却异常的不柔性。

问题分析

代码实现的功能前提是满足独特的功能，可用性、友好性、美观性、可扩展性都是开发规格上无法描述的潜在需求，好的开发工程师应该更多的理解开发功能后的真实需求，是谁在用，什么时候用，怎么用，而不是仅仅盯在最后一个点上而忽略过程的优化。

这才是客户真正的需求

原来我们从头到尾做了一堆的无用功。

总结

一个完美成功的项目，是一场艰苦的拉锯战，只有战略制定的合理、战术应用的得当、战役认真打的响亮，最后才能获得完美的胜利。

需求的了解、理解、落地是一个层层过滤淬炼的过程，任何一个环节都必须认真小心有技巧有策略的智慧加理性的对待。培养用户的信息对等是项目成功沟通的保证，沟通不顺畅就会埋下项目失败的炸弹，矛盾的冲突就是引线。