例1
例2
例3
今天在公司群中看到三段这样的对话，我陷入思考，才发觉Frank的处理方式是多么的出众。
我们所在的技术部也负责着每日的软件问题处理，处理由技术支持无法解决移交的问题，主要为软件异常与数据修复两类。
资源配置
a. 注册一个“数据修复”的QQ
b. 有一个“问题处理”的企业QQ
c. 每个人有一个对外的QQ，名字一致为“公司名+技术支持+数字编号”
d. 技术支持人员和研发组人员共建一个QQ群
人员配置
每天有2个人来负责，1人为主导，1人为辅助
如果问题处理负荷>2人，可以将问题转发到团队内部群里，其他人主动辅助处理
处理流程
数据修复
a. 每天主导负责的人员登陆该QQ
b. 任何人可以直接有问题的数据库发送至指定的“数据修复”的QQ邮箱中（利用QQ邮箱的及时通知）
PS： 是否需要修复数据有很简单的鉴别方式问题处理—企业QQ
a. 每天主导负责的人员登陆该企业QQ
b. 技术支持直接将企业QQ上的用户（soft有问题）无缝转接给上面的企业QQ（企业QQ的优点）问题处理—主动添加
a. 大家肯定会登陆自己的QQ（群里人员到位了）
b. 负责处理问题的2个人登陆着对外的QQ
c. 技术支持将不是企业QQ上的用户信息发在群里
d. 群里研发组当前版本负责问题处理的两个人员会主动回复get到
e. 处理问题的2个人用对外QQ添加用户
f. 解决问题……
g. 问题解决方案总结在群里或分享在知识库中
PS： 市场部等人员不在电脑旁，用手机QQ等方式
这样的处理流程带来的好处：
对内，分工明确，共同成长，不影响团结
问题来了不会有“是不是我该去处理一下”、“我处理别人也在处理重了”等问题
每个版本大家轮流来主导负责，锻炼相关的软硬技能
内部值班分配灵活调整，外部不需要关心（遇到假期等情况大家有事调换一下）
不会出现霸权
- 员工入职有先后，早入职的员工对用户问题处理的越多经验也越丰富；
- 早入职的员工也是被其他部门最为熟知的；
- 本着大家轮流坐庄学习，但其他组的人员会将问题单发给早入职的员工，这让这个版本负责的人很尴尬（这里反省一下，我在v5.40的版本中主导处理，遇到这种情况，情绪化越发严重，影响团结）
- 不会出现老人离职，用户问题处理无法正常运作的问题
对外，随时可以找到人处理问题
o，这就是封装?!
缺点呢？缺点应该是设计吧？需要去设计的，不是面向过程一样，遇水搭桥就可以了。
在现实中还有一个难点：需要各个部门配合，例如修复数据，不发送到指定邮箱，就要找组里人员单聊
不过在程序中这是有点，接口指定出来了，不会暴露内部细节
人比程序复杂
组里一开始人员少的时候，也没有上面这样的处理流程，因为没有必要；当组内人员多了，也出现了和其他组一样的问题，才有了这套流程；让我想到了面向对象的起源也是因为这个时代软件功能越发复杂而衍生的
虽然一开始有这个流程，但也会出现各种问题。想其他部门开始的时候没有配合；内部主导和辅助职责不明确；组里每个人都可以处理，但是如果你解决了问题，将问题解决方案和用户反馈给这个版本负责的人，让他在群里去公布，这样的做法应该更好吧……
这让我想到封装、重构、好的设计方案这些都不是一次就能完成的。都是迭代的结果。
