在工作中是否要保持跟同事分享技术或案例的习惯？

[0xfb709394]

目前 OP 的工作类似于做工单模式，年后组里要按工单量来算绩效了，解决工单的速度就成为了关键指标。

虽然大部分时候解决问题考验的是信息检索能力，但组里现在还有人连百度都不会用，OP 本人是比较喜欢分享案例的，毕竟被别人喊大佬的时候心里也有成就感。但后续绩效实施之后还这样做可能会削弱自身绩效优势，甚至可能出现乱棍打死老师傅的情况（别人简单的工作干得比你多，而你在琢磨疑难杂症一单搞一天），因此想到这个问题。

希望各位 V 友留下宝贵意见。

[hongyexiaoqing]

费曼学习法，把自己知道的讲给其他人，收益最大是你自己。别人不可能比你更懂。

[COW]

把一份工作拆成 10 个工单就好了

[guoooo00oohao]

可以的，不过你的同事可能其实并不愿意听。

给同事讲一遍我称其为一种小黄鸭调试法，因为讲着讲着你会发现有些地方你自己之前都没有考虑到；或者逻辑上不自洽。

[zeroonetwo]

有道则见，无道则隐

[povsister]

形成输出文档的习惯，口说无凭，何况你不能问一遍讲一遍。
文档也能很好回应老板质疑。毕竟一个只干工单的人和一个不断输出 KB 的人，谁更靠谱一目了然

[CEBBCAT]

我认为要逃脱这种制度

[liberty1900]

我觉得你应该跳出这个模式，跟老板谈你的主要工作就是分享案例，帮助组员解决困难工单

这样你的工作是有挑战性的，也是不可复制的，你的组员的工作正好相反

[AmberTest]

建议日常把各种案例写成文档，如果组内或者同事有相关的需求直接甩文档即可。这样
1. 满足了分享的制度要求（如果有）
2. 减少了直接口头沟通带来的时间成本和理解成本
3. 加深自己对 case 的理解，顺便解放记忆内存

[abelmakihara]

项目的问题肯定会分享啊 避免踩坑也避免互相无意间挖坑