《技术管理之巅》-试读与吐槽开发管理

程序员文章站 2022-05-13 18:07:42

...

简介

作者是一号店技术总监，从身临其境的管理感受出发比较接近实际。但是一号店的管理是不是很好这个我也没有待过所以没法评价，不管怎么样确定的是最起码能学到一招半式！

第三章团队架构

3.1 从零开始

相信很多在创业公司的朋友都很有感受，作为我个人虽然进的不是创业公司但是确实稳定公司里的创业团队，全新的一块业务全新的团队，一切都是新的，所以我多多少少能体会到作者写得一些东西。

招聘，行为面试法，具体就是让面试者举例子从中发现面试者的一些特质。不过本人技术面试做的比较多，我比较喜欢从技术问题出发来评测面试者的技术偏向及个人的一些特点，如是不是好学，是不是思维清晰，沟通是不是顺畅，还有是不是诚实，哈哈。个人觉得举例子等比较适合团队leader，项目经理等一些管理工作的职位。不过里面举的一些问题例子及面试注意都是很好的，这些是不是从面试的书里面学到了然后又搬来了？！

用人，“知人善用”很好地概括了。不过作者没有讲如何知人和善用，而是如何“留住人”，绝招1）宽松的环境，2）可发展，3）奖罚分明。GET！

育人，有三招：1）培训，2）培训，3）培训。其实不然，提供员工成长的沃土是交流分享和技术能实际用武之地，而非只有培训。文中还提到轮岗，也是一个不错的办法，一个人在不同的开发团队，甚至不同的岗位能学到很多不同的东西，but，一般好难实现特别是一些团队中的中流砥柱，整体靠他们来运转，他们换了那....所以做好替补还是很必要啊。

留人，1）薪水，2）成长，3）管理，4）生活品质，5）企业文化。所以我说嘛，用人也是这几招，唯一不同的是多了后面两点，不过4）我觉得应该叫人文关怀从属于管理和企业文化，可见作者也就那么几招，很多人想尼玛只要第一招就ok了，够人文关怀够成长了，我只能说你很实际，值得托付终身。

讲的那个故事虽然很真实很动人，不过看完以后没啥感受。吐槽。

3.2 互联网下的组织架构

扁平化、去中心化。举了个小米的例子，能从中学到，哦不是，应该是了解到一些小米的管理方式，三级模式确实很扁平，想想我厂到最顶层得六层，差一层就能坐电梯了。

扁平化确实可以节省很多决策路径，但是对于大公司来讲，最起码是一个产品或者说一个项目是一个团队，那么那个团队有leader吧，再者团队大点还得分小组，小组就有组长，组长得向团队leader汇报或者决策提交，这样的团队多了大boss也管不过来，除非团队leader能最终拍板决定，不过事实上不是这样的，很多还是得找老板毕竟这么多团队leader难免会有几个不是那么果断且判断准确而且最重要的是他买不了单。所以，还得根据做的业务不一样分事业群（好多公司那么叫），看就这么着就不只三层了，所以有点怀疑小米的例子是不是真实或者说细节没有交代清楚。

“阿米巴”模式是个很好的模式，前提是公司制定好规则，大家在规则之下*地玩耍。

都是很好的模式跟方法，不过视实际情况而定，没有一招鲜的玩法，只有最适合自己公司的模式，不断摸索不断改进的过程。

3.3 组织架构变迁

介绍了几十人到上千人的团队，角色划分及配比。好像都是这么玩的。介绍了阿里，百度和腾讯的架构变更，很生动。大家了解下就行，对于一些准备组织架构优化的老板来说这节你看了个热闹，并没有得到任何启发，有人说：no！学到了根据事业群去划分这样起码跟腾讯比起来省了好几年的探索。

3.4 异地团队的高效

异地其实不是件好事，要不然连恋爱这么好的事情搞成异地了以后都不推介，更何况技术团队了。咱们为什么要异地团队呢？主要是一线城市人才资源有限成本比二三线要高。异地最大的障碍就是沟通。通过接口人的方式来减少沟通是一个非常好的办法，我们也这么做，确实有用。还有个重要的问题是沟通困难了以后问题发现滞后甚至到最后关头才发现，所以每日晨会的方式是及时暴露问题的办法，敏捷也是有这种玩法。后面又介绍一个敏捷的玩法：白板还是电子的。

举了几种两地的人员角色分配，貌似这几种都玩过，不是贪玩是没有办法实际就是那样，而且异地的团队主要开发人员来自外包，当开发人员主动性很差时并且还在异地时真的很崩溃，不考虑实际情况的话，个人觉得第2种是最好的，因为毕竟开发时间占总时间的绝大部分，所以AA跟开发在一起开发起来比较顺畅，当PD需要是可以出差的毕竟占的时间不多。

总结

从试读的第三章来看初地一看槽点多多，但是细细想想很多我们觉得理所应当其实都是有道理的，从中学习到一些模式一些办法再结合自己的实际情况改良成适合自己团队的模式办法运用过来还是比较有意义的，总的来说比较实战话，成果怎么样根据不同情况效果也不一样。希望能读到其他章节！