管理需求

客户提出需求的方式，往往表现为强烈需要一个功能。这时候应该思考：客户为什么有这个需求？

首先，应该考虑客户需求的本来面目，而不是需求的功能描述。如果客户并不清楚了解自身的需求，就需要引导客户的需求，而不是信口开河或搞经验主义。

要多花点时间去了解客户企业的流程，看他们到底有哪些需要，看怎么样才能结合产品和服务，让客户企业运行得更流畅，看怎么样才能从根本上解决客户企业的问题。必须从需求出发，把客户要解决的业务还原，然后再站在全局业务的高度，考虑到底要解决的是什么问题。

项目经理必须认真分析、谨慎对待，想办法落实解决需求。如果客户提出的需求很合理，那么要坚持把现有产品功能用尽的原则。首先应该考虑系统是否有现成的解决方案，也可以进行创造性发挥，调动一切可以利用的工具与自己的产品进行整合，包括操作业务的变动。

如果想到可以解决问题的思路，要与客户实时交流验证。如果客户提出的需求非常到位，那么关键问题不要绕，一定要及早主动协调我方公司的资源去解决。要解决合理且关键的问题，就需要先了解我方公司的态度，并按照我方公司的意见和客户反复沟通。

但很多时候，客户提出的需求往往是管理漏洞造成的，技术手段并不能解决业务问题，属于不合理的需求。这个时候就不能轻易拒绝客户的需求，而是要和客户一起推导，直到他们发现自己提出的方案并不能从根本上解决问题，然后再和客户探讨真正解决问题的办法。

如果已经决定解决客户的需求，那么在解决过程中，项目经理一定要彻底搞懂客户的需求。要认真研究，弄清楚客户提出的需求，还要探究客户潜在的需求以及客户自己尚未发现的需求。

很多客户表达的问题和要解决的手段往往是分离的，不要把解决的问题和手段混淆在一起。有时候，要解决的问题是因为另一个问题造成的；有时候客户的需求是客户自己加工过的，要先分析清楚。

再好的方案也有缺点，要让客户自己选择，不要替客户选择。

客户的需求有三种常见类型：

规划时没有合理解决的问题，而且无法在本项目中回避，或者绕过去对客户项目没有什么合理价值。业务调研阶段就要主动思考和确认；在功能内部验证配置业务流的时候就要发现，并及时、尽早向公司回馈，强力推动解决。不要等到现场推广时让客户发现，再去改。
产品或服务在易用性、稳定性或性能方面存在问题，但的确有替代方案，或者客户暂时可以接受。项目团队应该承诺给予解决，但要和客户解释：这些需求必须纳入统一版本规划实现，不可能今天提出要求，明天就改好。要让客户理解，快速开发实现表面上是快，但从长远来看，可维护性一定很差，最终花费的代价会更高。项目经理在功能验证阶段要主动和客户项目组提出，项目推广过程中哪些功能可能会产生问题。在取得客户项目组理解的情况下，一起提前设计。一旦出现应用者不满意的情况，要做好沟通工作和相关应急备案。
客户应用后产生一些新的业务思想，希望项目团队来解决。这种业务需求可能包含很有预见的产品未来发展方向，也可能是客户将其他系统应该解决的问题，盲目要求在系统中加以实现。项目经理应该收集并回馈给公司相关规划人员做分析，看能否作为产品未来发展的业务参考。坚决不能给客户任何承诺，以合同为准，按合同办事。超出合同边界的需求，在一个项目中绝对不可以轻易响应。

关键性需求往往对提升客户的业务价值非常有价值，彻底解决才是正确的方法。关键问题不要拖，一定要及早主动协调自己公司资源解决。

当客户的需求清晰，而且也是很关键的问题，但客户在项目中的投入远远不足以支撑相关需求的开发时，需要先了解自己公司的态度，并按照我方公司意见和客户反复沟通。很多时候，我方公司根本无法承受过多的开发需求，这就需要项目经理去拒绝客户的合理需求。如果确定我方公司没有能力快速响应，就不要逼我方公司随意承诺。如果客户的需求不能满足，就一定要清楚地告诉客户，基于什么样的原因导致不能解决，或者拖后解决。不要利用信息不对称来蒙混客户，让客户以为公司正在响应中。

在小的需求问题上，尽可能不要动用商务谈判。可以响应这些小问题，但是要让客户知道自己已经帮助他们解决了哪些小问题。通过定期的汇总报告通报给客户，让客户欠个人情，为后来的回款提供方便。可以把这些小需求集中起来，汇总成一个大的开发需求，这样再谈费用会比较合适。

如果一定需要在商务上进行谈判，可以委婉地告诉客户：销售人员为了争取合同，很少有不过度承诺的，这是一种无法回避的现状。这种现状恰恰是造成实施顾问体现自身价值的机会。要思考如何在最小化开发成本下，有效解决业务问题，而不是指责销售团队或者逼压开发团队。很多过度承诺的产物，是客户心血来潮的产物。真正做项目的时候，经过深入思考，客户也会接受理性的目标，不会反复追究。前提是在调研阶段提供好的解决方案，也就是提供清晰的项目目标和完整的业务方案，与客户建立良好的私人感情。

由销售承诺的很多功能，其实未必是合理的需求实现方式。实施顾问在业务调研的过程中，往往有可能发现真正解决问题的方法。一旦和客户对某个需求功能实现方式形成僵局，实施顾问首先要去了解业务，分析这个业务到底想解决什么问题，这个问题到底可以通过怎样的办法来解决。可能会找到替代方案，甚至是更好、更容易被客户接受的方案。

有的功能可以和客户一起评估其对主要项目业务目标的符合程度。如果需求对主要目标实现没有帮助，就可以尽力去说服客户先将精力集中在主要目标上。一个项目是不允许有太多分支目标来发散精力的。如果个别客户非常固执，要求实现他的需求，就不要主动激起客户讨论这些问题，尽量淡化处理。

客户提出的需求很少有不合理的，往往是客户提出的实现办法并不能真正解决问题而已。客户提出的需求很少有不能解决的，往往是公司在现有资源情况下无法快速响应和服务而已。

实施顾问要多和客户沟通，告诉客户需求需要认真分析，形成系统方案才能进入开发。在产品很多功能没有完善之前，可以推出快速、短周期、小版本响应市场的开发策略，但一次只解决很有限的问题，在最大程度上平衡开发资源和市场响应的矛盾。应该有人去思考整个大版本的规划，适当的时候要投入专门的资源做根本性设计。

客户提出的需求往往有简单的解决方法，如果答案很复杂，往往不是正解。这个时候有三种对策：

拒绝问题：与项目无关或超出项目业务目标范围的问题（超出技术协议范围未必超出业务问题的解决范围）当场说明理由拒绝，不给客户任何幻想。先用文字记录，事后并不响应。如果不是真正影响项目的需求，可以放一放客户，让他自己忘记也可以。或者和客户一起分析问题，把问题复杂化，让客户意识到解决这个问题不仅需要开发，还需要客户内部做管理配合和资源投入，让其知难而退。也可以利用自己公司即将发布版本的功能，交换客户放弃对本功能的关注，并用文字确认，防止客户反悔。
推迟解决：在和公司内部沟通后，明确承诺问题是我方责任，但因为其附属于其他问题，或暂时无开发资源解决，和客户推迟实现版本时间达成一致。务必要将实现时间说得保守一点，承诺可以提前做到。除此之外，还可以寻找各种可行的替代方案，也可以将需求汇总，说服客户作为后续或新的合作内容，投入费用解决，不和本项目目标混淆在一起。
立即响应：如果确定问题存在且需要解决，一起形成详细规范、需求建议和缺陷报告。要包含业务说明、功能改进建议和项目影响优先级，然后给公司规划评审，确定解决方案，立即采取行动，说服公司落实资源去解决。

在整个项目生命周期中，都应该卓有成效地完成客户提出的要求。必须确保拥有一套确实有效的要求。

“确实”是指客户的真实需要，也就是可以明确不同要求之间的边界条件，以便能够设计出满足客户要求的方案。

“有效要求”是一种以可理解的业务表达客户需求的要求，这种方案能够解决真实的问题。

遇到问题，不仅仅要解决问题本身，还要解决问题所在的环境。