行业资讯
去年有个做园区物业的客户，为了压预算，把新访客系统拆成四块。门禁硬件给一家，访客小程序给一家，后台管理给一家，短信和电子发票再给一家。四份合同分别签，项目群拉了六个，平时对接的是老板的行政。 上线前一周，门禁刷卡的记录进不了后台，访客在门口等，保安拿纸质本子登记。硬件商说只保证刷卡开门，小程序公司说接口按文档写的，后台公司说字段对不上，短信服务商说模板还没过审。会开了三次，每家公司都能拿出自己没做错的证据，整条链路却停在那里。一、拆包本身没错，错在没人当总包 很多甲方拆包，是为了压价，也为了找更专业的公司。硬件找做硬件的，小程序找做界面的，后台找做数据的，听起来每一块都更划算。合同一签，各自的功能都能做，拼在一起却没人对最终结果负责。拆得越细，接口越多，没人管的地方也越多。 每家公司的责任边界，通常只写到自己的合同范围。硬件商负责设备能刷，软件公司负责页面能开，后台公司负责接口能通。至于刷卡之后记录怎么进后台，访客信息怎么同步给保安，异常时谁先排查，合同里没有一个人名。 这时候需要一个总包角色。总包可以是一家开发公司，也可以是甲方自己指定的项目经理，还可以是第三方。形式可以变，三样东西不能少，接口清单的确认权，联调排期的决定权，验收单上的签字权。没有这三样，总包只是一个称呼。 有的甲方找一家公司做总包，合同里只写收几个点管理费，实际工作还是各家干各家的。这样的总包只多了一道转手，出事时照样找不到人。总包合同要写清它对整体交付负责，分包款由它结算，接口扯皮由它裁决，延期也要算它的责任。总包还要审核分包的技术方案，不能等出了事再拉群。 如果甲方自己当总包，别让行政兼职传话。行政能约会议、能收发票，但压不住四家公司的技术负责人。至少要给这个项目指定一个能拍板的人，老板要明确授权，不然他在群里说的话，别人只当建议。二、合同里最该写死的，是接口边界和交付物 四份合同里最常见的一句话，就是配合甲方完成联调。这句话看着礼貌，实际没有约束力。有的合同写提供标准接口，标准是谁的标准，也没有下文。 接口清单要单独做一份附件，不能只放在聊天记录里。清单上至少写清五件事，接口地址和调用方向，字段名称和类型，数据多久同步一次，鉴权和失败重试怎么处理，测试环境和上线时间。每一行后面要有提供方和确认人。这张表由总包起草，甲方确认，各家签字。 付款节点也要挂到接口上。硬件到货
去年有个做物业的客户找我，问要不要招个程序员。公司刚上线一套收费和报修系统，开发公司在外地，平时微信沟通。老板说自己不懂技术，底下也没人懂，每次开会只能听对方讲，讲完了也不知道该问什么。 我问他，招来的人具体干什么。他想了一会儿，说帮着改改代码，顺便管管服务器。再问服务器在哪、谁在续费、数据库有没有备份，他叫来行政，行政翻了半天手机，只找到一张云厂商的账单截图。一、先分清，你要的是程序员还是技术管家 很多老板一问就是「要不要招个程序员」，真聊下去，自己也说不清招来干什么。改代码、管服务器、盯进度、验收、跟开发公司对接，这些活看着都跟技术沾边，实际是几种不同的岗位。 写代码的人最贵，而且一个人撑不起一套系统。前端、后端、数据库、服务器、支付接口，随便一块出问题，都得有人接。小公司招一个程序员，多数时候是让他修电脑、导表格、催外包，代码没写几行，工资一分不少。 多数甲方真正缺的是另一种人。他不用会写代码，但看得懂方案，知道报价单里少了什么，能判断开发公司说的「这个做不了」是真做不了，还是不想做。项目上线前，他能把验收清单、备份、账号、续费一项项盯住。这种角色，有的公司叫技术负责人，有的叫 IT 主管，也有公司让产品经理兼着。 前年还有一家做建材贸易的，老板招了个刚毕业的程序员，月薪一万二。干了半年，人每天忙着给仓库装打印机、帮财务导数据、替开发公司复现 bug。后来老板把专职辞了，换成一个月来两天的兼职顾问，验收和账号反而理清楚了。人不是越多越好，得看放在哪个位置。二、这几种情况，别再让行政兼着对接 行政兼着对接，在小项目前期还能撑。合同签了，系统上线，事情一多，问题就藏不住。不是行政不认真，是很多事超出了这个岗位能判断的范围。第一种信号，是系统数量上来了。一套 OA、一套进销存、一个小程序，再加上公众号和支付后台，彼此还有数据往来。今天这个登不上，明天那个对不上账，行政只能挨个问，问到最后自己也不知道该找谁。第二种信号，是钱花得有点分量了。每年云服务器、短信、域名、维护费加起来，已经超过一个岗位的工资。这笔钱花在哪、该不该花、明年会不会涨，得有一个人能拉出账单，跟供应商对一遍。第三种信号，是系统开始碰客户数据和钱。生产服务器上有订单、有会员手机号、有支付接口，出了事不是「页面打不开」这么简单。备份有没有做、权限给了谁、离职的人还能不能登，这些没人管，迟
去年冬天，一个做仓储的客户给我打电话，说原开发公司关停了。微信群里最后一条消息是对方老板发的，说公司不做了，后续有问题找技术负责人。他打过去，号码已经停机。系统还在跑，出入库、对账、司机排队都在用，但服务器在哪、数据库密码是什么、域名挂在谁名下，没人说得清。 他最初的想法很简单，把代码要到手，再找个人接着维护。真开始接才发现，代码只是一个压缩包，解压出来跑不起来。配置文件是空的，证书过期了，定时任务停在旧服务器上，短信和地图的账号还是用原公司名义注册的。 这类事这两年听得越来越多。开发公司规模小，抗风险能力弱，团队一散，项目就成了孤儿。接手的人不是不努力，是根本不知道有哪些东西需要接。一、先接住「能跑」，别急着接代码 交接其实分三层。最下面是能跑，业务今天不断；中间是能改，代码能编译、能部署到新机器；最上面是能维护，账号、备份、监控都在自己手里。很多老板一上来盯的是代码，结果最下面那层先塌了。 先确认几件最急的事。服务器现在谁能登录，域名和证书续费到哪一天，数据库有多大、备份放在哪，有没有监控和报警。今天夜里出故障，电话该打给谁。这些问题的答案，比源码放在哪个仓库重要得多。 我见过一个客户，代码拿到手，部署时发现系统依赖一个已经停服的短信通道，接口调不通，验证码全发不出去，业务停了半天。后来查出来，短信账号是用原公司员工手机号注册的，人走了，验证码收不到，账号也找不回来。二、代码之外，还有四样东西在别人手里第一样是环境和配置。数据库连接、缓存地址、对象存储的密钥、支付回调地址、第三方接口的 appid 和 secret，这些通常写在服务器的环境变量或者配置文件里，不在代码仓库里。还有 SSL 证书、定时任务、消息队列、webhook 地址，少配一个，系统就少一块功能。第二样是数据和备份。数据库账号密码只是入口，真正要接的是备份策略。每天几点备份，备份文件放在哪，保留多少天。最怕的是备份有，但从来没恢复过。真出事的时候才发现备份文件损坏，或者恢复出来少了最后三天的订单。第三样是第三方账号。域名、云服务器、小程序和公众号、微信支付商户号、短信签名、地图授权、CDN、OSS，这些账号大多挂在原公司或者原公司员工名下。给密码不等于能接手，很多要过户。小程序主体变更要审核，支付商户号变更要重新签协议，域名备案主体不一致，后面续费都麻烦。第四样是文档和知识。部署文
上个月一个做建材批发的客户，把合同和结算单一起发给我。合同总价 18.6 万，最后付了 23 万多，多出来的四万多，大半落在报价单最后一行，四个字，「其他费用」。 他说签的时候问过这行是什么，对方回答先做着看，发生多少算多少，都是实报实销。听着挺合理，做完才发现这行没有清单，也没有上限，今天一笔短信签名报备，明天一趟现场部署，后天一笔旧数据清洗。每笔都不大，加起来比一个功能模块还贵。 「其他费用」本身不是骗人的。项目里确实有说不准的开支，谁也没法在开工前把每一分钱算死。问题在于，这四个字把「说不准」写成了「不用说明」，签字的时候双方都不知道这个口袋有多深。一、这四个字，为什么容易变成口袋 报价单按模块报，模块能数页面、数角色、数报表。到了收尾，总有些东西数不清，销售又不想把总价写得太高，就往最后一行一放，写个「其他费用」，具体多少不写。 这一行最省事的地方在于，它没有计量单位。服务器能按年算，短信能按条算，数据迁移能按张表算，其他费用按什么算，没人说得清。没有单位，就没有比价的基础，三家报价单拉到一起，这行只能空着。 更麻烦的是，三类钱经常混在一起。一类是确定会花、只是没算进模块的，比如首年服务器和域名证书；一类是可能花、要看现场情况的，比如接口联调和历史数据清洗；还有一类是开发方本来就该做的，比如部署、培训和验收范围内的修改。 三类钱混在一个词里，结算的时候就有了操作空间。甲方拿着一行总数，不知道哪笔该付、哪笔不该付，只能听对方解释。解释一次两次还行，项目做了半年，谁还记得当初是怎么说的。二、拆开看，里面通常装着四类钱第一类是账号和资质。域名、SSL 证书、微信认证、小程序主体认证、APP 开发者账号、地图商用授权、短信签名和模板报备，还有软件著作权和 ICP 备案的代办服务。单笔看着都不大，几百到几千，但没人提前列，最后就都从「其他」里出。第二类是资源和流量。云主机、数据库、带宽、对象存储、CDN 流量、短信条数、实名认证和 OCR 的调用量、电子签的份数。这些东西第一年常常由开发方垫着或者送一点，第二年续费就是甲方自己的事，报价单上不写清楚，预算里很容易漏掉。第三类是数据迁移。旧系统导数据、字段对应、历史数据清洗、重复客户合并、附件和图片搬过来，这些活最容易被低估。表少、数据干净，几天能做完；表多、字段乱、还有一堆手工补录的脏数据，做一个月也收
上周有个做建材批发的老板来找我，说系统上线四个月，仓库报了个 bug，出库单打印出来的数量对不上。他找开发公司，对方回了句这是新需求，要按变更收费，报价三千。他翻遍合同只看到 “免费维护一年” 六个字，气得想换人。 这种事我一年能碰上七八回，争执的点几乎都一样，合同写了免费维护，为什么修个 bug 还要钱。我的判断比较直接，收不收费跟验收过了多久、跟维护期写没写，关系都不大。决定性的问题是，这个错，在当初就该不该做对。一、先分清它到底是缺陷还是变更 行业里判断缺陷只有一条硬标准，拿已确认的需求文档、原型图、验收清单去对照。文档写了出库单要显示数量，程序显示出来了但算错，这叫缺陷，上线四年也该免费修。文档里压根没提出库单要打印，你现在要用，这是新增功能，收钱合理。 验收单签了字，也不等于开发方从此免责。签字只代表当时看到的功能符合清单，不代表以后发现的所有问题都归客户自己扛。但验收确实是条分界线，清单里明确标着 “本期不做”“二期实现” 的东西，上线后再要，那就是变更，别拿维护期去压对方。 最容易吵的是需求写得含糊那种，比如只写了 “支持库存查询”，没说要区分仓库、要不要显示批次。这种模糊地带谁签字谁吃亏，事后各说各话。我的经验是按业务能不能跑来判，不做这个业务根本走不通，算缺陷；做了更好用但不做也能跑，算优化。二、三分钟能判完的三个对照第一个对照看同类功能。系统里别的列表都能按日期筛选，唯独费用明细不能，这种不用翻文档，就是漏做。同一个系统里两套标准，本身就是开发方自己没对齐，截图发过去，一般没人敢辩。第二个对照看环境。换个浏览器、换台电脑、换个账号登录还是同样的错，大概率是程序问题。只有某一台电脑不行，先查本地缓存、网络、打印机驱动，这一类多半不该算开发方的账，折腾半天发现是客户端版本太老，双方都尴尬。第三个对照看时间线。问题是不是某个版本更新后才冒出来，或者某个第三方接口改版后才出现。版本更新带出来的叫回归缺陷，开发方自己改坏了，免费修没得说。第三方接口变了导致的，属于适配工作，收不收费要看合同当初怎么约定。还有一种常被忽略的情况，数据本身错了。客户自己导了一批错误的基础资料，报表数字跟着离谱，这时候修的是数据不是代码。开发方帮忙可以，按工时收点费用不算过分，别一上来就扣 “系统有 bug” 的帽子。三、真要谈钱，先把 bug 分级 不分级就谈钱，
一、监理不是来盯程序员的，很多人一开始就请错了 我见过一个客户，合同签完就找了监理，要求对方每天去开发公司办公室，盯着程序员写代码，发现 bug 就记下来。监理干了两个月，交了一份三十页的问题清单，开发公司照单全改，项目该延期还是延期，验收会该吵还是吵。 监理这个角色，本来就不管写代码。他管的是你这边的账，需求有没有形成基线、里程碑是不是真的完成、测试报告是谁出的、付款节点该不该签字。技术细节他当然要看，看的是交付物够不够，不是替开发公司做架构方案。 还有一种更常见的误会，把监理当项目经理用。客户自己没人牵头，指望监理组织开会、催进度、协调几个部门。监理没有这个权限，也没有这个义务，他只能把问题摆到桌面上，推不动就是推不动。你缺的是甲方项目经理，不是第三方监理。 请之前先想清楚自己缺什么。缺技术判断，可以请监理或者技术顾问；缺人组织协调，招一个项目经理更直接；缺的是心里那点安全感，多少钱都买不来。二、几万十几万的项目请监理，钱基本白花 小项目有个很明显的特征，一个供应商，标准产品改改，周期一两个月，功能清单二三十条，金额几万到十几万。这种项目请监理，光起步费就吃掉一大块预算。 监理收费一般两种算法，按项目金额的比例，常见的在百分之三到百分之八，或者按人月算。十几万的项目掏两三万请监理，占比接近两成，这笔钱加到测试上，或者压在尾款里，效果都比多一个旁观者强。 这个规模真正管用的是三件事。需求清单写到字段和按钮级别，验收标准写成能一步步操作的用例，尾款留一成到两成压三个月。老板自己花两个下午把这些捋清楚，比请人替你捋更靠谱。 监理的价值来自信息不对称和多方博弈，甲方不懂技术，乙方说了算，才需要有人在中间核对。只有一个供应商、你自己就能拍板的时候，监理没有发挥空间，最后干的活就是把你微信里的意见整理成周报。 钱花了，责任还在你身上。监理签了字，软件出问题照样是开发公司和你之间的事，别指望一张监理报告能顶雷。三、几十万以上、多供应商、政企项目，监理才真正起作用 判断要不要请，看三个条件就够了。合同金额几十万以上而且周期超过三个月，两家以上供应商同时进场，项目要过审计或者用的是财政资金，占上两条就值得认真考虑。 多供应商的场景最值钱。软件商说硬件没到位，硬件商说接口没人给，集成商说这事不在我范围内，三方开会三次没结论。监理把责任矩阵列出来，接口谁提供、字
一、培训要按角色来，别把所有人叫进同一间会议室 很多项目的培训现场是这样的，会议室坐满人，项目经理放 PPT，从登录讲到报表，一口气讲两个小时，下面的人低头看手机。讲完发一份 PDF，签到表一签，培训这一项就算交付完成。 问题在于，不同角色需要的操作根本不是一套东西。老板关心审批卡在谁那里、数据准不准；管理员要管账号、组织架构、基础资料；一线员工只关心自己那五步怎么走；运维要会备份、看日志、重启服务。把这些人放在同一间会议室听同一套内容，结果是谁都没学会。 培训要按角色拆开，小班讲，最好在测试环境里拿真实业务跑一遍。管理员学建账号、配权限、导基础数据；关键用户学本部门的完整流程；一线员工只学自己每天要重复的操作；运维学备份、恢复、日志和故障上报。每类人讲完当场练，练完签字确认。 培训排期也不要挤在上线前三天。管理员和关键用户提前两周学，才有时间导基础数据、核对权限；一线员工在上线前一周学，离实际操作近，忘得少。上线当天再讲，现场只够处理登录问题。 验收标准要落到操作上。让关键用户在没有开发人员站在旁边的情况下，独立完成一笔业务，从录入、提交、审批一直走到出报表。做得下来，才算培训过；做不下来，课时再长也是走过场。二、操作手册要能让人自己查，别只会堆截图 操作手册最常见的做法，是把系统每个页面截一张图，凑成几十页 PDF。培训当天看着很全，上线后没人翻，因为它只告诉人按钮在哪，不告诉人什么时候该点、点错了怎么办。 能用的手册按角色分册，每一册只写这个岗位会用到的流程。每个流程写清四件事，什么情况下用、前置条件是什么、步骤一二三、失败时看哪里。步骤里的菜单名和字段名要和正式环境完全一致，截图不能用开发环境的测试数据。 手册还要能搜索。目录按业务场景排，不按菜单层级排，比如报销、请假、入库、对账，让人从自己要干的事找到页面，不用在系统功能树里猜。常用流程配一个二维码或短链接，贴在工位上，比翻 PDF 快。 交付格式写进合同，给可编辑的源文件，不要只给锁死的 PDF。系统改版后手册要同步更新，很多公司吃过亏，系统升了三个版本，手册还是第一版，新员工照着做全是错的。 手册的更新责任也要有人担。系统每次发版，开发方更新对应章节，客户接口人确认，版本号和系统版本对齐。没有人担这件事，手册三个月就废了。三、异常场景不演练，上线第一周一定乱 正常流程讲得再顺，上
上个月一个做餐饮连锁的老板拿来两份报价，同一个会员系统，功能清单几乎一模一样，一家报 38 人天，一家报 76 人天。他没问技术，只问了一句，这是不是有一家在坑我。我把两份报价拆开对着看了一晚上，结论是都没坑他，这两份报价说的根本不是同一件事。一、一个人天里，装的不只是八小时敲代码 先把计量单位说清楚。人天是工作量单位，一个人干一天算一个人天，但它从来不等于八小时都在写代码。我们内部算有效工时按 6.5 小时，剩下一个半小时是开会、回消息、等环境、被上一版的 bug 打断。有的公司按 8 小时满打满算，有的按 6 小时，同一个项目光口径就能差出两成。 真正占时间的还有很多不写进功能清单的活。需求要一条条捋，原型要跟甲方对，接口要跟前端联调，测试环境要部署，上线那天要有人守着，交付前还要写部署文档和操作手册。这些活不产生页面，也不产生接口，但都吃人天。 拿一个最不起眼的功能举例。手机号登录加验证码，看着半天能做完。实际要接短信通道，要处理验证码有效期和重复发送，要防刷，要写清各种失败提示，要在 iOS 和安卓两端各测一遍，测试环境的域名还得先备案。规规矩矩做完，一个人天打不住。报价里只写「登录模块 1 人天」的，要么是真做过很多遍，要么是没打算把这些算进去。 还有一块最容易吵起来，返工。需求改一次，前面做的一半要推倒重来，改三次的项目我们见过不少。人天报价通常是按需求冻结之后算的，冻结之前改多少次、怎么计价，合同里不写清楚，后面就是扯皮。二、同样的功能，人天数为什么能差一倍 差距通常出在四个地方，跟功能清单没关系。先看是谁来做，一个做过五个会员系统的熟手，和第一次接触这类业务的新人，同样的模块差两三倍很正常。新人未必不行，只是熟手知道哪里有坑，不用边做边试。 再看有没有现成的组件。支付、短信、文件上传、消息推送、权限菜单，这些通用能力如果团队封装过，接进来配一下就行，没有积累的团队，每个项目从头写一遍。复用是合理差价，但要看清复用的是组件还是上个项目的整段代码，后者迟早要还债。 质量要求同样吃人天。能不能扛住活动峰值，有没有操作日志，权限做到菜单级还是按钮级，出问题能不能查到哪一步，这些都不在功能清单上。同一张页面，能点通和能上线是两回事。 最后是甲方配合。素材谁提供，第三方接口谁去谈，验收谁签字，这些问题拖一周，开发就停一周。有的报价把这块风险算
去年有个做物流的客户找我，说他们那套 TMS 上线半年，验收会开了三次都没过。我去他们办公室待了一下午，发现甲方项目经理是老板娘的弟弟，原来是管仓库的，现在每天泡在开发群里，问的都是缓存命中率、消息队列、索引优化这些词，听着挺专业。可我翻了半天，他没记过一次需求变更，没写过一条验收标准。合同附件是一个 Excel，四十七行功能，没有编号，也没有优先级。开发那边的需求池一百三十六条，两边对不上。 这项目不是做坏的，是管散的。甲方项目经理不需要看懂代码，需要的是四本账，范围、进度、变更、验收。每一本都能落在一张纸上，每周五更新一次。一、范围账：合同那 47 行，要能和需求池的 136 条对上 第一件事是把合同附件里的功能清单重新编号。四十七行就编 C01 到 C47，一行一个号，不改原文，只在后面加一列。然后让乙方把需求池拿出来，按 R001 往下编，再加一列对应合同编号。这一列空着的，就是合同外的新增；一列对不上两个号的，说明合同里那条被拆过；一个合同号对着一堆需求的，说明乙方拆得比合同细，正常。 这张表拉出来，通常当天就能看出问题。有的功能合同写了但需求池没有，那是漏做；有的需求池有但合同没有，那是有人口头答应了。两种都要当周摆到桌上说清楚，别等到验收再翻。 状态那一列也有讲究，不要用百分比。客户管理已完成百分之八十这种话没法验收，也没法追。用四个状态，未开始、开发中、待测试、已验收，每周五更新，谁改的谁署名，改完发群里。看这张表就知道项目走到哪，比听汇报靠谱。 还有两个细节容易漏。合同里写明免费修改包含几轮，原型两轮、UI 两轮、整体两轮，这个轮要落到表上，改到第几轮标出来，超了就是变更。谁提的需求谁签字，部门负责人签，老板在饭桌上口头说的，让对接人补一条微信确认再进表。口头需求不是不能做，是做完没人认账。二、进度账：别问做了多少，要能看见东西 这周做了多少，这个问题没有答案。做了多少是个感觉，看不见也摸不着。乙方说做了五个模块，你没法验；说接口联调完了，你也没法验。要问的是这周有没有东西能拿出来看，看到了才算数。 里程碑要绑交付物，不绑日期。原型阶段交原型文件，UI 阶段交设计图，开发阶段交接口文档和联调记录，测试阶段交测试用例和缺陷清单，上线前交 UAT 签字和部署记录。每个里程碑后面挂一个具体的文件名，不写完成开发四个字。 周会别在会议室
上周一个做食品加工的客户把三份报价单发过来，说功能清单看着差不多，一家报 8.6 万，一家报 15 万，还有一家报 24 万，问我选哪个。我把三份打印出来铺在桌上看了半小时，最便宜那份最后一行小字写着不含第三方接口费用及服务器，最贵那份把云服务器、短信、等保测评、首年维护全列进去了。 这三份报价其实不在一个口径上。报价单这东西只看总价，很容易签的时候八万六，做完十八万六。下面这几项，签合同前建议一条条问清楚。一、按人天报还是按功能报 报价单最上面通常写着一个总价，往下翻才看到计价方式。有的写按人天计，单价一千二，预计六十人天，有的写按功能模块打包，客户管理八万，订单管理六万。 按人天报的，要问清楚天数是谁估的，估的依据是什么，做超了怎么算。同样一个客户管理模块，一家估十五人天，一家估四十人天，单价再低也没意义。按功能报的，要把功能清单落到能数得清的程度，几个端，几种角色，多少个页面，多少张报表，导出格式有几种。清单写得越粗，后面扯皮的空间越大。 还有一种写法是按阶段付款但没写总人天，这种报价最需要警惕。因为做完第一阶段你才知道总共要花多少，后面再谈价，余地就不大了。二、那几行「不含」 报价单的备注栏是重点，很多钱都写在那儿，字还特别小。拿到报价单先别急着看总价，把备注栏和不含项那几行读一遍，这几行常常比总价更能决定最后的落地价。 第三方服务费最常见。短信按条计费，一条几分钱，一年几万条就是几千块；实名认证、OCR 识别、电子签、地图定位、语音通知，这些都要单独向服务商买；支付通道有费率，收款还要结算周期。服务器也常被写成不含，云主机加数据库加带宽加备份，一年几千到几万，取决于访问量和数据量。 接口对接是另一笔。跟 ERP 对接、跟财务软件对接、跟钉钉企业微信对接、跟税控对接、跟银行或快递对接，一个接口从几千到几万不等，报价单里常常只写一句支持对接第三方系统，具体哪几个、谁去协调对方开放接口，都没写。 政企项目还要多一项，等保测评和整改。系统要过等保二级或三级，测评费、整改费、安全设备，这些通常不在开发报价里，一笔就是几万块。三、变更怎么算钱 软件项目几乎没有不改需求的，所以变更单价一定要在合同里写死。写清楚按人天还是按次，后面每次提需求才有依据，免得每改一次都重新扯一遍。 常见写法是变更按人天计，单价就是报价单上那个人天单价，问题是很多人天单
上个月陪一个客户开验收会，原定一个小时，从九点半开到下午一点。甲方信息中心的主任把打印好的问题清单摊在桌上，二十七条，一条一条往下念。乙方项目经理翻了两页就急了，说这些需求里根本没写。两边来回争，饭都没吃，验收单最后也没签。一、验收标准写在合同里，不写在需求里 合同里那句「符合甲方需求」，看着稳妥，实际等于什么都没说。甲方理解的需求和乙方理解的需求，中间隔着一整轮沟通。等到验收会才把两边的理解摆到桌面上，不吵才怪。 真正管用的做法，是在需求评审之后补一份验收口径清单。每个功能点后面写清楚什么算通过，尽量能数出来。比如报表导出这项，写到导哪些字段、单次十万行、点下去五秒内出结果，而不是笼统写一句支持报表导出。 这份清单不用多正式，一页表格就够，但要在开发动手之前让双方项目负责人签字。签的是理解一致，不是法律效力。目的很简单，后面不管谁换了岗，翻出来还能对得上。 有些甲方觉得这么干太较真，好像一开始就防着乙方。其实反过来想，前期把话说细，验收那天反而轻松，大家都按一张纸说话，不用比谁的嗓门大。乙方也愿意，边界清楚了，后期加需求才好谈钱。 清单的写法也有讲究，一行一个功能点，五列就够，功能名称、操作步骤、预期结果、测试数据量、通过与否。别写成大段文字描述，验收现场没人有耐心读。凡是能用数字的都用数字，十万条、三秒、五个角色，这些才是能当场验的东西。二、演示环境都好看，真实数据一跑就露 验收会上最常见的场面，是乙方打开演示环境，点几下，页面顺滑，图表漂亮，甲方点头。然后有人提议登到正式环境看看，一登进去，列表转圈半分钟，导出直接超时。 演示库通常只有几十条造得干干净净的数据。正式库跑了一年半，八十万条历史单据，手机号带空格，日期格式有三种写法，同一个客户重复建了四次档。这些脏东西，写代码的人没见过，测试也没专门造过。 权限是另一个重灾区。演示用管理员账号，什么都能看。换成一线业务员登录，该看的看不到，不该看的全露着。验收时找三个不同角色的人各登一次，比看十页截图都管用。 所以验收别只在演示环境走流程。拉一份脱敏后的真实数据，把最重的查询、最复杂的导出、最常用的审批路径各跑一遍。跑不动的地方当场记下来，别等上线以后让用户替你测。 准备这份数据一般要甲方 IT 配合，从生产库导一个副本，把姓名、手机号、身份证脱敏，再灌到验收环境。这件事听着麻烦，做一次也
上个月有个做母婴用品的老板找我，说公众号、小程序、企业微信都开了，粉丝攒了一万多，可到月底盘客户，谁也说不清这些人到底买过什么、该谁跟进。客户在公众号里问过价，在小程序里下过单，又加企业微信聊过售后，可这三个地方的记录对不上号，系统都当他们是三个人。这不是他一个人的问题。我接触的中小企业里，十个有八个是这种状态：入口开得挺齐，客户管理还是散的。第一步，先搞清楚三个入口到底各管什么公众号是内容阵地。用户关注你，是因为想看你发的东西，他今天看明天可能就不看了，你只能靠推文和菜单栏触达他。小程序是服务窗口。用户需要下单、查订单、领券的时候打开它，用完就走，不会天天来。企业微信是关系链。销售或客服能加客户为好友，一对一聊，发消息不折叠，客户离职了资源还留在公司。 这三个东西本来就不是替代关系。公众号负责让人认识你，小程序负责让人找你办事，企业微信负责把客户变成熟人。想用一个入口包打天下，多半哪个都没做好。第二步，看清各干各的，客户就悄悄丢了 三个入口数据不通，是最常见也最致命的问题。公众号看得到粉丝数，看不到他的订单；小程序看得到订单，不知道他是不是刚在公众号里留过言；企业微信里聊得热火朝天，却没有他过去半年买了什么的记录。 客户身份对不上是第二层。同一个人，在公众号里是 "用户 A"，在小程序里是 "会员 B"，在企业微信里叫 "王姐"，三个系统各自为政，等于把一个客户拆成了三个人管。 运营也跟着重复。这边公众号小编发活动，那边小程序团队做优惠，企业微信再群发一遍，客户收到三遍同样的内容，烦不烦。最怕的是老板还以为自己触达得挺勤快。第三步，打通的关键，是先把客户身份统一起来 微信生态里有个现成的工具叫 UnionID。公众号、小程序、企业微信挂在同一个开放平台主体下时，同一个微信用户的 UnionID 是一样的，靠它就能把三端的身份对起来。 UnionID 对不上的时候，手机号兜底。客户在小程序下单留了手机号，公众号关注时也绑了手机号，两个一比对，人还是那个人。 落地的顺序别搞反。先建统一的客户档案，一个客户一条记录，把来源、标签、订单、跟进历史都挂上去；再按渠道打标签，知道他是公众号来的还是活动拉来的；最后才是把各个入口的数据往这个档案里喂。一口吃不成胖子，先打通最赚钱的那条线，比如 "小程序下单 + 企业微信跟进"，比三个入口一起折腾强得多。第四步，
在线
电话
微信
需求
TOP