小团队的技术管理

简介: 小团队的技术管理原文链接  最近一年左右兼职技术管理的经验试总结,核心理念就是以人为本。小作坊  小项目的构成往往是一个相对有经验的人作为 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月前
|
监控
提高团队的执行力怎么办
提高团队的执行力怎么办
55 4
|
1月前
|
监控
提高团队执行力
提高团队执行力
44 3
|
敏捷开发 机器学习/深度学习 搜索推荐
如何做好创业公司研发团队的项目管理?
探讨创业公司中的软件研发项目管理问题: 大部创业公司的软件研发管理处于什么阶段? 如何改善软件研发过程和提高效率? 软件研发过程会涉及哪些工程理论和方法?
354 0
如何做好创业公司研发团队的项目管理?
|
缓存 监控 前端开发
带团队后的日常思考(二)
  经常在工作时被人小窗,这里的计算有问题,那里的表格没内容了等等,一开始肯定是懵逼状态,然后是根据症状一步步的摸索代码逻辑。
带团队后的日常思考(二)
|
运维 监控 NoSQL
带团队后的日常思考(一)
  由于公司规模并不大,因此一有事情就会拉个会议,例如需要大会、技术评审、汇报周会、突发会议等。一周中大概有20%~30%的时间会花在大大小小的会议上。
带团队后的日常思考(一)
|
缓存 前端开发 JavaScript
带团队后的日常思考(六)
  当前我们组管理着一套审核系统,除了数据源是服务端提供的,其余后台管理都是由我们组在维护。   这个系统就是将APP中的各类社交信息送到后台,然后有专门的审核人员来判断信息是否合规,当然在送到后台之前已经让机器审核了一遍。
|
SQL 小程序 测试技术
带团队后的日常思考(七)
  最近被插入了一个需求,我们组经常会被插入各式各样的需求,因为之前负责的范围非常广。   这次的需求就和一个陈年接口有关,其实要修改的地方并不多,就是为一个请求多加一个参数。   但是比较麻烦的地方就是验证阶段,就是我在加上这个字段后,我得知道发请求的时候真的带上了。   根据URL地址反查到了页面代码,在本地启动项目,访问页面,直接报错。   调试陈年项目,这种情况是经常发生的,涉及的问题很多,例如内部接口不通了,数据库表结构变了,需要的数据记录本地没有等等。
|
缓存 运维 前端开发
带团队后的日常思考(八)
  最近有个活动,在提测后的第二天,大家才得知上线时间是后天。但是问各个技术,大家都不知道这个时间,而产品是知道的,运营也知道这个时间。   那这就有点诡异了,为何会出现这个情况呢,进一步了解后,才发现原来在一次会议上,口头说了下上线时间和提测时间。   在那次会议上,大家都说了自己的开发时间,但是,对于提测时间,开发和运营却有不同理解。我的提测时间是11或12,但运营的提测时间是10号,以后对于这种时间截点还是要更敏感一点。   UI给到我们设计稿的时间,晚了一天,其实如果不晚的话,即使我们不知道上线时间,也会按预期进行。
|
移动开发 自然语言处理 前端开发
带团队后的日常思考(五)
  他们组没有一个正式的组长,只有一个临时的代理组长,这种情况从我进公司到现在一直是这种情况,也是蛮奇怪的。   前几天,这个代理组长和其中的一个组员爆发了点冲突,我从旁观者对他们对话的理解就是,组员觉得他瞎指挥,他觉得组员无担当。
|
开发者
技术团队管理者的软技能(上):关于团队文化和领导力
技术管理者或者技术领导者绝对不能够只有优秀的编程能力,其他的软技能也是对于架构师成长必不可少的。本文由中生代技术分享群申健为大家分享的关于技术团队管理者的那些软技能。精彩不容错过。
3752 0
下一篇
无影云桌面