如何看待用户需求？

秋叶

wammym  
规划和实施管理软软件一定要研究好用户的需求。
那用户的需求来自哪里呢？一方面是旧的工作习惯的计算机化，一方面由于管理上、战略上等方面带来变革所体现的需求。
对于旧的工作习惯的计算机化，首先要承认，企业旧的工作习惯显然是经过长期的积累的实际做法，并且通过修修补补对原有的工作过程进行了很多类似“赘生物”的自组织现象的东西，但最起码这个东西可以正常使用。因此，存在的就是合理的，用在这里还算合适，就是存在的肯定有他的道理，完全无用的，企业也不会让他存在。呵呵。第二，如果要实施，不仅仅是将旧习惯简单计算机化，有两个可能。这涉及到“管理＋IT”的模式的解释。首先，如果一个企业首先进行了管理的变革，已经进行了bpr之类的重组，那将这个过程计算机化就是软件的事情了。就是说，这方面，就需要企业现有的手工工作方式具有良好的模式。其次，如果企业的管理不好而不做改革，那么，那实施管理软件，应该是走不通的。其实上面的解释说明了两种思路，一是自上而下的“管理->IT”，另外一个就是自下而上的“IT－>管理”。我们现在大量的存在的情况是第二种情况吧，那要想第二种成功，怎么办？那就要增加IT的内涵，就是将管理上的变革融合进软件中，或者在实施之前，将管理变革（包括流程疏导）放在IT实施之前。虽然这样增加IT的难度，但如果不这样，恐难成功。其实就是不能为IT为IT，功夫在IT外面。因此所谓的IT－>管理的思路不是字面的那个过程，是对IT的内涵的一个扩展。呵呵。
用户需求有错么？如何看待事实上是软件厂家的一种'写照“，呵呵。显然没错，病人就是不舒服。这是事实，要尊重的。回避用户的"不舒服”，这种'挑选“不好，呵呵。
一个人去看医生，就说自己不舒服，医生经过诊断，可以有两个结果：有办法解决，和没有办法解决。
如果有办法解决，还有三个分之：病人不接受，不让解决（显然自己的方案拟提的这个方案了啊）；病人接受，但这个医生却自己不能够解决，需要去大医院解决（如果医生非得自己解决，也是一种欺骗），那也是；第三，病人愿意，医生自己可以解决了（皆大欢喜贝，呵呵）。
如果没有办法解决：还有两个分之：病人接受，那就over；但这个医生却骗人家说自己可以解决；病人接受，问题也无法解决，也OVER。
所谓的”有所不为，才能有所为“是其中的哪些情况呢？而不是盲目的接单？
或者是为什么自己要主动放弃做某个用户？做了哪些分析才放弃的？

秋叶

春雨  
昨天看到一个古老的笑话：庸医将病人治死了，病人家属找他理论，他说：“我的治疗方案都是按书上写的做的，我没有错。那是他没有按书得病。”

wammym  
大家能不能说说，什么样的单子不会接？为什么不接？（是自己主动放弃而不是被动的啊）

Pumbaa  
经常有这样的情况:
有一位病人去看医生(庸医)。病人对医生说，"我得了XX病，请给我开XXX药"。医生未经思索，"这些药都有，我开个方子你去拿药吧"。
结果病人死了，庸医说"都怪他自己啊，没搞清自己的病就要求乱开药"。

wammym  
面对这样的客户，如果就开药了，说明了什么道理？
不就是看人家孩子土，埋汰，就欺负或者糊弄人家了贝。不过这个理由是说不过去的，将这个上升到行业道德上的谴责恐怕也不为过的说，呵呵。

秋叶

我看了一下上面的帖子，好像这个医生大家都给他一个“庸医”的定义了，既然是庸医，发生这些悲剧肯定就不能避免。
“君子爱财，取之有道”，有多少人能真正做到？我想这是做人做事的根本，我是这样认为的。
对客户的需求，你需要去引导的，哪些是对的，哪些我们自己的能力不行还做不到？哪些是不能实现的、不合理的！前几天，我给一家军工企业演示完我们的Javelin，企业相当满意。但当我知道他们用的是SDRC，Cadence等CAD软件后，我就告诉他们我们目前解决不了他们的CAD集成问题，让他们去看一下国外的PDM产品。我想这就是我们的“有所不为”，我想这是一种对我自己从事的事业的一种尊重！

秋叶

你是一位负责的医生。
用户的需求是需要分析才能得到的。如果用户说：“我需要什么什么功能。”这是一个需求吗？不一定是。
可能他的要求是错误的。甚至他希望解决另外一件事情，但他以为要这个功能就可以解决要解决的事情。
所以，有经验的实施人员会首先了解企业的业务流程/工作报表等工作信息，而不是首先问“你希望软件有哪些功能？”

秋叶

对于所谓的用户需求我们需要分开看待：用户有些需求是属于借鉴性质的，实际上就是从其它软件的应用功能上来进行对PDM来进行要求，我以为这类需求如果超出了PDM的概念范畴、如果脱离了企业的实际应用，那么应该给予否定。此类需求一无实际用处，二则会造成其它有用模块的实施进度。另一种需求，是属于企业实际应用中的特殊需求，它关系到用户应用的合理性和高效性，一般是带有行业色彩的，这类需求需要认真对待。
我在作PDM实施过程中，我对用户讲的很多的一句话就是“我的工作重点是结合计算机的应用来优化你们的工作模式。”
医生存在的第一属性不是“庸医”或“良医”，而是“中医”或“西医”或“藏医”。要西医改行作中医，就算是白求恩也是白搭！（呵呵，西医中我就知道白求恩比较有名，见笑！见笑！）

秋叶

“我的工作重点是结合计算机的应用来优化你们的工作模式。””有道理，呵呵。
医生存在的主要原因是他可以看病，而不是因为他能“制药”，是根据病人的具体情况（企业业务模式或者流程）给出合理的处方（这才是抓药）。
不过，药还要分两种：处方和非处方。呵呵。
PDM软件显然是处方药，而不是什么可以直接购买应用的保健品或者非处方药，就需要在医生开处方和可选择药物之间的双向配合才能找出最佳或者是最实用的方案。

秋叶

如果把用户要上PDM就看成是病人未免太简单了吧。
现在更多的企业要上PDM是希望通过PDM在企业的成功应用使企业能够更健康的发展。
所以企业的需求分析是一个复杂的过程。
我们更注重的是量体裁衣，而不是所谓的对症下药。

秋叶

to 天喻人，呵呵，严重不同意你的看法。
以前和网友讨论过，网友曾经如是说，呵呵：
【"量体裁衣"---信息化中最蹩脚的比喻
许多人提到企业信息化时，喜欢用衣服做例子，认为应用软件要量身打造。
这种比喻很自然，穿衣服要合身，因为身材不可能在短时间内改变。因此，量体裁衣，天经地义。
一个人身材越标准(符合尺码)，就越容易买到现成合身的衣服；若身材不标准，例如腰特粗，则必须定做。
企业在信息化过程中，是否也要“量体裁衣”呢？
这要看他家企业的“身材”是否标准-----因为没有标准，就无法管理（No standard， no management）！
他的管理规范吗？产供销财务等各项管理职能都集成了吗？各项数据都准确及时吗？
手工下的管理是粗略的，不精确的、不及时的，在此基础上的作业流程也是不合理的，当然管理也是不标准的，
依据这样一个不标准的管理来量身定制应用软件，最多只能得到一个不规范的、不标准的落后系统。
因此，"量体裁衣"是信息化中最蹩脚的比喻！】

秋叶

照这么说，不标准的企业就不经过基础管理改造、BPR就不能上应用软件了？再说了，管理有统一的世界标准、国家标准、行业标准吗？应用软件又是根据什么管理的标准来开发的？我理解天喻人的量体裁衣也是一种对症下药，根据企业的模式进行适当的二次开发和模块增减。
说得不对，我也是来学习的。

秋叶

大家都是来学习的，每个人都可以有自己的理解，鼓励。呵呵。
管理＋IT的思路，我感觉没有置疑的空间，呵呵。。
管理不可能有标准，那句话说的是，幸福的家庭都是相似的，而不幸的家庭却各有各的不同，条条大路通罗马，呵呵。
天喻人说：
我们更注重的是量体裁衣，而不是所谓的对症下药。
客户的那个”体“如果不合要求，就要更改，否则实施软件，就不是提高效率，而很可能是”更快速的制造错误和混乱“。

秋叶

管理＋IT的思路，我感觉没有置疑的空间，呵呵。。 这思路是对的，我也没有质疑的意思，这是一个大的方向，但在现阶段还是有重点的，我觉得应该先是IT。
客户的那个”体“如果不合要求，就要更改，否则实施软件，就不是提高效率，而很可能是”更快速的制造错误和混乱“。
合什么要求，是软件的，还是管理的？管理方式各企业有各企业的不同。如果不合软件的要求就要改，那软件是不是适应性是不是也太差了？至少在现阶段，还有大量企业没有实现基本的信息化，实施了软件就会“更快速的制造混乱和错误”，那他们现在的管理是在制造混乱和错误？

秋叶

to topcircle
“这思路是对的，我也没有质疑的意思，这是一个大的方向，但在现阶段还是有重点的，我觉得应该先是IT。”
管理＋IT这个思路如果你承认，怎么还会有这个推论，有了方向，我们就要贯彻啊。你可以再解释解释你的理由。呵呵。否则的话，有点舍本逐末的感觉。（怎么感觉你很倔强啊：((  
合什么要求？
是合乎管理了，而管理合乎什么？是业务模式了，呵呵。这个就是管理+IT思路的贯彻。
如果企业现在不是“管理是在制造混乱和错误？”这种状况，那上信息化的目的究竟是什么？这里的IT是信息化，不是OFFICE之类的“即开即用”的软件。要不，你说的基本信息化根我说的是另一码事，呵呵。
也许你说的是这个意思。
咱们现在还没有孤岛，就想直接假设彼此之间的高速公路和桥梁，呵呵。对于这样的，我也反对这么做。信息化必须要全面规划分步实施，首先建立各个信息化孤岛才能逐步推进。你说的是这个意思吧，呵呵。

秋叶

新加坡一公司招标，要求非常苛刻，项目期限短得惊人。
几家软件公司投标。都是一味的强调自己的技术基础如何好，如何能够实现。实际上在他们的心里也一定打鼓，不确定是否能满足。
一家印度公司却从完整的软件质量过程、技术出发，提供了详细的分析，分析哪些要求能够实现，哪些根本不可能实现，或者实现了成本也不合算。然后提出了保证质量的最短时间要求。
结果：印度公司中标。
结论：成熟的软件商引导了理智的客户成就一个成功的案例。

亚西亚

有些用户提出的PDM需求，乍一看似乎很专业，PDM软件该有的功能他都知道。
仔细一看，不过是一个不错的资料收集整理着的编写，而非需求分析者的著作。
整个需求，就是国内外常见PDM系统宣传的优势功能集大成，与他企业的实际业务和需求没有什么关系。
用这种需求还选型，一是找不到一个可以满足所有这些需求的PDm软件，二是就算有这个PDM软件也解决不了他企业的问题---他自己都还不知道企业要解决的问题是什么，哪些问题最重要。
以此为依据的选型，不出问题才怪---先是找不到一个满意的，后是被一个高嘴忽悠一通胡乱选一个完事：要是运气好，遇到好的实施顾问，经过培训和调研回归真实需求；运气不好，人家塞一堆是似而非的功能过来，什么都有，什么都不能用，那就痛苦了

秋叶

客户提出的需求很少有不合理的，往往是客户提出的实现办法并不能真正解决问题而已；

客户提出的需求很少有不能解决的，往往是公司在现有资源情况下无法快速响应和服务而已；

客户提出的需求往往有简单的解决方法，如果你的答案很复杂，往往不是正解。

秋叶

做实施没有一帆风顺的，对于现有产品，客户提出不满，提出这样那样的问题是常有的事。

如果客户提出一个需求，往往表现为强烈需要一个功能，这个时候很多实施人员可能开始考虑这个功能是否合理，是否容易实现，并以此为基础和用户展开谈判。

一个有经验的实施人员这个时候首先应该思考客户为什么有这个需求，不要光看需求的功能描述。

首先应该考虑的是客户这个需求的本来面目是什么，有时客户的需求也是客户自己加工过的，比如客户认为在某个表单加个字段就可以实现这样一种业务，但实际上可能不是那么简单。

也就是从需求出发把客户要解决的业务还原，然后再站在全局业务的高度考虑我们到底要解决的是什么问题。

这个时候我们可能就会发现很多时候用户提出的需求往往是管理上的漏洞造成的，技术手段并不能解决业务问题，属于不合理的需求。

这个时候我们并不能轻易拒绝用户的需求，而是要和用户一起推导直到他们发现自己的方案并不能根本上解决问题，然后探讨真正解决问题的办法，这样用户不但会收回自己的想法，还会建立对你分析能力的认可。

如果客户需求是很合理的，首先应该考虑系统是否有现成的解决方案？很多软件在长期发展中还是积累了很强的能力，而实施人员未必能够了解全面，这个时候要抱定一个原则：

把现有产品功能用尽！

要想把现有产品用尽往往需要创造性发挥，调动一切可以利用的工具和自己产品整合，包括操作业务的变动。

如果想到可以解决问题的思路，要立即与客户即时交流，验证。

很多时候用户是非常通情达理，只要你能给他一条路，他就会用。即使这条路现在很麻烦，用户的忍受能力也会超出我们的想象。

如果我们能够在未来版本中持续改善，还有可能获得极好的口碑。

但是很多时候用户提出的需求非常到位的指出我们系统中的不足，也是我们产品的软肋，也就是通过功能绕不过去，或者勉强能绕过去，但终究是不能长久的。这个时候还要记住另一个原则：

关键问题不要绕，一定要及早主动去协调公司资源去解决！

对于一些关键性需求，往往它对提升用户的业务是非常有价值的，有时彻底解决才是正确的方法，变通实现可谓治标不治本，难免以后面对更复杂的问题。

实施人员往往都能意识到这个问题，但在公司内部解决和协调问题可能需要大量精力和投入，因而产生畏惧心理，结果耽误了项目，也影响了自己的绩效。

还有很多人觉得项目现在有时间，等到了实施到这块业务的时候再解决，一拖就把解决问题的时机给耽误了。

我们做信息化项目，对于客户的需求应该是一个负责任的态度，既不是一味听从客户，也不是一切都以软件不能修改为借口，这样是无法建立客户对你个人和公司的信任的，没有信任也不能指望会有一个好的沟通，好的团队来完成项目实施。

有的时候，客户的需求清晰，而且也是很关键的问题，但是客户在项目中的投入远远不足以支撑相关需求的开发。

这个时候还要记住第三个原则：

   要解决的合理且关键问题，如果用户支付金额并不合理的情况下立即了解公司意见，并按公司意见和用户反复沟通。
很多时候公司考虑到市场影响，用户后续追加潜力，版本主动规划符合度等多方面的因素，会在项目中承诺解决问题，这个时候实施人员是幸运的，但还是要花费大量时间和用户沟通，确定需求实现的时间可以在双方的承诺能力范围内。

对于客户的需求，如果已经决定进行解决，那么在进行解决的时候，一定要搞清楚客户的需求。这部分的需求，不仅包括客户提出的需求，还包括客户潜在的需求以及客户自己尚未发现的需求。虽然这样会造成一定程度的项目范围蔓延，但是同时会未将来的实施带来的很大的收益，避免问题解决得不彻底不但不能得到用户的认同，还会怀疑我们的能力。更重要的是实施团队会获取客户的信任。

也有的时候公司根本无法承受过多的开发需求（很多管理软件公司的产品离成熟还有很长的路要走），这个时候我们不得不面临最痛苦的事情，去拒绝用户的合理需求，因为我们的公司资源还不能承受。

如果公司随意承诺实现，最终并不能实现，结果并不比不承诺实现好，至少后者是讲真话的人。

对于客户的需求，如果不能满足的时候，一定要清楚的告诉客户基于什么样的原因，不能解决或者拖后解决。

不要利用信息的不对称来蒙混客户。因为在很多的时候，你所认为的掌握的信息，客户很快就会掌握或者他已经掌握。如果采用蒙混的方式，可能会使得自己处于一个很尴尬的处境。

对于客户的需求，如果需要在商务上需要进行谈判，可以委婉的告诉客户。注意：在小的问题上尽可能不要动用商务谈判，如果客户总是被告知需要进行商务谈判，他可能会感到厌烦，在他们看来你是在不停的向他们伸手要钱。

应该让客户知道你已经帮助他们解决了那些问题，这些可以通过定期的汇总报告通报给客户。

最糟糕的情况是，为了拿下合同销售人员做了某些需求的明确承诺，甚至将这些内容作为条款写进技术协议中由双方公司签字确认。

到了实施环节，公司告诉我们最近的版本规划无法实现，这个时候实施人员好象陷入两头受气的困境，用户要求你去兑现承诺，公司要求我们去引导用户的需求。

这就提出了一个如何引导用户需求的问题。

秋叶

国内企业的现状，很多客户其实都不知道自己的需求的，而是我们去引导。这种用户其实数量远大于知道自己需求的用户。

怎样去引导客户的需求呢？
要引导用户的需求，不是信口开河，或者搞经验注意，而是要多花点时间去了解企业的流程，看他们到底有哪些需要，看怎么样才能结合软件来让企业运行的更流畅，看怎么样才能解决企业的问题。把这些业务了解透彻了，就能站在用户角度和管理软件高度提出合理又让人信服的需求了。

对于前期由销售承诺的很多需求，其实未必是合理的需求，实施人员在业务调研过程中，往往有可能发现真正解决问题的办法，一旦就某个需求实现形成僵局，首先要去了解业务，分析这个业务到底想解决什么问题，这个问题到底可以通过怎样办法来解决，然后评估这些办法和我们的主要目标的符合程度，如果需求对我们主要目标实现没有帮助，我们就可以尽力去说服用户先将精力集中在主要目标上，一个项目是不允许有太多分支的。
如果用户还是非常固执要求实现自己的要求，一个有效的策略就是不主动激起用户讨论这些问题，淡化处理，拖一拖也就可能把问题拖掉了，这也是一种没有办法的办法。

秋叶

项目过程中发生的客户反映和提交的软件问题中，有这样几种类型：
1. 操作熟悉程度造成的问题，这种问题通过培训和指导很容易解决，关键是快速响应，认真热情，确认掌握才能放手处理其它事情。

2. 系统设置不当造成的问题，这种问题如果影响不大可以先告诉用户可以解决，然后约定解决时间，如果有严重影响，而且又可以解决，要立即协调资源解决，给用户留下良好印象，今后有无法解决的问题的时候也就相信你迟迟不动不是态度问题了。

3. 软件产品缺陷，这种问题要承认设计缺陷存在，根据影响程度采取相应对策，最终问题是否解决要归档持续跟踪，确认在项目结项前有一个双方认同的结果。

4. 业务流程上的管理问题：很多用户习惯性用技术性思维去解决管理问题，以为有了两个功能某些管理问题就会消息，他们没有意识到管理问题可以被技术工具从一个现象改变为另一个现象，但一定不能自己消失，除非你找到了管理解决办法，因此我们不得不象一个顾问一样去思考，到底有什么办法解决这些技术性问题要挑战的管理问题，然后看看是否能说服用户采取一些对策，如果不能，就说服用户不要采用技术手段去挑战这类问题。

5. 产品性能引发的操作需求：对性能的不满往往会衍生出很多操作的需求，这些需求的满足往往进一步引起性能的下降，所以最有效的办法就是想办法说服公司在软件性能开发上想办法。

6. 软件产品功能不足：如果是软件功能不足影响业务实施，没有办法，说服公司尽快解决，千万别去回避。

7. 用户的不合理想法：很多用户由于对软件和相应管理思想不了解，而提出一些很奇怪的想法，对这些用户实施人员是很头痛的，只好用拖字诀处理了。

秋叶

越了解企业业务，越有能力控制企业的需求

客户需求的问题也符合80/20原则，对于重要的20的需求，坚决要解决，不能绕，但未必就是技术手段解决。

解决了项目也就认同了

对于某些需求即使合理也要在刚出现苗头时自信的打死，项目反而能更顺利，不要让用户陷入细节和我们较量。