江苏省高级人民法院民 事 判 决 书(2019)苏民终267号上诉人（一审被告、反诉原告）：苏州睿途网络科技有限公司，住所地江苏省苏州工业园区娄葑星湖街999号99幢701室。法定代表人：蒋伟。委托诉讼代理人：边学梁，上海市锦天城（苏州）律师事务所律师。委托诉讼代理人：宋恒冲，该公司项目总监。被上诉人（一审原告、反诉被告）：上海樱蓝网络科技有限公司，住所地上海市闵行区放鹤路1088号第6幢A4090室。法定代表人：孙林茂，该公司总经理。委托诉讼代理人：潘赟，上海恒衍达律师事务所律师。上诉人苏州睿途网络科技有限公司（以下简称睿途公司）因与被上诉人上海樱蓝网络科技有限公司（以下简称樱蓝公司）计算机软件开发合同纠纷一案，不服江苏省苏州市中级人民法院(2018)苏05民初184号民事判决书，向本院提起上诉。本院于2019年3月6日立案后，依法组成合议庭，公开开庭审理了本案。上诉人睿途公司的委托诉讼代理人边学梁、宋恒冲，被上诉人樱蓝公司的法定代表人孙林茂，委托诉讼代理人文敏（后樱蓝公司撤销其代理权限）到庭参加诉讼。本案现已审理终结。睿途公司上诉请求：撤销一审判决并依法改判。事实和理由：1.原审法院关于软件开发、交付日期、需求变更，以及樱蓝公司的经济损失等事实认定错误。涉案软件已于2018年2月初开发完成，并具备交付条件。2018年2月底，睿途公司向樱蓝公司发送验收申请，但樱蓝公司不接收软件、不配合验收。尽管涉案合同约定交付日期为2017年9月20日，但合同履行过程中，樱蓝公司提出了大量需求设计变更，并新增软件功能，导致开发进度延长，为此双方一致确认交付日期变更为2018年2月。此外，一审法院关于樱蓝公司经济损失的认定错误。樱蓝公司一审未详细说明相关发票的明细，也未提供证据证明相关发票与涉案软件之间的因果关系，不能确定相关支出与本案的关联性。2.一审法院认定涉案合同已解除，并要求睿途公司承担涉案合同履行的全部责任，属于适用法律不当。2018年1月18日，樱蓝公司仍同意睿途公司继续进行开发，睿途公司同时也按照樱蓝公司要求将涉案软件的核心数据交付对方。1月20日，樱蓝公司在未事先通知、未给予合理催告期限的前提下，单方发出解除合同的通知，系违约行为，不应产生合同解除的法律后果。一审法院认定睿途公司应当承担涉案软件本身以及开发周期的全部责任，既不符合定制开发合同的性质，也不符合软件开发行业的惯例。樱蓝公司二审答辩称：原审判决认定事实清楚，适用法律正确，应予维持。1.睿途公司未按合同约定完成产品开发，构成迟延交付。2017年9月至11月，樱蓝公司曾三次催告睿途公司交付产品，但睿途公司始终未完成产品开发，构成迟延交付。截至2018年1月，涉案软件开发尚有三分之二的内容未完成。双方未书面确认产品交付日期延至2018年2月，睿途公司主张涉案软件开发合同变更交付日期，没有依据。樱蓝公司提出的修改意见，并非新增功能。本案开发进度延迟的主要原因是，睿途公司缺乏按期开发产品的履约能力，其在合同履行中多次更换产品经理，导致反复确认产品需求。2.睿途公司迟延交付构成根本违约，合同解除于法有据。睿途公司未按约定日期交付符合要求的产品，导致合同目的无法实现，樱蓝公司的经营损失不断扩大。在通知解除合同前，樱蓝公司已三次催告交付产品，睿途公司未能及时交付，构成根本违约，符合解除合同的法定条件。3.睿途公司应赔偿因其违约导致的经济损失。樱蓝公司在软件开发期间支出的网络、通讯、服务器等费用，均系用于软件开发，与本案具有直接关联，睿途公司应依法承担赔偿责任。樱蓝公司向一审法院提出诉讼请求：1.确认《技术服务合同书》于2018年1月20日解除；2.判令睿途公司返还合同价款275000元，并支付自2018年1月20日起至实际清偿之日止，按照中国人民银行同期贷款利率计算的利息损失。3.判令睿途公司赔偿经济损失222018.44元。4.诉讼费用由睿途公司承担。睿途公司向一审法院提出反诉请求：判令樱蓝公司支付275000元及其自起诉之日起至实际履行之日的利息（按同期银行贷款利率计算），反诉案件受理费由樱蓝公司负担。一审法院查明：（一）签约情况2017年7月5日，就樱蓝公司（甲方）委托睿途公司（乙方）开发“跨境服务APP”（本软件）软件项目，双方签订《技术服务合同书》，约定：一、项目内容：可以互联网与移动互联网环境下运行的软件，软件需求双方协商确定。本软件开发的栏目架构及相关功能开发细节由《本软件开发需求表合同附件一》载明，使用本软件角色终端：用户（ios、andriod）、商家管理（ios、andriod）、运营管理（PC）。约定合同总价款包括乙方软件开发期间所有费用（含税费并提供普通增值税发票）为固定包干价55万元，除上述款项外，甲方无需支付任何其他款项（不含第三方例如：短信验证通信费）。二、合同价款、付款方式、开票方式之2.付款方式：设计款：合同签订后三个工作日内甲方向乙方支付合同额度的20%设计款为11万元；初验款：项目在约定的时间内乙方完成相关开发工作，甲方验收合格后三个工作日内向乙方支付合同额度的40%项目款22万元。乙方收到初验款后一个工作日内提交互联网搜索引擎（发布上线）。终验款：项目上线运行60日历日后进行项目终验收，验收合格后3个工作日内甲方向乙方结清尾款合同额度10%合同金5.5万元；乙方收到终验款后一个工作日内发送软件源代码到甲方指定邮箱，项目并进入维保期。三、开发周期与进度说明：分需求设计阶段、研发测试阶段，双方约定（乙方）完成所有开发工作，交付时间为2017年9月20日。研发阶段的开始时间为定于需求确认时间（以确认邮件为准），若需求确认时间延期，交付时间顺延。以上如因国家规定节假日放假，时间顺延，或因修改意见未能及时反馈，则顺延。合同四、五为甲方、乙方的权利和义务；六、交付、验收事宜：乙方必须按甲方确认的方案完成整个项目的开发工作并交付甲方验收及将本软件投入试运行。1.验收内容与业务流程之（1）验收内容：需求验收、原型验收、UI验收、平台交付验收、源代码验收。（2）验收流程：乙方完成阶段性工作时，通过邮件发送验收通知到甲方指定的邮箱；甲方收到邮件后3个工作日内提出反馈与修改建议、若不回应自当默认验收；提出反馈与修改建议的文档直接回复邮件，乙方负责人收到后并回复告知修改完成时间。2.BUG修复、改动、增加功能说明之（1）BUG修复调整时效（详见列表）；之（2）功能改动说明：甲方把业务逻辑、交互体验要改动调整需求以文档发送给乙方指定邮箱，乙方负责人收到后1个工作日回复改动工期与实施完成时间；改动需求完成后邮件通知甲方确认验收，并告知此需求后期不再无偿修改。之（3）功能新增说明：本次开发项目功能表（附件一）之外，甲方提出新增功能需求发送乙方负责人邮箱；收到后2个工作日回复报价与开发工期，甲方认可乙方新增功能报价需要签订补充协议并支付预付款，待甲方验收本合同原有功能3个工作日内乙方给出开发新增功能的进度表。3.验收的标准明细之（1）项目采用现场、邮件方式验收，验收标准以符合附件一所提供的功能为准。之（2）验收由双方人员共同参与。系统开发或配置完成后，经乙方内部测试通过，即可按照项目进度配合甲方进行系统初验，所有系统功能模块符合本协议要求，能够正常运行。之（3）初验完成后，系统整体试运行30日后，初验遗留问题已解决，乙方确认系统具备正常运行条件，即通知甲方系统已准备就绪，等待最终验收。当系统通过测试时即终验完毕，甲方向乙方签发终验报告。之（4）系统达到验收条件后，由乙方提出验收申请。之（5）甲方根据乙方提交的验收申请进行确认，甲方自验收申请收到之日起2个工作日内未组织验收的，视为自动验收合格。之（6）甲方验收不合格，应出具书面的异议，甲方怠于通知或者自验收申请收到之日起15日内未通知乙方的，视为自动验收合格。之（7）验收分初验和终验两次，初验通过后才能进行终验。验收可进行多次，如不合格，乙方应及时加以修改纠正。直到验收合格为止。双方还约定了项目验收交付文档清单、知识产权、保密条款、系统维护等内容。跨境旅游项目报价明确作为合同附件一。其中项目实施周期说明有三：1.项目实施周期为3个自然月，2个月可以项目投入试点运测试（根据本报价所涉及功能点）；2.项目的实际实施周期需要根据项目调研情况即需求分析/产品设计情况（该部分预20个工作日）如此项延期，则整个项目周期顺延；3.硬件费用不包含在本次报价内，2万个人用户注册使用，购买阿里云服务器费用可控在1万人民币/年。双方确认签约前已经历需求设计阶段，6月份就存在沟通产生了合同附件一的报价基础，签约时已作为合同附件一的跨境旅游项目报价表构成需求确认的标准。2017年8月24日，睿途公司宋恒冲发送给樱蓝公司孙林茂傻孩子境外游项目需求确认邮件，附件为傻孩子压缩包，包括傻孩子用户端、商家端（html/png）、流程源文件及后台修改rp文档等内容。该邮件附件构成睿途公司对其理解的樱蓝公司前期需求描述的细化版本。2018年8月8日睿途公司整理的38项功能变更和8月14日樱蓝公司的回应均以该2017年8月24日邮件附件为依据或者依据之一。（二）微信记录反映的履约过程2017年7月7日，睿途公司潘文丽邀请樱蓝公司孙林茂加入“傻孩子跨境游项目沟通群”，群人数为11人。从群记录反映睿途公司安排的项目联络人（产品总监）为刘翔，后经历了白雪、王明星的二次更替。1、刘翔为睿途公司涉案项目产品总监时期的微信记录2017年7月7日，孙林茂加入微信群，在群内第一次发文涉及“昨天讨论余额可提现和不可提现”问题。当晚，孙林茂发送了“皇包车APP”的页面截图给刘翔，提示参考“皇包车”的司机端后台，“不要受太多影响，还是按照我们说的逻辑来”。随后孙林茂又发送了若干张“你来出境游APP”有关快捷订单的截图，就其“在聊天框里做快捷订单的过程”提供样式说明给刘翔，并解释了包车下单的三种模式。孙林茂解释“我不知道我后台接送跟包车有什么逻辑的不一样，从操作内容上，接送跟包车的区别是，接送不看时间，只看两地的距离。包车一天只有10小时，活动范围是有限制的”等等需求描述。当天孙林茂又发送了“小红书APP”的页面截图，提示“可以关联微博、通讯录，微信好友”，“附近功能里面需要展示两个东西，一个是附件的人（附带发的攻略啥的）。另一块是附近美食”。当天下午10:45，孙林茂提出“从现在开始我把说的东西编号吧”，并总结了五项需求描述：1需要对客户会员等级进行管理和权限加减，2对客服分类，3充值后要求，4民宿除了房费还要有押金，5发动态或者攻略的人或者朋友圈的人，要能识别这个人是长期在国内还是国外的ID。2017年7月8日下午7:49，孙林茂提出“把美食的快捷球加到游玩的二级页面里面哈，跟包车，民宿一个级别的”。还与刘翔探讨“客人在客户端点击‘我的’是进入个人页面（类似于小红书或者微博）还是个人中心（后台余额，帮助中心之类的）”的利弊，后要求分为“个人页面和个人中心”两页，“商家版也有后台分页。之前说好的，如果一个人有三个角色，那就有导游，民宿，商城这三个后台”，“优先派单”、“求单”、“SOS消息”、“余额显示隐藏”等等功能模块的需求描述。2017年7月9日、7月10日，孙林茂继续需求描述：“商家发的朋友圈”，“都有一个按钮‘进入ta的店铺’可以去逛一下”。还提出其要找个小银行谈，需要“绑定银行卡功能”。“商家要有明显的国内卖家还是海外卖家的标志”、“APP的底色为绿色，鲜绿色，环保的绿”。需要“一个发布图文信息的地方”，“可以选择某国家，某个城市近期有什么演出啊，活动啊，赛事啊，需要填写国家，城市，活动介绍，和如何买票参与之类的介绍”，后台需要“删除评论”功能。“客户端的个人中心某个醒目的地方应该有个单独的大按钮，‘我要成为商家’，然后链接到下载商家版的应用商城”等。2017年7月10日下午3:12，睿途公司刘英发送了包车和民宿的业务流程图，孙林茂解释“接机送机拼单”功能，“还需要一个同行甩单”功能并举例解释。随后孙林茂确认第一张图“流程OK，中间有一个问题，抢单成功，订单匹配成功后跟客人的点对点消息渠道要打通”。关于民宿流程，孙林茂疑问“民宿商家如果其他渠道有了订单，是可以在我平台没有订单情况下，自助减少库存或者关闭预定的对吧”。睿途公司宋恒冲表示“今天我们这边会做一部分成果产品，明天得麻烦你来我们这边了”，“最好11号、12号都在这边”，“这样在你13号飞之前，咱们把原型图和所有业务流程图都完全敲定”。宋恒冲发了一份终端类别的示意图，包括“用户”、“司机、商城商家、民宿房东”、“运营总台”三个模块，孙林茂予以确认，并表示“主要把具体功能完善好就行”，同时就三个模块，孙林茂问“像发布攻略和朋友圈这些，属于哪个部分的？”宋恒冲予以解答。宋恒冲问“你说的朋友圈是指分享到微信的朋友圈还是咱们‘傻孩子’里面的朋友圈”，孙林茂答“我知道客人之间没有好友功能，就像小红书那样的，发布动态的朋友圈，就叫动态好了”。“最后这个APP使用的流畅性一定帮我多下点功夫，用户体验不好，做啥都白搭”。宋恒冲答“一定的”。之后孙林茂发截图，继续需求描述：需要“自定义的分类”、在客户端有“商务合作的一个通道”，终端三个模块之外的业务，“比如赛事活动举办、商务考察、医疗体检、翻译等等，这个也不算个功能模块，有点像签证那一页”的“图文介绍”，有“联系客服”的按钮。孙林茂还解释民宿的房费是“预定要全额支付”，“只是一笔钱分成两块，一块是房费，一块是押金”还举例说明，并解释“这个押金不给房东一直在平台，房东确认退房没问题，这边退房费，结束之后，房东和客户可以相互进行图文信息的评价”，双方进一步交流民宿“押金问题”。期间孙林茂还解释了“司机那个端也没有尾款，顶多有个加班费，现做个单付费”，在司导，商城，民宿板块的个人中心里，要有“常见问题和规则说明”。7月10日下午7:03，刘翔发送了“用户端”和“商家端”链接，让孙林茂用电脑打开看一下，并提示“有很多页面需要明后两天我们来沟通”。当天下午7:37，孙林茂继续需求描述“不光可以推荐首页到微信朋友圈，商城的店铺，漂亮的民宿，和靠谱的司机，客人觉得好，都可以分享到朋友圈”。下午9：21，孙林茂在电脑上打开了刘翔所发的“用户端”、“商家端”链接，开始边配图边提意见、问题和需求描述，交流中涉及“司导”和“民宿”接单的差异。对于客户端“订车”流程，孙林茂提出“缺了一大块吧，我说做得更像皇包车，现在更像你来出境游了，直接是个平台了”，“签证，用车，民宿，管家这些都在出行里面，每个用快捷球表示”等等。最后，孙林茂问“好像我这个群里说的很多小功能没有看到。就是要等明天沟通是吧”。刘翔回复“很多细节的东西需要双方沟通确认一下”。2017年7月11日下午6：01，孙林茂在群里发了自己的邮箱ｍｉｃ×××＠ｑｑ.ｃｏｍ，还描述需求“定接送机要有填写航班号的地方”。当晚11：55，睿途公司潘文丽问“回去了吧”，孙林茂回复“回了”。即，孙林茂当天下午在苏州又回上海了。2017年7月12日下午3:34，孙林茂需求描述“我平台要有个官方发布图文作为展示的页面。也不是推荐到首页的，是我们官方会搞一些活动，像是自我宣传的意思”，“有点像公众号文章那种”，刘翔答“这个工作量就大了”。孙林茂理解“顶多加个链接，里面某个东西链接到某个页面就可以了，你只要给我个能上传编辑这些内容的页面，其实跟个人发布图文攻略差不多，只是官方的，固定页面而已”。刘翔解释“不一样的，你这个相当于平台的公告和广告，需要后台配置编辑器，前端还要给你一个专门的页面入口，还有页面显示，不跟一般用户发布的动态混在一起的话，需要有个专门的新增页面去展示，你还要想好这个新增页面的入口安置在哪”。之后，孙林茂表示理解了。2017年7月13日上午，双方继续交流“出行页面”需求的理解和缺漏，孙林茂质疑睿途公司刘英对“当地美食”按钮需求，“好像这个没记录吧，天呐，是不是真的要我从头把群里发的功能捋一下，是不是还有别的”。宋恒冲问“当地美食链接到哪里去呢”，孙林茂答“只增加一个展示页面，我自己上传点名，图片，联系电话，简单介绍”，双方就此交流，孙林茂理解为“像签证那样，就是一个页面，不需要再点击了”，宋恒冲解释“签证是一个图文混排，美食应该是一个瀑布流，两个差别很大啊，前端一个页面，后台需要有管理上传的地方，中间还有接口，看似一个页面，还是需要挺多工作”。双方就各自理解“签证和美食”项目异同交流和争论，最后孙林茂放弃，但表示“我们说好的那几个模块尽量给我完善吧，当时说合同不用那么细，垂直可以延伸。所以说好的模块给我尽量细化一点吧”，“话说，好像没有什么功能是不需要工作量的，那没说就不做了吧，如果我拿这个‘标配’能活到第二期，下次再需要你们做的话，可能就不能三天就签合同了。我看得每一个按钮去对功能了。我觉得，我们对‘标配’这俩字的定义不大一样”。此为睿途公司第一次对孙林茂的需求提出工作量大的说法，而孙林茂则对“标配”感到担忧。随后双方还语音和微信视频通话。当时孙林茂坐飞机出行了，要一个月后回来。2017年7月14日上午6：35，孙林茂问“余额提现”规则，睿途公司刘英答“在讨论会员等级的时候，定下来：充值的钱可以提现，提现都有周期，会有3-5天的资金沉垫时间。会员等级根据充值金额和消费金额设置权重来划分等级。”孙林茂自问自答“分成可提现不可提现的话，是因为退单的部分没办法辨别属于哪一部分对吧”，又对“评价的内容”补充了需求描述，并提示“其他我说的功能，没有拿出来讨论的都是没有问题的，不是忘了对吧”。2017年7月15日下午5:43，刘翔提示孙林茂“用户端原型图发您邮箱了”。2017年7月16日下午10:49，孙林茂对用户端原型图逐一反馈：“接送机”：是不是可以更详细点，像个人信息，特别是联系方式。航班号之类…是不是需要有个填写的地方，称呼，先生/女士，联系方式，护照号等；“全部路线”：是否需要显示发布时间？有些固定路线是常年用的；“单次接送”：如果订个往返的疑问；出行时间和服务类型：具体含义不清楚；“消息中心”：列表的排列问题，最上面横向排列，可以左右滑动切换的那种，怎么成了竖排；“更多分类”：需要一个自助添加的自定义分类按钮，第三次说了；“机票攻略”：说过不要机票链接；“签证攻略”、“入境注意事项”：可以做成简笔卡通形象来展示流程，而不是文本；“我的钱包”：是否可以加个链接按钮，比如“我要血拼”就链接到商城那里，比如“世界那么大，我要去看看”就链接到出行的首页，比如“就想找个地方待几天”点击链接到民宿那里；“设置”：类似“VIP救援电话”显示文字可以随时改；在该页面，不光有个电话，还得告诉客人什么事情在帮助范围。需要有个说明。图文也是卡通展示；“账户充值”：要有银联；“分享有礼”页面中的“活动规则”：不能乱写，询问“现在都有什么”；个人后台“我的”：提示最后一次聊天要有“个人界面和个人后台”两个东西。“最后怎么解决的来”；“绑定邮箱”：下面要有很粗很宽的“我要赚钱（成为商家）”的按钮，链接到下载商家版的APP商店。2017年7月17日上午7:36，睿途公司刘翔回“上述问题今天会逐一解决，另外商家端的原型也会今天打包发您邮箱”。2017年7月17日上午8:41，孙林茂发文“鉴于我说的很多功能没办法往上加，所以我觉得商城做出来应该达不到我说的效果，用户用着可能也会比较尴尬，所以我准备变换一下模式（应该是加的最后一个比较重要的东西了），把商城从我的主营业务里降级，我就好好做旅游吧，但是合同包括商城了，也就不做删除了，商城做还是要做，但是我不准备拿商城赚钱了，做成会员制的，就当为在我这里做过旅游定制的老客户服务了，商城海淘的东西价格会定得很低，完全可以省出会员费，就卖给老客户，这样他们就不会挑剔我的APP商城板块不好用了”，孙林茂详细叙述其功能后概括为：“增加一个付费会员功能，有了各种权限设置”。要求大家研究下，“要是用很多工时，那其他地方省一下吧，因为聊过两次，我感觉其他地方就算不省，也应该做不成我想要的那么细”。下午1:59，睿途公司刘翔回复孙林茂对傻孩子APP原型修改意见：1.关于消息，因为通过底部按钮跳转的是一级页面，所以用列表形式展示消息分类比较好，而且在聊天页面会有快捷订单的功能，这样排版页面会比较好看一些。2.自定义分类的添加是在后台进行的，前端进行展示。3.“机票攻略”，上次说的是用增值业务来替换，但是关于增值业务的具体展示方式还有待商榷。4.签证等相关说明文档，如果有具体图片就OK。其他页面已经按照需求更改好。下午4:32，孙林茂回复签证的部分要自己可以修改，宋恒冲答“在后台可以修改”。孙林茂还提出美食的页面没有，宋恒冲回“上次跟你说过算新增功能”。下午9:24，孙林茂提出商品分类是不是还要增加一个国别分类。睿途公司未做回复。2017年7月18日，孙林茂发了若干大众点评APP的页面截图，并说明“不需要用户到店，不需要在线买单，不需要购物券，不需要团购。说白了我APP跟这些店没关系，我就是要个页面展示，告诉客人附近有哪些店就可以了，顶多有个点击电话号码自动拨号功能，其他要求就是我能上传图文。图片和介绍。再留个地方后面客户可以评价。对了，要说功能，那就是点击地址显示店铺位置，我觉得就这个算麻烦的吧”，“如果显示地址这个太麻烦，那就让他们自己复制好之后自己开谷歌地图或者苹果地图自己查”，“连预约都是他们自己打电话约，我就是让用我的客人自己能看到周围有啥东西可以吃，不需要实现什么功能，加个评价端口应该不难吧”，要求宋恒冲评估“这个美食部分需要多少工时”。2017年7月20日，孙林茂再次提出要宋恒冲评估美食页面的工时，不需要在线下单那些功能，只要图文展示。随后，孙林茂对商家端的原型发文“完了，我发现一个很重大的问题，就是为什么讨论的选择车型的那一些，一直没有出现，这样做出来，这个APP是没有办法订车的”，并描述了接送机需求。随后对刘翔的回复产生质疑，认为“消息的中心”理由不成立，“是否是因为技术原因才一次次的坚持这样子说服我？”“机票”页面不符合要求。“攻略详情”页面参考小红书或者马蜂窝，下面是需要有评论的。“我的”页面之前提出的问题并没有解决。“余额提现”页面的“全部提现”四个字去掉，到账需要五个工作日。“我的收藏”页面的收藏的第二个不是司导，应该是路线或者攻略。会员制的问题，要有一个交费升级会员的地方。美食的图文页面的店铺列表进去后，每家店铺下面有评价列表。睿途公司刘翔答“人数和车型选择会加到页面里面去，消息那块会改回原来的样子，机票那个删除掉关于替代的增值服务有待进一步确认，个人页面会新做一个别人点击的页面。”“提现和收藏会改成你说的。”刘翔提出，会员制的问题待进一步商榷，因为涉及改变逻辑，而且是核心逻辑，整个商城体系不一样的了。孙林茂强调“原来那样子，宋总说的标配里面，我想要的东西，很多都没有了，整个商城体验会变得不尽人意，所以我就想做成会员制了”，刘翔建议孙林茂和宋恒冲沟通这个问题。2017年7月21日，孙林茂提出要将涉及机票的内容省去，换个美食界面。睿途未做答复。上午8:03，孙林茂回复：商家端基本可以，主要能实现那些功能就好了。下午4:12，刘翔回复：修改过的原型图已经发送到邮箱。2017年7月22日上午8:57，孙林茂再次提出要将机票页面换成美食页面。宋恒冲回了一段语音。后孙林茂回复：让其评估一下差多少，并提出要与宋恒冲商量商城会员制的事项,宋恒冲语音回复。后孙林茂获知两种地图调用方式的成本和工作量，孙林茂继续对美食页面的需求描述。2017年7月23日上午6：47，宋恒冲回复：22日在群中讨论美食部分的调用第三方地图应用和内置集成SDK开发包的问题，建议“还是使用调用地图的方式”。2017年7月24日上午7：44，孙林茂接受宋恒冲的建议，问需要的工时。下午4：50，刘翔发：美食功能模块页面压缩包，因孙林茂打不开再发邮箱。2017年7月24日下午9:28，孙林茂质疑“快捷订单”页面的逻辑问题，提出“这个快捷订单功能是客服和司导用的，客人没有这个快捷订单这个功能”，并描述客人申请定制服务的流程：“1客人申请定制服务。2跟客服聊天，详情内容咨询，谈妥。3客服用快捷订单把第二步聊天内容转化成订单”；“我的”页面“绑定邮箱”缺个“我要赚钱”的按钮及相应功能描述；“余额提现”要改成“5个工作日到账，下面还有个24小时到账”；“美食”页面中“促销，套餐，订座”功能“全都不需要”，“只需要地图和评价的功能”，“排序只要按照距离来排”。下午10:38，刘翔回“其他任何问题直接说就好，合理范围内的改动一定最短时间里完成”。孙林茂提示“客户端那么多细节，后台逻辑你们要捋清楚”，刘翔回“肯定的，后台的原型也差不多了，最晚周三的时候会邮件发你让你过目一遍的”。（注：周三为7月26日）2017年7月25日下午1：54，刘翔发：原型图部分截图，孙林茂回：图没啥问题了，标签的名字大多都需要改。刘翔回：“文字都可以改”，“最好能先出一个标准的文档，第一版上线的时候用户看到能明白意思并且方便使用”，文档“对前端还是有一定影响的”，希望孙林茂“先写一份文档我这边该你改掉，因为原型这边没问题了，接下来就要让UI出图了，之后就开始研发了”。刘翔建议要改内容的提示方式，例如“我的---个人中心”，即把“我的”这个模块的名称改为“个人中心”。2017年7月26日下午7：39，刘翔告知孙林茂“后台的原型明天一早到公司就发您邮箱，今天出了点意外状况，多多包涵一下”。2017年7月28日上午11：07，孙林茂发：打开邮件后的乱码截图。宋恒冲回“管理后台的原型图，需要用电脑查看的”等。孙林茂回“我这几天在大阪，我的30晚上才能回东京”。2017年8月2日上午7：12，孙林茂问进度，宋恒冲回“在搭建技术框架了”，希望孙林茂对管理后台原型图“抓紧给修正下细节问题”。当晚11:18，孙林茂表示“刚回家，打开电脑，后台这个厉害了，我感觉不当面谈，完全无法沟通”，“很多名词我都不知道后面链接的什么东西，所以完全没法反馈”，孙林茂准备8月14日回国内。2017年8月5日上午9：05，孙林茂提出“我刚想起来，客户端的原型图里一直都没有看到客户选择车型的一块啊，还有UI的图一直没有发给我”。刘翔回“原则车型那个加了，UI正在做，框架已经在搭了，具体细节等效果图出来你那边给个确定的方案就OK了”。2017年8月15日下午5：55，孙林茂发“大家好，明天我中午11点出发”，“到你们公司估计1点左右”。2017年8月16日上午11：28，睿途公司刘英邀请丁岩岩入群，丁岩岩自我介绍“负责项目后台的原型，下午和您对接下项目需求”。孙林茂问“原型换人了吗，不是刘翔了吗”，丁岩岩解释“今天刘翔请假了。”孙林茂知道刘翔上午搬家，丁岩岩随后告知还没搬完。下午4:23，睿途公司潘文丽邀请陈浩东入群。当天下午，孙林茂在睿途公司面谈管理后台原型。2017年8月17日下午1：50，孙林茂要丁岩岩“昨日给你写的那个流程图拍照发给我一下”，丁岩岩发了。2017年8月18日上午8：27，宋恒冲修改群名为“傻孩子跨境游项目沟通群”，问孙林茂“老乡，今天几点到？”上午9：58，孙林茂回“刚上高速，大约十一点半到”。上午11:27，丁岩岩发了9张流程图。下午2：18，宋恒冲发了链接（https//www.juhe.cn/docs/api/id/43）。当晚孙林茂发了若干页面截图。2017年8月19日下午9：18，孙林茂问丁岩岩进度，“剩余的流程图做完了吗，5号左右要测试啊”，并自问“我要做的是那些规则，文档，编辑的东西对吧”，并提示“到什么时候你们要告诉我去申请接入支付宝微信之类的，还有短信验证码什么的”。宋恒冲回“周一给你个表格”。（注：周一为8月21日）2017年8月21日下午1:43，丁岩岩发：傻孩子流程图jpg格式的压缩包。2017年8月24日下午12:02，宋恒冲发：两个链接。当天下午2：03，孙林茂发：若干页面截图。下午7：33，丁岩岩回：“Axure看原型图，业务流程visio”。2017年8月25日下午9:22，孙林茂提出“好像接送机包车那里都缺了个选项，行李数”并需求描述。2017年8月26日下午2:54，孙林茂问“华南，华东，华北，放在哪里？”“还有UI何时给我看”。宋恒冲回“华东是上海，华南是广州，你看一下你的客户那边最多就放哪”。关于UI，刘翔表示“正在收尾”。孙林茂要求“9月20号要把车的部分上线，这个不能耽误了，剩下的在10月20之前，这个最底线了”。2017年8月28日上午10:10，刘翔提示效果图“已发送”，孙林茂回“飞机上，信号不好，马上起飞，落地再看吧”。2017年8月29日上午9：11，潘文丽问孙林茂“效果图确认的怎么样了”，孙林茂回“还没看完”并复“除了那个订车的地方，和发布路线那个地方需要增加行李数的选项”，“分享到朋友圈的链接，是不是哪里应该有个东西引导大家下载注册啊”。潘文丽建议“有问题及时说出来，标个号，123…，今天一定要把效果图确认掉啊”。孙林茂回“一定”，并问“是不是该让我们负责做设计的跟你们UI对接一下？图片规格尺寸什么的”，宋恒冲作了回应。下午2：30，潘文丽问孙林茂核对效果图的进度，孙林茂回：1“司导端”订单详情，“在每个订单下面都有个费用说明和改退补偿”，要有文档说明的空间。刘翔回：这个说明需要孙林茂给文档；2“提现功能”，收款和提现渠道不统一；3“订单类型不符”，没有“确认完成订单”，“有一方没评价就在待评价里面，这样吧，司导没有待付款的订单，把待付款去掉，换成待评价”。该界面订单类型的顺序为“进行中、待评价、已完成，全部订单”，并作需求描述；4“发布房源”中内容不符，“房源名称，出来个线路价格”等等。孙林茂再次提示“20号第一期第一版上线，加油哦”。刘翔问“订单状态又改”，宋恒冲表示“状态不好修改了，今天上午，为了你的这个状态已经调整了一次数据库了”，孙林茂回“不是状态改，是归属的区域改，一个栏目里面有三种订单，不觉得乱吗，而且，第三种本来还出来个什么确认按钮？本来就没有的吧”。孙林茂继续指出“商家合作”等问题。刘翔回“订单状态当时我们面对面确认的，进行中包含待评价和待确认”。孙林茂回“那进行中那里也不能出来三类订单啊”，孙林茂认可“司导那里不应该有待付款”是“当时没考虑到，只是说跟出境游一样，但是我的模式跟出境游不一样”。双方争论当初需求描述是否明确以及对应逻辑，孙林茂提出修改意见并同意改状态“是最后一次”。下午4:37，孙林茂问民宿模块中是否“可以链接到房东聊天界面”，质疑“订单显示”。后发现“不是用最新版本改的”，“我以为说一个就可以了，这得我每个页面说”，又提了若干修改意见。下午5：15，孙林茂发“好像看完了”，“就那个状态归类那个要辛苦一下了，剩下的细节。先这样，我公司过几天会进来一个UI，到时候我们自己可以改，现在第一版这样可以了”。下午5:52，刘翔回“为了尽快上线，这个功能咱放二期吧，我第一次听到这个需求啊”（注：指粉丝列表），孙林茂同意后“刚又发现个小问题”，“我的钱包”要“单独突出一下”。当天，陈浩东邀请“Alex”入群。2017年8月30日上午9：47，睿途公司潘文丽问进度，睿途公司陈浩东回“修改好了”。上午10：52，孙林茂提出一些修改意见。宋恒冲问“相关的第三方账号在申请了吗”，孙林茂回“在申请了，都在等审核”。下午1：34，孙林茂提“签证，美食就只有一个页面，这个要跟车的部分一起上哈”。下午4:49，陈浩东发出“傻孩子效果图8-30”压缩包。下午6:06，孙林茂对部分“上下位置”调换、差错、银联功能、支付和提取不对称以及关于“分享有礼”，“我刚想到，我怎么知道他有没有分享”等问题及需求描述。下午6:35，Alex发出“司导端页面修改好了”并发送“订单详情”和“我的订单”的页面截图。孙林茂回了修改意见。下午6:48，陈浩东发送5张页面截图，下午6：49，Alex发了新的截图。孙林茂回了截图“本来这个样子，这个布局就挺好看的，你就在名字旁边加个会员符号就行了，一改连布局也改了”，“航班号不能当标题用啊”。2017年8月31日上午10:21，陈浩东又发送页面截图，孙林茂回“可以的”，只是嫌“绑定邮箱”位置“放在这里太突兀了，或者放到个人资料里去”。对刘翔提了两个问题：一是“分享有礼”的确认，二是VIP紧急电话要跟会员等级挂钩。刘翔回“分享注册的时候是要填邀请码的，电话那个正在做。”关于用户端、商家端区分，孙林茂建议“参考皇包车和智联招聘”，“名字都叫傻孩子”。孙林茂要求“做完车，抓紧先做商城，再做民宿”。2017年9月2日上午10:54，孙林茂问“司导关闭按钮在哪里”，刘翔与孙林茂交流该问题及需求描述，孙林茂予以解释并称“咱们讨论过”。2017年9月5日下午6：01，孙林茂问进度，潘文丽回“都在忙呢”。2017年9月8日上午9:39，孙林茂指刘翔“那些文档，我13号回国后给你吧”。刘翔回“文档可以晚一点，那个第三方的配置资源你这边尽快啊，对开发有很大影响的”。上午10:57，刘翔让孙林茂选logo，孙林茂回“我让我公司的人设计了，最晚啥时候给你”。下午6:59，刘翔发孙林茂给的logo“是用这两个吧”。9月11日上午11：21，孙林茂答“是的”。2017年9月11日下午1：46，刘翔问孙林茂“修改订单时间这个功能”涉及范围。孙林茂答“其他上午开始的都需要，接送机也需要，特别送机需要”并作需求描述。2017年9月12日上午11：21，孙林茂对申请苹果开发者账号注册时所用与域名相同的公司邮箱用户名为“wanghui”有异议，认为“你们的对接人是王辉，但是你们的甲方是上海樱蓝”。2017年9月14日下午1：37，孙林茂问“商家发布的商品，和房东发布的民宿也都要审核的吧”，刘翔答“房源是审核的，商品没有”。孙林茂要求都审核，“否则我平台可能被害死”。孙林茂问进度“什么时候可以接手？现在到什么状态”。下午6：27，刘翔答“正在加班加点的赶工呢”。2017年9月17日下午1：37，孙林茂发：图文“提现（暂不可用）”，要求“提现按钮功能做好后，能不能给我个开关，初始为灰色，暂时不可用”。宋恒冲回“程序员在加班你的项目，文丽在监工”。随后孙林茂提起“好像说让我回来考虑下会员权利，现在好像只有会员等级，但是会员高低完全没用”。（注：系重复提）宋恒冲回“等周一我问一下，刘翔具体是什么情况”。2017年9月18日上午8：49，刘翔回复会员等级权利：“具体的方案是您那边给出文档说明然后我们来予以实现，另外，商城那部分是用优惠券取代了会员权利”。孙林茂回“等级名称给你们了吧，三个vip可以打救援电话。还有，客户端，提现功能照常做，但是给我后台一个开关按钮吧，打开状态可以提现，关闭状态，提现按钮直接不显示吧”（注：灰色改为不显示）孙林茂就会员升级部分“之前我们说过的，会员等级升降除了根据消费自动升降还可以手动的”，“这样再把提现按钮做成可开关，这样我就能组合出N种会员玩法了”。2017年9月21日下午5：05，孙林茂问了刘翔电话，电话沟通。2017年9月23日上午9：47，孙林茂问进度，“还需要多久上线”。宋恒冲回“支付还没申请好，微信和支付宝都没弄好”。后孙林茂知道原因：“只是现在绑定对公账户，要等我周一回去换成一般户绑定”。宋恒冲回“这边，开发都在对应做联调测试和对应解测试出来的bug”。（注：指包车模块）孙林茂提示“签证。美食页面一起的吧”，宋恒冲答“这几个，在你们做用户测试的时候添加上，你正式上线的时候可以跟得上”，对于正式上线时间，宋恒冲表示“我这边给到你那边后，你们填充下数据，跑跑流程觉得没问题就可以上线了”。宋恒冲提示“另外有些页面的图你那边也可以做了”。2017年9月25日下午3：26，宋恒冲问“傻孩子项目的版权信息署名”。当时孙林茂疑问“有些页面的图是哪些？”随后约明天见面谈。9月26日下午2：44，孙林茂发：6张皇包车APP的页面截图。2017年9月28日上午9：27，刘翔问孙林茂“上次我们说的接送机、包车游、单次接送这些服务产品的模板什么时候给我们”，孙林茂回“这个模板不就是个页面吗？”“不用做成固定的，就是调用固定线路列表里面的那个页面，得我能自己填”并作需求描述。上午10：58，刘翔回“每种产品需要的信息不一样”，要孙林茂“把每种订单要填写哪些内容”告诉他。孙林茂表示“我们在申请著作权的事，你们要提供60页源代码给我”，同时建议“你们在测试，现在可以发包给我，我们也同时测试”。下午12：11，孙林茂继续图文解释需求描述时“发现一个问题，产品列表里面没有这个东西，只有定好的线路”，（指：缺包车和接送机的订单）。2017年9月29日下午1：25，孙林茂问进度，要测试包。宋恒冲答“今天还不行，我们还在调整昨天你修改的逻辑”。孙林茂吐槽“我要提前什么时候准备什么东西？不能一次只办一件事，到了跟前又得等几个工作日这样”。宋恒冲回了语音。2017年10月1日上午11：12，孙林茂发“冯总说12号给我个流程打通的版本。我自己测试。问一下我需要准备什么东西测试”，“12号的版本是安卓和ios都有对吧”。宋恒冲答“手机的话，之前签字的规格书里面有的，先测android”。宋恒冲回：安卓测试好了，“ios我们这边主要测，同步提交到AppStore，两个版本的功能是一样的”。下午11:23，孙林茂问刘翔要修改后“客服甩到司导端的订单页面”，“想知道做成什么样子了”，10月5日前睿途公司未回应该要求。2017年10月6日下午1：09，孙林茂又问“要准备什么东西来测试”。宋恒冲回：安卓手机，“你那边有一份规格说明书，里面有android手机的型号”。因为换了一个UI设计，孙林茂提出9号或者10号带人去睿途公司交接一下。2017年10月10日上午11：12，孙林茂问：图片大小的确定方式。之后，宋恒冲回“先把流程都调好，最后微调UI”。10月10日下午3：14，孙林茂对民宿部分“先马克”。2017年10月11日下午3：15，孙林茂表示自己找了个UI，“想做我们自己的风格”，问“除了按钮功能，整个页面是不是都可以自己发挥设计”。宋恒冲答“不是，这个后期可以微调，框架性的结构不能自己发挥”，“可以微调，布局不能变了”，宋恒冲解释“微调”：“比如按钮的形状位置颜色等”。冯仲伟解释按照孙林茂对UI的设想，“需要额外核算工时”，“需要前端从新开发”，“不是换图片，需要切图，写JS，写到程序里面”。孙林茂对冯仲伟“额外核算工时”感冒：“对的时候，只跟我谈功能，每次我说排放位置，就说后面可以改，这叫可以改”，“举个例子，你们看用车部分，需要客人填写名字联系方式那几个选项，对功能的时候，就在下面加了那几个选项，然后做出来UI就那样放着，连大小都没改，这是对功能的时候产品的人随便填上去的。你们不给我改，还不让我改”。潘文丽回孙林茂“你把要改的地方提出来，最好用word做个列表”，“影响到技术二次工作的又不影响平台使用的建议一期暂时不动”。孙林茂回潘文丽“这个不是功能，一条一条的列，这是设计”。冯仲伟表示“如果你们UI了解技术，她会知道工作量的”。冯仲伟承诺10月12号最早傍晚6点，最晚晚上12点把测试版本给到孙林茂。2017年10月12日，下午10:45，冯仲伟发：用户端和商家端的链接和登陆账号、密码。2017年10月13日上午9:36，冯仲伟问孙林茂：是否看过版本了，并表示“今天研发部会继续完善，开发别的模块功能，安装包也会不断推出新版的”。上午9:43，孙林茂反馈：商家端注册不了。上午10:32，冯仲伟重新发送了最新版，并表示“目前是内测版，不属于运营版，小bug肯定会有，页面优化的工作，等功能全部完成后才能做”。测试中上午10：59，孙林茂问“经常闪崩,这个怎么描述给你们”。冯仲伟问“点击哪个按键？”孙林茂发了张图，“先评估一下这种改动需要的工作量，就是字体大小，方块改成椭圆，图标大小改了一下”。冯仲伟争执了下，最后回“刚刚问了一下，安卓工程师，需要半天时间，从新写页面；IOS也需要半天”。孙林茂对出行页面不满意。上午11:22，孙林茂质疑“出行页面”的样子，冯仲伟回“出行模块还没有做；这次新版是[包车定制]”。上午11：32，孙林茂邀请姚月鹏加入群，孙林茂介绍：姚月鹏负责测试。姚月鹏要求“账号中加入虚拟金额进行测试，或者告诉我在后台如何添加金额”，随后姚月鹏提供了三个测试账户的手机号（131××××7410、150××××5396、187××××5727）。后姚月鹏将测试商家端和客户端时候存在的问题做成了word文档发送至沟通群。下午12：51，姚月鹏询问是否有专门的客服软件，随后安装了客服工作台。宋恒冲给出账号密码后，姚月鹏发“我这里账号还是没钱，现在在哪里确定订单？分配订单，在这个客服软件中无法操作，无法分配订单”。宋恒冲回“点开，会提示你登陆系统，在系统里面分配，在列表里有分配订单”。10月13日下午2：05，姚月鹏反馈：“无法添加新的司导分配订单”，“下单时无法选择车型”，“私人定制也完全不能用啊”、“任何一个客户端的部奏完成之后都没有任何反馈和提示”等等测试问题。2017年10月14日下午1：32，孙林茂问进度。2017年10月16日上午11:31，姚月鹏发：加图文的客户端app测试文档，下午1：17发：商家端app测试文档。2017年10月17日下午6：03，孙林茂问动静，潘文丽回：“都在工作的，群里面反馈的问题技术在改，然后测试在测回改，我们内部沟通是通过公司的钉钉和禅道，所以这个群里暂时没有交流”。2017年10月19日上午11：46，孙林茂问进度，“两天没有反馈吗？今天19号了”。下午12：32，冯仲伟回“下午发布新版本”，下午5:55“雨寒”邀请“招财进宝”入群。2017年10月20日下午8:17，冯仲伟发出更新链接。孙林茂认为“这怎么不要不给？”“说好昨天，我们今天还能测一下，今天周末，一拖又是3天”。冯仲伟解释“昨天还有bug修改完”，“下周开发其他2个模块，和页面优化”。2017年10月23日，“花开半夏”（白雪）加入群。上午10:19，姚月鹏反馈“问题基本都没有解决”，“只是加了一页，整体上次提出的问题，基本没有变化”，“可能你们正在修改，现在接机，送机，按天包车游，点击暂时无法显示”。冯仲伟回“接机，送机，按天包车游，点击暂时无法显示，自己添加资料”。上午10：48，姚月鹏问“在哪里添加，这个后台系统没有任何提示，添加的部分”。睿途公司“雨寒”反馈“包车——产品列表”。上午11:36，姚月鹏发现“很大一个问题是，包车线路、司导，接送机或其他一些服务没有按国家划分，在城市越来越多之后，客户没有办法按照所需的城市找到相应的服务，所有的服务都堆在一起，每一个服务没有独特的属性，后台这边可以我们人工自己来找相应城市的订单，进行推送反馈，而客户那边看到的是一大堆全球不同服务堆在一起，没有任何划分，他们无法从中找到自己想去的目的地城市的服务，如同点开飞猪旅行第一项肯定是选择目的地出行地点，从而在其子页面找到自己需要的服务，之前在word文档中说的问题，就是这样还是没有变化”，“后台系统也是一样，就算没有分类，但是提示系统是很重要的。”2.白雪为睿途公司产品总监时期的微信记录2017年10月23日上午10：30，“花开半夏”（白雪）通过扫冯仲伟分享的二维码入群。2017年10月25日上午10:41，姚月鹏表示“客户端无法登陆，所有账号显示登陆超时，账号已在其他地方登陆”。白雪表示“应该在调试接口”。下午8:00，姚月鹏建议“所有的沟通消息，请发入群中即使沟通，明天word文档也会在群中进行发送，沟通最新进展。”白雪要求“为了完善沟通机制并且保障双方利益，重要决议事项将以双方邮件回复为依据”。2017年10月26日至11月2日前，双方就出行模块筛选城市的需求描述、功能优化和新增功能的分歧、确认需求的途径、已经明确的需求重复描述的问题、车辆与车型逻辑、是否理解错误后纠正方案还是新增功能、确认需求后开发还是先优化功能、重新整理需求文档+原型以及效果图以及必须确认再开发等等问题，产生争执、沟通与交流。2017年11月2日下午1：09，白雪@樱蓝公司姚月鹏，发：“稍侯发包，不确认是解决文档中所有问题的，不包括未邮件确认的新功能与需求变更。”“如之前讨论，总要事项将均以邮件为主。”孙林茂回“群里发的信息同样是白纸黑字。”双方为微信用于沟通、邮件用于确认结论的区分发生争执。后孙林茂问“ios端我从来没见过，啥时候给我看下”，“我客人大多都是用苹果的”。白雪答“ios端只完成了部分功能，目前集中在安卓端。”2017年11月3日下午7：44，孙林茂“我要20号我这次走之前上架。”白雪答“对于是否安排后续工作稍后我会公司内部沟通后再给您最终消息，对于需求，之后我会重新更新需求概述文档后需要您确认其内容，再按照相关其做出设计工作”，孙林茂回“ios你们现在还没有做出来，就照表格里你整理出来的东西做就好了”，白雪答“确认需求后我会给出具体的计划，不过坦白讲20号风险比较高。”孙林茂理解“你说20号，风险高，那就是百分百搞不定”，“上次9月13-10月13我就想那个时候能上架，拖了一个月，这次还是搞不定？”“你们知道我所有的需求了，先赶工ios吧”。2017年11月6日上午8：39，白雪@孙林茂，就其未理解的司导订单分配逻辑问题问孙林茂，双方就是否分地区、是否增加“地区筛选”、客服人工分配还是系统自动筛选的逻辑，以及实现方式交流。孙林茂回“不分就不分吧，就混在一起行了，后面我自己弄，筛选就筛选吧，我要抓紧上线”。白雪答“关于订单的分地区，稍候我梳理一下”，“现在大多数订单的出发地目的地应该是手写的，是没办法自动筛选出地区来，而且具体是按照出发地还是目的地拆分订单也是需要确认的”。孙林茂悟道“如果这样岂不是手动也没办法筛选？”孙林茂发：两段语音。白雪答“所以六大产品，可能地区的筛选逻辑是不同的。”白雪梳理地区筛选逻辑后的交孙林茂确认，孙林茂确认“OK”，但对“第三条，没看懂”，孙林茂指私人定制，“我跟你们每个人都说过，一直没做出来。我们公司不做大团，就做私人定制旅游，如果按照你们现在做的，就是说我们私人定制这个功能按钮基本上是废的。说点跟你们有关的，签字确认原型图那天，你们原型图还差好多没给我做完，当天丁岩岩搬着电脑现给我改的，你们说，我不签字不敢开发，我就在你们没有完成的情况下，签字了，当天提出了很多问题，说好的照着新的做。你们也答应了，但是一直没改对，每一次都理解不透。现在直接不承认了。那就算了，这个我认栽，我自己再找人改好了。你们觉得三个图上面没有的，就不用做好了，现在要求速度，请你们赶工交付，谢谢。剩下的问题我自己处理。”2017年11月7日上午11:58,孙林茂发了份表格“傻孩子需求确认v3-20171102.xlsx”并说明“这是文丽发给我的，就像我昨天说的，没有的就不用做。”白雪回“现在制作原型与写需求说明文档，预计今天下午可以给出，计划会一并给出，视需求确认时间”。孙林茂回“还视需求？需求都不加了”。11月7日下午11：08，白雪提示已发出“需求规格说明书以及计划”邮件。2017年11月8日下午2：22，姚月鹏反馈“在发来的word文档中发现了如下问题的缺失，已整理成word文档形式”并发“问题未记录.docx”文档。11月9日下午12：59，姚月鹏提示“所需文案资料全部收到一起了，除车辆的部分在Excel中发过去”并发“傻孩子资料提供-20171103.docx”文档、“车型维护列表.xlsx”文档。2017年11月10日下午3：37，白雪回“确认回复文档请邮件回复，谢谢”。双方就“需求规格说明书”应当包含的需求范围发生争执，樱蓝公司认为缺失了“后台分配不同账号”、“后台车型维护”等内容，睿途公司认为属于“新需求与需求变更，孙总确认说明不做，所以不会包括在需求规格说明书中，需求规格说明书说明的是我们要交付的内容”。2017年11月14日上午11：06，姚月鹏发“关于车辆维护问题，现车辆级别，现仅为舒适豪华两个级别。”11月20日下午4：47，孙林茂问进度。2017年11月22日上午11：50，丁岩岩提示“优惠券规则确认已经邮件了，请查看确认下优惠券规则。”白雪提示“民宿原型的邮件昨天已经发出了，有问题请及时反馈”。姚月鹏予以回应。2017年11月23日上午10：09，孙林茂问“车的部分”进度，“能打包一个看看不”。白雪答“暂时不能，请参考当时需求文档一并发送的计划表，目前是测试阶段，版本更迭比较快，不太适合打包看”。下午2：38，白雪问：民宿部分功能的含义，姚月鹏予以了解释。下午，姚月鹏疑问白雪关于民宿原型的邮件，白雪解释针对描述的问题“在每一项上增加了备注说明，类似于上图中增加的说明”的反馈。姚月鹏回“大部分的问题，你理解的都没问题，我在邮件中回复你了，上面有写待定，或需要讨论的问题，稍后给你回复，其他的就可以按照这个修改了。”11月24日，姚月鹏回复了民宿部分“关于地图展示的问题”的需求描述，孙林茂补充了“签证页，美食”的需求描述。11月27日上午10：11，白雪提示“用户端民宿原型的调整内容已经整理邮件了，稍候会更新原型图，关于商家端和管理平台的原型也请尽快帮忙确认”。上午11：03，姚月鹏提示“邮件已确认回复”。稍后，白雪回“出行模块的原型忘记包括在里面了，稍候确认一起更新给你们。”随后，姚月鹏问“出行模块现在开始制作了么”，白雪回“出行除了美食模块都是可以使用的，美食计划安排在民宿开发周期内。”2017年11月28日下午4：20，白雪提示“用户端和商家端调整的原型已经重新邮件发送了”。因后台部分很难看清，睿途公司丁岩岩于2017年11月30日上午9：23给了本地文档。11月30日上午9：51，姚月鹏问：发布房源的“可预订日期是怎么设置的”，交流后要求“换成不可选日期，未来六个月内不可预订日期，并且这个不可预订日期可以随时调整”。丁岩岩发“分享有礼获得优惠券的规则”“不能按照每个用户注册时间来判断30天有效”，孙林茂要求“领取之日算”。白雪回“目前优惠券逻辑就是这样的，如果要修改，需要修改整个优惠券体系及发放逻辑，至少需要5天”，孙林茂要约冯仲伟、宋恒冲下午面谈。3.王明星为睿途公司产品总监时期的微信记录2017年12月4日下午1：30，白雪邀请王明星（茶留余香）加入群。12月5日、12月6日，双方继续交流、确定一些细节问题。12月6日上午11：45，王明星@孙林茂@姚月鹏：“住房政策这块当初我们如此设计是由于房屋是个人的，每个人对房屋的入住要求更具个性化，我们维护模板信息并不是很利于商家去维护个人的住房政策。有些时候可能几个字或者几十字可以说明的，提供模板后用户去筛选保留模板信息反而会浪费更多的时间。”此为王明星首次群内信息。2017年12月6日下午4：14，姚月鹏提示白雪“民宿部分原型图已确认”。12月7日下午11：38，王明星发IOS用户端“傻孩子客户端.ipa”安装包（49.87M）。2017年12月11日下午4：35，王明星提示“发了两封邮件，请看下，周二下班前给下回复吧”，姚月鹏回“需要的东西很多，暂时无法在周二前回复。”12月12日下午3：11姚月鹏问“包车出行的部分”进度，王明星答“包车模块：安卓端、IOS用户端部分已打包发给你们测试，IOS商家端现在在收尾内测发现的一部分bug；出行部分：原型已经确认，效果图设计中；民宿模块：原型已经确认，效果图设计中；商城模块：原型设计中，商家后台选择在移动端还是PC端开发还需要你们确认（昨天发给你了邮件）”。2017年12月14日上午9：47，姚月鹏索要“安卓端、IOS端的测试用例”，要“根据测试用例来测一下”，认为“IOS端在功能层面都无法实现，全是bug,需要修复时间表”。王明星拒绝提供测试用例，要对方“整理反馈出相应的bug，我们会根据反馈的问题对比当初的需求进行评估。”姚月鹏质疑对方“是否有进行过系统测试”，“在所有测试人员的测试当中应该解决以下问题：1界面适配问题，2主体流程应该流畅跑通，3小功能点的逻辑处理，4用户体验的细节处理，在同一个页面中发现了所有的问题类型，测试人员是如何进行测试的，所有发现的下列问题都没有解决，不提供测试用例是如何可以证明你们是测试过的？并且测试用例是常规文件并非机密文件。”姚月鹏继续回了前述“下列问题”所指的具体问题。下午1：55，王明星回“你说的这些问题我刚刚核实了我们在新版本中都已经修复了，新版本今晚会提供”，王明星称其中（配图）“这个bug我们没有重现”。2017年12月19日上午9：29，王明星提示“昨天还有之前发你邮件还请注意查收，涉及三个方面内容：民宿效果图、出行效果图、商城商家后台开发事宜”。上午10：13，姚月鹏（配图）问：民宿订单全部订单页面“1在图中待付款的用户如何能发私聊，2待付款的状态是从那里实现，下订单后没有付款？没有付款的订单无法进行私聊，只有付款后才双方打通进行私聊”；“对比商家端，客户端房东个人资料展示页面不足，房东评价页面缺失”，“另外在商家端上传民宿照片五张太少了，不够展示民宿产品，另点开可展示大图，而不是被剪裁之后的”等等，王明星作了解释。但双方对王明星关于“上传多张照片没问题，但是后期用户体验的问题我不能保障”的信息产生争执，姚月鹏要求对方说明原因。樱蓝公司要求“轮播可以固定长宽比例，但点开需要完整大图”。2017年12月20日上午10：58，王明星问“房东修改房源不可预订日期”的提示处理问题、“物流费用是如何结算”等疑问，12月22日上午10：17，姚月鹏回：要对方“参照原型图流程图”。12月23日下午3：36，孙林茂问王明星“你们天天催我民宿和商城的原型图确认，那包车的部分就这样了吗?”“刚才邮件给你们确认了，功能实现和原先约定工期不变的情况下，同意改成pc端。”王明星回：包车的部分“有问题提出来，我们一起看的，现在没有得到你们关于这块的反馈呢”。孙林茂回：“我晕，说让你们提供测试记录，你们说没有，现在几乎没有一个功能是可以一次走通的，而且每次出bug和闪退的地方都不一样，你让我们做你们的测试工作吗？”姚月鹏补充“安卓还能凑活一下，ios完全用不了，一直bug和闪退”。王明星强调“我们肯定是做过测试的，而且流程肯定也是通的，否则怎么能提交测试，如果真的有什么问题请反馈具体的问题，让我们知道具体问题去解决。”孙林茂、姚月鹏发：bug和闪退的截图、视频。2017年12月25日上午9：40，王明星问“你们的技术什么时候可以介入呢，我们现在要对民宿、出行进行排期了”。孙林茂要去日本，回“回来后再说，你们先排”。12月26日下午1：41，孙林茂要“最新的客户端、商家端，安卓，ios都要，还有后台的，我们认真测试一遍”。王明星发了相应链接、账号、密码。王明星报进度：“用户端ios的最新版本修复了优惠券显示的相关bug，商家端ios的目前还存在一些bug在修复中”。2017年12月29日上午11：45，王明星问姚月鹏“商城模块的内容原型可以确认了吗？”孙林茂回“商城有发过给我吗”，王明星答“发了都是邮件”。2018年1月2日上午9：43，王明星提示“商城的设计图上周已经提交了”，另问“开发人员进场”时间，并“让你们开发人员帮忙申请一下谷歌的开发者账号”，孙林茂答“好”。1月5日上午9：44，王明星提示“商城用户端的效果图已经邮箱发出，还请本周完成确认”，并提醒“百度、谷歌的开发者账号还请下周能提供，如果没有这些账号，地图功能不能实现”。姚月鹏答“百度地图开发平台开发者账号王辉已经发过去了，谷歌开发者下周应该能好。”双方沟通商城自营与第三方的区分、客服分配、客户维权等需求描述。1月5日下午7：54，王明星提示“效果图已经更新并邮件”，1月6日下午3：40，姚月鹏问“对话框中的进行的商品链接”处理。王明星答“目前做的，只是简单的对话联系功能。”2018年1月9日上午9：47，姚月鹏发包车部分问题总结：六个包车模块分为三个类似部分，发现46个问题，“这个最新版本的安卓版很多问题是我曾经反应过的，出现的问题并没有真正修改、解决，未达到之前要求的‘通知一览表’功能”。上午10：10，姚月鹏索要“现在进度的版本”，王明星回“民宿部分还在开发中，现在已经完成也只有包车模块，如果现在打包给你，民宿部分也是没有办法试用的”、“目前商家、民宿的是在并行开发”。姚月鹏继续索要“ios版本客户端”，王明星发了“傻孩子客户端（1）ipa”安装包。2018年1月18日上午9：16，姚月鹏索要“修复好bug的ios与安卓版本商家端与客户端最新版本”。王明星回进度：“本周六我们会完成民宿模块用户端的功能，提供内测版本，下周会提供给你们测试的版本，届时包车模块的bug也会在新的版本里面完成修复。如果现在提供新的版本，还会存在部分bug没有修复的情况，还请知悉”。在姚月鹏一再要求下，王明星同意“周六提供”。下午5：44，王明星问姚月鹏民宿模块：“用户下单、房东接单后”订单状态。（三）解除合同的通知2018年1月18日，樱蓝公司申请上海市闵行公证处为孙林茂使用手机下载安装“傻孩子”客户端、相关操作的保全证据公证。当天下午1：39，王明星问姚月鹏“服务器修改密码了吗，我们访问不了了”。2018年1月20日，樱蓝公司快递函发出解除合同通知书，通知称“你公司却严重迟延履行主要债务。在2017年10月12日交付的用户（andriod）终端软件，存有严重质量问题，至今无法使用；而其余两个终端软件至今未交付。你公司严重违约行为，导致我公司的经营计划完全落空，给我公司造成了很大的经济损失”，“希你公司在收到本通知书后的三日内，立即全部返还我公司已支付的合同款等费用，并承担由此产生的各项经济损失及违约金”。睿途公司收悉后，于2018年1月23日回复不同意解除合同，要求继续履行。并回复了两点理由：1.“自签订技术合同以来，双方一直保持着良好的沟通和联系，尤其是对技术合同中的项目需求设计以及开发周期进行了确认。在项目开发过程中，我方按照技术合同的约定积极进行项目的开发研制工作，并且根据贵方对项目需求设计的变更要求进行了相应的调整，但由于贵方的变更要求与最初的需求设计规格差距较大，项目开发周期和交付时间也进行了相应的顺延，上述变更事宜均得到贵方的确认。直至贵方发出《解除合同通知书》前，该项目仍在有序进行，相应的开发工作以及交付时间均得到贵方的确认。目前，该项目已经接近尾声，已处于基本完成阶段，在贵方确认的交付期限内完全可以如期完成交付”。2.“该项目耗费了双方大量的人力、物力和财力，不到迫不得已不要解除。自双方签订技术合同以来，我方始终按照合同约定积极进行项目的开发工作，并始终与对方沟通确认项目的相关事宜，我方的工作均是源于贵方的要求，开发工作、开发周期以及交付时间也均得到贵方的确认，并无违约行为”。一审法院关于双方诉讼主张所依据的要件事实的分析：1.樱蓝公司请求确认双方合同于2018年1月20日解除；睿途公司抗辩不同意解除并反诉请求樱蓝公司支付剩余开发费用。双方诉讼主张涉及《中华人民共和国合同法》（以下简称合同法）第九十四条的法律适用，结合樱蓝公司的事实和理由，具体涉及合同法第九十四条第（三）项：当事人一方迟延履行主要债务，经催告后在合理期限内仍未履行；和第（四）项：当事人一方迟延履行债务或者有其他违约行为致使不能实现合同目的。2.结合樱蓝公司起诉状及2018年1月20日解除合同通知书，概括樱蓝公司所陈述合同解除的事由为：睿途公司严重迟延履行合同义务，经多次催告，截至2018年1月18日仍未完成开发，致使樱蓝公司的经营计划完全落空，分别对应合同法第九十四条第（三）项、第（四）项，由此产生樱蓝公司的第二项、第三项诉讼请求。3.睿途公司的反诉主张以樱蓝公司解除合同事由不成立为基础。睿途公司针对解除合同事由不成立的陈述，主要体现在本诉答辩中，包括：已于2018年2月开发完成，未迟延履行；开发周期迟延的责任在于樱蓝公司，樱蓝公司不断变更和增加设计以及需求确认延迟。根据上述分歧意见，一审法院归纳以下具体争议：对照项目开发周期，睿途公司开发进度是否已经迟延以及迟延的原因。樱蓝公司是否存在变更和增加设计，以及是否存在需求确认迟延。如存在变更和增加设计，以及存在需求确认迟延，对睿途公司软件开发进度的影响。一审法院认为：（一）类似本案项目合同争议的特点涉争合同名为技术服务合同，该案案由计算机软件开发合同纠纷。按照项目类型，本案属于计算机软件定制开发合同。通常类似合同的甲方，该案中为樱蓝公司，一般不具备非常丰富的软件技术相关知识，在合同签署的一刻只能概要描述自己想要达到的目的，而没有办法把实现细节和功能点做专业严谨的描述。按照双方对涉案合同签约过程的一致意见，双方在签约前已经历沟通过程并形成合同附件一“跨境旅游项目报价”。软件开发方，该案中为睿途公司，需要针对甲方的概要描述进行详细需求分析。例如，双方合同约定开发周期有需求设计阶段，合同附件一项目实施周期说明之2约定项目的实施周期需要根据项目调研情况即需求分析/产品设计情况（该部分预20个工作日），需求分析和产品设计工作项目的工作内容包括：“通过与客户沟通详细需求，从而对用户需求进行深化分析，以此描述功能逻辑、功能规则、操作细则，本项产出物：需求规格说明书、UI草图（原型图）、UI高保真效果图”。编写需求规格说明书的目的，如本案中睿途公司提供证据需求规格说明书1.1编写目的所示，有以下目的：1.准确全面定义、阐述涉案项目的业务需求，明确涉案项目的目标和功能。2.为客户的有关业务部门和技术部门提供对系统的统一的文字的理解。为业务部门判断系统是否满足其业务需要提供文字依据，为技术部门监督项目功能提供统一标准。3.在涉案项目之前尽可能周密考虑全部需求及设计要求，减少以后可能的重新设计、重新编码、重新检测等工作。4.为设计项目方案、编制计划进度提供文字依据。5.为对项目的完成进行确认和验证提供基准。因此，作为软件开发方，本案中睿途公司应当在产生的需求规格说明书中与甲方就软件的核心目标、开发范围、业务功能、技术选型等进行详细约定，并经由甲方确认后进行开发。从而，类似本案合同争议中，需求规格说明书是后续所有的开发内容是否变更的依据。类似涉案软件开发项目，判断开发进度的迟延，通常包括以下几个方面：（1）开发方是否按约定要求提供了阶段性产出，即需求规格说明书、原型图、效果图，并向需求方提出明确的确认要求。（2）需求方是否对开发方提出的内容及时反馈和确认。（3）如果有需求变更，提出变更的时间是否会显著影响开发进度。（4）开发方是否有可运行的软件测试或验收版本交付。（二）关于睿途公司证据需求规格说明书的分析与评判类似涉案软件开发项目，通常具有前期需求沟通到报价确定、签约之时存在信息不对称的特点。签约不久的2017年7月13日，樱蓝公司获知该报价标准下“软件产品”的功能需求对应软件开发工作量和产品报价之间的平衡，相应功能需求被界定为“标配”类别。由此，樱蓝公司对软件满意度的期待并不高，正如樱蓝公司孙林茂所表达“如果我拿这个‘标配’能活到第二期，下次再需要你们做的话，可能就不能三天就签合同了”，樱蓝公司要求“说好的模块给我尽量细化”。约定开发范围内的软件功能模块尽量细化，是需求方的主观要求，也属于睿途公司在充分理解需求描述后必须履行的合同义务。本案中，睿途公司以2017年8月24日完成确认的邮件附件“傻孩子文件包”为证据，并标定该证据为“需求规格说明书”（以下简称“8月24日需求规格说明书”），睿途公司据此整理樱蓝公司的需求变更、功能增加。“8月24日需求规格说明书”1.0版本创建于2017年8月17日，状态为草稿。列出客户提供的参考产品包括“皇包车”“小红书”“你来出境游”等。业务流程、系统功能详见邮件附件中业务流程图、原型图。但从8月24日后双方围绕需求描述、原型图、效果图的提出和确认展开的微信群记录显示，樱蓝公司仍在不断描述、重复描述需求，睿途公司不断求证需求描述的含义；也未见明确指向8月24日邮件附件为基准的需求变更、功能增加的意见交流。以睿途公司标注需求规格说明状态为草稿，可见8月24日邮件附件“傻孩子文件包”，在履行过程中的地位，并不像睿途公司在诉讼中主张的那样，既是需求变更的依据又是工期应予顺延的证明。据此，一审法院认为，“8月24日需求规格说明书”仅系根据需求描述产生的阶段性产出物。本案中睿途公司作为开发方，以“8月24日需求规格说明书”为需求变更、功能增加的标准，对需求方符合一般认知常识的需求描述，缺乏详细的理解说明以及功能设计的逻辑，将构成开发方睿途公司的疏漏。（三）关于解除合同通知事由的具体分析1.关于约定的项目实施周期双方2017年7月5日签约后，孙林茂于当日汇付睿途公司预付款即设计款16.5万元，合同约定自合同预付款到账次日起算，完成所有开发工作，交付时间为2017年9月20日。但结合合同包括附件一有关“开发周期与进度说明”以及合同关于交付、验收的条款，本案合同项目约定的开发周期为三个自然月，分三个阶段：第一阶段，项目调研即需求分析和产品设计情况阶段，时间为一个月（预20个工作日）；第二阶段，架构设计和研发阶段，时间一个月，即从项目调研开始二个月可以投入试点运测试，但研发阶段的开始时间以需求确认的邮件时间为准；第三阶段，完成交付阶段，即项目调研开始三个月完成终验交付，开发方完成阶段性工作时，通过邮件发送验收通知，此阶段需求方可以要求功能改动和功能新增。验收分为初验和终验，初验通过后才能进行终验。验收可进行多次，如不合格，乙方应及时加以修改纠正，直到验收合格为止。2.关于项目开发周期与迟延履行主要债务的问题本案中，双方确认签约前存在初步需求描述阶段形成了合同附件项目报价清单，但签约后，孙林茂自2017年7月7日加入微信群，发送信息的核心内容为需求描述，此后孙林茂重复需求描述、解释需求描述的信息交流状态始终存在。从纠纷处理角度，为划分项目实施周期的三阶段，一审法院同意睿途公司以“8月24日需求规格说明书”为研发阶段的开始时间。从研发到测试，双方又对测试时间存有三次预期或者要求：第一次，2017年9月5日左右。根据2017年8月19日群记录，双方预定测试时间为9月5日左右，9月20日车的部分上线；第二次，2017年10月12日。根据2017年10月1日上午11：12群记录，睿途公司将交付流程打通的版本，樱蓝公司将参与测试；第三次，2017年11月20日。2017年11月3日下午7：44，孙林茂“要20号我这次走之前上架”，但被委婉拒绝。白雪回复“确认需求后我会给出具体的计划，不过坦白讲20号风险比较高。”之后，开发周期跨入12月，樱蓝公司准备验收的工作人员实际成了睿途公司的测试员，睿途公司还期待樱蓝公司技术人员的加入。王明星时期的微信记录显示，樱蓝公司多次问进度、索要最新版本测试、索要测试用例，未见睿途公司给出明确的时间。根据2017年12月25日微信群记录，王明星问“你们的技术什么时候可以介入呢，我们现在要对民宿、出行进行排期了”，结合睿途公司反诉状“口头约定在2018年2月交付”可推知，2017年12月之后，睿途公司已不再预测交付日期。综上，一审法院认为，对照项目实施周期三阶段、3个自然月的约定，以2017年8月24日为研发阶段起算时间，至2018年1月20日前，睿途公司尚未交付可运行的软件测试版本。因此，樱蓝公司通知解除合同主张睿途公司严重迟延履行主要债务的事由成立。3.关于严重迟延履行与经营计划落空的问题根据合同约定，使用本软件角色终端：用户（ios、andriod）、商家管理（ios、andriod）、运营管理（PC）。樱蓝公司在解除通知中，确认2017年10月12日睿途公司交付过用户（andriod）终端软件，但存在严重质量问题，无法使用；其余两个终端至今未交付。樱蓝公司系孙林茂为自然人独资设立的有限责任公司。因此，从孙林茂签署企业入驻合同到本案软件项目签约，从樱蓝公司设立到正式入驻办公、雇佣员工的时间节点与本案软件开发项目实施周期的关联度可合理推知，樱蓝公司的设立、开始运营以及进一步的经营活动，均以本案软件开发项目的实施周期和软件顺利交付为背景。睿途公司迟延履行，已经影响到樱蓝公司的经营计划，睿途公司严重迟延履行，不再预测交付时间，必将动摇樱蓝公司的经营计划。据此，一审法院认为，2018年1月20日，樱蓝公司通知解除合同中主张睿途公司的迟延履行债务，致使经营计划落空的事由成立。（四）关于睿途公司的反诉主张的顺延工期的争议睿途公司反诉主张涉及的顺延工期，一是需求确认延期的顺延工期。睿途公司认为合同有效期到2018年7月5日，该合同仍在有效期内，对方有“修改意见未及时反馈”顺延工期的事由；二是需求变更增加的顺延工期。以下分别论述：1.关于需求确认引起的顺延工期争议。睿途公司所指为“8月24日需求规格说明书”。前已述及，从纠纷处理角度为划分项目实施周期的阶段，一审法院同意睿途公司以“8月24日需求规格说明书”为研发阶段的开始时间。但并无证据表明，该时间节点之前睿途公司提出确认至樱蓝公司确认之间，存在足以判断为迟延确认的情形，事实上，睿途公司请求确认的邮件发送时间即为2017年8月24日。而樱蓝公司主张的严重迟延履行主要债务，实际发生在2017年11月20日后，樱蓝公司明确要求最后的上线的时间得不到满足，客观上项目实施周期跨入2017年12月。以上分析，从2017年11月7日孙林茂发“傻孩子需求确认v3-20171102.xlsx”并说明“这是文丽发给我的，就像我昨天说的，没有的就不用做。白雪回复“视需求确认时间”后，孙林茂抱怨“还视需求？需求都不加了”可合理推知。而此前的2017年11月3日，孙林茂要求11月20日上架被委婉拒绝。据此，一审法院认为，在项目实施周期实际已进入2017年12月的情形下，因“8月24日需求规格说明书”的确认，是否应当顺延工期与解除合同通知事由之间，已不具有关联性。2.关于需求变更、增加及相应确认是否迟延对开发进度影响的争议（1）关于樱蓝公司需求变更、增加设计的争议履行过程中，存在樱蓝公司需求变更、增加设计的事实。例如，2017年9月17日孙林茂要求“提现暂不可用”给个“开关”；2017年11月28日姚月鹏要求发布房源的“可预订日期”换成“不可选日期，未来六个月内不可预订日期，并且这个不可预订日期可以随时调整”。睿途公司以“8月24日需求规格说明书”为依据，梳理了首页、全部动态、接机送机等38项功能模块的变更。一审法院认为，对特定需求功能设计要求的优化细化，既是需求方的要求，也是开发方研发设计阶段应尽的义务。38项功能模块的变更中，睿途公司标注为优化细化类别的计23项，以开发方视角，可确定睿途公司在对待用户需求进行深化分析、架构设计和研发中，有未尽合理注意义务之情形。换言之，要求樱蓝公司确认的“8月24日需求规格说明书”系草稿，达不到需求确认细化版本的标准。基于以下理由，一审法院也不认同睿途公司主张的樱蓝公司需求变更、增加设计足以影响开发进度。一是睿途公司并未充分理解樱蓝公司的需求描述。双方确认2017年7月5日签约前已交流沟通产生《委托开发合同附件一》，可以想象签约前孙林茂的需求描述并不充分。2017年7月7日孙林茂加入微信群后，持续发布涉及各功能模块的需求描述，睿途公司有专人记录，有专人与之交流对接。从微信记录看，孙林茂还多次在睿途公司面谈需求。作为需求方，樱蓝公司的描述符合一般认知常识。睿途公司应当针对樱蓝公司的需求描述进行详细的需求分析，形成详细的理解说明以及功能设计的逻辑。睿途公司产品总监的频繁更替客观上进一步延缓了充分理解需求描述的进程。故此，一审法院认为，睿途公司将汇总的38项涉案软件功能模块变更中的多数归入优化细化类别本身，可知睿途公司作为开发方的疏漏。二是睿途公司所指需求确认的时间不具有客观性。睿途公司归类为设计变更、新增项目计14项，从时间看，主要处于睿途公司白雪出任产品总监时期。微信记录显示白雪出任产品总监的主要工作就是恢复以邮件确认需求的规则。白雪于2017年10月23日加入群，10月25日，白雪要求“为了完善沟通机制并且保障双方利益，重要决议事项将以双方邮件回复为依据”。因此，白雪的工作，总体上在于弥补此前睿途公司理解需求描述方面的缺失，并细化、确定为需求分析和产品设计的产出物。即，睿途公司主张需求变更的时间本身不具有客观性，不体现樱蓝公司需求描述及其是否变更的真实时点。以睿途公司主张的变更时间判断，变更时间分布从8月25日至11月之间。其中，接机送机、安田包车游、快速预订、钱包四项变更在8月25日、8月30日、9月8日的群记录中已有涉及；私人订制，在10月13日已反馈为“完全不能用”；民宿模块开发周期在计划中本已靠后，2017年8月31日孙林茂要求进度的先后为“做完车，抓紧先做商城，再做民宿”，即细化方案的确认相应靠后。三是需求变更的判断标准不可靠。睿途公司主张的需求变更，樱蓝公司归纳为：实现某功能的解释、文案变更、位置变更、功能缺失、设计缺陷、合同附件的要求等七种类型。樱蓝公司认为，其中接机送机、安田包车游、快速预订三项变更，出于原设计有功能缺失，缺少中间流程，属于开发方要求变更确认；其中指定司机、司机订单操作、用车订单处理三项变更，分别属于相应模块子项目中的相应功能的解释或描述，属于睿途公司的理解错误；其中司机认证一项变更，所谓增加车险证、缺少游艇驾驶证是文案变更；其中住民宿、民宿订单详情两项变更，属于合同附件的要求，属于睿途公司设计缺失；其中民宿列表、民宿详情、民宿预定三项变更，部分属于变简单了，部分属于功能解释；其中私人订制行程一项变更，部分属于完善页面、部分属于原来用户需要填写的内容，仅“选择城市”一项有区别；其中钱包一项变更，部分属于减少绑定银行卡功能开发，部分属于文案变更、位置变更以及对方技术问题无法实现的调整。不排除睿途公司归入变更增加的项目中，确有樱蓝公司提出的需求变更。一审法院认为，鉴于前述“8月24日需求规格说明书”不具备细化版本的价值，难以确定睿途公司所指需求变更、功能增加是否构成实质上的变更增加。四是睿途公司的履约能力被合理质疑。通常理解，需求变更、增加，以开发周期判断，相关需求变更越往后提出越影响开发进度。本案中，睿途公司泛泛主张了需求变更与工期迟延的关联，并未指明某项具体的需求变更、功能增加如何显著影响了开发进度。而2017年12月后的微信群记录显示，12月14日樱蓝公司索要测试用例并质疑睿途公司是否进行过系统测试；12月20日左右，樱蓝公司仍在质疑睿途公司内测环节的真实性；至12月25日，睿途公司开始期待樱蓝公司技术人员的加入。一审法院认为，双方在项目实施周期跨入12月后的分歧，并非樱蓝公司是否有了需求变更或者功能增加，而是睿途公司的履约能力。据此，一审法院认为，睿途公司抗辩需求变更和增加设计导致开发周期延长符合软件性质及开发合同约定的观点具有一定的合理性，但不足以构成睿途公司严重迟延履行的有效抗辩。（五）关于解除合同后的损失赔偿问题合同因一方当事人违约而解除之后，依据《中华人民共和国合同法》第九十七条，合同解除后，尚未履行的，终止履行；已经履行的，根据履行情况和合同性质，当事人可以要求恢复原状、采取其他补救措施，并有权要求赔偿损失。该案中，睿途公司已经需求分析和研发，并已交付过安卓版用户终端软件，但从软件项目整体判断，对于安卓版用户终端软件的交付，对樱蓝公司没有独立存在的价值，仍应当视为整体未履行。根据《中华人民共和国合同法》第一百一十三条规定，当事人一方不履行合同义务或者履行合同义务不符合约定，给对方造成损失的，损失赔偿额应当相当于因违约所造成的损失，包括合同履行后可以获得的利益，但不得超过违反合同一方订立合同时预见到或者应当预见到的因违反合同可能造成的损失。该案中，樱蓝公司主张其经济损失222018.44元均为直接损失。一审法院认为，其中公证费6030元作为诉讼支出，以及为开发软件支出的网络、通讯、软件服务、服务器等费用47483.94元，两项合计53513.94元作为直接经济损失，樱蓝公司有权要求赔偿。但对于员工公寓租金24648元，明显不属于应当预见到的因违反合同可能造成的损失。关于员工工资92153.5元、公积金3703元和办公场地租赁费用48000元，属于樱蓝公司为经营所必须支出的费用，可归入樱蓝公司投资风险的范畴。虽然樱蓝公司系孙林茂为自然人独资设立的有限公司，孙林茂与睿途公司宋恒冲有老乡情谊，有理由判断睿途公司应当知道樱蓝公司的设立及其经营计划即为涉案跨境游APP项目的运作。但订立涉案软件开发合同之时，要求睿途公司将孙林茂为“傻孩子跨境游APP”项目设立公司的成本预见为软件无法交付可能造成的损失有失公允，一审法院不予支持。综上，一审法院认为，因睿途公司一方迟延履行，经催告后在合理期限内仍未履行，致使樱蓝公司合同目的落空，樱蓝公司有权解除合同。睿途公司除应当返还已付开发费用，还应当赔偿损失。依照《中华人民共和国合同法》第九十四条第（三）项、第（四）项、第九十七条、第一百一十三条之规定，一审法院判决：一、上海樱蓝网络科技有限公司与苏州睿途网络科技有限公司之间2017年7月5日签订的《技术服务合同书》于2018年1月20日解除；二、苏州睿途网络科技有限公司返还上海樱蓝网络科技有限公司已支付合同价款27.5万元，并支付自2018年1月20日起至实际履行之日止按照中国人民银行公布的同期贷款利率计算的利息损失，于判决生效之日起十日内履行；三、苏州睿途网络科技有限公司赔偿上海樱蓝网络科技有限公司经济损失53513.94元，于判决生效之日起十日内履行；四、驳回上海樱蓝网络科技有限公司的其他诉讼请求；五、驳回苏州睿途网络科技有限公司的反诉请求。一审本诉案件受理费10610元，由上海樱蓝网络科技有限公司负担834元，苏州睿途网络科技有限公司负担9776元；反诉案件受理费2713元，由苏州睿途网络科技有限公司负担。一审判决认定的事实有相应证据证实，本院予以确认。本案二审中，睿途公司提供以下证据：1、第三方蒲公英发布平台中关于傻孩子用户端可执行性APP安装包的数据。证明其已经于2018年2月6日完成符合合同约定的软件。2、睿途公司内部记录每个项目开发进度和内容的管理系统，证明樱蓝公司通知解除双方合同关系之时，涉案软件已经开发接近完成。樱蓝公司质证称：证据1形成时间在一审开庭之前，不属于新证据。同时，该证据的真实性无法核实，且只能证明睿途公司在某时间点把开发的代码上传过，但证明不了软件的代码内容。证据2的真实性不予认可，该份记录无法看出具体的开发进度，也显示不出其开发的内容。本院认证意见：睿途公司提交的第三方系统数据记录及其公司内部系统记录，仅能显示某一时间点数据上传的事实，而无法证明具体的软件数据内容，不能达到睿途公司的证明目的，本院对其关联性不予认可。二审另查明，樱蓝公司的委托诉讼代理人潘赟表示对樱蓝公司原委托诉讼代理人文敏在二审中参与诉讼活动的效力及所发表的意见均予以确认。二审争议焦点：1.涉案软件开发合同是否应当解除；2.如果应当解除，一审法院认定法律责任是否适当。本院认为：一、睿途公司未按约定时间完成软件开发义务，涉案合同应当解除根据《中华人民共和国合同法》第九十四条第（三）项、第（四）项的规定，当事人一方迟延履行主要债务，经催告后在合理期限内仍未履行；当事人一方迟延履行债务或者有其他违约行为致使不能实现合同目的的，当事人可以解除合同。本案中，睿途公司主张，由于樱蓝公司新增需求，双方已将软件交付日期变更为2018年2月，其不构成迟延交付，且樱蓝公司未经催告即发送解除函，不产生解除合同的法律效果。对此，本院认为：首先，关于涉案合同履行期限问题。涉案《技术服务合同书》明确约定软件交付时间为2017年9月20日，同时约定项目实施周期为三阶段、3个自然月。依据查明的事实，樱蓝公司在2017年9月14日，询问软件开发进度后，又于9月23日等多次催问上架时间，2017年11月3日樱蓝公司的法定代表人孙林茂在微信群中明确要求涉案软件应于2017年11月20日上架，并指出“上次9月13日—10月13日我就想那时候能上架，拖了一个月，这次还是搞不定”。此后的微信记录中，双方未就上架时间进行明确沟通。据此可以认定，虽然樱蓝公司在合同约定的交付期限届满即2017年9月20日后仍继续催促涉案软件开发的进度，并最后宽限要求睿途公司于2017年11月20日上架。根据沟通记录，不能得出双方已将软件交付时间变更为2018年2月的结论。因此，睿途公司关于“双方已将软件交付时间变更为2018年2月”的主张缺乏证据证明，本院不予支持。其次，关于开发需求调整是否对交付期间造成实质性影响的问题。睿途公司作为软件开发方，其义务包括准确定义、阐述涉案项目的业务需求等。从双方微信沟通记录来看，樱蓝公司对涉案软件的定位是基本明确的，睿途公司需要根据樱蓝公司的定位，准确理解、定义项目需求，及时完成软件开发和测试，并交付验收。一方面，虽然双方多次就软件开发需求进行调整，但睿途公司列明的38项需求变更中，有24项不涉及功能新增和变更，应为优化细化类别，并不导致软件开发工作任务的过分加重。即便睿途公司主张其中14项为功能变更和新增，但樱蓝公司抗辩称该14项中部分系睿途公司设计缺失导致的增加，部分属于功能解释，部分属于睿途公司无法实现技术的更换等，睿途公司未进一步提供证据推翻樱蓝公司的抗辩。另一方面，樱蓝公司已给予睿途公司一定宽限期，即便涉案软件需求存在一定调整，该部分变化主要分布在2017年8月25日至10月期间，樱蓝公司要求睿途公司于2017年11月20日上架涉案软件，亦具有一定合理性。而截至2018年1月18日，樱蓝公司对睿途公司提供的软件进行公证时，客户端的三个模块只能看到包车定制和民宿预约两部分，且尚不能判断现有两部分模块的具体应用。本案二审中，睿途公司也明确“一共三个模块，在12月份的时候出行模块已完成，民宿和商城模块没有完成”，并表示其开发的软件无法在庭审中进行演示。此外，睿途公司自签订涉案《技术服务合同书》后，曾三次变更软件开发负责人，导致双方反复沟通确认软件开发需求。综合上述事实，可以认定睿途公司在理解、定义软件开发需求，以及完成软件开发的进度方面存在履约障碍。一审法院认定需求变更和增加设计不足以构成睿途公司严重迟延履行的有效抗辩，具有事实依据。第三，关于通知解除的效力问题。依据查明的事实，樱蓝公司的法定代表人孙林茂曾于2017年9月14日、9月23日、9月29日、10月14日、10月19日、11月3日、11月6日、11月14日等多次在微信群里催促涉案软件进度，并多次要求产品上线。以上微信聊天内容，构成樱蓝公司对睿途公司履行合同的催告。如前所述，樱蓝公司给予睿途公司的履约宽限期为2017年11月20日，此后樱蓝公司也一直在催要成果，但直至2018年1月20日，睿途公司仍未交付可运行的软件测试版本，樱蓝公司向睿途公司发函解除涉案合同，符合法律规定的合同解除的要件。一审法院综合案件事实，认定睿途公司迟延履行债务，致使樱蓝公司经营计划落空，并确认涉案合同解除并无不当。二、一审法院关于涉案合同解除后的法律责任的认定，并无不当《中华人民共和国合同法》第九十七条规定，合同解除后，尚未履行的，终止履行；已经履行的，根据履行情况和合同性质，当事人可以要求恢复原状、采取其他补救措施，并有权要求赔偿损失。本案中，睿途公司的合同义务是开发相关软件，涉案软件的交付应以可实际使用和上线运营为准。本案中，睿途公司已交付的软件尚未完成全部模块设计，樱蓝公司不能以其开发的软件投入运营。因睿途公司未及时交付可以上线的软件，导致合同目的无法实现，樱蓝公司不得不另行组织开发。因此，一审法院认定睿途公司整体未履行软件交付，并判令睿途公司返还已付价款，具有事实和法律依据。另根据法律规定，基于睿途公司严重违约，合同解除后，樱蓝公司有权要求赔偿损失。本案中，樱蓝公司提交的发票包括网络、通讯、软件服务、服务器等费用，均为软件开发配套工作所应支付的必然费用，属于樱蓝公司的实际损失。睿途公司虽对以上费用与软件开发之间的关联性存在异议，但未提供反证。一审法院判令睿途公司向樱蓝公司支付经济损失53513.94元，并无不当。综上，睿途公司的上诉请求不能成立，应予驳回。一审判决认定事实清楚，适用法律正确，应予维持。依照《中华人民共和国民事诉讼法》第一百七十条第一款第（一）项的规定，判决如下：驳回上诉，维持原判。二审案件受理费6227.71元，由苏州睿途网络科技有限公司负担。本判决为终审判决。审 判 长 汤茂仁审 判 员 史乃兴审 判 员 史 蕾法官助理 刘 燕二〇一九年十二月二十八日书 记 员 袁雨田