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