小团队的技术管理

简介: 小团队的技术管理原文链接  最近一年左右兼职技术管理的经验试总结,核心理念就是以人为本。小作坊  小项目的构成往往是一个相对有经验的人作为 leader,带几个毕业生构成一个三五个人的小作坊。没有达到配置专门的项目管理人员的程度,因此管人管事管技术,三权集中在一个人身上。

小团队的技术管理

原文链接

  最近一年左右兼职技术管理的经验试总结,核心理念就是以人为本。

小作坊

  小项目的构成往往是一个相对有经验的人作为 leader,带几个毕业生构成一个三五个人的小作坊。没有达到配置专门的项目管理人员的程度,因此管人管事管技术,三权集中在一个人身上。

  对效率上有好的和坏的影响,但也是不错的选择,开发人员一般是比较难管理的,职业的项目经理很难做好这个事情。

  这也从一定程度上让这个 leader 的精力极大分散,很难做较多的 coding 工作,分散在项目管理,对外对内协调,以及人才培养,质量控制等工作。耗散精力,同时也对能力有较大的锻炼,提高了独立生存能力。

年龄特点

  之前有专门讨论过,由于婴儿潮的原因,90后人逐渐开始变少,同时由于没有经历过童年的物质匮乏和最近几十年中国经济的快速发展,这代人相对80后更崇尚自由,会少一些牺牲,多一些自我实现,也因此相对更难于管理。

  这代人的成长环境也确实优越一些,接触电脑早,教育资源优质,也少走了不少弯路。相比之下,同样是工作两年,明显新生代比曾经的我有诸多优势。当然,这也是相对的。

无为

  无为不是什么都不做,而是让无来为,事情本身有自己内在的规律,把一群优秀的人放在一起自然就能做好事情,这种协作的能力是天赋的。无为是尊重客观规律,不做不必要的干涉,在宏观上把控,抓大放小,用养的心态,往往能释放应有的创造力,得到高质量的产出。大部分的控制都是弄巧成拙。这一点作为90后,亦是相当的认同。当然,对于作者后面讲到的无为所致使缺陷,也是不做反驳。毕竟是人,每个人都有其特点;而且,从于何人,事于何地,也需另当别论的。

以人为本

  工作为了什么,首先是钱,然后是成长,再然后是实现理想。

  培养和保持一个精英团队,对技术有卓越的追求,互相认可彼此的技术水平,这样的环境在国内是十分稀少的,自然会在一定程度上珍惜。

  独立承担更多的责任,而不是把底层自己实现掉,剩余 ui 层来做。对管理者来说,大部分的模块已经没有什么挑战了,应该放手放权让组员独立承担,对自己精力是一个解放,可以锻炼了组员独立解决问题的能力。如果每个人都能做到自我管理独当一面,就有机会变得轻松了。寻找一些有技术深度的点出来,把部分预研工作交出去。独立面对产品和 ui,节省自我的精力,也对组员有好处。

  抓大放下,不深入细节,过多的控制有副作用,细节的争论消耗精力,又因为组员把全部精力投入到一个点上,因此也很难占到便宜。

  保持coding,要有自己的核心技术,否则,很快就会受到挑战。管理者有点像是坦克和治疗的责任,来保证 dps 全力输出。

  我推崇流程尽可能的弱,因为几乎每个流程都有副作用。deadline 会影响质量,refine 然后就不被鼓励,指标越精细越抑制创造力的发挥。如果大家都是 kpi 导向,就没办法做到卓越,真正的卓越从每个人的自我实现中涌现出来。

  真诚沟通,不是从公司的角度,而是从对方的角度,究竟我认为怎么做是对的。在一个公司待的时间毕竟有限,三五年可能就不在了,一个互联网公司的寿命本身就短。技术也一样,很快就过时。作为个人和团队,应当如何共同应对这些挑战。

  程序员把代码看做自己的孩子,因此要尊重组员的代码,这样他们才能用最大的爱心和热心来维护这部分。 曾经我让G同学改了H同学的部分代码来实现一个需求优化,后面有问题找H同学,感觉他的意思就是,代码被G改乱了,他不想管了。这也说明了,保持所有组员的高水准的必要性。之前我也接手过一些代码的维护工作,坏味道非常重,非重写不可。持续产出低质量代码的人,应该从编码工作中脱离出来,或者隔离到一个不被任何人依赖的地方。此一段 每一观皆讲到我的心坎里

无为的缺点

  无为执行起来实际上非常的困难,也有一些不利的方面。类似民主,能释放创造力,有时又效率地下。无为相信人,但人终究有时不可靠的,这就导致有可能出现有人吃大锅饭,或者自我管理能力不强失控的情况出现。

  具体表现在时间和进度上容易失控,如何及时发现和化解这种风险,而不是视而不见。因此需要一个清晰的项目计划和任务估计,一方面及时发现风险,一方面也是对时间管理能力的锻炼,这一点很重要。

  人治有好处也有缺点,容易形成军阀割据的情况,因此聪明的管理者会引入法制来进行约束,法制把人拉回平等的水平,一定程度上也是必要的。 也就是,以德治国是不够的,还需要依法治国。

  在中国很难有纯技术的环境,不得不在一定程度上 kpi 导向,国内的各种创新院研究院,都没有好下场。因此,要保持平衡。

权力的味道

“如果你们告诉我的有关他们的事是真的,那么我只能说,他们还没有尝到真正的权力的味道。” -宋美龄

  权力是个好东西,但不能迷恋。有舍才有得。想拥有就会恐惧,就会耗费精力,而实际上拥有与否并非是个人意志所控制的,不如随缘。

  物竞天择,换个角度,天竞物择,没有要为了一个具体的事情改变自己。同时又要像水一样,不守一个固定的形态。

讽刺

  我曾经有过一个神级的 leader,可惜当时太年轻,选择去挑战而不是学习,错过了不少机会,回想起来十分后悔。如今我也在经历类似的事情,很具讽刺意味。每个人都有缺点,正确的做法是扬长避短,而不是挑刺,所谓三人行必有我师,也只有走过弯路才会懂得。

  我们都还在成长的路上。

倾城之链 | NICE LINKS DJI Mavic Air
目录
相关文章
|
1月前
|
监控
提高团队的执行力怎么办
提高团队的执行力怎么办
45 4
|
1月前
|
监控
提高团队执行力
提高团队执行力
37 3
|
敏捷开发 机器学习/深度学习 搜索推荐
如何做好创业公司研发团队的项目管理?
探讨创业公司中的软件研发项目管理问题: 大部创业公司的软件研发管理处于什么阶段? 如何改善软件研发过程和提高效率? 软件研发过程会涉及哪些工程理论和方法?
350 0
如何做好创业公司研发团队的项目管理?
|
监控 NoSQL 前端开发
带团队后的日常思考(三)
  参与制订业务方的BUG规范,业务方最近投诉我们技术部,在飞书群中提出BUG后,技术部没有人响应,认为我们的态度太冷漠。   后面我就提出任何看到的人,只要知道是谁负责的,就@那个人,大家都不要客气,这是第一步。
带团队后的日常思考(三)
|
存储 缓存 移动开发
带团队后的日常思考(四)
  这次公司有个五周年的庆典活动,但正好碰到两个APP的版本发布,以及三个测试老员工离职,只进来了两个新成员,其中一个恰好要休陪产假,那么测试组资源异常紧张。   虽然我们提前了整整一周提测,但一直到周五还有很多点没测到。测试组甚至想到了阶段测试,因为多个活动的上线时间不同,所以可以先测最先上线的活动,后面的再往后推,延迟测试,这是他们组的一个对策。
带团队后的日常思考(四)
盖洛普Q12在团队中的应用
周五给大家做了个盖洛普Q12的分享。
盖洛普Q12在团队中的应用
|
开发者
技术团队管理者的软技能(上):关于团队文化和领导力
技术管理者或者技术领导者绝对不能够只有优秀的编程能力,其他的软技能也是对于架构师成长必不可少的。本文由中生代技术分享群申健为大家分享的关于技术团队管理者的那些软技能。精彩不容错过。
3747 0
|
敏捷开发
技术管理
最近一直在思考技术转管理过程中需要注意到的一些事情,现在就总结下分享给大家看看 在转变过程中,需要注意到一下三个方面 业务管理 团队管理 技术管理 业务管理 业务管理,主要就是管理我们需要处理的业务需求。
1255 0