研发这四年来给老板和外界部门的体感不太理想，开发速度慢、返工多、功能模块不能复用。
造成问题有以下原因：
- 老板需求紧急，给的交付期限非常有限，最后担心做不完交付质量受影响。
- 产品思考不深入，写的文档不具体，只是简单传达需求。
- 研发专注于业务代码，技术架构考虑不足，扩展性、维护性都有待提高。
站在各自角度，我能分析他们这么做的原因和面临的困境。
- 老板：市场是变化的，必须快速做出响应，要的东西越快越好。
- 产品：这是产品能力有限，产品思维不足，做事深度不够，不能把老板脑子里抽象的概念具象化，交付给研发更完善的产品文档。
- 研发：基于产品文档实现功能，问题是文档质量不高，产品层面就要不停的返工，业务细节更是模棱两可，要研发自己猜测，时间都用在推测老板需求上，猜错了就返工代码上，没有时间想技术架构。
每方都有的局限，如何破局？我结合最近的项目聊聊我的做法，这也是一个任务众包项目，老板希望我们结合 AI 从 0 做一套任务协作系统，包含 H5 和 Admin，交付周期 7 天。
原始流程
- 产品以众包平台为核心写了个背景文档和产品文档，AI 痕迹明显，可用信息不多。
- 老板、产品、研发一起开会过这个背景和文档，讲了很多不够具体的内容，上万行的文档，一次会议就过完了，没有评审、拆任务环节，只知道交付周期 7 天。
- 研发没办法，条件反射的问那要做什么东西，分了几个抽象的领域，开始写代码。
- 写的时候业务流程一点不知道，AI 写什么就是什么。
2 天后我们做完了 Admin 后台功能，但只保证了从前端接口到后端服务器的调用，没有业务逻辑。
我对这个过程非常困惑，这样做出来的东西，真的是老板想要的吗？他真实的目的是什么？
于是我放下来代码，从背景开始，重新思考整个流程。
优化流程
核心目的
首先我要搞清楚，我们做项目的目的。
背景中只说明了当下的市场情况，没有对做事目的阐述，结合之前开的会，老板提到希望借用项目让我们在未来做 SAAS 平台时提效，同时这个项目想嵌入到 SAAS 中成为能力的一部分。
到这里有两个目的
- 使用 AI 给产研提效。
- 做个任务协作项目未来嵌入 SAAS。
还要更深度的思考一下，核心目标是什么，如果只能留一个目的，要留哪个？
最核心的目的只有一个，其他是由这个目标分散出来。不会既要又要。
所以核心目的是让产研学会使用 AI 提效，而且任务协作项目，只是手段，用于为目标提供案例。
那如何向老板证明我们达成了目的？是把任务协作系统做好吗？
我觉得不是，把任务协作系统做好，是 AI 提效的结果。
AI 提效需要重新设计 AI 嵌入后的工作流程，每个步骤 AI 怎么提效，即下面这张图。
flowchart TD
%% 后端流程节点 - 左侧主线
背景["背景<br>(产品主+AI辅)"]
业务架构["业务架构<br>(产品主+AI辅)"]
后端功能["后端功能<br>(产品+后端+AI)"]
数据库设计["数据库设计<br>(后端主+AI辅)"]
接口文档["接口文档<br>(产品+后端+AI)"]
后端代码["后端代码实现<br>(AI主+后端辅)"]
%% 测试流程节点 - 右中侧
测试["测试流程<br>(测试+AI)"]
%% 前端流程节点 - 右上侧
UI图["UI图<br>(产品+UI+AI)"]
前端页面["前端页面<br>(AI主+前端辅)"]
%% 主线连接 - 垂直流向（后端流程）
背景 --> 业务架构
业务架构 --> 后端功能
后端功能 --> 数据库设计
数据库设计 --> 接口文档
接口文档 --> 后端代码
%% 测试连接 - 直角连接避免交叉
业务架构 -..-> |测试流程| 测试
接口文档 --> |测试流程| 测试
%% 前端连接 - 直角连接避免交叉
业务架构 -..-> |前端流程| UI图
UI图 --> 前端页面
%% 前后端对接 - 直角连接避免交叉
接口文档 --> |前后端对接| 前端页面
%% 布局调整
%% 把后端代码放在接口文档下方
%% 把前端页面放在接口文档右侧
%% 把测试放在UI图前面
%% 样式设置
classDef 人主导 fill:#FFE6CC,stroke:#D79B00,stroke-width:1px;
classDef 后端 fill:#DAE8FC,stroke:#6C8EBF,stroke-width:1px;
classDef 前端 fill:#D5E8D4,stroke:#82B366,stroke-width:1px;
classDef 测试 fill:#E1D5E7,stroke:#9673A6,stroke-width:1px;
%% 样式应用
class 背景,业务架构 人主导;
class 后端功能,数据库设计,接口文档,后端代码 后端;
class UI图,前端页面 前端;
class 测试 测试;
%% 连接线样式 - 后端流程线
linkStyle 0,1,2,3,4 stroke:#6C8EBF,stroke-width:1.5px;
%% 测试虚线
linkStyle 5 stroke:#9673A6,stroke-width:1.5px,stroke-dasharray: 5 5;
%% 测试实线
linkStyle 6 stroke:#9673A6,stroke-width:1.5px;
%% 前端虚线
linkStyle 7,8 stroke:#82B366,stroke-width:1.5px,stroke-dasharray: 5 5;
%% 前后端对接线
linkStyle 9 stroke:#D79B00,stroke-width:1.5px;
这是我最终把流程打通后画的图，具体每个步骤的细节不多赘述。
分析到这种地步，才算把目的分析透彻。
产品业务
背景中大致业务流程是，创业者需要找人帮忙做事，大学生有时间，我们要做个通用的任务众包平台链接他们。
粗略一看好像很简单也很具体，我们之前的需求也类似这样，实际上这就是个初步的想法，具体细化一下场景，全都不确定。
我们研发向老板反馈产品文档不够完善、不清晰不具体，老板总会反过来问我们产品哪里做的不好，这其实是对研发比较大的挑战，这相当于在教产品怎么做产品。
往往研发说不出具体问题，又会被老板责备，那我今天就以这个项目为例，演示下我们研发期望的产品是怎样的，我是怎么做的。
调研
我调研了市面上任务众包平台，猪八戒网、一品威客、闲鱼、BOSS直聘、青团社，每个平台都注册了发单方、接单方，至少体验一次接发单流程。
只要做到这一步，再回头看之前写的业务流程，就知道有多不具体和模糊。
业务边界
盈利模式
这里每一家平台的盈利模式都不一样。
青团社是纯给发单方卖流量，不做订单和交易。
闲鱼以订单交易手续费为主，默认 0.6%，超过 1万元限额或 10 单，超出的部分额外收取 1%。
并且闲鱼做担保能力非常强，他直接和支付宝联动，钱不需要走三方平台支付提现，直接在支付宝做冻结。
BOSS 直聘比青团社更优秀，他不仅卖发单方流量，还卖接单方流量，而且在流量之上，他还卖服务、数据。
如果我要做个任务协作平台，靠什么盈利？
系统体系有订单、资金，所以我做的线上业务，和闲鱼类似，靠手续费盈利。
那能不能模仿线下类型的卖流量呢？
闲鱼没有直接买卖流量入口，只能通过内部的虚拟货币兑换流量，只有老用户、日活高的用户才能获取更多虚拟货币，闲鱼的内部流量非常稀缺，他们不做可能是出于平台某些目的，比如维护流量整体平衡、维护老用户利益等，而不仅仅是盈利方面的考虑。
所以未来后期做大了，可以尝试卖流量、服务、数据，现阶段只通过的交易手续费、提现手续费盈利。
用户
用户是谁？从哪来？用户有什么特征？
调研中有的平台发单方是大企业，接单方是服务商；有的是发单方是企业主、小企业，接单方是个人；而像闲鱼，发单方和接单方几乎都是个人的。
后来了解到这个项目最开始给我们公司内部使用，发单方是我们自己，接单方是兼职人员，未来对外开放，还提到兼职人员愿意接受较低的单价。
所以我理解我们最开始发单方是微小企业，接单方是个人，跟青团社类似，未来发单方可能发展到有个人，比如工作室，所以在用户模块要保留下扩展性。
如果我们能构建一批兼职接单方，我们就有资格反向要求发单方，比如保证金、认证费、门槛费等。这和市面上常见的发单方市场不同，他们平台做各种妥协吸引发单方，比如一品威客承诺验收满意再付款。
任务和订单
这就更加丰富多彩了，调研显示每家平台都不一样。
有的是服务商打包商品类型售卖；有的对任务做了各种分类，发单方自行选择发布；有的有悬赏、计件、投标交易模式，会影响后续订单流程；有的是用一下担保平台，随便写点什么两个人就交易了。
结合上面说的，我们是先做个给自己用，那我得去调研下我们自己会发布哪些任务，比如找人剪视频、代运营等。
代运营的场景很特殊，可能还需要接单方缴纳押金，要设计到流程中，剪视频是计件付费。
还有没有其他交易方式？我需要找公司内部发单方聊聊，问一问他们还有哪些任务类型，现在是怎么解决的。
要划分任务和订单的边界，我需要更多信息。
资金
调研中有的有钱包，有的没钱包，主要是订单支付和余额钱包支付区别。
余额钱包的研发工作量、代码复杂度、对账难度比订单支付大，这两者对发单方来说他们更倾向哪一种？我觉得更倾向于余额钱包，但引入余额后发单流程的支付也会跟着调整。
我需要调研自身业务的发单方，获取更多信息，判断余额钱包是否核心诉求。
其他
合法合规、财务税务、违规行为防范、运营成本、沟通成本（不像淘宝可以不建联直接下单）、任务匹配度、客服成本等等，这是众包平台都会面临的问题，先有个概念，后续做增量的时候要考虑到。
总结
以上是我在做任务协作项目思考的过程。
现在再回头看背景中提到的业务流程「创业者需要找人帮忙做事，大学生有时间，我们要做个通用的任务众包平台链接他们。」，还觉得清晰具体吗？
研发面临大量的业务模棱两可的情况，比如
- 发单方和接单方共用一个账户吗？金额可以互转吗？
- 付款在发布任务时还是接单后？
- 任务和订单的边界在哪里？
- 任务的状态机，订单的状态机，他们两个状态如何对应？
- 订单售后和仲裁如何设计？能否在完单后发起？
- 任务是否需要进行中和订单联动？
任何看似模棱两可怎么做都行的情况，一定是没想好，想到一定程度，就会发现缺少信息，要再去获取更多信息。
比如我最开始思考付款在发布任务还是接单后？看似都可以，于是我想对比下两者区别，发现对比不出来，因为缺少任务更具体的边界。
所以我去问老板我们的用户是谁？他们会发布什么任务？
得知我们要先做给自己内部人发任务用，我要去调研自己人会发什么任务，才能分析出两者区别，再做决策。
综合看来这句话非常非常关键，把广泛的、通用的众包系统，聚焦到具体行业，以兼职人员为接单方，企业为发单方的任务协作平台系统。
这些本该产品梳理的场景，到研发执行阶段全部爆发，代码已经写了一部分，不得不返工重新思考场景，产品也想的不深刻，随意给一个方案，最后系统存在漏洞，一旦出问题，研发负责。
这就是研发的困境，我们对产品的期望是能解决所有业务上模棱两可的场景，能有理有据的说明为什么这么设计。
