行业资讯
3 月，客户带着一张 A4 纸来了。纸上画了个框图，说要给厂里的设备加远程监控，设备数据能实时看到，异常能告警，两个月要上线。我们当时没说能做，也没说不能做，只说先去现场看一圈。这个项目最后做了半年。不是拖延，是物联网项目本来的样子。这篇把它从头到尾复盘一遍，钱花在哪、时间耗在哪、坑踩在哪，一次说清。第一个月：需求只说了半句客户那张 A4 纸，核心就一句：设备数据要能看、能告警。听着简单，问下去全是事。什么设备？老设备还是新设备？有没有现成的通讯接口？数据多久采一次？存多久？报警发给谁？谁来处理？答案是一连串的 "不知道" 和 "还没想过"。这是物联网项目和普通软件项目最大的差别：普通软件的需求是人和流程，物联网的需求里还有一堆设备和协议。设备型号没定，后面全是空谈。那一个月，我们一半时间在陪客户理需求，一半时间在等设备厂家回邮件。经验：物联网项目谈需求，一定要问到设备层。什么设备、什么接口、什么协议、数据量多大，这四个问题先问清楚。选型：通讯方式吵了半个月设备定了，下一个问题是数据怎么传上来。WiFi、4G、NB-IoT、LoRa，各有各的道理。厂区有没有 WiFi 覆盖，没有就得走蜂窝网络；走蜂窝要配 SIM 卡，每张卡每月流量费要算进成本；设备分布散不散，决定要不要上网关。报价的差距，一大半差在这里。有人说 "几千块就能做"，大概率没算卡费、网关和现场施工。等合同签了再补，价格就不是当初那个价了。那次我们和客户拿着厂区平面图，把每种方案的覆盖范围画了一遍，才定下来。这一步省不掉。开发：联调才是真正的耗时大头软件开发本身，反而是整个项目里最顺利的一段。真正的坑在联调。设备端、网关、平台，三方要能对得上话。可设备厂家给的协议文档写得不全，有几条指令的参数说明是错的，现场设备版本和文档对不上。一封邮件过去，三天才回。还有一次，设备发上来的数据全是乱码，排查了两天，发现是通讯协议里一个字节的顺序和文档标的不一样。这种问题，纯靠软件团队在办公室盯，盯不出来，得拿着设备在厂区里一遍遍试。所以物联网项目的周期，不能按 "软件开发要多久" 来估，要按 "三方联调要多久" 来估。预留的时间，宁可多，不要少。现场实施：没有网、没有电、位置不对按计划两周装完，实际装了三周。第一天到现场就发现，设备计划安装的位置没有电源插座，拉线要绕半面墙。还有两个点位 WiFi 信号差，得换方案重
最近来找我们聊 AI 的客户，一大半开场是这样的："我想用大模型做一个智能客服"" 我想给系统加个 AI 功能 "。问他想解决什么问题，答不上来。这就是大多数 AI 项目第一步就走错的地方：先选技术，再想问题。顺序反了，后面全拧巴。这篇不聊技术名词，就聊三件事：AI 到底能帮你解决什么、怎么起步最划算、以及别对它抱什么期待。先分清，AI 能干什么、不能干什么AI 不是万能钥匙。先把它能干的活和干不了的活分开，你才知道该不该上。它擅长的，是重复、量大、有规律的那类事。一是处理文字。合同要点提取、客服问答、报表总结、文档归档，这类活 AI 干得又快又稳。二是看图。识别单据、数货架上的商品、检查产品外观瑕疵，比人眼快得多，还不累。三是分析数据。把一堆历史数据扔进去，让它找规律、做预测、给建议，这个它擅长。它干不了的，是三类事。一是要担责任的决定。AI 可以说 "建议这样做"，但出了事责任得有人扛，指望 AI 替你拍板，不现实。二是行业里没有先例的活。大家都还没搞明白怎么做的业务，AI 也帮不上忙，它学的是已经发生过的东西。三是感情和分寸。面对面的沟通、安抚情绪、处理复杂人际关系，AI 只能打辅助，替代不了人。判断标准很简单：你那个环节，是不是重复、量大、有规则？是，AI 有机会；不是，先别急着花钱。起步有三种方式，别一上来就选最贵的确定值得做之后，怎么起步？绝大多数人用不着从零开发，三条路按顺序选。第一种，接现成大模型 API。 用别人训练好的大模型，通过接口接入你的系统。客服机器人、文档问答、内容生成，很多场景这个就够了。周期短、费用低，通常几周就能跑起来。第二种，在现成模型上做定制。 把你自己行业的资料喂进去，让它更懂你的业务。适合 "通用模型答不准" 的情况，比如行业术语多、产品特殊。成本和时间比第一种高，但还在可控范围。第三种，完全自研。 自己训练模型、搭算力、养团队。这是头部大厂和特殊行业的玩法，对绝大多数中小企业来说，贵、慢、且没必要。多数生意，从第一种开始就够了。先跑起来，验证真有用，再考虑要不要往第二种走。一上来就奔着自研去，钱花在验证之前，是最常见的浪费。数据才是 AI 的燃料技术路线定了，还有一个东西决定成败：你手里有没有数据。AI 好不好用，七成取决于喂给它的数据。它靠学你的历史记录变聪明，没有数据，模型再强也是空壳。做智能客服，你有没有过去三年的对
大部分人签软件开发合同，是这么签的：开发公司把合同发过来，扫一眼总价，问两句工期，签了。真到项目出事那天回头翻合同，才发现当初看漏的东西全在纸上写着。这篇不列法条，就按一份合同从头翻到尾，把最容易出事的那几处指给你看。第一处：功能清单，写得有多粗翻到合同中间，找到那张功能清单。这是全合同最重要的一页。最怕的写法是 "开发一套进销存系统，包含商品管理、库存管理、报表功能"。三行字，完事。商品管理管到哪一层，库存是按件算还是按批次算，报表长什么样、能不能导出 Excel，这些都不写，后面就有得扯。你说 "进货要自动提醒补货"，对方说 "这不在合同里，是新增功能，加钱"。到这一步，你已经没有讲理的依据。功能清单宁可在签约前磨细一点，写进合同，也不要事后靠聊天记录。第二处：验收，谁说了算合同里写 "系统上线后 15 日内完成验收"。看起来挺清楚，其实等于没说。15 日内，按什么标准验收？功能对不对、数据准不准、性能达不达标，标准在哪？合同里没有验收标准，验收就是乙方说了算，他说完成了，你只能认。签约前把验收标准写进合同：哪些功能逐条核对、数据准确性怎么验证、响应速度要求几秒内。标准越具体，验收那天越不用吵架。第三处：源码归谁，决定你以后能不能换人这处最容易被忽略，因为大部分人根本不看知识产权条款。合同里如果没写源码归属，或者写的是 "乙方保留全部知识产权"，那你只是买了个使用权。以后想加功能、想换开发公司、想把系统卖给分店，都得回来求他，价格他说了算。签之前确认清楚：源码、数据库结构、设计文档的归属，是不是归你。验收通过后源码是否交付。这一条，直接决定这套系统是你的还是租的。第四处：钱怎么给，比给多少更要紧总价谈得再狠，付款节奏没谈好也是白搭。常见的坑是 "签约付 50%，开发中付 30%，上线付 20%"。上线是什么？没验收就上线，等于还没确认东西行不行，尾款就快给完了。等项目出问题，你手里已经没有能牵制对方的钱了。合理的节奏应该是：定金少一点，尾款多一点，尾款和验收结果挂钩。你手里捏着钱，对方才会把你的验收意见当回事。第五处：售后和延期，写没写清楚合同里 "系统验收后提供一年免费维护"，一年之后呢？是每年收维护费，还是出了问题按次收费，写没写？响应时间也很关键。系统半夜崩了，多久有人处理，电话还是工单，写没写。很多小公司口头答应 "有问题随时找我们"，出事那天微信不回、
上个月有个客户来找我，说店里那套用了八年的进销存系统，"一天都忍不了了"。打开一看，界面是十几年前的风格，报个价要跳四个页面，库存数据偶尔还对不上。老板情绪很激动，张口就是要重做。我劝住了他。不是这套系统不该动，而是 "重做" 这两个字，大多数人没想清楚它到底意味着什么。先分清三个词，别把代价算错改造、重构、迁移，是三件完全不同的事，花的是三种完全不同的钱。改造，是小修小补。某个模块不好用，改掉；某个流程卡顿，捋顺。风险小，周期短，改动范围锁死在局部。迁移，是换底座。系统照用，业务逻辑不动，把背后的技术框架、服务器、数据库换一遍。好比给老房子重新走水电，房子还是那个房子。重构，才是推倒重来。代码重写、数据库重建、页面重做，相当于把房子拆了盖新的。很多客户说 "我要重构"，心里想的其实是 "这系统太难用了，你们帮我改改"。真按重构报价，报价单能把他吓一跳。所以第一件事，是先把话说准，你到底要的是哪一种。什么情况真的该动老系统不是都得动。我判断一个系统该不该动，就看四条。跑不动了。 并发一上来就卡，报表要算半小时，业务高峰期系统直接罢工。这是性能撑不住了，属于硬伤。改不动了。 想加一个功能，开发说 "这个改动会牵连十来个地方"，改一个点要测半个月。系统的结构已经锁死了它的扩展空间。没人会了。 系统是用十几年前的技术写的，当年写它的程序员都转行或退休了，现在全公司没人敢碰，出了事只能干瞪眼。撑不住了。 安全漏洞没人补、数据没有备份、合规要求过不去，风险已经大到不敢让它继续跑。占一条，值得认真考虑动它。一条都不占，那你其实没有重构的理由。什么情况别急着动反过来，我也拦过不少想重构的客户。系统能用、每天稳定跑着、业务都靠它撑着，这种时候最忌讳大动干戈。重构最大的风险从来不是技术，是业务断档。新系统还没跑顺，老系统已经停掉，库存乱了、订单漏了、客户电话打进来没人答得上来，这个损失比系统难用大得多。我见过一个项目，重构做了一半，钱花了，人累了，业务方每天在群里催，最后老系统继续跑着，新系统烂尾在服务器里。根子不是技术不行，是启动之前没人想清楚 "这三个月业务怎么办"。系统只要还在好好干活，就不存在 "必须立刻重做" 的紧迫性。它可以等，等你准备充分。动之前，先盘点三件事决定要动，别急着找开发公司报价。先花半天，把这三件事写在纸上。它到底在撑什么。 这套系统连着哪些业务，断了会死哪
"我不懂技术，怎么跟你们提需求啊？"这句话，做开发的人几乎每周都会听到。说这话的客户，一半是真的谦虚，一半是怕说外行话被忽悠。先说结论：提需求这件事，考验的是你对自己的生意熟不熟，跟懂不懂技术没有关系。你不需要会说代码，需要的是把你每天怎么做事、怎么挣钱、哪里最烦，讲给别人听。这篇不讲大道理，直接给方法。提需求最常见的三个坑先看看需求为什么总说不清，大多逃不开这三个。只报功能名。 "我要一个会员系统"" 我要一个进销存 ""我要一个商城"。功能名听着专业，其实信息量接近零。会员怎么分级、积分怎么算、进销存管到哪个环节、商城谁上架谁发货，全都没说。开发公司听完，只能按自己的理解猜。只说结果，不说过程。 "我要能查库存。" 这句话没错，但库存是怎么来的？是每次进货手动录，还是和供应商系统自动同步？盘点怎么盘？报损怎么处理？过程不说清，做出来的查库存，大概率不是你想要的查库存。需求全在脑子里。 客户心里其实有一套完整的想法，但没写下来，也没讲全。讲到一半觉得 "这个不用说了吧"，结果开发公司真的不知道。需求没有落到纸面上，就等于没需求。这三个坑的共同点，是把 "需求" 当成了 "名词"，而不是 "过程"。讲人话的三件套：讲场景、讲流程、给例子别急着背功能清单，试着用三种方式说需求。讲场景。 不说 "我要会员系统"，说 "我的店长每天下班前，要把当天的充值、消费、退款统计出来，发到工作群里"。场景一说，开发公司立刻知道要做什么、给谁用、什么时间用。讲流程。 不说 "我要一个下单功能"，说 "客户现在是这样下单的：打电话给我，我在本子上记，月底手工对账。我想让客户自己在手机上选、自己付款，账自动对"。流程一说，改造的目标就清楚了。给例子。 你手上如果有现在用的纸质单据、Excel 表格、对账单，直接拍照片发给开发公司。一张真实的单子，顶一百句描述。开发公司照着单子做，跑偏的概率小得多。这三件套有一个共同点：都在说 "你现在的样子"。现在的样子说清楚了，要改成什么样，自然就出来了。分清 "必须有" 和 "可以没有"提需求时，人很容易把什么都当重点。预算有限、工期有限，需求也得排队。把需求分成两堆：一堆是 "没有它，生意没法做"，一堆是 "有了更好，没有也能先跑"。前者先进开发，后者往后排。这招还有一个好处：开发公司拿到需求清单，知道什么是底线、什么是弹性，报价和排期都会实在很多
系统做完，验收当天，客户打开一看："这跟我想要的完全不一样。"开发这边也委屈："当初需求就是按这个做的，怎么现在全不对了。"这个场面，在软件行业太常见了。两边都觉得自己有理，最后闹到互相扯皮、拖尾款、甚至打官司。说句实话，验收当天才发现问题，责任多半不在验收本身，在开发前就埋下了。这篇把验收这件事从头捋一遍：为什么总扯皮、怎么分阶段验收、验收清单该列什么、不合格怎么办。验收扯皮，根子在哪大多数验收纠纷，逃不开三个原因。需求没写清。 合同里写着 "做一个会员管理系统"，但会员等级怎么分、积分怎么算、手机端要不要、报表长什么样，全都没写。没有依据的验收，最后只能凭感觉，凭感觉就有得吵。标准不可量化。 "界面要美观"" 操作要流畅 ""功能要完善"，这些词在验收时一点用都没有。什么叫美观，什么叫流畅，甲方乙方各有一套标准。写进合同的验收项，必须能回答 "达到什么程度算合格"。心态错位。 甲方把验收当成 "找茬大会"，乙方把验收当成 "走个过场"。一个使劲挑毛病，一个使劲糊弄，最后验收变成了拉锯战。这三个问题，都不是验收当天能解决的，都得往前挪。聪明做法，是分阶段验收别把宝押在 "最后那一次" 上。项目周期里设几个验收节点，每个节点确认一次，问题早暴露、早修正，成本最低。需求确认阶段。 需求文档和原型图出来后，先验收一次。确认功能清单、页面结构、业务流程，这一关过了，后面开发才有据可依。开发中演示。 开发到一半，约一次演示。看看界面方向对不对、流程顺不顺，这时候改，改的是局部；等到全部做完再改，改的是全局。上线试运行。 系统部署上线后，不要急着终验，留出试运行期。真实业务跑几周，数据对不对、有没有报错、业务人员用不用得惯，这些问题只有真实使用才会暴露。终验。 试运行没问题，再走正式验收流程，签署验收确认。分阶段验收还有一个作用，它逼着双方每过一关都把问题摊开说，而不是攒到最后一刻爆发。验收清单，该列这些项不管项目大小，验收清单至少覆盖这几个方面。功能：逐条对照需求，每个功能点实际点一遍，而不是听对方说 "都做了"。数据：测试数据跑几轮，看数据是否正确、统计是否准确、导入导出有没有丢。性能：正常业务量下，页面响应、操作流畅度、并发承受能力。性能指标应该在需求阶段就定下数字，比如 "查询响应 3 秒内"。兼容与适配：不同浏览器、不同手机型号、不同系统版本都要过一遍，业务越依赖线
选软件开发公司时，不少企业会纠结一个问题：本地公司，还是外地公司？一线城市的团队规模和技术储备看起来更有吸引力，本地公司的沟通和响应又让人更踏实。两边都有道理，但多数企业在对比时，比错了重点。下面我们直接把两类选择的差别、适用场景和签约前要确认的事项讲清楚。 软件外包的坑，大多出在沟通环节做过软件采购的人应该都有体会：项目延期、返工、验收扯皮，真正的原因往往不是技术能力，而是需求没对齐。需求不明确，是大多数项目的起点。企业方知道自己要"一个管理系统"，但管什么、怎么管、哪些流程要覆盖，通常要到开发过程中才逐渐清晰。这个过程中，需求确认的效率决定了整个项目的节奏。当面沟通的优势在这里体现得很直接。白板画图、现场比划、边说边改，一次需求访谈可以明确七成细节。远程沟通则要依赖文档往返，一份需求文档改七八个版本，是远程项目里常见的现象。软件项目的工期，很大一部分消耗在需求确认上。沟通距离每增加一档，这段工期就相应拉长。 本地公司的价值，体现在响应和介入深度本地公司的优势，通常不体现在报价单上，而体现在几个关键节点。需求阶段，可以高频安排面对面访谈，原型确认、页面评审都能随叫随到，减少理解偏差。上线阶段，系统出现问题可以当天响应，严重时直接到场处理，不必排队等工单。迭代阶段，长期的小改动、流程调整，一次面谈就能定清楚，不需要来回两轮邮件。这些看起来是"便利"，实质是对项目风险的控制手段。对依赖系统运行的业务来说，响应速度不是加分项，是刚需。外地公司的风险，主要在交付链条一线城市公司聚集了大量工程师，技术底子通常不错，这一点不否认。但需要留意一个事实：签约的公司和执行团队，可能是两拨人。外包行业转包现象普遍，销售端承诺方案，执行端拆分到下层团队，验收时对接人可能已换过一轮。这种结构下，质量控制和责任追溯的成本会明显上升。远程沟通的隐性成本同样存在。需求文档往返、验收时的理解偏差、响应时间的延迟，在项目周期里都会被放大。软件项目一半的问题出在沟通上，距离会加剧这个问题。远程外包能胜任的场景需要说明，远程外包有它适用的场景，并非所有项目都必须本地化。需求已经明确。功能清单、页面结构、业务流程、验收标准都白纸黑字定好，远程执行和本地执行的差异不大。标准化程度高的产品，如电商模板、企业官网、管理后台，远程团队往往因为交付经验多，效率和性价比更高。企业方有熟悉技术的人员参与管理，能把远程
"我想做个 APP。"来咨询的人，一大半开口都是这句。你再问他：这个 APP 打算解决什么问题？用户什么时候会用？很多人答不上来，说 "就是觉得现在做生意，应该有一个"。这话没毛病，但方向容易跑偏。你需要的可能根本不是 APP，是个小程序，甚至公众号就够。这三样不是越高级越好，是越合适越好。为什么人人都想做 APP？说到底是被带着走的：看同行做了、听人说了 "APP 才显得正规"、或者就是直觉觉得 "手机上的东西都叫 APP"。这些理由都成立，但都跟 "你的生意需不需要" 没关系。先把 "别人有什么" 放下，想想 "你的用户要什么"。这三样，到底是干嘛的公众号，是给别人看的。发文章、发通知、放个菜单，用户在微信里关注你，你发的东西他能刷到。它的本事是 "触达"：隔三差五能跟你说上话，新品、活动、行业动态，都能送到人眼前。但它不适合 "办事"。让用户在公众号里下单、约课、查余额，流程绕、体验一般，用户操作两步就想退出去。公众号的价值是 "把话说出去"，不是 "把事办完"。小程序，是给别人用的，但用完就走。扫码进来自助点单、约时间、查余额、领券，办完事关掉，不用下载。它的本事是 "方便"：没有安装门槛，路边的海报、桌角的二维码，扫一下就能用，用完也不用想着删。小程序的短板是 "存在感低"：用户办完事就忘，很难主动想起你。指望它做品牌沉淀、做深度互动，不太现实。它是 "办事的窗口"，不是 "留人的家"。APP，是让人装到手机里、天天打开用的。能做推送、能用摄像头定位这些手机能力，用户粘性最强，天天见。它适合真正的高频场景：打卡、记账、刷内容、下单，一天不开就难受。代价也最大：要下载、要过两个应用商店的审核、开发和维护都最贵。最怕的是做成一个 "装了没人用" 的 APP—— 用户下载那一刻的热情，撑不过三天。所以别问 "哪个高级"，问 "你的用户是来看、来用、还是来常驻"。做哪种生意，上哪种车开店的—— 餐饮、美容、健身、教培这些，用户到店要办的事就那几样：点单、约课、办卡、查余额。拿餐饮举例：扫码点单、会员储值、优惠券，这些事用户打开就办、办完就走，小程序正合适，还便宜、上线快。你不需要他天天打开你的店，他要吃的时候能找到你就够了。这类生意做 APP 的很少，做了也多半是浪费：用户不会为了吃顿饭专门下载一个 APP。做平台、商城、高频工具的—— 用户天天用、要推送、要提醒
谈项目的时候，最常听到的对话是："这个系统多久能做出来？" "正常的话，两个月。" "能再快点吗？"两个月后，需求还没聊完的大有人在。不是谁在骗你，是 "开发" 这两个字，在大家脑子里理解的不一样。你以为是 "写代码" 要两个月，实际上写代码只是中间一段。这篇文章把一套软件的真实时间构成拆开给你看，看完你就知道：周期长在哪、哪些能压、签约前怎么把工期谈实。一个项目的时间，其实花在五个环节以一套常规的定制管理系统为例，周期大概是这样的：需求梳理：1-2 周。把你要做的事一条条聊清楚、写成文档。这步最容易被跳过，也是后面返工的根源。界面设计：1-2 周。出原型、出视觉稿，你看着像 "还没开始写代码"，其实这步决定后面改多少。开发：4-8 周。这才是大家以为的 "做软件"，前端、后端、数据库一起上。测试：1-2 周。自己测、给你测、发现问题修掉。上线部署：3-7 天。装服务器、配域名、导数据、试运行。加起来，一套常规定制系统 2-4 个月，是正常区间。说 "一个月上线" 的，要么是模板套壳，要么后面必有加急费。（以上是常规项目参考，具体周期以实际评估为准。）为什么实际总比报价时说的长？报价时给你的周期，是按 "理想状态" 算的：需求一次聊清、决策人当场拍板、你随时在线、开发不出意外。实际不是这样，时间基本丢在这四个地方：沟通往返。 一个需求点要确认三遍：先微信问，再开会定，会后又变。每次往返看着不起眼，攒起来就是一两周。改动返工。 做完的功能要改：字段加一个、流程换一下、样式调一版。改一次看着快，但牵一发动全身，测过的还要重测。联调对接。 系统要对接支付、短信、硬件、别的系统，对方配合慢，你就只能等。验收扯皮。 "这个和我要的不一样"—— 哪里不一样，说不出来，又得来回对。哪些项目真的能快？不是所有项目都要两三个月，看你在哪一档：快（2-4 周）：展示型页面、营销小程序、模板改改就能用的系统。需求基本固定，没什么定制逻辑。常规（2-4 个月）：带业务流程的管理系统、小程序 / APP 的第一版。上一条说的五个环节都跑一遍。慢（4 个月以上）：对接硬件、对接老系统、多端同步、复杂权限、高并发，或者需求还在变。判断标准一句话：要跟别人系统打交道越多、流程越绕，越快不了。想压缩工期，真正有用的几个办法想快点上线，砍的不是开发，是这些：需求写细再开工。 把你要做的每件事列出来，哪
前两天一个做传统生意的老板来聊系统，其他问题都还好，问到数据，他明显犹豫了一下："数据是不是都存在你们那边？"我知道他真正想问的不是技术，是：这些家底交出去，还安全吗？这个问题没有标准答案，但确实有一套问法。别急着让人报价，先把下面几句聊完。先反问自己一句：数据泄了，怕不怕？聊数据安全，第一件事不是问技术，是问自己：这套系统的数据，丢一份或者漏出去，你会不会睡不着？客户名单、报价体系、进货渠道、财务账 —— 这些数据一旦出事，轻则丢生意，重则伤根基。越靠这几样，越不能随便交出去。反过来，如果系统里存的都是能重新补的记录，丢了也就丢了，那就不用纠结，怎么省心怎么来。有的行业，规定已经替你选了做政务、金融、医疗这些，不用你自己纠结。等保、数据不出境、行业监管、甲方合同里写着 "必须部署在指定环境"—— 规定已经把答案写好了，就是私有化部署。这种情况别讨论性价比，合规是底线，先照着要求办。钱的事，按三年算很多人一听私有化就摆手："太贵了。"其实得看怎么算。云端按月按年付，第一年看着便宜，用三年五年加起来不是小数目，人一多还按人头加钱。私有化前期要买服务器、买授权，看着吓人，但后面主要是运维费，用久了反而摊薄，而且系统是自己的资产，不是租的。一句话：别比第一年，比三年。最难的不是装，是养这一条能劝退一半想私有化的人。系统装完不是结束。服务器要打补丁、要备份、半夜可能要处理告警，这些都得有人管。公司里没个懂技术的人，要么花钱外包，要么硬扛。硬扛的常见结局是：备份没做过、补丁没打过，出事那天才发现系统早就在裸奔。所以先回答：这套系统，以后谁维护？给自己留条退路最后想一个长远的问题：三年后要是换系统，这堆数据搬不搬得走？云端的系统，数据能不能导出、导出什么格式、迁移麻不麻烦，全看服务商。有的系统看着好用，数据却锁死在里头，想走都走不了。私有化的数据在自己手里，想对接、想换，主动权在你。如果拿不准，就选一条折中路：先用云端跑，签约时白纸黑字写清楚 "数据随时可完整导出、格式开放"。最后，签约时记得问这一句说了这么多，其实就一句话：数据是你公司的资产，不是系统的赠品。不管最后选云端还是私有化，签约前都把这句话问清楚 ——"我们的数据存在哪？以后能不能完整导出来？"对方答得含糊，直接换下一家。
到底软件开发该不该找人做，还是买个现成的就行。这个问题问得最多的是两类人：一类觉得定制贵，想省事买现成的；一类买完现成的发现不好用，又回头想定制。两边都花了冤枉钱。其实这不是技术问题，是算账问题。下面 4 个问题过一遍，答案基本就出来了。先说清楚两种选择是什么买现成的（SaaS 或成品软件），意思是你的业务去适配软件的流程。它怎么设计，你就怎么用。好处是便宜、上线快，坏处是它不会为你一个人改。定制开发，意思是软件来适配你的业务。你要什么流程就做什么流程。好处是贴合、想改就改，坏处是贵、周期长。没有哪个绝对好。关键在于你的情况更靠哪边。问题一：你的业务流程是通用的，还是独有的？做进销存、客户管理、报销审批这些，全行业都差不多，现成系统完全够用，没必要花定制的钱。但你要是做的是冷门行业，比如特殊品类的生产管理、带行业规矩的审批流、要和自家设备对接的流程，现成系统大概率没有，或者有但不好用。这种情况，定制才是正解。判断标准：你描述业务流程的时候，如果对方软件销售一听就懂、直接给你演示功能，说明你的业务够通用；如果你讲了半天对方还在问 "这个场景我没见过"，那基本得定制。问题二：你愿不愿意改自己的流程去适应软件？这是最容易被忽略的一问。很多人买现成系统之前信心满满，买回来发现：得按软件的逻辑重新捋流程，员工要学新操作，以前的干法全得变。如果你愿意改，而且改了不伤业务，那现成系统很划算。如果你死活改不动 —— 比如行业规矩就是那样，客户就认那套流程 —— 那就别硬买，硬买的结果是系统买回来吃灰。问题三：这个系统以后会大改吗？业务几年内很稳定，流程十年不变，买现成的没问题，反正也不用改。但你要是正处在扩张期，或者业务模式年年变，现成系统的短板就出来了：想加个功能，要么做不了，要么得加钱等排期，要么整个方案换掉。这种时候定制 + 一个好架构，比买现成划算，因为架构是为你以后的变化留的口子。问题四：数据在谁手里？这条最容易被普通老板忽略。买现成系统，数据存在服务商的服务器上；哪天你不续费、或者服务商调整业务，数据取不取得出、取出来能不能用，都是问题。如果你的数据敏感，比如客户名单、报价体系、生产配方，或者公司有硬性要求必须数据自己掌握，那至少要考虑私有化部署或者定制开发。数据握在自己手里，晚上睡得着。顺便算一笔账：现成系统的隐形费用很多人觉得现成系统便宜，其实算总账不一定：按年
很多客户选公司只看两样：报价低不低、案例多不多。这两样都不太靠得住。报价低可能是没算清楚，案例多可能是包装出来的。判断一家公司靠不靠谱，其实用不着多高深。签约前把下面 8 个问题问一遍，回答的质量基本能说明问题。1. 你们怎么了解我的需求？上来就报价格、催你签约的，先放一边。靠谱的公司会先问清楚：你要解决什么问题、现在是怎么干的、系统给谁用。他问得越细，后面返工越少。判断标准很简单：聊需求的时间比报价格的时间长，基本靠谱。2. 这个项目谁来负责？问清楚：项目经理是谁、开发几个人、有没有专职测试。一人包干不是不行，但你要知道风险 —— 这个人一离职，项目可能就停了。还有一句值得问："这个项目是你们自己人做吗？" 有的公司接单后转包给别的团队，这一问能筛掉一批皮包公司。3. 报价单里包含什么？让公司把报价拆开：需求、设计、开发、测试、上线各占多少，包含几次修改、多久维护。不给明细、只说 "全包" 的，后面大概率加钱。顺带问一句：超出需求范围的新功能怎么算钱？这是扯皮高发区，最好提前说清楚。4. 你们用什么技术做？不用懂技术，但要看对方能不能把技术讲明白。问 "系统用什么架构、数据怎么存、以后业务量大了撑不撑得住"。支支吾吾答不上来的，技术团队可能很弱。再问一句系统用什么语言开发。以后你们自己维护或者换人维护，用的技术越主流越省事。5. 合同里怎么写？重点看四条：付款节点：别一次性付清，按里程碑付，做完一步付一步。验收标准：什么算做完，白纸黑字写清楚。源码归属：验收付款后归客户，必须写进合同。保密条款：你的业务数据不能外泄，违约怎么赔。这四条缺一条，合同就先别签。6. 上线之后谁管？问清楚：交付后有没有免费维护期、多久、超出怎么收费、平时有问题响应多快。系统不是做完就完，业务一变就要改。售后跟不上的公司，报价再便宜也别选。7. 有没有同类案例？要案例别只看效果图，问三个问题：这个项目做给谁的、什么时候上线的、现在还在用吗。还在稳定运行的老案例，比一堆漂亮截图有用得多。8. 能不能先小范围试一下？第一次合作，可以从一个小功能或者一个模块开始。做得好，再放心把大项目交出去。愿意让你先试的公司，通常对自己的水平有底。总结 8个问题问完，公司靠不靠谱，心里基本有数了。问的过程也是互相摸底 —— 正经公司不怕你问，反而会觉得你是个懂行的客户。要是对方答得含糊、催你赶紧签约、又
在线
电话
微信
需求
TOP