鲁达 果见案例库
根据「管理全景图」汇总相关模块案例。
内容来自小酒馆、小茶馆、小咖馆和小饭馆内，群友们真诚热情的讨论。
欢迎在管理之路上徜徉的你加入管理社群，分享交流管理相关的话题（文末扫码加入）。
案例详情
问题
抛一个问题，如何处理与团队成员的技术冲突? 在开发过程中，小到编码不规范（如错误码使用不正确、冗余逻辑等），大到特性级别（两种方案均可，复杂程度不同），拒绝接受意见，否则撂挑子。
背景：
1、这个成员是倔强的入职一年的应届员工。他认为他的写法好，但很多时候是眼界限制了想象。他的方案会给以后运维带来很大的问题，但是他不会考虑这些。编码规范也是有的，但是编码规范不会约束这么详细。
2、我们项目成员 90% 都是校招自己培养的，绝大部分都是比较好的。但是有些还是倔强的。他能力还是可以的、主动性还不错（在其他组可以称为良好了），但就是存在这种问题让我比较无语。
3、我们部门 5 个项目组，其他项目组人离职多且找不到人，我们团队还在招人。所以主动开人是不可以的，且开是下下策。
4、我们团队十五六个人，并且还要负责产品、技术、项目等。不能兼顾到每一个人，工作任务大都是自管理的。
群友互动
@无缘
多招点应届。
群友互动
@常怀珠
我记得上次也有人问过，可以让他研究编码规范，研究后给大家分享。还有工具层面，设置好模板在代码提交之前跑不过就改呗。工具是有非常细的。
毕业一年了都跟不上团队要求。两年后也不一定能改。你开了这种例外后，还怎么约束其他人。
让他写检讨书，签字然后转发给所有人。另外管理手段也是因人而异的。上面的 case 只针对例外。有一些主观能动性高的你说说，人家就能领会了。方法有的是，看你自己决定了。
她是不认可，还是不理解，你要了解动机。
群友互动
@赵海俊
那就搞清楚他为什么不改，是不屑还是其他。如果屡教不改，开了呗。这种问题很好处理吧
屡教不改有啥办法，有些人的性格和价值观跟你就不一样，你能怎么办。搞明白原因，如果能解决就继续，不能解决就开。一个应届生就把自己搞成这样 ，要是一个老油条该咋办。对得起自己的良知就好。
检讨书也是一种方式，管理跟每个人的性格和价值观有很大关系，有些人可能就喜欢搞检讨书，有些就非常反感。
我觉得建国老师说的一句很对，从自己的良知出发。让他多学习，要是初期我的做法是会送几本书给他看看，后面再聊聊看书心得啥的。要么你找个人带他。如果还在招人，你得注意培养一些骨干了。
群友互动
@ullyer
检讨书给成人用，感觉有点过。不太能接受这种方式，可以做个 Casestudy。
检讨书有侮辱的成分，除非他自己主动写。一般不会让别人写，这种你让写就写的，基本也就老油条，写了也没啥用了。
群友互动
@张正龙
如果你们对代码要求比较高，那就严格的编码 Checklist。
群友互动
@寻梦
叫他读几段不规范的老代码，就知道代码规范的重要性了。也可以把代码规范放入绩效考核里面。
全景图分析
诊断
管理者目前的问题是团队成员不愿意接受意见要如何处理？那么对应到管理上，这个事情对于管理团队的影响是什么呢？团队的协作？项目质量或者项目进度出现问题。
管理者站在团队的角度先思考清楚自己根本上想解决的问题是什么。
应对思路
知、愿、能
我们可以从「知、愿、能」的角度来进行思考。即知不知道、愿不愿意、能不能做到。
知不知，对方了不了解「小到编码不规范（如错误码使用不正确、冗余逻辑等），大到特性级别（两种方案均可，复杂程度不同）」带来的对他个人和团队的影响。
也许她对于代码不规范的影响不够了解，也不知道两个方案最终结果的不同。如果只是认知上的问题，那么当了解后可以有效的改善。
愿不愿意，当知道了影响后，对方有没有意愿去改变。如果不愿意改变，具体的原因是什么呢？
案例中的管理者提到了倔强，但倔强是一种感受或者表象。不愿意按照建议改善的根本原因还是需要管理者花时间去了解的。比如说他认为更改的成本很高（也许也是认知上的错误），或许是感受到了不被信任。
因为管理者也提到了能力不错、主动性良好。那么重点还是为什么不愿意。
关于如何促使一个人做出改变，美国学者理查德·贝克哈德的改变公式，可以给我们一些指导：
想要改变一人，可以从他的「痛点、痒点」出发，并和他一起制定「迈出第一步」的行动计划，从而去帮他克服掉改变的阻力。
了解这个倔强的、能力不错且主动性良好的员工，他的不满、他的愿景以及改变的阻力。一起约定下一步需要作出的改变和行动。
流程机制
作为管理我们还需要意识到如果我们的目标不是帮助这一个组员成长，而是让大家都遵守规范，产出高品质的代码。又或者大家能在方案选择上都使用「较好」的方案。那么我们即使投入了大量精力解决了这个人的问题，再来一个新的员工，还存在同样的问题，我们还要再来一遍么？
这个时候如果人靠不住，我们就需要靠流程机制了。比如管理者也提到了有编码规范，但是一个流程的有效执行需要目标清晰、责任明确、机制健全、沟通到位。
比方说如果说编码规范无法覆盖全所有的情况，那么我们可以制定 CodeReview 机制。当然如果有足够成熟和合适的检查工具，那就更好了。你可以让业务组长去监督这个机制。需要跟监督人和所有执行人达成共识和约定后续的沟通方式。
角色认知
最后是提醒下管理者，认真再思考下，是不是一定要员工做出所有的改变。一个是管理精力有限，改造这个员工的收益是否值得。二是自主的工作是对于员工非常重要的激励。如果所有的细枝末节也掌控在管理者手中，最终大概率还是背离了管理者的初心。三是人无完人，管理者更多的是知人善用，发挥员工的优势之处。
更多内容可查阅图书《知行：技术人的管理之路》。
期待你的案例分享！