🏸 💺 👩🏼‍💼 如何有效处理GitHub上的问题 ☎️ 📼 🌭

GitHub上的票证有所不同：请求实现某些功能，错误报告，客户投诉，安全系统警报，团队回顾等。在这里，我们了解团队如何使用和讨论它们。

内容：

什么是车票？

对于许多团队来说，“门票”是一个通用术语，可以表示：

要求执行功能。
错误报告。
顾客投诉。
安全警报。
团队回顾。

公共还是私人？

对于项目，您可以创建公共票证和私人票证。通常，公共对象是针对用户，客户，代理等的。私有对象-对于开发人员，承包商，合作伙伴等的。

公开票

专注于底线。
强调可以做什么。
不要发布机密信息。

私人机票

关注细节。
突出显示研究信息，因为它有助于识别不同票证之间的可能模式。
根据需要添加机密信息。

评分

必须对所有票证进行评估，以便能够将它们相互比较并了解确切需要处理的内容。有多种评估方法，而在实践中，以下方法效果很好。

优先等级

示例：优先级1（先执行），优先级2（先执行），优先级3（先执行）等。
类比：待办事项列表，其中优先级1是最高优先级。
: , . , .
: 0 (P0), , .

: 1 ( ) 5 ( ).
: - 1 (), 2 (), 3 (), 4 (), 5 ().
: . . , .
: 0 () 5 (). , .

: 1 ( ) 10 ( ).
: 1 ( ) 10 ( ).
: . . . , .

: — «», «», «».
: .
: , .

MoSCoW

: MoSCoW — «must», «should», «could», «won't». « », «», « », « ».
: , , - : « » « ».
: . .

: «would» «won't», , , «would» , , - : « , ...».

: « 1 %» , 1 % , « 100 %» — .
类比：在给定期间或所讨论的样本中某事物或重复发生的频率。
优点：使您可以评估问题发生的频率。可以转换为“每天20次”之类的成绩。您可以总结为“总是”，“经常”，“有时”，“很少”，“从不”。它可以表示为百分比：“ 80％的案例受到影响。”

累积评分

示例：通过优先级，影响力，损坏，大小，MoSCoW和频率的组合来评估票证。

假设有一个重要的客户在一个小时内来到办公室签署协议，并且销售团队在现场发现了以该客户的公司名义出现的错字。

卖家首先将门票设置为优先级1。
1 ( ), .
3 (), .
«» , .
MoSCoW « », .
2 %, 2 % .

这是有关机票等级的讨论示例。

-通常，除了危险外，还可以独立评估频率。如果在正常使用期间不太可能发生该错误，那么即使风险很高，也可以降低优先级。通常，这就是风险管理的方式。

-开发人员或测试人员可以很好地评估错误的危险，但他不知道所有用户还是仅其中一些用户会遇到此问题。频率是另一个维度。可以通过将危险乘以频率来计算优先级。

-格式应如下：危险*频率-解决方法的难易程度=优先级。如果方程式的任何成员发生了变化（例如，找到了一种新的解决方法，或者发现几乎没有人去到下降的网页），那么将调整优先级。如果没有“估计将影响的人数”和“将对他们造成多少影响”，则只有一种危险。它看起来只是图片的一部分。

-质量保证工程师在初步研究过程中根据技术标准确定了危险。这只是产品专家确定优先级的因素之一，从这一点开始，优先级就成为关键参数。

-对于某些用户，该程序有时会崩溃，他们会丢失所有已完成的工作，并且非常生气。他们给机票分配了最高危险。但是，如果只有一个人遇到问题，并且这是定期发生的，并且用户已经习惯了更频繁地储蓄，那么产品技术人员应该给票证一个较低的优先级。

-危险代表一个人对问题的感知：如果在特定情况下遇到问题，则他会将危险评估为最大。优先级描述了项目管理团队如何看待错误：最有价值的投诉者报告的错误-带来很多钱的客户，遇到困难的董事等会获得更高的价值。不要使用错误的危险来评估优先级，因为它们是间接互连的。

-使用优先级和危险性的经验表明，理论上它们之间可能有所不同，但实际上大多数人看不到。这些术语经常被混淆，以至于变得不可分割。

-Google的内部错误跟踪系统可以处理优先级和危险性。P0 S0是最紧急的任务，P2 S2是标准的，P4 S4是最紧急的任务。这有点开玩笑，认为危险是没有道理的（因为实际上，危险与优先级没有区别）。

-我们仅使用优先级。测试人员根据试探法（例如，跌落-P1，外观改善-P5）分配初始值。开发人员将重点放在此值上，以选择您需要首先开始使用的错误。然后根据用户体验和应用程序行为调整优先级。如果我们真的需要查看测试人员设置了什么值，那么我们可以在应用程序中使用``历史记录''或``修订''功能来跟踪错误。

票证模板

该模板将帮助您的团队有效，全面地涵盖重要主题。

它可以使用：

主要投诉人：遇到问题的人对该问题的一般描述。
参与者：参与情况的用户-用户，员工，合作伙伴，特定人员等。
症状：问题的明显迹象-用户意见，触发器，警报等。
历史记录：与情况相关的辅助信息-类似案例，报告，链接等。
诊断：内幕发生的事情-根本原因或原因链等。
预测：对潜在后果，变化等的评估
骨折：信息丢失，应用程序崩溃，进程阻塞等。
治疗：我们为改善情况采取的措施-程序，待办事项清单，限制等。

作者模板文件：TEMPLATE.md

事后发布

验尸消息的发布将告诉团队何时处理该情况。

您可以运行分析：

对于用户而言，任何明显的问题，例如意外崩溃或错误。
如果需要，例如工程师或管理层的任何干预。
在任何事件调查中，因为这反映了监视的需要。
在有关方面要求进行审查，审核或减少事件后果的情况下。

无辜验尸

对于无辜的验尸，值得将重点放在症状，原因和治疗上，而不是怪罪于某人。这样的检查首先要确认每个人都有良好的意愿，并使用当时可用的信息来完成所有可能的事情。

如何有效处理GitHub上的问题