项目也可以通过挖掘客户潜在需求，注入新技术的灵魂，并将蛋糕做大，签下大单。
不过在挖掘需求之前，一定要搞清楚客户大概的预算，就算搞不清细节，也最好能知道客户预算的上限在哪里，否则的话挖掘需求就是白忙一场，甚至遇到贪婪没有节操的客户，提一堆需求欺骗说有很多预算而实际上后面签约的时候开始耍手腕，最常见的赖皮方法就是将一大堆需求含糊地写进RFP中，而单子却签很小并在项目实施过程中要求所有功能实现。
言归正传，谈比较正常的情况。
需求整理阶段是挖掘潜在需求的关键阶段，这个阶段是要件定义前的阶段，通常会做一些提案，但是比提案本身更重要的是QA表。
这里不得不说的是沟通的艺术，举个例子，我观察日本卖房的营业人员，越是大公司的营业，越是不会非常热情地向客户推荐房子，也不会议价，往往从挖掘客户真实需求着手，比如客户是比较注重生活品质的，还是比较注重通勤距离的，是比较喜欢自然的，还是向往都市高档消费夜生活的等等，往往客户一开始会提很多相互矛盾的需求，什么都要，而最最真实的需求会在不断的沟通中渐渐显露出来。大公司的营业会不动声色观察客户，倾听客户，然后通过提问一点点把客户的真实需求挖掘出来。这个过程中他们并不随便推销自己的房子，只有在最后比较清晰的阶段才给出备选方案，而他们真正想推荐给客户的房子，甚至故意不会推荐，通过非常微妙的方式吊足客户的胃口，在最后阶段突然抛出来，这种时候，客户根本不会去议价，生怕买不到手。
沟通的关键不是说，而是倾听。
软件开发签约其实也是如此，营业不仅仅是那个名片上写着营业的人，他们当然也是营业，但他们主要是搞清楚客户方的底牌，比如预算、关键stakeholder，客户那里真正说了算的人，客户公司部门间的利益关系，竞争对手的底牌等等。
而挖掘客户需求的恰恰是solution或者system consultant的团队，QA表是非常重要的一环，因为QA表不是简单的提问，而是在通过提问向客户展示开发方的专业知识，赢得客户的信任，通常人们有过错觉，以为提案是展示过程，但这是只知其一不知其二，因为提案就像不断推销房子的营业，重在说而不是倾听，是把自己脑子中的东西Push给客户，而不是把客户脑子中的需求一点点pull 出来。只有从客户的头脑中pull出来的才是客户的真实需求。
因此QA表如何问问题非常重要，既要展示一些已有的专业知识，又要不断征询客户的想法，多给客户一些option，引导客户说出真实的想法，这个交互的过程中，客户会发现自己没有注意到的地方，需求一下子就会奇迹般膨胀，客户被激发后甚至会去做功课，参考相关的同行的产品，在那个基础上不断加需求。这是一个相互激发的过程。
一旦到了这一步，需求就开始变大了。
到了这一步就要开始控制风险，因为有些客户脑洞也是从这个时候开始的，大到无法收拾，就是项目的灾难。consultant或solution最好是一个team, 不同的人员不同的性格，有厌恶风险的，有比较开拓型的，互相制约。
而且这个时候一定要开始做技术调研，因为新的需求也带来技术上的不确定，最好做一些POC，确认一下，如果大的POC，需要专门制定POCphase，客户如果能够给到预算，POC可以做得详细一些。
同时还要回到客户真实需求的原点，引导客户务实，用不同的方式实现客户的真实需求。这里更要注意的是，不能突然让客户失望，需求刚刚膨胀起来突然被浇了一盆冷水，说技术上无法实现，这种打击虽然比较大，但也是对客户负责的做法，通常随着沟通的深入，客户方也会参与一起修改调整需求。
如果通过营业得到的客户的预算不是很高，在QA中问问题就不能问太多，免得客户一下子胃口大开，而是要简洁，控制好边界，将需求明确化，一边确认需求一边就要开始草拟前提条件，这是一些限制条件，界定项目作业范围，明确不做什么，而不是做什么，确定哪些需求客户不需要，复杂度上降维。
事实上很多功能做了之后真正使用的部分并不多，时常牢记简洁化功能。
实际情况是，客户的预算也会发生突然的变化，如果要件整理中遇到客户新的战略变化，预算突然加大，这个时候比较谨慎的客户会分阶段签约，对于分段签约的单子，不同阶段功能的分布和master schedule 的制定非常关键。
除了一些根据客户的优先度是考虑因素之外，第一阶段所实现的功能又要简洁保证成功，而功能本身又能够足够吸引客户，引起后续签约的兴趣。这是个漫长的和客户不断交往的过程，需要非常耐心，但也不需要做得太过分。
项目中接触的客户，一般是客户的IT部门或者是对业务拓展部门的业务人员（不是领导），对业务创新和流行的商业趋势有一些了解，具有比较强的行业背景知识，如果客户不能给出这样的部门或者负责人，则一定要及早提出来，免得需求不清楚。
网友评论