[论文解读] Fundamental Analysis of a Developer Support Chat Log for Identifying Process Improvement Opportunities

Zádor Dániel Kelemen|arXiv (Cornell University)|Jan 1, 2015

Software Engineering Techniques and Practices参考文献 12被引用 1

一句话总结

本文提出一种数据驱动的方法，通过分析一个软件开发团队六个月的Skype聊天记录，减少开发人员支持聊天中的干扰。利用消息频率和用户活跃度等简单指标，研究识别出流程中的漏洞，并提出可操作的改进建议——如轮换调度员角色、知识库和静音政策——从而减少支持时间，并降低核心开发时段的干扰。

ABSTRACT

In this report analysis of a support chat log of a development team is shown. Developer support chat is used to provide internal support to other development teams. The report shows how a fundamental data analysis helped to identify gaps and action items to boost performance of a development team by reducing time spent on developer support chat and minimizing interrupts from other developer teams. The report also shows an example of how a root cause analysis can be supported by simple data analysis in finding process improvement opportunities.

研究动机与目标

• 解决核心开发团队因未追踪的聊天干扰导致的技术支持时间过长的问题。
• 通过分析消息日志，调查过度使用支持聊天的根本原因。
• 识别流程改进机会，以减少支持所花费的时间并最小化团队干扰。
• 为共处一地的软件团队提供可操作的、基于数据的支持优化建议。

提出的方法

• 从一个核心开发团队收集了为期六个月的Skype聊天记录（144个活跃日，共3,498条消息）。
• 使用唯一的Skype ID将聊天记录与组织数据（用户角色、团队）合并，以丰富消息上下文。
• 对7项关键指标进行基础数据分析：总消息数、活跃用户数、每位用户/角色的消息量，以及每日/每周模式。
• 由于广播式消息系统中存在歧义，排除了复杂指标（如对话长度）。
• 利用分析结果识别支持实践中的漏洞，并推导出改进措施。
• 提出制度化解决方案，如轮换调度员角色和针对不活跃用户的静音指南。

实验结果

研究问题

• RQ1 如何利用聊天日志数据识别开发人员支持干扰的模式？
• RQ2 聊天日志中的哪些指标最能揭示内部支持流程中的低效问题？
• RQ3 如何通过支持聊天日志的简单数据分析推导出流程改进？
• RQ4 如何在保持对开发团队响应能力的同时减少支持开销？

主要发现

• 核心开发团队在144个活跃日内共发送了3,498条消息，花费了大量时间处理支持请求。
• 大量消息来自外部开发人员，表明缺乏集中化的支持协调。
• 最活跃的用户不一定是团队成员，表明非核心开发人员频繁发起支持请求。
• 分析显示，支持干扰在核心开发时段频繁发生，严重影响了生产力。
• 轮换调度员角色被识别为减轻个人负担并提高响应一致性的关键解决方案。
• 建议实施知识库和静音政策，以减少重复查询并最小化不必要的干扰。