大企业体系相对完善，大型部门主要是决策和判断，每个人的性格和能力反倒不重要；

小团队一般在第一线冲锋陷阵，主管对每个人提出要求，下属自然而然就会有情绪，容易被下属品头论足，放大身上缺点；

主管的职责：

主管不是传声筒，主管也不是模范；要通过下属完成目标；

主管要制定目标，方针；

下属挑战目标，主管要及时关注下属进展（比如开早会）；

下属如果有收获，会巴不得能展现自己的成就；

评价下属：

工具：能力意愿矩阵，FFS 理论

能力低意愿低：一般为新人，必须下命令；给以详细的指导和密切的监督，找时间肯定和夸奖他们；

能力低意愿高：支持加指导；肯定意愿，

能力高意愿低：工作缺乏自信，

能力高意愿高：放权，不需要询问，这种人你要让他感觉到你十分信任他；

FFS 理论：五种因素和压力

善于掀起变革的开路人：

善于维护后方的守卫：

善于开拓的侦查员：

不可或缺的协调员：人情味

开会

开会之前要做好议程；一定要让参加会议的人提前了解开会的内容；讨论资料；

会议结束前明确任务：

1：分析问题

2：提出解决方案，每个方案的利弊

3：提出自己推荐的方案：

邮件

简介明晰：

及时反馈

如果遇到什么事情没法完成，一定要提前给约定的人说明；

共享文档

Google Drive

OneNote

石墨文档

腾讯文档：

任务管理

任务要会预估时间，要进行合理的拆分，每个人的任务预估时间后，要进行任务的切分，每次提交的代码就是一个功能，否则不好做代码评审；

不要在全部功能都写完再提交所有的修改，这样任何代码评审中的任何意见都会引起大量的修改；除非你的需求设计设计的很完美；

经验

一：早会是必要的，早会上每个人说说自己做了啥，怎么做的，这样既可以防止有人偷懒，又可以交流经验，防止类似的问题出现不会改，而且前一天不会的东西，早会的时候大家可以讨论讨论，做过的给个建议。

二：团队一定每次安排几个人学习新的东西，然后小范围实验，可以大范围教学推广。学习的人轮流来。

三：项目开发文档精细化，明确化，需求的变更必须经过设计人员，设计人员文档化。

四：团队的管理者不要事事亲为，多分任务给下边的人，要看到下边的人的光芒。

一定要有意见箱

有福利有规则层级分明

没福利就要打感情，让其感觉到一直在这也挺好的。会画饼！！

减少不必要的浪费时间的形式化

开会前自己要有一定的清晰思路和退路，如果没有讨论出结果，自己要有自己可能定的东西，自己先不要说如果团队有更好的，大家讨论通过当然很好，如果没有就用自己的，大部分时间开会时讨论不出来问题的。

员工个人魅力，告诉员工跟着我你会得到很大的提升。

了解员工擅长啥？发现不了就让他自己去发现，经常夸一夸“哎，你这个地方还不错啊！”

防"杠精"：分配任务给他，让其感到委以重任，但是也让其自己感觉到自己能力不行。

最担心那种这不行那不行的，又提不出解决方案的。

防止三个和尚没水吃，将其细化任务规则

拍板人！！当好拍板人。将结果公示化让大家都明确清除。

让大家看清楚懒人。

对于新人一定要定期了解其进步，能分配给什么新的任务了。

完成任务时，不要想着取代上级，要想着辅助上级；学习技术时要想着取代上级；

除非要开发的功能显而易见，首先需要在纸上写出你对需求的理解并画出流程图（简化版的规格需求说明书），在脑海里对这段代码进行一个完整的构思。除非你彻底弄清楚了如何修改，否则不要开始代码编写。

禁止傲慢——其实不只是新人——一些有几年工作经验的开发人员也会表现出这种傲慢，一部分原因是其满足于个人获得的专业成就，另一部分可能的原因是其缺乏和优秀的人共事的机会，有点坐井观天。

技术不是越新越好，而是能够最接近的解决当前的问题的最好；