维修补助、问题和用例

[nobrick]

在Slack上面有一个版本比较早的描述关于师傅补助的文件：

补助现阶段已月为单位计量，每一个月，师傅接的前80单，每单补助5元钱，80单之后，每单补助10元钱。每单的补助在用户支付完成后，同师傅维修金额一起自动结算进师傅钱包的总金额内。

设置根据是一周工作5天，每天按接取4单计算，一个月为80单，其余单数为周六，日的额外加班时间接取的，因此将补助提高至10元也是合情合理的。

夜间补助（应为夜间维修价格）为基础系统定价*1.5倍，夜间补助时间段为预约维修时间定在夜间8点至夜间12点之间的订单。

当用户的预约修理时间定在晚上8点至晚上12点之间的时候，系统报价（车马费+基础维修费）显示金额将自动x1.5倍。同时在报价框下方出现一行提示：此订单为夜间维修订单，需额外征收夜间维修费（基础订单价格x1.5）。(这个1.2、1.5倍价格浮动已经更新在wiki，以最新版本为准)

上面的需求描述（前两段）还有没有什么需要变动的地方？

80单之前每单师傅补充5元，80单之后每单师傅补充10元。

下面是我的一部分问题：

• 每单的最小成交金额是否有要求？
• 每单获得补助的最小成交金额是否有要求？
• 80单之后每个师傅无论多少单都可以每单获得10元补助吗？
• 上述问题，有没有相关的限制标准和策略，如果有的话需不需要随时更改策略？（比如在后台中供管理人员灵活定制，可能实现比较复杂）
• 当前的应用支付方式分为“现金支付”和“微信支付”，是不是只有“微信支付”才能获得补助？如果是，之前说的“前80单”“后80单”（以及涉及前面几个问题的订单都需要指明）指的是不是只有使用微信支付的订单？
• 师傅获得补助，师傅在具体哪个环节得到信息显示和通知？

上述问题也可以按照我自己的理解来实现，不过最好能够留意一下其中的重要问题，以免实现与核心需求不一致。更改需求实现，等于之前做了很多无用功，效率会低很多~

我觉得最好的解答问题的办法是 用例 + 原型图~
用例 ≠ 需求文字说明，需要针对不同的角色（师傅还是普通用户），描述他们关于这个需求可以选择的动作路径：

角色：用户
用例：放大象
前提：没有大象在冰箱里面
步骤：
1.1 把冰箱门打开
1.2 把大象放进冰箱里面
1.3 把冰箱门关上
结果：大象在冰箱里面

角色：大象
用例：进冰箱
前提：冰箱门是打开的
步骤：
1.a 冰箱足够大：跳进冰箱里面去
1.b 冰箱不够大：Run!
1.a.1 等待用户把门关上
结果：
- a路径：在冰箱里面等待用户把门关上
- b路径：Run baby run!

---

UPDATE
刚刚看到zhuxiang发在business channel上的文件，这个应该是最新版本：

补助现阶段已月为单位计量，每一个月，师傅接的前80单，每单补助5元钱，80单之后，每单补助10元钱。每单的补助在用户支付完成后，同师傅维修金额一起自动结算进师傅钱包的总金额内。

设置根据是一周工作5天，每天按接取4单计算，一个月为80单，其余单数为周六，日的额外加班时间接取的，因此将补助提高至10元也是合情合理的。

夜间补助时间段为预约维修时间定在20:00-24:00点之间的订单。其中20:00-22:00的补助倍数是1.2倍，22:00-24:00的补助倍数是1.5倍。

当用户的预约修理时间定在晚上8点至晚上12点之间的时候，系统报价（车马费+基础维修费）显示金额将自动乘以倍数。同时在报价框下方出现一行提示：此订单为夜间维修订单，需额外征收夜间维修费（基础订单价格乘以倍数）。例如基础总价格为x元，当前的倍数为β倍（1.2或者1.5），则夜间系统报价为y=β×x元。

[nobrick]

@zhuxiang @wangxiran

[wangxiran]

@nobrick 是的，曲铭，和朱湘聊了下，觉得直接1.5可能价格有点高，要不就是8-10点，1.2倍；10-12点1.5倍，还是以预约的维修时间为准，可以吗？
然后就是你的问题，我的理解是这样的~
1、每单的最小成交金额是否有要求？
每单的成交金额的最低要求为系统报价，也就是如果在支付时候，用户输入的支付金额小于系统报价，系统会不通过，并提示：支付价格不能少于系统报价。这也是变相的防止了刷单和套补贴的口子。
2、每单获得补助的最小成交金额是否有要求？
每单获得补助的最小金额也应该就是系统报价了，因为系统报价是用户可以进行支付的最低金额，也就可以等同于师傅获得补助的最小成交金额了。
3、80单之后每个师傅无论多少单都可以每单获得10元补助吗？
是的，只要完成的是合理的订单（用户完成支付）那么就可以获得补助。从万能小哥的宣传来看其实1天接3-4单已经很多了，所以一个月80单获得5块补助已经不是很高了。
4、上述问题，有没有相关的限制标准和策略，如果有的话需不需要随时更改策略？（比如在后台中供管理人员灵活定制，可能实现比较复杂）
是的。。。如果可以的话，价格（车马费+基础价格。。）与补助是最好流出端口进行调整的。因为毕竟以后还要去其他城市，基本每一个城市都要重新进行一次定价的。。而补贴也是同样的，甚至在一个城市，根据师傅的热情，补贴很有可能每个月都要调整一次的。。
5、当前的应用支付方式分为“现金支付”和“微信支付”，是不是只有“微信支付”才能获得补助？如果是，之前说的“前80单”“后80单”（以及涉及前面几个问题的订单都需要指明）指的是不是只有使用微信支付的订单？
是的，只有微信支付才能获得补贴，因为暂时线下支付无法确定是否为刷单，所以这80单也就是单指只是通过微信支付的订单。未来如果可以，也可以同过线下反冲的方式解决（就是通过现金支付也可以，不过要求师傅讲用户支付的金额通过微信的方式反冲给我们）。
6、师傅获得补助，师傅在具体哪个环节得到信息显示和通知？
这个还是真没考虑到的。。因为我们是默认师傅知道这个规则的。。不过如果可以，是否可以弄成和用户的订单被接单一样，当用户最终完成支付后，师傅的微信端也会收到一条微信，显示本次已完成订单的订单金额，时间，订单号，维修项目，与补助金额呢？（如果可以我立刻写需求~）？

[wangxiran]

@zhuxiang ~~

[wangxiran]

@hymRedemption ~~

[wangxiran]

@nobrick 曲铭你说的这个用例我不是很清楚。。是指我和朱湘画的那个UI图，最好将管理员操作的每一步用你举例的那种方式列举出来呢？还是之前的那些需求，主要用你举例的这种方式列举出来呢？

[hymRedemption]

@wangxiran 用例就是我写的“后台管理用例”的东西

[nobrick]

@wangxiran 其实用例在咱们的 Wiki 之前就有的，主要是建议采用这种方式来描述需求来提高效率。

当然关于这个需求现在已经基本描述清楚了，也不一定需要再书写更多的内容。只是这样的描述方法确实会出现很多模糊、逻辑不严谨的地方，在一开始可能就会产生不少疑问，然后需要反复沟通、交流才能最终确定。

用例最初看起来麻烦一些，但它其实非常符合软件工程 需求->设计 流程的最佳实践，也是产品经理常用的手段。由于它定义了一些规范，强迫你必须从这些规范的角度去思考问题（其实就是去思考整个软件产品运作的过程），从一开始就避免了很多不必要问题的产生，会高效很多。

比如这个需求如果采用用例的方式提出来，可能一开始就会很自然地解答出上面很多疑问，而且即使存在一些问题，答案也很容易直接补充到用例本身。而故事式的大段需求文字可能会粒度太大，不够细致，等于需要从这些内容中像阅读理解一样再次提取出“严谨的需求逻辑步骤”，一些细节、特殊的情况就只能依靠反复沟通，或者靠编程人员自我发挥~~~~~~~~~ :D

用例其实最直观的了解方式就是看看现有的例子，比如我最上面的举例，还有 @hymRedemption 写的 后台管理相关用例。网上也有一些更深入的讲解，但我觉得其实最本质的事情在于咱们希望能够大幅度提高需求沟通效率，咱们的需求不是固定的，很可能会持续变化，所以面临新需求，通过最直观的方式了解用例以后真正投入使用受益才是关键~

[wangxiran]

@hymRedemption 嗯嗯，之前还确实没认真看，现在好好学些下！

[wangxiran]

@nobrick 要的，曲铭。因为之前也是一直用叙事手法沟通，不过我也发现了这种方式还是太糙，不够细致。我去看看那个讲解，学习下！下次的需求，就用用例的方式去阐释。 ：）

[nobrick]

关于维修补助还有个问题：怎么才能限制师傅，自己以用户身份虚假提交订单、然后自己再去接单，赚取补贴的恶意刷单行为呢？ @wangxiran @zhuxiang