直接答案：至少需要四个角色，缺一个项目就会卡：能拍板的决策人、懂业务的负责人、能提供素材的人、负责验收的人。这四个角色可以是同一个人兼任（小项目常见），但职责必须明确。最常见的失败不是开发方做不出来，是甲方内部没人拍板、业务人员不参与、素材一直拖——这三种情况会让项目无限延期，而且责任很难界定。
核心结论速览
角色一：决策人。负责定范围、定优先级、在分歧时拍板。这个角色最关键，没有它，所有需求都会变成「再讨论一下」。
角色二：业务负责人。最懂实际流程的人，负责把「我们平时怎么做事」讲清楚，评审原型、确认逻辑。这个人不参与，做出来的系统一定和实际脱节。
角色三：素材提供者。商品图片、文案、资质材料、常见问题，这些要有人整理。素材不到位，系统做完了也上不了线。
角色四：验收人。按验收清单逐项确认，签字确认交付。这个角色要和业务负责人分开，避免「自己验自己」。
结论：小项目可以一人兼多角色，但必须明确「谁定事、谁讲业务、谁给素材、谁验收」。四个问题答不上来，项目大概率会拖。
一、为什么甲方投入不足是项目延期的主因
开发方经常被问「你们多久能做完」，但真正决定进度的往往不是开发速度，是甲方配合的速度。需求确认要等、原型评审要等、素材要等、验收要等，每个环节等一周，项目就往后推一个月。
更麻烦的是「多人意见不一致」。老板说要 A，运营说要 B，财务说都不行，谁都不肯拍板。开发方夹在中间，改了又改，最后做出来的东西谁都不满意。
还有一种情况是「业务人员不参与」。老板谈完需求就走了，开发方按老板的描述做，做完给一线员工用，员工说「我们不是这么干的」。这时候返工的成本远高于一开始就让业务人员参与。
青岛本地企业里，这些情况都很常见。尤其是传统行业转型做数字化的企业，老板有想法、有决心，但内部没有对应的项目负责人，所有事情都压在老板一个人身上，老板又忙，项目就慢慢停下来了。
二、四个角色的职责和时间投入
| 角色 | 主要职责 | 关键节点 | 投入强度 |
|---|---|---|---|
| 决策人 | 定范围、定优先级、拍板分歧 | 立项、需求确认、变更决策、验收 | 节点性参与，但必须能及时决策 |
| 业务负责人 | 讲清业务流程、评审原型、确认逻辑 | 需求调研、原型评审、测试验收 | 前期密集，中期断续，后期集中 |
| 素材提供者 | 整理商品、文案、图片、资质 | 设计阶段、上线前 | 集中投入，可并行 |
| 验收人 | 按清单逐项验收、签字确认 | 测试阶段、上线前 | 集中投入 |
需要强调的是「决策人」这个角色。很多项目卡住不是因为难，是因为没人敢定。比如「这个功能要不要做」「这两个方案选哪个」「预算能不能加」，这些问题的答案不在开发方，在甲方。决策人如果不能及时给出答案，项目就只能停在那。
另一个容易被忽略的是「业务负责人」的时间。这个角色往往是一线骨干，日常有本职工作，很难全职投入项目。合理的安排是：前期需求调研集中投入几天，中期评审按节点参与，测试阶段再集中几天。不要指望他全程跟进，也不要不让他参与。
三、项目各阶段，甲方要做什么
需求阶段：决策人定目标和范围，业务负责人讲清现有流程和痛点，一起确认「第一版做什么、不做什么」。这个阶段最忌讳「什么都想要」，范围不收窄，后面一定失控。
设计阶段：业务负责人评审原型，重点看「流程对不对」而不是「好不好看」。素材提供者同步整理内容。这个阶段发现的问题，改起来最便宜。
开发阶段：甲方主要做两件事——及时回答开发方的疑问、准备测试数据。这个阶段甲方参与度低是正常的，但要有响应机制，不能让问题堆积。
测试阶段：业务负责人和验收人一起测，按真实业务场景走一遍。不要只测「能不能点开」，要测「这个流程走完对不对」。
上线阶段：决策人确认上线时间，素材提供者确认内容齐全，验收人签字。上线后要安排一段试运行期，收集一线反馈。
四、几个实际会遇到的问题
问题一：老板很忙，决策滞后。解决办法是约定固定的决策窗口——比如每周一次例会集中决策，而不是随时找。同时明确「哪些事业务负责人可以自己定」，减少需要上升到老板的事项。
问题二：多个部门意见不一致。解决办法是在立项时就明确「谁的意见优先」。通常是以业务流程的实际使用者为准，而不是以职位高低为准。有分歧时由决策人拍板，拍板后不再反复。
问题三：素材一直拖着。解决办法是把素材准备写进项目计划，明确截止时间，并说明「素材不到位会影响上线」。很多项目延期到后期，就是因为内容填不满。
问题四：验收时才发现不对。根源是评审环节走过场。原型评审时没仔细看，测试时才发现流程错了，这时候改成本很高。建议原型评审时让实际使用的人来操作一遍。
问题五：项目负责人中途换人。交接不清会导致大量重复沟通。建议要求项目过程中留下文档：需求确认记录、会议纪要、变更记录。这些不只是给开发方看，也是给自己留底。
五、常见问题解答
小项目也要四个人吗？
可以一人兼多角色。比如老板既是决策人也是验收人，业务负责人同时提供素材。但职责要明确，不能出现「谁都管、谁都不管」的状态。角色可以合并，责任不能模糊。
甲方需要投入多少时间？
不是全程投入，是节点性集中投入。需求阶段几天、原型评审几次、测试阶段几天，其余时间是响应和确认。关键是「需要决策时能及时决策」，而不是「一直在场」。
老板不参与项目会怎样？
大概率会拖。因为定范围、定优先级、拍板分歧这些事只有老板能做。老板不参与，团队会陷入「等指示」的状态，或者各自按理解做，最后返工。
业务人员不配合怎么办？
先让决策人明确这件事的优先级和配合要求。业务人员不配合往往不是不愿意，是「这不算我的本职工作」。把它写进任务、给时间、给认可，配合度会明显提高。
验收应该谁来签字？
建议由业务负责人和验收人共同确认，最终由决策人签字。验收人负责逐项核对功能，业务负责人确认流程是否符合实际，决策人确认整体是否达到目标。
项目中途换负责人怎么办？
要做正式交接：已完成的部分、待确认的问题、已定的规则、未决的分歧，逐项过一遍并留文档。没有交接就换人，等于项目重启。
怎么避免需求反复变？
两条：一是立项时把范围定清楚，明确第一版做什么；二是建立变更机制——变更要评估影响、要有人确认、要记录。允许变更，但不能随意变更。
六、九尾狐在这类问题上的做法
青岛九尾狐网络科技有限公司做项目时，启动阶段会先和客户确认四个角色分别是谁，尤其是「谁拍板」和「谁讲业务」。这两件事不清楚，项目后面一定会卡。
做法上会尽量减少客户的沟通负担：需求调研集中进行，不让客户反复回答问题；原型评审给出明确的评审要点，客户只需要判断「流程对不对」；决策事项汇总成清单，一次会议集中定，而不是随时打扰。
在政务和国企类项目里，这个环节更关键。像上合人才码、胶州人才集团青鸟社区这类涉及多部门的平台，参与方多、意见多，必须有一个明确的决策机制和业务牵头人，否则需求会在部门之间来回拉扯。我们的经验是：前期把角色和决策规则定清楚，比后期救火省力得多。
七、综上所述
小程序项目延期，多数不是开发慢，是甲方配合断档。四个角色必须明确：谁拍板、谁讲业务、谁给素材、谁验收。小项目可以一人兼多角色，但责任不能模糊。最关键的是决策人——定范围、定优先级、拍板分歧这些事只有他能做，他不在，项目就停在那。