目前 OP 的工作类似于做工单模式，年后组里要按工单量来算绩效了，解决工单的速度就成为了关键指标。
虽然大部分时候解决问题考验的是信息检索能力，但组里现在还有人连百度都不会用，OP 本人是比较喜欢分享案例的，毕竟被别人喊大佬的时候心里也有成就感。但后续绩效实施之后还这样做可能会削弱自身绩效优势，甚至可能出现乱棍打死老师傅的情况（别人简单的工作干得比你多，而你在琢磨疑难杂症一单搞一天），因此想到这个问题。
希望各位 V 友留下宝贵意见。
9 条回复 • 2024-11-29 10:23:25 +08:00
 |
1
hongyexiaoqing 27 天前  3
费曼学习法，把自己知道的讲给其他人，收益最大是你自己。别人不可能比你更懂。
|
 |
2
COW 27 天前 via Android
把一份工作拆成 10 个工单就好了
|
 |
3
guoooo00oohao 27 天前 2
可以的，不过你的同事可能其实并不愿意听。
给同事讲一遍我称其为一种小黄鸭调试法，因为讲着讲着你会发现有些地方你自己之前都没有考虑到；或者逻辑上不自洽。 |
 |
4
zeroonetwo 27 天前
有道则见，无道则隐
|
 |
5
povsister 27 天前 1
形成输出文档的习惯，口说无凭，何况你不能问一遍讲一遍。
文档也能很好回应老板质疑。毕竟一个只干工单的人和一个不断输出 KB 的人，谁更靠谱一目了然 |
 |
6
CEBBCAT 27 天前
我认为要逃脱这种制度
|
 |
7
liberty1900 27 天前
我觉得你应该跳出这个模式，跟老板谈你的主要工作就是分享案例，帮助组员解决困难工单
这样你的工作是有挑战性的，也是不可复制的，你的组员的工作正好相反 |
 |
8
AmberTest 27 天前
建议日常把各种案例写成文档，如果组内或者同事有相关的需求直接甩文档即可。这样
1. 满足了分享的制度要求（如果有） 2. 减少了直接口头沟通带来的时间成本和理解成本 3. 加深自己对 case 的理解，顺便解放记忆内存 |
 |
9
abelmakihara 27 天前
项目的问题肯定会分享啊 避免踩坑也避免互相无意间挖坑
|
Select Language