| Boss | Leader |
| 驱动员工 | 指导员工 |
| 制造恐惧 | 制造热情 |
| 面对错误，喜欢使用人事惩罚手段 | 面对错误，喜欢寻找解决问题的技术或管理方法 |
| 只知道怎么做 | 展示怎么做 |
| 用人 | 发展人 |
| 从团队收割成绩 | 给予团队成绩 |
| 喜欢命令和控制 | 喜欢沟通和写作 |
| 喜欢说，“给我上” | 喜欢说，“跟我上” |
转自http://coolshell.cn/。
Category Archives: 团队管理
一对一会谈：清单对对碰
一对一会谈：清单对对碰
有关如何组织一对一会谈（即管理者与员工定期进行的面谈），比尔·坎贝尔曾经向我们推荐过一种比较独特的方法。管理者应当把最想在会谈中涉及的5件事写出来，员工也应该列一份这样的单子。把两张不同清单拿出来后，单子上十有八九会有几个条目是重复的。对于所有的一对一会谈而言，双方共同的目标都是为了解决问题，如果管理者和员工不能独立找出最需要两人共同解决的问题，那么摆在两人面前的问题就更不可忽视了。
除此之外，比尔还为我们推荐了一个好用的一对一会谈大纲，让我们在应用中受益匪浅。
1.工作表现
a.可以是销售数据
b.可以是产品交付情况或有关产品的重大进展
c.可以是消费者的意见或产品质量
d.可以是预算数目
2.与同事之间的关系（这对企业成员的团结一致非常关键）
a.产品人员和工程人员的关系
b.市场人员和产品人员的关系
c.销售人员和工程人员的关系
3.领导与管理
a.你有没有对你的人员起到指导和帮助的作用？
b.你有没有把“害群之马”清除出团队？
c.你有没有在人才招聘上下功夫？
d.你能否激励员工做出创举？
4.创新（最佳实践）
a.你是否一直在进步，是否一直思考着如何才能变得越来越好？
b.你是否经常对新的技术、新的产品及新的方案进行思考和评估？
c.你是否将业界或世界上最顶尖的人或企业作为对比标杆？
《凤凰项目》之布伦特
《凤凰项目》之布伦特
By NEOHOPE
《凤凰项目》是一本介绍DevOps的书，书中有一个叫做布伦特的人，他个人能力很强，工作超级努力，对公司的各种IT环境了如指掌，做事情超级靠谱，大家都喜欢找他合作，有了问题也会第一时间想到他，就是一个公司的英雄人物。
但问题是，长期的工作模式，导致了IT部门几乎所有重要事情都需要布伦特参与才能成功，于是可怜的布伦特天天加班，而且无论如何都完不成堆积如山的任务，最终造成了大量的任务积压，IT部门被各种投诉。
同时，由于工作压力，布伦特更加没有时间写文档，做事情只好走捷径，甚至会直接变更一些数据流程，最后很多环境只有他清楚，很多事情只有他可以做，就是一个恶性循环。
新上任的比尔将布伦特识别为IT生产环境中的约束点，并对此采取了对策：
1、告知布伦特，拒绝除凤凰项目以外的任何项目，如有疑问直接找布伦特的领导沟通，并与CEO取得了共识。让请求需要通过层层过滤才能达到布伦特，从而保证了布伦特可以将精力放到最重要的项目中，让布伦特去做该做的事情“偿还技术债务，保证系统的稳定性、安全性、可扩展性、可维护性、可操作性、持续性”，而不是“修理打印机，升级电脑，连接网络”；
2、对所有积压的任务，进行区分，所有不需要布伦特参与的变更都可以根据优先级执行，所有需要布伦特的项目都需要等待凤凰项目，从侧面引导大家使用其他资源，并在此确保好钢用在刀刃上；
3、在其他部门领导绕过流程，直接为布伦特安排其他工作时，直接抽丫的；
4、围绕布伦特，组建了一个资深小组，学习布伦特的工作经验，并形成文档，将布伦特的经验传授过所有人，将布伦特从各种复杂繁琐的事情中解放出来；
5、最后，将布伦特整理的各种脚本，做成自动化发布软件，最终解放了生产力；
最终结果是，一开始大家承受了很大的压力，但经过一段时间后，大大提升了工作效率。并发起了独角兽和独角鲸项目，取得了成功。
我们周围的布伦特是谁？我们有好好保护他吗？我们有找人帮他把经验变成团队的经验吗？我们如何帮他提升到一个新的水平？
呆伯特法则
呆伯特法则
By 斯科特·亚当斯
呆伯特法则：意指1990年代一个讽刺意味的观察，认为公司倾向有于把工作能力最差的员工提升到管理层，以把他们能对公司造成的损害减至最低。“呆伯特法则”是彼得法则的变化。彼得法则指在阶层式组织或企业中，人会因其工作出色，而被擢升到他往往不能胜任的高级职位，相反变成组织的障碍物（冗员）及负资产。
职场百态
By 斯科特·亚当斯
一些事没人做，
一些人没事做。
没事的人盯着做事的人，
议论做事的人做的事，
使做事的人做不成事、做不好事。
于是，
老板夸奖没事的人，
因为他看到事做不成。
于是，
老板训诫做事的人，
因为他做不成事。
一些没事的人总是没事做，
一些做事的人总有做不完的事。
一些没事的人滋事闹事，
使做事的人不得不做更多的事。
结果，
好事变坏事，
小事变大事，
简单的事变复杂的事。
然后公司开始出事，
为了解决这些事，
老板开始要求不做事的人做些事，
这些人才做一点点事，
就到处说他做了全天下最难的事，
也有人啥事也不做，
只会说这是一件不可能成功的事。
最后，
做事的人还是不得不接下这些没人做的事，
公司得救了，
不做事的人就说：
那还不是他们在开头做了许多事，
公司完蛋了，
他们也会说：
我早说过那是不可能成功的事。
最后全公司的人都不做事，
反正不做事也不会出事，
多做事反而会惹事。
阿拉伯谚语：
“你若不想做一件事，可以找到一万种借口。
你若想做一件事情，终会找到一个方法。”
致新人，差距是如何产生的（02）
致新人，差距是如何产生的（02）
Hansen
先从一个故事讲起：
一个师傅带两个学汽修的徒弟，都从喷漆开始。一年后，师弟都会调悬架了，师兄连轮胎都不会换。师兄问师傅，为只教师弟不教自己。师傅说，为了把漆喷好，你师弟请教了几个老师傅，查了不少资料，每天晚上都自己花时间尝试各种想法，半个月就可以自己做好了。你呢，每天看似很努力，但一个问题出了几次还不知道为什么，三个月后还是只能处理最简单的刮擦，怎么教你新东西？换轮胎不是我教的，我带你俩出去修车，都遇到过爆胎。你师弟看过一次，第二次就主动要求试试看。你呢？我换车胎的时候，你在抽烟玩手机吧？。。。
总结一下也就是： 性痴则其志凝。故书痴者文必工，艺痴者技必良。世之落拓而无成者，皆自谓不痴者也。
以下内容节选自《平台组动员会议2017.ppt》：
自主学习
2016年你学到了什么？读了几本书？看了多少教程？读了谁的博客？在StackOverflow上回答了几个问题？GitHub上贡献了几行代码？LeetCode上通解决了几个问题？是否接触过新的语言？
考个证？拿个学历？参加个会议？参加个培训？
2017年，你的学习计划是什么？是不是要重复2016年做的事情？你的2016年是不是在重复2015年做的事情？
Google还是百度？英文还是中文？
什么是高原反应？
什么是努力，知道迈特凯、洛克李、迈特戴吗？
如何提升自己？请用5%的休息时间来提升自己。
主动思考
支付宝有几种支付方式？微信有几种支付方式？为啥需要这些支付方式？
全家移动支付的时候，需要收银员做什么操作吗？为什么？
滴滴打车，司机抢单算法是如何计算的，你知道什么是滴米吗？
手机定位有几种方式，必须要GPS才能定位吗？手机计算你走了几步，是怎么实现的？
什么是Java？Java常用框架的原理是什么？Tomcat是怎么工作的？JVM究竟是做什么的？Dubbo怎么实现RPC的？
软件哪里可以优化，哪里应该改进？我的代码哪些地方有些问题？
Stay hungry, Stay foolish。
做喜欢的事情，还是应该做的事情？
随着一个人的成长，这是一个人必然会遇到的问题。（你父母希望你先写作业，还是先看电视？你希望自己的孩子怎么做？）
任务分配的时候，是应该把业务流程讲解清楚，还是让他、她自己去看去理解？
代码注释应该怎么写？
单元测试应该怎么写？
SVN代码提交的时候，注释应该怎么写？
代码提交之前是否应该通过单元测试？流程是否应该跑一遍？
程序发布之前，是不是应该自己先测试一下？还是直接扔给测试或实施？
如何提高员工的归属感
如何提高员工的归属感
Hansen
1、物质奖励（除了薪水，还要有适时的激励和奖惩）
员工工作，就是为了更好的生活。一切只谈理想而不谈待遇的企业，都是在耍流氓。
但要知道，物质奖励可以留着员工的人，但很难留住员工的心。
这和追女朋友是一个道理的。
2、让员工知道自己的职业道路，以及上升空间
一个没有进步空间的岗位，是留不住人的。
3、让员工提升对自己工作的认可，其实就是提升对自己的认可，从而增加员工的自信
人对自己做的事情认可了，才能坚持下去
4、管理层应该去了解你的员工，去关心你的员工，增加团队粘性
团队关系良好，是很强的粘合剂
有些员工带有自来熟的属性，也是很合适的粘合剂。
可以参考海底捞。
5、良好的企业文化
重视每一个员工，和谐的人际关系
重视员工的权利，明确员工的义务
增强员工话语权，让员工一同参与出谋划策，增强员工的使命感及荣誉感
6、管理层的示范作用
要起到带头做用，勇于担当
让别人喜欢你，让别人认可你，让别人信服你
7、公平考核制度及竞争环境
you can you up. no can no bb.
8、要对员工进步，并提供相应帮助
让程序员永远在同一层次上，重复同样的工作，是留不住人的
要求员工自学、积累、创新，并给与教育、培训的机会
看看很多从外包企业出来的哥们，在外包做了十年，重复了十年，最后把自己荒废了。
9、培养并激发员工的兴趣
包括工作相关和工作无关的兴趣。
产品管理模式演化
==========================================================
最开始的时候，公司产品管理比较混乱，几乎对每一个客户都进行了定制，出现了大量的分支。
后面发现维护成本太高，开始合并各版本之间的功能，但最终仍有十几个版本。
PS：后来公司换了老板，初期很多有经验的研发及实施人员都流失了，很可惜。
==========================================================
2009年，项目比较小，我们采用的是按功能划分的方式进行分工的，经常一个项目就一个人，或一个项目拆为几大块，每人一块来进行。这个模式持续了一段时间。
现在回过头来看这段时间的一些产品，产品功能不多，但需求做的很好，产品定位比较准确，符合客户要求，后期移交其他同事维护后，架构上和界面上都没有大的变化。对于小规模的开发，这种方式还是适用的。
==========================================================
2010年底到2011年，公司开始了电子病历项目的开发，投入了不少的人力。由于项目变的比较复杂，现在变成了十来个人一起扑到一个项目上。第一次引入了需求、测试人员。本人甚至客串了一段时间的美工+前端（惨不忍睹）。
这段时间是架构转型的时间，时间紧任务重，语言也刚开始学，加了很多班，好在项目最终验收了。
后来由于很多原因，整个产品线被砍掉了，又流失了不少人。
==========================================================
2012年，开始了平台项目，初期核心团队不大，产品已经有了原型，加上前面的积累，整个任务还算顺利，但仍然是加了很多班。
架构为简单的SSH，后台逻辑为主，前端现在看来惨不忍睹。
花了很多时间，补充平台应用。
==========================================================
2013年，团队人员增加了很多，引入了MVN，开始有了较好的任务分工，架构变的明晰。
花了很多时间，把其他缺失的部分补上来，逐渐形成了一个产品线。
开始使用快速原型法。
开始引入ESB。
==========================================================
2014年，团队人员再次增加了很多，同时加上很多水平不错的同事加入，有了较好的发展。
开始推进单元测试，产品流程越来越规范，快速原型法使用的越来越多，大量使用交互稿。
很多地方开始务实，产品定位进行了调整，很多项目都开始使用ESB。
部分项目，前后端开始分离。
==========================================================
2015年，团队人员有些变动，核心团队还比较稳定。
开始推进高并发，更加关注代码质量。
补充了很多ESB的接口。
前端团队飞速成长，前后端彻底分离。
==========================================================
顺便说一下，我在2009加入公司时，研发中心除了总监，只有我一个人。初期从其他部门调来几个人员，加上招的一些人，也不足10人，现在研发中心已经接近150了。
致新人，差距是如何产生的（01）
今年，我们组来了很多的java新人（编程经验小于一年的小朋友）。
对于他们，我都会做下面的事情：
1、让他们自己列出自己的知识架构，从而告知其不断积累的重要性
90%的人只用过java语言，只知道SSH。
这里，我会结合他们大学课程、实际经验，给他们补充一部分知识架构，拓展一下视野。
并告诉他们如何去对比的学习新知识，如何找到一种适合自己的学习方式，并要找到适合自己的知识积累方式。
2、以一个很简单的例子，告诉他们应多考虑原理，而不只是用
在一个网站中，在只用了一个框架，比如struts2或spring mvc的情况下，前端登录页面的用户名、密码，是如何发送到后台，并返回验证结果到前台的。
所有人，都直接提到了action如何获取用户名及密码，但只有很少人考虑了，浏览器是如何找到服务器/容器的，也只有很少人知道，容器是如何定位到哪个应用、哪个action的。
然后，会告诉他们，希望他们可以在一年之后，用最复杂的解释，告诉我，这个流程是如何运作的。两年之后，把整个流程变简单，并可以自己去实现一个简单的框架。
3、送给他们一本《程序员的职业素养》，让他们自己去领悟其中的内容
4、探讨他们的职业发展道路
5、开始安排培训，并开始逐步解除新项目
因为，在我看来，程序员在前三年的时候，是个明显的分水岭，所用的学习方式，直接决定了他是程序员还是码农还是该转行。
团队的沟通成本真的太高
以前读《人月神话》的时候，感觉作者一再强调“沟通成本”实在是有些夸大其辞
现在，联系这一件件的事情，
发现，即使在这几十人的团队，百十号人的公司
沟通成本仍然高的可怕
总结下来一下几种情况：
1、认为自己很牛，不愿意和不理解自己的人沟通，大多数人都有一些这样的倾向，这样的人，最后失败了只会责怪别人，认为“这里不适合我，要是周围的人能理解我，我一定做的比谁都好”
2、认为自己不能让对方，尤其是强势的人认同自己，沟通了也是白沟通，于是选择沉默，认为“你瞧不起我啊，我还瞧不起你呢”或“告诉你了，听不听是你的事情”或者最后出事了“让你不听我的，该、、、”
3、认为沟通不重要，宁可去写代码也不愿多说两句话，多发封邮件，多打个电话，结果初期很容易沟通的事情，最后成了不可沟通的矛盾，这样的人一般这样想“这么简单的事情，你怎么可能不知道”，“算了，打什么电话啊，最后再说”
4、传声筒，很多时候，一句话，经过一个人传播后，意思会彻底变化，即使侧重点不同，甚至语气不同，这个也会害死人的。
唉，团队啊团队，细想起来问题好多啊
沟通成本高很可怕，但还有救
当每个人都选择沉默的时候，就真的晚了
一个高效IT团队需要什么？
1、在一个高效的团队，
团队成员首先需要有良好的专业技能和高度的自觉性，缺一不可。
成员之间沟通是提高效率的关键，
高层领导的重要性，战略眼光及决策能力
中层领导的重要型，有较好的领袖才干，对技术的发展方向要有良好的把握，可以服众
产品经理的重要性，专业技能过硬，执行力要强，对项目工期把握要好，对下属能力要有良好了解，要有良好的沟通能力和抗压能力，知道自己的职责不推卸责任，知道自己的职权范围不轻易许诺。
2、为了激发员工的积极性，
需要建立一套行之有效的赏罚制度。要赏罚分明，罚要有理，赏要有力。
同时要有一套良好的晋升制度，让每个人知道自己努力的方向
最终建立的仍应该是金子塔型的
3、人才储备
人才储备十分重要，
挖人和防治被挖
4、保密制度
对核心人员，
对产品经理
对程序员
5、良好的招聘及培训机制
可用之人，骑马，牵牛，赶猪，打狗