技术团队管理沉思录 2018-07-26 / 634 次 / 快抢沙发 /

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

本人从 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。然后就没有然后了,产品经理直接找到我来反馈这个问题。

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

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

不断更新中!

打赏
本博客所有文章如无特别注明均为原创。复制或转载请以超链接形式注明转自ifeegoo 的个人博客,原文地址《技术团队管理沉思录
上一篇: « 下一篇: »
暂无相关文章

> 添加新评论

Copyright © ifeegoo 的个人博客 Time is limited, less is more! / 粤ICP备15109713号-1 / Theme by Hang & Ben / WordPress / 知识共享许可协议