最忙的员工就是好员工？非也。
【场景1】
AB两名程序猿在一家快消品企业的小IT部门工作。分别是两个业务系统的开发担当。诸如这种非IT企业的IT团队，通常不具备规范的软件开发流程，基本上每个程序猿要负责或参与所负责系统的需求分析、设计、编码、测试、部署、维护等各阶段。
- B同学聪明，快速完成，快速部署，有时趁领导不在还能开小差玩玩小游戏。B同学的成果交付给业务部使用时，总会有一些问题抛出，B同学便总跟业务部同事沟通问题，然后回来解决。如此反复。
- A同学喜欢闷头工作，做事严谨，每次有开发任务，都能做得比较让人放心，交付给业务部使用时，也鲜有bug出现。A同学偶尔也会开小差，但更多的时间是继续思考一些技术或需求场景更好的解决方案。
【场景2】
AB和CD两组同学在同一项目组工作，使用相同的框架。AC的职责是写业务服务层代码，BD的职责是写前端UI代码。现两组都接到了开发任务。
- A同学开始写服务层，B同学开始写展示层。A同学写了逻辑代码，然后编写了简单的测试用例，保证了接口的可用性和逻辑的正确性。 然后，告知负责展示层的B同学，直接调用已经测试ok了的服务层接口，这样B同学只需专注自己的界面和脚本编写。
- C同学开始写服务层，D同学开始写展示层。C同学完成了逻辑代码的编写，编译ok，然后，告知负责展示层的D同学，D同学调用服务层接口时，遇到了好多问题，不断的找C同学，C同学便来回跑。
工作要讲究方式方法的，并非你在团队内部越“活跃”，你的工作就越出色。同样，作为管理者，也要擦亮眼睛，不要根据表面每个人的“活跃程度”来妄下标签。必须建立看功劳不看苦劳的标准。没有功劳的苦劳越多，就表明浪费资源越多。 消除“我在干活了，苍天总会可怜我吧。“的侥幸心理。如果你的考核失衡，不公平的绩效，会影响团队氛围和大家的情绪。
像场景1，领导很可能收到业务部门负责人对B同学的热情态度的褒扬。而A呢，你的工作没有问题，没人想到你。 我身边也曾有过这样的同事，工作完成了，线上运行情况也ok。领导就觉得他的工作不饱和，赶紧分配别的任务，后来，这同事也逐渐变得圆滑了，故意留些bug，让领导时不时记着他的存在。