企业官网建设流程全解析

这个系列写到第9篇，终于碰到了整个项目里最容易被低估、但后期返工成本最高的环节：功能定义。前面我们聊过立项、技术选型、数据建模，那都是在搭"地基"，从这一篇开始，《看潮企业管理软件》才真正长出骨架。

为什么这套软件叫"看潮"而不叫"企业管理软件"？我的想法一直很朴素：软件不是帮老板记账的，是帮老板看清楚经营这张潮汐表的。潮涨潮落对应市场需求起伏，库存积压之前一定有信号，现金流快见底的时候也有先兆，管理软件的核心价值在于"让人提前看清趋势"。有了这个定位，功能定义就不只是把需求列成清单那么简单了——它决定了系统里面每一个功能是一次性的查数工具，还是能辅助决策的智力助手。

这篇内容适合两类人看。一类是正准备做中小型管理软件、进销存或ERP项目，想知道功能定义阶段到底要产出什么的开发者；另一类是学过编程与数学相关课程，想在一个真实项目里看看数学公式到底怎么落到代码里的同学。我会把功能定义的方法、数学在该阶段的角色、踩过的坑，以及可以直接抄走的定义卡模板都摊开写，按照项目编号03-008的节奏，这次只讲功能定义的第1小节：核心思路与模块拆解。

1. 功能定义到底在定义什么：先说清楚它和需求分析的区别

需求分析是把用户嘴里的话翻译成"他想要什么"，而功能定义是把"他想要什么"翻译成"开发能照着做、测试能照着验、用户能照着用"的东西。很多人把这两个阶段混在一起，导致需求文档写了50页，开发拿到后依然不知道怎么建表、不知道一个按钮点击之后系统内部该发生哪几个动作。

1.1 从"老板想看趋势"到"一个可开发的功能条目"

随便举一个《看潮》项目里的原始需求："老板想看销售趋势。"

这句话如果直接丢给开发，开发会有一百个问题：趋势按天算还是按月算？按订单金额算还是按回款金额算？包含退货吗？数据从哪个表取？展示成折线图还是柱状图？看不看得见明细？哪些角色能看？

功能定义要做的事情，就是把这一句话，变成一个带角色的、带数据来源的、带计算规则的、带展示形式的功能条目。落到项目里长这样：

• 功能名称：月度销售趋势看板
• 用户角色：总经理、销售总监
• 业务目标：及时发现业绩上涨或下滑的拐点
• 数据来源：sales_order表，取订单状态为"已完成"的记录，历史数据保留12个月以上
• 处理规则：按自然月聚合订单金额，同时计算本月环比（(本月金额-上月金额)/上月金额）和同比（(本月金额-去年同月金额)/去年同月金额）
• 展示形式：近12个月销售额折线图，配环比、同比数值卡片
• 非功能要求：页面加载不超过2秒，仅高管角色有查看权限，进入页面时默认显示最近12个月

这条写完，前后端开发、测试、产品、老板之间有了统一的语言。前端知道要画什么，后端知道查哪张表、聚合口径是什么，测试知道用例该怎么设计，老板也知道界面大概长什么样。这就是功能定义的核心价值：把模糊变成可执行。

1.2 功能定义卡：让每一条需求都有"身份证"

在《看潮》项目里，我定义了一套统一的功能定义卡，每个功能必须填满这张卡才允许进入开发排期。刚开始团队嫌麻烦，说"这不是多了一层官僚流程吗"，后面发现这套卡片是救命的，因为每一次需求变更、每一轮测试回归，都要靠它做基线。

定义卡的标准字段我列在这里，可以直接抄走：

每张定义卡就相当于功能模块的最小单元。后面开发排期、测试用例编写、用户手册编写全部从卡片里派生。我们在第一版功能定义阶段一共产生了47张这样的卡片，每个卡片都有独立编号，需求变更时只动对应的卡片，不会出现改了一个口径、连累一片功能的情况。

1.3 数学在这个阶段扮演什么角色：三个真实场景里的"翻译学"

课程编号03-008既然叫"编程与数学"，那功能定义阶段最值得讲的就是数学怎么介入。我的经验是，数学在功能定义里主要起三种作用：统一口径、提供决策模型、划定算法边界。

统一口径靠的是公式。比如"毛利率"这个词，财务说它是 "(营业收入-营业成本)/营业收入"，销售说它是 "（售价-进货价）/售价"，两个人说的都是"毛利率"，数字就是不一样。功能定义时如果不用数学公式把口径锁死，开发出来报表两边都不认。

提供决策模型靠的是算法。库存该什么时候补、补多少，销售趋势下个月会是什么走向，生产排产怎么最省成本——这些问题本质都是数学问题，功能定义阶段要决定选哪把"尺子"去量它。

划定算法边界同样重要。不是所有功能都需要上复杂模型，功能定义阶段就决定了"这个功能算到哪一步为止"，比如库存预警只做到"超阈值提醒"还是做到"自动生成采购建议单"。数学的复杂度和技术实现成本直接挂钩，这一步想不清楚，后面就是无底洞。

2. 核心功能模块拆解：看潮软件四个主战场的设计思路

《看潮》第一版的目标很明确：做一套中小型商贸企业能直接用起来的管理软件，覆盖销售、采购、库存、财务四个核心业务域。这四块不是凭空想出来的，而是从"企业每天要回答什么问题"倒推出来的。

2.1 经营仪表盘：指标计算口径比图表样式重要一百倍

经营仪表盘是所有人打开系统见到的第一个页面，也是"看潮"这个名字最直接的体现。但仪表盘最难的从来不是图表画得多炫，而是上面每一个数字的来路都经得起追问。

我定下的核心指标并不多，就六个：今日销售额、本月累计销售额、销售额环比、销售额同比、库存周转天数、应付账款账龄。每一个指标在定义卡里都写死了计算公式：

• 今日销售额 = 当天订单状态为"已完成"的订单金额合计（不含已退款订单）
• 本月累计销售额 = 本月1日0时至当前时间内的已完成订单金额合计
• 库存周转天数 = 360 ÷ (出库成本 ÷ 平均库存成本)，其中平均库存成本取月初与月末库存成本的均值
• 应付账款账龄 = 当前日期 - 采购发票最迟付款日，逾期超过30天标红显示

这里有一个真实的教训。项目里销售部和财务部对"销售额"的理解完全相反，销售部按"订单日期"统计，财务部按"开票日期"统计。平时各自看没问题，一旦老板开周会把两个数字放一起，差了十几万，会议室当场就吵起来了。后来解决方案就是功能定义阶段增加了一个全局参数：系统全局销售额默认按订单日期统计，开票日期统计可以作为筛选条件，但两个口径必须在界面上明确标注。数字可以不同，但每个数字都得说得清楚自己是哪个口径。

图表选型其实也是一个数学问题。时间序列数据用折线图展示变化趋势，部门结构对比用横向柱状图，费用构成用占比堆叠图。选错图表类型不是审美问题，而是会误导判断。比如用饼图展示12个月的销售额分布，读者会陷入"每个扇区都很小"的认知负担，远不如一条折线直观。这个原则我直接写进了仪表盘功能定义卡的规范里。

2.2 销售趋势模块：用最小二乘法做出第一个"预测"型功能

销售趋势预测是《看潮》软件和普通进销存拉开距离的地方。不过先说明，我这里不是要讲ARIMA、LSTM这些重型模型，而是从一个中小企业可落地的角度，选了一个性价比最高的工具：一元线性回归加移动平均的组合。

数学公式很简单。一元线性回归假设销售额和时间存在线性关系：

y = ax + b

其中 y 是预测销售额，x 是时间序号，a 是斜率，b 是截距。用最小二乘法拟合，参数通过以下公式求出：

a = Σ(xi - x̄)(yi - ȳ) / Σ(xi - x̄)² b = ȳ - a·x̄

这里 x̄ 是x的均值，ȳ 是y的均值。在功能定义阶段，我把这个算法写成了技术方案文档，然后开发用Python做了个快速验证版本，核心代码大概是这样：

import statistics def linear_trend(data): x = list(range(1, len(data) + 1)) x_mean = statistics.mean(x) y_mean = statistics.mean(data) numerator = sum((xi - x_mean) * (yi - y_mean) for xi, yi in zip(x, data)) denominator = sum((xi - x_mean) ** 2 for xi in x) a = numerator / denominator b = y_mean - a * x_mean return a, b sales = [8230, 9110, 8700, 10200, 11600, 12400] a, b = linear_trend(sales) next_month = a * (len(sales) + 1) + b print(f"斜率: {a:.2f}, 截距: {b:.2f}, 下月预测: {next_month:.0f}")

还有一重保障是移动平均平滑。用最近三个月的均值去抹平季节性和偶然波动，和线性回归结合使用。到底是取3个月还是6个月的窗口，功能定义阶段定为可配置参数，而不是写死在代码里，这个决定在后面上线时帮了大忙——不同行业的业务波动周期差异很大，写死了就只能眼睁睁看着预测结果被人吐槽。

我必须强调一点：预测功能在定义卡验收标准里，不能写"预测准确率达到90%"，这是给自己挖坑。我在项目里写的是"系统展示预测值的同时，同步展示历史实际值对比图和预测置信区间"。前者是承诺了不可能保证的事，后者是提供了理性使用的依据。功能定义阶段就划清这个边界，后面省掉无数场关于"为什么预测不准"的扯皮。

2.3 采购与库存模块：EOQ和安全库存的落地逻辑

库存管理是数学公式密度最高的模块，但大家对它的误解也最深。我见过有人直接照书抄经济订货量公式，结果算出采购数量比仓库容量还大；也见过有人完全不信公式，永远凭经验订货，结果高库存吃掉利润。实际情况是，公式有用，但要用对前提。

经济订货量EOQ模型解决"每次订多少最划算"的问题，公式是：

Q* = √(2DS/H)

其中 D 是年需求量，S 是单次订货成本，H 是单位商品年持有成本。用一个实际算例：某商品年销量12000件，单次订货成本500元，单位年持有成本12元，代入算出：

Q* = √(2 × 12000 × 500 / 12) = √1000000 = 1000件

也就是说每次订1000件时，总成本最低。这个公式的价值不是给一个精确最优解，而是给决策者一个"量级感"——你每次订货是500件还3000件，哪个方向偏离合理区间，心里立刻有数。

安全库存解决的是"提前期内需求波动怎么办"的问题，公式是：

SS = Z × σ × √L

其中 Z 是服务水平对应的正态分布系数，95%服务水平对应Z=1.65，σ 是提前期内日需求量的标准差，L 是订货提前期天数。算例：σ=20件，提前期L=7天，则安全库存 = 1.65 × 20 × √7 ≈ 87件。在实际定义功能时，我把这个公式做成一个可配置项，企业可以自己填服务水平等级，然后系统自动算Z值，不用使用者去查正态分布表。

重新订货点的公式是：

ROP = d × L + SS

也就是提前期平均需求 d×L 加上安全库存。在《看潮》里，库存模块功能定义卡上就写清楚：系统每天检查所有SKU的实时库存，当库存低于ROP时，在采购建议列表中生产一条补货建议，建议数量按照当前策略与EOQ计算值取接近值。整个链路是数学公式驱动业务流程，而不是设计一个人每天盯着库存表肉眼看。

单说这个模块，我就遇到过经典算例和实际完全对不上的情况。后来分析原因，是某些供应商的最低起订量远高于EOQ计算结果，还有一些商品的持有成本被严重低估。解决办法是在功能定义阶段就加上两个约束条件：最低起订量和最大仓储容量。也就是说算法输出的是"建议值"，但会经过约束校验，超限时直接提示原因。数学公式负责找方向，业务规则负责守边界，这两者不是替代关系，是配合关系。

2.4 成本分摊与核算：权重公式是跨部门吵架的终结者

财务模块里最值得数学介入的是成本分摊。举个典型场景：某贸易公司有三个产品线，共用仓库、共用物流车辆、共用办公室，每个月的仓储费、物流费、行政费用是一个总额。问题是月底要把这些费用分到三个产品线头上计算利润，怎么分才公平？

按人头分、按订单数分、按收入占比分、按占地面积分——每个部门都有一套对自己有利的分法。这种情况我在项目里见过太多。制造业的例子也类似：一条产线生产三种产品，总水电费和设备折旧怎么分配到sku级？

功能定义阶段能做的，就是把这些分摊规则直接定义为算法公式。我采用的是最容易被接受的方式：按"成本动因"分摊。比如仓储费按各产品线月均库存金额占比分摊，物流费按各产品线订单重量占比分摊，行政费用按各产品线收入占比分摊。

公式统一长这样：

分摊费用_i = 总费用 × (动因值_i / Σ动因值)

用一个表算清楚：

这个功能定义的价值不在于算法多高级，而在于把"怎么分"这个争议提前锁死。财务每个月按这个规则跑一遍，部门之间有疑问就把公式和原始数据甩出来对照，吵架成本瞬间降下来。

这类"分段计算"的规则在工资模块里更明显。个人所得税是典型的分段税率结构，比如应纳税所得额不超过一定额度按3%征收，超过部分按10%、20%逐级跳转。用一个速算扣除数的数学公式就可以把分段函数压缩成一行计算逻辑：个税 = 应纳税所得额 × 对应税率 - 速算扣除数。如果没有这种数学抽象，代码里就会写一大段if-else，还容易出错。功能定义阶段一个核心任务就是寻找业务规则背后的数学表达，能用公式表达的，就不要用分支判断硬怼。

3. 数据模型与权限设计：功能定义里最容易翻车的两个暗礁

功能定义阶段人们容易犯一个致命错误：只定义"功能好不好用的样子"，不定义"数据从哪来到哪去"。但数据恰恰是功能能否成立的前提。我在这个项目里花了大量时间做"从功能反推数据表"这件事。

3.1 从功能反推数据表：先有单据，再有报表，次序不能倒

很多人设计系统时习惯先画界面，界面画完再想数据表。正确顺序是反过来的——先梳理公司每天会产生哪些单据，单据之间存在什么流转关系，数据表就自然而然出来了。

拿《看潮》来说，销售模块功能定义直接决定了销售订单表的结构。我在定义卡里写了一个功能叫"创建销售订单"，它的处理规则包含：选择客户、添加商品、锁定单价、填写数量、自动计算金额、登记收款方式。每一条规则就对应一个字段或一次计算逻辑。订单主表需要客户ID、订单日期、订单状态、总额；订单明细表需要商品ID、单价、数量、行小计。金额自动计算靠的就是业务与数学的简单约定：行小计 = 数量 × 单价，总额 = Σ行小计。

采购入库会影响库存余额，销售出库也影响库存余额，但库存表不能只是"当前库存数字"，它必须有一张完整的库存流水表记录每一次变动。功能定义里写了"库存变动可追溯"，数据库就天然需要一个inventory_transaction表：时间、商品ID、变动类型、变动前数量、变动数量、变动后数量、关联单据号。这个设计就是在功能定义阶段敲定的，它是"看潮"这件事的技术底座——没有流水，哪有潮汐可看。

我给团队立了个规矩：任何报表功能，一定要先能找到它依赖的底层单据和流水表。报表是"果"，单据是"因"。从果推因，功能就不会悬空。

3.2 角色权限矩阵：每个列表页的SQL都要带上的条件

另一个翻车高发区是权限。很多小企业的管理软件一开始不做权限设计，结果上线之后人人能看销售额、人人能导客户名单、甚至人人能看工资条。《看潮》在功能定义阶段就做了完整的RBAC权限模型，文档里直接画了一张角色权限矩阵。

矩阵看着简单，但背后隐含了三种级别的权限控制：功能级（能不能点进这个页面）、数据级（列表SQL自动带上的过滤条件）、字段级（同一张表，成本和售价对销售员不可见）。数据级权限做起来最容易被忽略，但影响最大。销售总监只能看自己团队的数据，这个规则一旦定了，销售数据列表的查询SQL就会固定拼接一个"team_id = 当前用户所在团队"的条件；老板不受限制，额外加一个白名单判断。

业务字段权限里最难处理的是成本信息。一张销售订单列表，销售员看到的是售价和销售额，老板看到的是成本、毛利和毛利率。功能定义阶段就明确"成本字段仅财务和高管角色可见"，这个规则直接落实到后端接口层，而不是靠前端隐藏。前端隐藏只是消灭了界面入口，后端不控制的话，接口一把梭全部数据都返回了，权限就是摆设。

3.3 功能优先级与版本规划：MVP不是什么都做，而是什么都砍得明白

《看潮》第一版功能清单列出来的时候有60多个功能点，真要全部开发完，团队要到年底才能上线。在功能定义阶段就必须用理性方法砍需求：MoSCoW法则。四个字母分别代表Must（必须有）、Should（应该有）、Could（可以有）、Won't（这期不做）。

M类功能：销售订单管理、采购订单管理、库存管理、应收应付管理、经营看板的基础指标。这些是业务运转的底座，缺一个系统就转不起来。

S类功能：销售趋势预测、库存预警、毛利分析、客户对账。它们很重要，但没有M类那么生死攸关，可以作为M1版本交付后一个月内快速迭代的功能。

C类功能：多币种结算、多仓库调拨、自定义审批流。这些功能有价值，但当前主要客户用不上，放到M2甚至M3再说。

W类功能：CRM客户全生命周期管理、完整OA审批、移动端App。这一版明确不做，避免团队把精力耗在边缘场景上。

每个功能定义卡上都加了一个字段"目标版本"，研发排期时直接按版本号筛选。这套做法在项目进行到后面时，价值尤其大。第10篇我会接着讲功能定义第2小节：具体到《看潮》的模块拆解结果和数据库结构如何从功能卡中长出来，这篇先把"功能定义"这件事本身讲透，可以说它是整个项目最省时间的投入。

4. 功能定义阶段的四个大坑，我替你踩过了

这些坑没有写进任何教科书，全是项目实战里真金白银换出来的。分享出来，希望你能少走几步弯路。

4.1 过度设计：一条需求的两种死于方式

见过太多团队死在"想得太美"上。某创业团队做一个进销存项目，功能定义阶段非要加入自定义字段、可视化流程引擎、多租户隔离，理由是"以后客户肯定会要这些"。结果是团队花了好几个月去搭一个无比重的基础框架，连采购单和库存都还没打通，公司现金流撑不住了。对中小规模管理软件而言，"预留扩展空间"不等于"现在就做扩展"。

具体到《看潮》的做法是：允许在关键数据表上预留2到3个扩展字段，但不设计动态字段功能；流程审批固定支持"提交-审核-驳回"三级，但不做可视化流程设计器；多租户只预留tenant_id字段，不做独立分区和隔离层。这些决定的理由非常实际——第一版最大的敌人是"永远上不了线"，而不是"以后扩展要加班改代码"。

4.2 数据和算法脱节：好公式也需要好数据来养

这个坑在趋势预测模块差点踩进去。一开始我想用较复杂的模型来拟合销售数据，后来盘点了一下目标用户的实际情况：很多小微企业系统里只有过去几个月的数据，有的甚至只有几十个SKU的订单记录，样本量根本支撑不了复杂模型。硬上复杂模型的结果就是输出结果完全没有参考意义，业务部门直接抛弃这个功能。

后来我把策略调整为分级方案：有12个月以上历史数据的客户，启用趋势预测模块，用一元线性回归加移动平均；数据不足6个月的客户，只提供同比环比统计，不做预测；数据介于两者之间的，提供移动平均展示但不承诺预测结果。这个"看数据下菜碟"的思路在功能定义阶段就写进了方案文档，上线时的接受度高了很多。

4.3 没有验收口径：功能做完了但没人敢说"完成了"

"库存预警功能你做完没？""做完了。""那测试为什么没过？""测试说预警时机不对……"这个对话的根源是定义卡里没有写验收口径。后来我在每个功能定义卡里增加了上面表格里提到的"验收标准"字段。以库存预警为例，标准写的是：

用户设置某SKU的安全库存阈值后，系统在库存低于阈值时，在库存列表页展示红色预警标记，同时可触发采购建议提醒；预警状态在库存补货入库后自动解除；预警规则对全部SKU可见，修改权限仅限管理员。全部符合，才算完成。

这个标准让开发和测试都有了"尺子"。测试不再用模糊感觉找bug，开发也不必反复确认需求。卡上写清楚，整个交付节奏提速了接近30%。

4.4 评审自测：团队开功能评审会时过一遍的关键问题

功能评审会的价值完全取决于问什么。我给团队整理了一个问题清单，每个功能定义卡过会时逐条过：

这些问题30分钟可以过一遍。提不出来这些问题的团队，不是大家不努力，而是没人站在"这个功能将来要被人骂还是被人夸"的角度去看它。

5. 给正在设计企业软件的你：马上能做的三件事

看到这里，你对功能定义已经有了系统认识。如果手头刚好有一个软件项目正在启动，这三件事现在就能做，不用等团队凑齐。

5.1 画一张功能地图

拿一张A3纸或者一块白板，横轴写角色，纵轴写业务模块。把每个模块和角色交叉点上标出功能：这个角色在这个模块里能做什么、不能做什么。这张地图画完，模块边界和权限框架同时有了。一张好地图胜过50页需求文档。

《看潮》的功能地图我画了三版，第一版模块之间有重叠（销售和财务都想管应收账款），第二版权限含糊（所有人都有权限看库存），第三版才清晰。画图的过程自己就会暴露这些矛盾，这就是它最大的价值。

5.2 写一份数据字典草稿

不用急着写数据库建表语句，先把每个业务名词的字典定义写清楚。比如客户ID、订单类型、出库方式、库位编号，这些词一旦在定义卡里出现，字典里就要有解释。字段的候选值也要写清楚，订单状态是1还是paid，是要统一约定的。这份草稿是开发、测试、产品三方对话的公共词汇表，避免协作时鸡同鸭讲。

5.3 用Excel做一个纸上原型验证

很多人以为画原型必须用专门的工具，其实Excel完全够用，甚至更快。把界面画成Excel里的表格和图形，配上几行假数据，找业务方走一遍业务流程，过程里会发现大量逻辑漏洞。纸上原型最大的优势是便宜：发现问题改格子比改代码快一百倍，而且没有任何技术债。

在《看潮》项目里，"创建销售订单"这个核心流程，就是通过纸上原型推翻了三次设计。第一次发现库存不足时不知道在哪里提示，第二次发现订单审核人和下单人不能是同一人已经开始流行，第三次才确定整个流程横跨三个页面两步操作。如果直接写代码，每一次推翻都意味着返工，而在Excel里，改动只需要几分钟。

结尾最后给我带来深刻体会的事

最后分享一件我做项目过程中的真实体会。早期我也跳过功能定义阶段，拿到需求就直接上手写代码，因为觉得"客户要什么先做出来给他看再说"。结果做了一个多月，表结构改了三轮，前端页面推倒重来两次，团队成员加班到崩溃，最后还是回到功能定义的老路上，重新整理了全套定义卡才把项目拉回正轨。

从那以后我养成了一个习惯：任何一个新项目，无论大小，第一周一定只做一件事——把需求嚼碎，然后塞进一张张功能定义卡里。算式可以错，方案可以改，但"这个功能到底要解决什么问题、谁来用、怎么算、算完干什么"这四个问题必须一开始就答清楚。因为工具选错了可以换，方案设计错了可以改，但功能定义阶段的模糊，会在开发、测试、验收、上线的每一个环节加倍奉还。

如果你也在做类似的管理软件，欢迎照着这套模板走一遍，有什么新想法或者踩到什么新坑，回头再来一起聊。