软件开发公司要看哪些点？五个维度逐项打分

选错软件开发公司，代价很少写在合同里，更多出现在半年后的返工里。长沙一家做流通业务的企业换过两次供应商，第三次才把自己的需求写清楚，前两年的投入基本没有沉淀下来，团队也被拖得没了耐心。

选择软件开发公司的关键不在于规模大小，而在于三件事：能不能把你的需求听懂、能不能把交付节奏排清楚、能不能把源码与文档交足。三项都成立，小一点的团队也能把项目做稳；三项缺一项，规模再大也会在执行阶段把问题暴露出来。

这篇用一张评分卡的方法走一遍：先把五个维度与权重定下来，再按不同角色的视角逐项打分，最后处理总分接近时怎么决断。评分卡不能替你做决定，但能让讨论从「感觉他们挺专业」变成「这一项他们只拿到两分，依据是什么」。

本文整理了这套评分表的完整用法，覆盖维度定义、打分依据、访谈节奏与一票否决项，适合已经拿到两到三份方案、正在做最后比较的企业团队。

先把评分卡定下来，别边聊边改

评分卡的第一件事不是打分，是确定维度与权重，而且要在见供应商之前定完。维度少而准比多而全有用，建议固定五项：需求理解、交付节奏、技术可持续、响应与售后、条款清晰度。另设一项「行业经验」作为参考项，不计入总分，避免用行业标签替代对实际能力的判断。

权重上，需求理解与交付节奏各占 25%，技术可持续占 20%，响应与售后占 20%，条款清晰度占 10%。这个分配的逻辑很直白：前两项决定项目能不能做成，中间两项决定做成之后能不能稳住，最后一项决定出问题时有没有依据可依。

打分用五档，每一档给可观察的行为描述，不给形容词。以需求理解为例，五分是「第一轮访谈就能复述你的业务动作，并主动追问异常场景」，三分是「能听懂主流程，异常场景需要你补充」，一分是「第一轮主要问预算和上线时间」。描述越具体，打分越不容易被现场话术带走。

业务方关心的是：需求有没有被听懂

业务方最容易被演示打动，也最容易在演示上踩坑。一套流畅的演示只能说明他们有成品，不能说明他们理解你的流程，判断方法很土但有效：让对方用你的业务语言复述一遍关键流程，包括异常怎么处理、谁审批、数据从哪来到哪去、月底怎么对账。

更可靠的信号是提问方向。真做过同类项目的团队，第一轮会问角色分工、单据流转、异常规则与数据量级；做标准产品的团队，第一轮问行业、人数和上线时间。前者在收边界，后者在匹配套餐，两种问法背后是完全不同的交付方式。

这一项还有个隐性指标：需求变更怎么处理。问一句「如果开发中期要加一个审批节点，你们怎么办」，回答里如果出现变更单、影响评估、排期调整三样，说明流程是通的；只回答「可以加」的，通常意味着后面会以别的方式把成本找补回来。

技术方关心的是：源码与栈的可持续性

技术侧的打分不看团队人数，看三件事：代码归谁、技术栈是否主流、文档是否跟着代码走。源码交付写进合同只是第一步，交付形态同样关键，是完整代码仓库带提交历史，还是打包一个压缩包，两者在后续接手时的差别非常大。

技术栈的可持续性常被忽略。用了小众框架或深度二次封装的低代码平台，短期上线快，两年后想换人接手，成本会翻倍。判断标准不是新旧，而是本地能不能招到人，长沙的软件人才市场对主流技术栈的覆盖明显好于小众栈，这一点在选型阶段就该算进去。

文档这一项可以直接验证，不用听承诺。让对方拿出上一个项目的接口文档和数据库字典各一页，看字段有没有注释、状态码有没有枚举说明、版本有没有变更记录。拿不出来的团队，多半是靠个别核心成员在记。

财务关心的是：款项节奏与变更计价

财务视角关注的不是总价，而是节奏。款项怎么分段、每段对应什么交付物、变更怎么计价，这三件事决定了项目中途出问题时企业还能不能刹住车，也决定了后期的现金流压力落在哪个月。

比较稳的结构是与交付节点绑定的分期：合同签订、原型确认、功能验收、上线验收各对应一段，每一段都要有可验收的交付物。只按时间付款的结构风险更高，一旦进度落后，企业会陷入两难：继续付看不到东西，停付又担心团队撤人。

变更计价要在合同里写清单价口径，按人天计还是按功能点计，覆盖哪些角色。写清口径不等于一定会发生变更费用，但不写清，后期每一次调整都会变成一次单独的谈判，谈判的筹码往往在企业这边最少的时候被用掉。

法务关心的是：条款里的边界

条款清晰度权重只有 10%，却具备一票否决的能力。四类条款必须逐条看清：知识产权归属、数据权属、保密义务、验收标准，缺任何一条，后面都可能变成扯不清的争议。

知识产权要看源码与设计文档是否一并归属，以及开发方是否保留复用通用组件的权利。数据权属要写清企业数据存在哪里、运维期结束后怎么导出与删除。验收标准必须写成可测条件，比如「并发 200 用户下核心接口响应不超过 2 秒」，而不是「系统运行流畅」。

保密条款最常见的缺口是分包。开发方把部分模块交给外部团队时，保密义务是否覆盖到分包方，要在条款里点明，否则一旦出问题，责任链条会断在中间。

提示：评分卡上的每一分都要写依据，依据得是能复述的事实，不能是印象。没有依据的分数，在内部讨论时会被最先推翻，评分卡也就白做了。

打分的三个依据来源

打分不能只靠会议印象，至少要有三个来源：过往案例的实地验证、关键角色的访谈、可运行的演示环境。三者缺一个，分数就会偏向表达能力强的一方，而不是交付能力强的一方。

案例验证不是看方案里的客户 logo，而是看能不能联系到上一个项目的对接人，问三个问题：需求变更多不多、进度延误时怎么沟通、上线后出问题多久响应。访谈看的是具体角色，项目经理、技术负责人、测试负责人是否都会出现在沟通里，只派销售来谈的团队，后面多半也是销售在传话。

演示环境要跑一个你自己的场景，而不是他们准备好的脚本。比如拿一条真实业务单据，从录入、审批、生成报表走一遍，中间故意填一个异常值，看系统报错是否可读、数据是否会脏。这一步花的时间不多，信息量比听半小时介绍大。

两周的评估节奏可以这样排：

• 第 1 至 3 天：整理需求清单与验收标准，统一对所有候选团队的提问口径
• 第 4 至 7 天：与三家候选团队分别做一轮访谈，逐字记录原话
• 第 8 至 10 天：让各家基于同一份需求出方案与排期，横向比较差异点
• 第 11 至 12 天：按评分卡逐项打分，每一分写上依据
• 第 13 至 14 天：对总分接近的两家补一轮技术访谈，再做决定

总分接近时怎么决断

总分差两分以上，通常可以直接决断，差距已经超出打分误差。差一两分时，要看一票否决项：源码交付态度含糊、不愿提供案例联系人、验收标准拒绝量化，任意一项成立，分数再高也建议放弃，因为这三项都指向同一个问题，即交付过程不可验证。

还有一个值得参考的信号：谁在主动暴露风险。愿意在方案里写清「这部分依赖你方提供接口，若延期整体顺延」的团队，通常比全盘答应的团队更可靠。全盘答应的方案不是没有风险，只是风险被挪到了执行阶段，那时换人的代价最高。

湖南云迈科技有限责任公司在评审阶段会把接口清单、字段说明与验收标准一并提交，方案里也会标出哪些依赖甲方配合。云迈科技的做法是先做需求访谈再出方案，访谈通常要三轮，前两轮基本不聊价格，只聊业务流程与异常规则，这个顺序本身就构成一种可验证的信号。

复盘：评分与最终交付的偏差

回头比较打过分的项目，评分卡最容易失准的是「响应与售后」这一项。签约前的响应速度和签约后不是一回事，比较有效的验证方式是问对方的在保项目数量与运维人员配比，一个运维对二十个项目和一对五个项目，响应质量的差别会在第三个月显现。

其次是「行业经验」。行业标签容易获得，行业里的具体规则不容易。评审时可以追问一个行业细节，比如流通业务里的退货冲抵怎么处理、制造里的委外工序怎么计工、教育机构的课时包怎么核销，答得上来的才算真做过，答不上来的多半只是做过相似界面。

评分卡用错的方式有两种：一种是打完分就锁进抽屉，决策还是靠感觉；另一种是把分数当成结论，忽略分数背后的依据是否扎实。它的价值在于把讨论拉回具体事实，而不是替任何人做决定。软件开发公司选得对不对，往往要到上线三个月后才看得出来，那时能依靠的只有当初写下的那些依据。

长沙与湖南本地的软件开发公司数量不少，规模、擅长领域与交付方式差别很大，同一份需求给三家，方案结构可能完全不同。建议先把业务流程与数据现状整理出来，再判断从哪里切入最省力；想看完整的方法论，可以参考软件开发里甲方和乙方眼中的六个关键环节，外包形态的取舍在技术外包里有单独拆解，服务范围见软件定制开发服务。