Flunes什么时候选 BugHerd: 所有评审都发生在一个你能掌控的特定网站上。 钉在元素上的可视化评论是你流程的核心。 你想要一块管理网站反馈任务的 kanban 看板。
Flunes vs BugHerd
- 是，原生支持
- 部分，靠增购项
- 否，并非其职责
「部分」指可通过集成或付费增购实现，并非核心模式。
迁移到 Flunes 你能得到什么
你团队的反馈不局限于某个你能往里加脚本的网站。
你想要干净的 GitHub issue，而不是一块钉评论的任务看板。
你不想为提反馈的人按内部成员人头付费。
纯文字报告加可选截图就够用了。
工作真正发生的地方
用一块钉评论的看板时，反馈和修复待在两个地方：评论在页面上，代码在 GitHub 里，得有人在两边来回搬。Flunes 把每条报告直接丢进仓库变成一条 issue，于是讨论就发生在分支、提交，以及关掉它的那条 pull request 旁边。你的队友拿到一条魔法链接，从不接触 GitHub；仓库所有者登录一次，就在他平时分流其他一切的同一个地方审阅 issue。没有要单独查看的任务看板，也没有第二个工具要你的开发整天开着。
团队增多时费用仍然固定
团队会不断加人：一个新的 PM、第二个 QA 测试、一个想插话的支持负责人。按内部成员人头计费的工具会惩罚这件事，把每个多出来的审阅者都变成一笔账，于是团队只好限量发放访问权，或者干脆不邀请那些本该来报告的人。因为 Flunes 不为提反馈的队友收费，你可以在每个项目上把链接发给每一个 PM、测试、设计师和支持人员，而不用看着账单往上爬。作为 BugHerd 替代方案，无论你邀请三个人还是三十个，这笔账都算得过来，访问与否的决定也回到工作本身，而不是席位数。
Flunes 不会做的事
Flunes 是刻意做窄的。它不把评论钉在线上页面的元素上，不在截图上画箭头，也不给你一块可以在列里拖来拖去的网站任务 kanban。没有要你队友安装的浏览器 widget，也没有可视化标注层。如果你整个评审流程都依赖在渲染好的页面上点一个按钮、把标记正好留在问题所在的位置，那 BugHerd 能做，Flunes 不能。Flunes 接过纯文字报告加可选截图，把它们整理成干净的 issue。当反馈来自你自己的团队、可以是关于任何东西、而不只是某个你掌控的站点时，这很有用。
常见问题
不会。Flunes 采集的是纯文字报告（可选附截图），不做线上站点元素级的钉点标注。如果你要的就是在为客户搭建的网站上做钉点可视化反馈，那 BugHerd 更合适。