一次范围蔓延poc的反思

7月26日入场一家s2b公司进行poc，前期工作由售前整理好poc范围、客户期望达成的目标、时间计划，和客户领导层开了一次启动会。

原计划是给一个小系统进行压力测试，发现该系统是否满足业务期望的流量承载能力。启动会上能感受到这家s2b(外企)的领导是不懂技术，但很有外企人的管理逻辑，能鼓动大家一起干活的人。启动会上大家沟通的目标是验证系统能否承载1200tps压测，摸高1500tps，该领导发散性说了关注的是服务质量，这次poc不仅验证的是平台能力，更看重服务能力，期望咱们能做更多的事来告诉他系统的问题（后面会说到这里给范围蔓延埋下了隐患）。

前面由于有个新手跟客户的供应商在对接技术问题时暴露了些初级问题都不太懂，供应商投诉到s2b的领导说我们不够专业，马上当天就被客户拉小群约聊此事。当周周例会汇报进度，由于我没有识别好相关方，在会上和s2b客户领导有些激烈言辞，导致某总对我们服务态度产生质疑。

后续两周解决些技术问题，完成poc内容。

进行项目总结汇报时，售前完成汇报后，某总询问供应商是否认可我司的poc方案，供应商PM支支吾吾，技术则说两种方案有区别。某总这时进入发散模式，按自己理解描述了技术问题，说想通过压测发现系统的瓶颈，更多的是指能否在更大压力下把系统压挂，并分析定位问题。这一需求蔓延在会上有理有据的提出来，导致销售、售前只能接招。

反思整个poc过程，最大的问题在于计划是按模板而列，技术型项目的计划最大的风险在技术方案上，前期没制定详细的技术方案，并跟供应商的人核对，导致完成poc后对整体方案实施产生质疑。

接下来是两天投入交付、售前、销售、架构师来重新按客户要求继续完成蔓延的内容。。。

后续改进：需要针对实施poc的项目有技术方案模板，针对不同客户需求有不同的难易poc方案，同时有不同资源排列组合。售前、销售要引导客户期望，一次poc服务投入是要考虑成本，投入的实施人员按核对的技术方案，验证的功能点清单划勾，超出范围的内容有理由拒绝。