背景介绍
此文介绍的是一个产品从需求调研到上线的整个流程，整个产品历经3周，参与人数4人，经历了下图三个阶段：找出痛点，缕清需求，写出代码
项目起源
在和流量战场的一次会议中，卡卡西老师对于业务的预测，未来一个月后，我们将会有大量的订单进入，为了提高目前我们对未来订单的应对能力，我们需要一个跟单系统，至于需要什么信息，有什么功能，做成什么样子，这些内容一概不知
找出痛点
这是我们进入的第一个阶段，我们需要知道：我们的服务用户是谁，我们的用户需要什么样的东西，我们的产品需要解决什么问题，为了解答这几个问题，我们做了如下事情：
贴近用户
向前线索要情报
- 夜一提供助贷流程图
- 索隆提供培训资料
参与战斗
- 跟商务线下跑触点，谈合作
- 和运营去和用户面聊，参与整个跟单（由于调研期间没有订单，所以更多的是询问有跟单经验的小伙伴）
访谈用户
制作MRD
- 进行市场调研，参加商务的早晚效率（由于团队成员中阿葵亚对运营很了解，所以重心点放在商务）
- 驻扎前线，反馈信息（阿葵亚驻扎深圳战场），最终出具MRD文档，用户画像，行业报告
准备调查问卷
- 获取到的信息的疑惑点，想要了解的信息以问卷的方式进行调查（这一步最终没做）
- 问题需要具备非开放式，尽量设置成是或者否的方式
- 问问题方式不具备引导性
进行竞品分析
- 快鸽
- 按揭帮
- 数据项，数据名称，数据排版的理由
- 理解对方的业务流程
- 思考为什么会有这个功能点
- 服务的对象，产品的定位
成为用户
- 把自己当做自己的用户实际的去思考，我在工作的时候什么状态是不满的
- 以下是我在当时状态下了解到各个角色的工作内容以后，把自己当做该角色提出的疑惑点
这一阶段的产出，了解到需要解决的痛点
- 内部：商务和运营同步信息
- 外部：用户和触点及时看到信息
缕清需求
在找出痛点阶段，对于我们的触点，商务，运营的工作内容及触点的工作内容及痛点都具备了一定的理解，每个人都自己的一些想法，我们小组成员需要把自己的想法画出来，进行交叉认证，然后达到一致，再往后续的落地走，保证大家方向无偏差，大概过程如下：
制定use case
- 找出报单到最后反润中的整个流程的场景，分离出来
- 反思：在这个过程，没有进行场景划分，导致我把很多调研的小块小块的需求堆积在一起，没有主次之分，也没办法串联各个小块的需求
初期我的原型图是这样的(看目录就能看出来很乱)：
- 按实际的use case为路径，串联参与的角色需要做的事，梳理出整个系统应具备的功能
- 反思：在这个过程中，我是按照各个角色去梳理他们需要参与的事情，导致会缺少部分功能
- 永远只给用户一种方案做一件事情，当你自己都拿不准方案的时候，用户一定比你更懵
- 反思：在触点注册的时候，由于对需求的把握不准，提供了两种方案：一种是商务注册，一种是触点注册
美化PRD
- 如何使用Axure（找无所不能的产品经理教你吧，或许下次会有简单的教程）
- 判断整个保留下来的use case是否保证闭环了，比如说你有商务在进行操作，但是商务的角色在哪产生都没去想，这就是明显的错误了
- 按照use case画出各个参与方的整体流程图
- 反思：在做这个的时候，我是直接在各个页面之间加了点击事件，企图模拟出整个流程，你可以想象一下，当我给大家在将我的流程的时候，我不断的在页面间切换来切换去，别人不断问你这个是谁的页面的时候的想死的心情，废话不多说，贴出整体的页面流程图：
- 细化每个小页面的图
- 参考竞品，按最优的方式展示，包括页面元素，最重要的是字段展示顺序
- 注重小细节，用户操作习惯，比如说如果是订单显示，这个时候，用户有疑问，能否在页尾就找到负责人电话
- 反思：对于这几个点个人建议还是交给专业的人，让我们万能的产品来做吧，毕竟这些东西不是一蹴而就的，当然如果你够强，那我也不拦你
- 没有对比就没有伤害，看看下面两幅图
出UI图
- 可以提前做一些颜色基调的设计，基础元素的设计，比如按钮，导航等
- 有类似logo之类的设计，可以并行做
- 尽快把PRD敲定
- 反思：由于对设计师工作的不太了解，没能提前的让设计参与进来，尤其是logo图，到了临了才发现原来还有logo没做
写出代码
作为技术，这是我们最熟悉的一个战场，任务虽然圆满完成了，然而还是有很多不足，大概过程如下：
做出计划
- 按照倒推的方式进行时间规划（deadline摆在那）
- 从后往前推，上线需要多长时间部署，测试需要多长时间，联调需要多长时间，那么剩下的就是开发时间了，不够？那就从别的地方挤时间吧
- 划分出所有能够并行的任务
- 比如微信公众号认证，模板消息申请，域名，线上环境部署，前后端分离开发…
- 制定好时间节点后，同步让大家知道，留下邮件
- 定好没个时间节点应出的东西，然后小组达成一致，最后再邮件通知大家
- 反思：在这个过程中，定好了时间节点，在实施的时候，有的东西未能到位，比如说：10号截止需求的变更，理论上是需要在10号的时候，所有的东西都定下来，然后再12号才拿到设计好的ui图；最终没能邮件通知到大家，只是过了一个会，这个相当于是一个承诺式的工作方式，过会后，需要把结论发送邮件给大家，避免大家忘记各个时间节点或者有部分突然的变更
- 反馈进度
- 这个当然不用说，实时的反馈进度，让整个小组，关心这个项目的人员清楚，现在我们在哪一个阶段，需要什么帮助，有什么风险点
- 反思：在这个阶段是做的最不好的，项目进入开发的时候，就相当于进入黑盒了，知道最后上完线，大家才恍然大悟，原来上线了；给自己找几个小借口，项目时间太紧了，可能反馈进度，需要花费时间，所以偷懒了；其次，项目功能不太多，没法进行阶段性反馈（其实都是借口，哪怕花一分钟的时间，大概说下做完哪些了，大家心里也有数）
并行开发
- 并行并不是说各自开发各自的，到联调的时候再进行沟通，需要时刻保持沟通
- 比如说在开发的时候，遇到多种角色如何传递角色id的情况，页面判断如何做，及时的沟通，达到一致后，再开始干活
- 这块做的其实还不错，鼓励下自己，可能是前端是合作的老伙伴了，得心应手
- 规范好接口，写好接口文档，能够减少很多沟通成本
- 接口做好规范，命名，数据返回格式（看着设计图来，尽量把格式都转换好），避免前端关键字，比如分页时候的length，返回的时候读返回json数组，一会对象一会数组，还是很容易抓狂的，该get就get该post就post（get，post区别不知道？google去吧）
- 必要的接口文档，至少得说明：接口地址是什么，上送值是什么，返回数据的含义
- 这块也做的不错，接口文档，返回数据格式各方面能想到的还是去做好了，虽然最后接口字段可能不断地在变，这也不可避免
测试上线
- 执行use case
- 这个比较简单，直接按照PRD走正常流程就行，一般都没问题，开发就是按照这个流程做的
- 执行异常逻辑
- 特殊的场景，比如注册了，没完善信息报单会如何，注册了，商务未登录过消息怎么发送
- 这块没有去专门的列所有的场景然后进行测试，而是发动了群众的力量进行测试（测试完之后内心还是忐忑的）
最初的计划
最后晒一个设想的开发计划，自己感受下
友情提示，记得和第一张图对比着看，理想和现实的差距
