技术团队管理沉思录

摘要：团队管理难，技术团队的管理更难，做管理很虚，但是也是有迹可循。

本人从 2014 年到现在，也差不多有四年多的技术团队管理经验，希望能够将之前的一些琐碎以及系统的管理的经验做一些思考总结，对自己有更好的提升！

1.团队成员有技术高于一切的自我认知。

案例：最近公司在做一个智能存钱罐的项目，App 端分别由一个 Android 开发工程师和一个 iOS 开发工程师来开发，在开发应用的过程中，作为项目经理和产品经理经常反馈 iOS 开发工程师的对于产品和业务的理解，以及开发效率，明显要低于 Android 开发工程师。

分析：
1.开发效率不高。是不是技术能力相对弱很多？这个原因第一个被否定掉，据我分别和 Android/iOS 开发工程师的接触，其实发现 iOS 开发工程师的整体技术能力比 Android 开发工程师的还要高些。这个肯定不是单纯的技术能力问题。对于开发效率不高这个事实，先按下不表，先分析其它的问题。
2.对于产品和业务逻辑的理解差。依据我对 Android/iOS 开发工程师的了解，他们之间对于产品和业务的认知能力，差距并不大。这个也无法推断出原因。
3.先自我分析下，自己曾经是不是也有相关的问题。后来想起来自己在做 Android 开发工程师的时候，也有被项目经理说个这种情况，我自己的原因是因为过于看重技术，认为产品和业务一点都不重要，只要把需求实现了就可以了，从来也不思考为什么要这样做，也从不考虑用户体验。这个是个人对于技术、产品、业务、项目之间的重要性优先级认知有问题。
4.经过第 3 点的分析，反过头来思考 iOS 开发工程师存在问题的原因。iOS 开发工程师在讨论某一个具体的技术点，尤其是算法和新技术的时候，很有热情，看得出来很享受，而且平时经常购买一些和新技术相关的书籍，比如大数据、计算机视觉等。但是当在讨论某一业务的时候，显得并没太精神。对一些细节的产品用户体验，并没有思考。比如在用户蓝牙没有连接上音频推送的时候，提醒用户说“A2DP 没有连接”，这种很差的产品用户提示，都没有意识到，而且对于一些只需要经过一定思考的业务逻辑，也理解的不好。
5.经过以上分析，并且和 iOS 开发工程师的直接深入沟通，可以得出结论：iOS 开发工程师是因为在认知上面，忽略了产品和业务的重要性，认为技术高于一切。我只需要抓住技术就可以了，而不是去理解产品和业务。过于沉醉于技术实现，而忽略了产品和业务，当然还有用户体验，同时过于追求代码的完美，导致效率降低。

解决方法：
1.告知 iOS 开发工程师当前问题的根本原因：在你的意识中，你认为技术是高于一切的，其他的都不重要，导致了你对产品和业务的忽视，而且过于沉醉于技术，导致了你的开发效率降低。
2.告知原因还不够，每次总是告知对方这个理论原因，对方还是印象不够深刻，也就缺乏改善的动力。
3.我告知他：你这样下去很危险，为什么，因为认为技术高于一切，这个是很多新手容易犯的一个非常严重的认知错误。如果你不及时的意识并且改正这个认知的话，那么你就一直停留在新手的阶段，随着你年龄的逐渐增大，你就会逐渐失去你的竞争力。除非你满足于现状，你觉得你现在工作上的目标，事业上的成就，就仅仅局限于做一个只会用技术实现需求的 iOS 开发工程师，你不想改善你自己和家人生活的话，那么你可以保持现状。如果你不想这样，你还有追求的话，那你一定要改变这种意识。一个优秀的开发者一定是对产品、业务、用户体验等有深刻认知的，技术实现只是其次。用户不会关注你底层代码如何实现的，而是注意到你的用户体验如何，对于公司和企业来说，产品是否能够大卖，这个才是最重要的，技术只要能够实现功能就可以。

故事一：很多时候，我们并不是关心并不是怎么让程序运行效率高 20% ，而是怎么才能够把想法变成产品。你想要整一个网站，你觉得你需要学习计算机技术，写代码要从底层开始学起，于是你开始了汇编语言的学习，当你学习了很久，发现汇编语言很难，实现一些基本的功能都很麻烦复杂，当你终于学会汇编语言，准备向高级语言进阶的时候，你的竞争对手早已经通过高级语言完成了一个网站的开发，而且还利用广告实现了盈利，完成了从想法变成产品，而后靠着这个网站收益，购买了一部哈雷摩托车，暑假的时候，骑着摩托车去旅行去了。而你仅仅是学会了汇编语言，其他的什么都没有得到。

故事二：著名的苹果平台文档工具 Dash 的开发者把 iOS 版本开源了，然后马上有人发现了里面的代码是各种简单粗暴，开始各种吐槽。可是你们不知道的是：他靠着这个 Dash，一年收入 27 万美元还有给自己 5 周的假期。

2.中层管理者的职责和所需能力的思考。

3.如何让会议变得更加有效。
备注：会议是否必要，如何减少会议时间，提高效率，这些都是会议创建者必须思考的问题。

案例：目前我个人主持或者参与的会议有以下几种：
1.每周一上午《公司工作周会》。
2.每周一到周五上班之后的 30 分钟，分别参与《前端后台每日早会》和《Android iOS 每日早会》。
3.每周三下午《iOS 部门技术研讨会》。
4.每周四下午《Android 部门技术研讨会》。
5.每周四上午《项目管理周例会》。
6.每周五上午《软件开发部技术分享会》。
7.每周六上午《公司分享会》。

从以上统计来看，我个人参加的会议还是非常多的，还不包含一些临时的关于项目的讨论会。当然，有一部分会议，不能称之为会议，我们只是聚居在一起做一个讨论，或者做一个内容阐述。这些会议目前看来都是需要开的，那么我们需要从高效来着手，否则这些会议还是会大量的占用个人的时间，尤其是会议参与人员越多，对团队的时间也是比较大的干扰。

4.代码管理的重要性。

5.开发人员任务优先级的安排。

案例：最近公司一个 iOS 开发工程师，提出需要调研 JSPatch，以便来更好的解决 iOS 应用 Bug 的修复，但是当前他另外一个项目，拖了一个多月，还没有完成。

目前公司开发人员的工作，一般分为两块，一块是做项目，一块是技术平台小组，通常情况下，项目作为优先级，而不是技术平台小组的调研内容优先，我们给客户做的项目，优先级肯定是要更大，技术的提升是必要的，但是当前优先级不够高，而且项目一直拖了很久，这个时候再同意做 JSPatch 的技术调研，是不合适的，因此果断的拒绝，并且强调当前项目的延期和重要性，需要以项目为主。另外，有一些对新技术有热情的人，在人员工作分配的时候，可以优先考虑这些人进行技术调研，喜欢做项目的，也是可以优先安排项目来做，在顾全大局的时候，考虑到每一个的兴趣和热情，是一种好的管理手段。

6.不要仅仅反馈问题。

案例：最近公司一个 iOS 开发工程师给出的 Ad Hoc 测试包，产品经理无法安装，当产品经理问他的时候，他只是反馈：这个测试包用到了推送证书，是另外一个账号的，里面可能没有你的手机 UDID。然后就没有然后了，产品经理直接找到我来反馈这个问题。

产品经理需要的是能够在他的测试机上安装测试包，他想要的不是你反馈问题的原因，而是要解决这个问题。很多人在职场中容易犯这样的错误，有人反馈问题，到了自己这边，只是反馈下原因，而不是直接去解决问题，然后做问题的总结。

及时的解决问题，而不仅仅反馈问题。

不断更新中！

打赏