软件开发领域的许多专家认为，不可能将一个开发团队和用户支持结合在一起。 一个或另一个。 通常，应向个人提供支持。
今天，我想告诉您有关Odobrim.ru我们如何设法将不兼容的产品，或者更确切地说，是开发团队如何支持产品的信息。 那就是同时是2-3支撑线。
Odobrim.ru是一项免费的在线服务，用于选择信用卡，贷款和独立于银行的个人贷款。
我们的任务 ：帮助客户获得并维持能够解决客户任务的最佳贷款产品。
呼叫处理过程的结构如下
1.“客户服务”照顾我们的客户-第一线支持。 是的，是的，在好的地方，它是存在的:)）
“客户服务”可帮助用户解决使用该服务时出现的所有问题。 任何关心客户的公司都应该有第一线的支持，您可以全天联系以获得支持。
如果“客户服务”能够帮助客户，则下一行将不会开始。 如果否，则开始上诉，并将上诉传送到下一行。 到目前为止，还没有什么超自然的东西。
之后，通常会有另外两个支持线，但我们只有一个：我们将第二和第三支持线结合在一起。 这是在产品进入市场后发生的，因此我们已经生活了大约两年。 我们生活得很完美！
2.定期监视用户请求。
值班的工程师被自愿召唤一次每周值班。
推荐板类似于看板。
一切都非常方便地配置在上面：
3.申诉的初始分类是由值班工程师进行的，并根据其结果分别创建Bug（参考文档/要求的bug）或Story（任务）。 他们依附于流通。 我们有纠正错误的期限，服务员正在努力赶上他们。
4.在下一阶段，已修复的Bug由开发人员（Blocker，Critical）修复。 然后由值班工程师进行更正的验证和确认
5.故事（任务）被转移到PO（产品所有者）以进行优先排序。
在过去的两年中，开发团队已经处理了来自我们业务部门和用户的270多个不同优先级的呼叫，其中包括第一线支持无法处理的呼叫。
这种方法的优点
- 来自客户和业务部门的上诉不会丢失，而是集中在一个板上。
- 团队看到了产品的所有主要问题，并有兴趣解决这些问题，也就是说，它离服务的用户越来越近，这对服务和整个产品的质量产生了积极的影响。
- 每个开发人员意识到自己将必须值班时，都试图更好地编写代码，以免给自己和同事带来其他问题。
- 总会有一位负责任的工程师。
- 团队在解决常见产品问题方面的参与正在增长。
- 持续监控，无需其他规定。
这种方法的缺点
团队成员需要高度的敬业精神，责任感和兴趣。 勇于当值。
如果您遇到了类似的支持组织方案，请在评论中分享您的经验。