上班记 (八) --先签合同？先签技术协议？

在2001年的时候，当时所在公司发生一次业务争论，我在工作日记中记录了这个问题。

争论是从如何做需求调研开始的，我们当时发现一个问题需求调研除了要总结好的方法和套路外，质量和项目边界关系很大。

当时我们做CAPP/BOM项目，很多合同没有约定到底实施多少表格，只当工具软件按节点卖。那么实施部提出技术协议是否应该在签合同前就和用户约定好，而不应该签了合同后用需求调研的方式来约定。

结果引发了争论，首先实施认为如果技术协议谈得太仔细，一要增加前期沟通成本，而且会发现用户越提越多，我们当时CAPP/BOM是按用户要求我们配置的表格报价，配一张表和十张表价格是不一样的，如果前期谈用户肯定希望我们多配一点，这样我们的价格就上去了，这样的话在竞争环境下很可能造成合同流失。

如果技术协议谈得很简单，用户肯定也不接受。

如果把技术协议先弱化，放在实施阶段确认，很容易造成公司吃亏，因为实施人员当时都是技术型的，很容易被用户逼让步。

结果讨论来讨论去，得出意见是需求调研时明确多少资金范围内做哪些配置，哪些不做，实施要承担引导的责任。

当时有人提出即使实施来引导，万一用户需求反复变更怎么办？万一用户提不出有价值的需求怎么办？

当时一个有经验的老工程师谈了他的意见：

上班记 (八) --先签合同？先签技术协议？: 1、到现场先告诉用户我们的流程；

上班记 (八) --先签合同？先签技术协议？: 2、让用户重视需求调研过程，必须安排关键人物沟通；

3、需求要尽量主动了解用户难点和重点，和用户多就产品价值进行沟通，对用户问题能理解少问，能看到的就少问，慢工出细活；

4、关键问题不要轻易让步，学会组织开会---拉人帮忙---让领导在报告上签字

不过现在看这个问题，觉得依然是个问题，当然现在开目是要求前期尽量清晰约定需求（以业务边界为主，不以功能边界为主），为了签单可在公司授权情况下适当模糊，不晓得同行有更好的思路没有？