团队管理的一些心得

2019独角兽企业重金招聘Python工程师标准>>>

##心得主要从以下四个方面说起

• 道不同，不相为谋
• 项目风控
• 有爱，信任，团队凝聚力
• 规范，专研，润物细无声

道不同，不相为谋

企业的文化就是老板的性格，团队的文化就是团队经理的性格

没错，这看着确实是有些专制和官僚，但是，实际情况就是如此。

目前国内相对浮躁的创业氛围，一个好的团队，可能需要有以下3个特性：

• 有责任心，正直，对自己的将来有规划和期望

有目标的人，对自己负责的人，才会对自己所做的东西负责，这样，leader也才会放心的把一些重要的事情交给他。

• 能耐得住寂寞，能吃得了亏

一个公司，不可能是经常有从零开始的项目的，也不是每个好的项目都可以给你挑，更多的还是现有产品的维护开发，以及一些零散的脏活累活，尤其是针对一些新来的同学，不管你是新手还是老鸟，都应该是需要有能耐得住寂寞吃得了亏的品性，才能等来好项目。

• EQ要过得去

关于EQ，可能有些同学觉得我码个代码，怎么还需要考量EQ。其实这个对于团队协作来说，是至关重要的，包括我自己，也一直在做自控和提升。试想：一个不敢和陌生人交流，也不敢打电话的人；或者说没有团队意识，崇尚单干只会单干；或者经常情绪失控冲突不断，适应弹性弱；对于团队来说，简直就是灾难！

项目风控

技术以产品为驱动，产品以公司战略为驱动

技术是为商品服务的，是藏在商品里面的，能不用就尽量不用，因为多了只能意味着伴随更多的风险，况且能赚钱的只是商品而不是技术，不需要再商品中可以去炫耀有多牛逼的技术，客户不会买单，也不懂。

在项目、技术风控上，我觉得应该尽可能的把关以下5点：

• 新产品、新团队、新技术坚决不能同时出现

当时是要研发一款新的APP产品，临时组成了一个6人小分队，包括产品、测试、研发、设计，经过研发内部和技术总监多方讨论，最终采取了cordova的方案，并采用了当时还是beta版本的ionic框架，虽然经过1个多月产出了一个beta版本，并在半个月后推出正式版，但是交互体验实在不是很好，还是在优化了部分ionic源码的情况下，依旧只能达到可用的状态，尤其是在android机型上，比jquery mobile只能说好那么一点点。这为后续的native改版，耗费了不少的进度，所幸是回归了正途。期间新团队的磨合，新技术的踩坑，一个多月，几乎都是在加班中度过，说多了都是泪。

• 基础框架、基础功能严格把关，尽量不采用未经商用的第三方组件

这种例子就不举了，相信很多人都有或多或少的经历，引用了个小众的第三方组件，号称有啥啥啥功能，一旦业务量上去，就时不时出现些诡异的问题，真的是恶心得不要不要的。

• 重要业务必须要有完整的业务流程图

主流程主业务，相关的研发必须要100%的理解，才能构建出强壮易扩展的核心骨架。否则云里雾里的不断叠加功能，就会让一些悄然发生的错误不停的扩散，最后让整个产品的业务数据崩盘。

• 防止走极端

言语间处处是类，处处是抽象、封装、分离，不惜一切的使代码高内聚低耦合。 结果是自己看自己的代码赏心悦目，别人看他的代码云里雾里。如果不精通设计模式按照常规理解业务的思路去阅读代码的话，就更看不懂了，对阅读者或者说是协作者要求太高。还有一点，则是这样的做法性价比太低，高投入低回报。商业软件，首先是要叫座，其次才是叫好，纯粹的东西放在教科书里或者是自己的兴趣爱好里即可。

• 数据的安全

简洁明了一句话：从头到尾都不能松懈，尤其是针对新手！

有爱，新人，团队凝聚力

最好的方法，为每一位新成员选择一位性格合适的师傅或战友。
在工作协作中，没有总监、经理，这些会让员工产生隔阂、距离和权利争斗。
只有师傅、老师和战友，一起扛枪、一起战斗，消灭一个个目标。

我觉得这是一个和团队战斗力直接挂钩的内容，主要体现在以下5点：

• 对团队要有爱

对团队要有爱，保护好每一个成员，对内可以非常严格，但对外就应该是值得信赖的保护伞。比如来自外部的批评，负责人要第一时间承担下来，再是内部具体消化解决。

• 抓大放小，多搭舞台，给机会、给项目去锻炼

抓大放小，尽量的给机会、给项目去锻炼人，但是任务要选对人，且要超出其能力的0.5倍左右，小于1倍。

多看多交流，少干涉，让团队自己去搭配表演去解决问题。

只在合适的时机插手，什么是合适：方法效率明显很low的时候，项目进度快要失控的时候，出现严重的协作问题的时候，不管手头有多重要的事情，都应尽快组织相关人员沟通交流，这种问题越拖越严重，百害而无一益。

• 重要模块尽量安排两个人共同去完成

重要模块尽量安排两个人共同去完成，并引导他们多沟通交流。相比单人开发，双人模式会在工作内容上彼此负责，会多一分代码质量上的考虑，另外对于业务的理解和实现方案也会更全面一些，能提高项目的风控，但是，最大的前提还是选择的两个人要愿意交流和合作。

• 及早培养多个替代者

嗯，每个人都有因为自己的理想或者其他原因，突然要出去走走的时候。

• 奖励承诺，必须兑现

奖励承诺，必须要想尽办法兑现。实在不行，那也要有充分的人性化的理由，坦诚沟通。

规范，专业，润物细无声

从游击队到兄弟连，从兄弟连到正规军

这一块内容，是最费时间精力的，但一旦生效，也是回报最大的地方，主要分为以下3点：

• 规范，需要种植到骨子里

规范，应该不是一字一板强行要求出来的，规范之所以能成为规范，那肯定是有大多数聪明的人都认为有其优秀的地方，需要有人去引导，更需要自己去悟去感受，去融入到骨子里，那才是真正给予的。 强迫或者无理由的要求，只会适得其反。

• 对成员的专业度负责

出发点必须是要对团队成员的前途负责，不是说有什么活就分配什么活，结果给人感觉就像个混子，什么都干过，什么都拿不起，一出公司就得饿死。专业的人就该做专业的事，如果连他自己吃饭的本事都不专业了，那你还能要求他投入多少青春？ 我会经常抽空看一看项目的一些重要业务的代码，如果有看到我不太能理解的，就会先记下来，及时的找相应的研发一起讨论为什么这样写的原因，一起交流其合理性或者是有没有更好的方案，互相尊重，共同成长。

常此下来，我发现很多时候是我没有理解透这一块的具体业务，因为有些细节只有代码写到了才会发现，而他边想边写了一周，你就大致看了几小时，一些精妙的设计一下子显然理解不了。也有时候是因为我对业务的理解比他范围更深更广一些，导致我觉得当前的代码实现应该可以更好一些。

而有些时候则是个人的写法风格问题，像这种情况，如果对性能、稳定性几乎没有影响的话，我一般是会提一些建议和相应的解释，但不会强求。因为殊途同归，一个对自己有专业要求的人，肯定是不会让自己保留连自己都觉得不规范的代码存在的。只是说要给予耐心让他去量变到质变，去润物细无声的影响他，而不是拔苗助长。更何况，每个人总是认为自己的选择是对的，不然就不会选择了，其实，只有时间才知道是对是错，所以作为leader也只能是建议而已。

• 信息的最大化共享，阶段目标的交流

多交流，永远是一件好的事情，尤其是项目到了一定阶段或者是里程碑的时候，更应该多交流多总结，交流可以了解彼此的性情态度、人生价值观、技术观，从而在工作中，做出更好的优化配置，因为旁观者清，当局者迷，有些同学很努力，但是不擅长总结自己，这种情况就可以及时给他制定一个切实可行，在某段时间可达成的，他自己也喜欢且愿意努力，对他未来的职业发展也很有好处的职业目标。如果一个人一直在努力做没有目标的工作，很容易迷失方向，产生负能量，因为不了解而损失一个努力上进的成员，就太不划算了。

完结

在此，非常感谢《走出软件作坊》这本书，虽然是一本关于传统软件行业的书，但是依旧受益颇多。

转载于:https://my.oschina.net/rayinhangzhou/blog/719827