@Lenciel

软件的复杂度

人类创造了很多复杂度极高的系统:社会、经济体、软件和网络等等。在处理这些复杂系统方面,科学理论和实践上的进步其实非常小。

查一下 ICCS(The International Conference on Complex Systems)的2018会议你会发现,无论研究对象是什么,大家背后的数学基础或者方法论还是高度趋同的。

比如Natalia Komorova关于癌症突变的人口动态以及它如何受到维数的影响的研究,跟Cesar Hidalgo关于相关性原理经济地理学的讲座,思路都是基本一致的。

另一个例子是Nassim TalebStephen Wolfram,两个超级大牛的研究和观点上有那么多的共同点,让人觉得好像是平行世界的两个实例被我们同时接触到了。

在软件开发这个领域,当我们提交代码的时候,常常会有「随便动了一个看似无关紧要的地方,整个系统就崩塌了」的体验。这种隐藏的耦合性,其实也说明了软件的复杂度之高,趋于一个有机体。

为什么整个软件工程,无论是架构还是实现的方方面面,都是在管理复杂度,但却没有人讨论它呢?哪怕是从业者,也有很多都不太知道Postel定律Conway定律抽象漏泄定律

我觉得这很可能跟计算机科学的数学基础有关系:整个学科是基于离散数学的,而离散的部分聚合时,其实需要连续的数学工具来理解其行为。实际上,现在也确实有一些团队在采用反馈和控制理论,来尝试对软件系统的复杂度做更好的控制了。

技术团队基层管理怎么做

目录

最近好几位刚刚开始管人的同学问我,能不能给他们分享一下怎么做管理。

趁着劳动节,整理一点儿自己的看法。

首先,「怎么做管理」是一个特别庞大的话题,我自己的路还很长。这里的想法都比较主观片面,请酌情服用。其次,我最熟悉的还是技术团队的情况,所以除开一些做各种管理角色共性的部分,主要还是这个上下文。

是什么?

刚开始做管理的同学最容易犯的两个问题是:

  1. 把做管理当成「晋升」
  2. 把做管理当成「工作的一部分」

管理不是晋升

做管理不是晋升。

做管理是切换到一个全新的职业通道上,你是新手,你欠缺大量的必备技能。

怎么提高团队的效率,怎么考核团队的绩效,怎么选育用留人才和打造工程师文化,怎么分配自己的时间,怎么做好向上和向下的管理。

你会在很长一段时间里都表现很糟糕,如果你感觉很良好,这可能只是你表现得特别糟糕的迹象而已。

「晋升为管理者」的念头,让很多根本就很讨厌做管理的人,或者也没什么东西可「管理」的人,干到一定资历的时候就蠢蠢欲动。

特别重要的是,如果你没有服务意识和同理心,很难做好管理。

所以你因为看了片觉得霸道总裁讲话的样子很威风,内心有了奇怪的野望,千万别做管理。工作是职场人生活的主要内容之一,没有什么比遇到一个奇葩老板更惨的事情了。

请不要做奇葩。

管理不是「工作的一部分」

行业里好像经常在讨论一个特别无聊的话题,「CTO 要不要写代码」。

写代码和解决重要的技术问题,是两码事。

管理岗位的工作,时间是碎片化的,解决技术问题则需要有比较连续的不被打扰的时间。

在同一时间内你只能做好一样。

基层管理者通常都是表现出了技术上异于常人的优势被提拔的。但你选择了做管理,就要习惯被各种人和事情打断,不要再想着给你带来无上荣光的 Vim 了。

做管理是服务团队,激励员工,不管面对的是新项目还是烂尾楼,把商业目标分解成任务计划,把战略分解成战术,推动,执行,落地。

做管理要用心去理解员工的需求,评估员工的能力,分配给他们有挑战但又够得着的任务,为他们打造上升通道。

做管理是学习。

在做员工的时候,我们看公司就好像在逆向工程一个复杂系统一样:根据获得的片面的信息,猜测公司怎么每天都在做各种我们看起来这么挫的决定。

等做了管理者,你会学习到公司运营的更多细节。你会学习到(希望你能)组织是怎么协作的。你会学习如何进行一些不太愉快的对话。你会学习怎么调动那些你不太认可,可能也不太认可你的员工。你会学习如何处理冲突:一开始看起来很难,但是等你做管理越久,你就会发现直接的「冲突」简直是员工给你的福利,背后涌动的暗流才是麻烦所在。

你会学习每天精疲力尽的回家,觉得自己一件有「实际意义」的事情都没干,也不那么惶恐。

怎么做?

在一开始,作为基层管理者,你要识别哪些事情是「有用功」。

互联网行业,有很多地方 996,有很多人晒熬夜的图片。

这些肯定增加了总功,未必增加了有用功。

效率 = 有用功/总功

遇到活不要想着加人:作为管理者,你想到的是加人或者加钱,这不叫管理者,谁都可以做这样的管理者。

代码应该越写越少,活应该越干越轻松。

如果有 80 个人,你每天想的是这些人干嘛。如果是 8 个,你想的是,我干什么才是对的。

受限的团队才能抓住重点。

但你当然也需要一些管理动作。

每天

  • 了解每个同学的计划,进度和困难。可以通过站会,也可以通过代码审核,也可以通过聊天,但是必须做。
  • 参与至少一个技术讨论,看你能不能理解并发表建议。不要组织或参与冗长无功的讨论,如果还处于问题定义比较模糊的阶段,最好线下面对面讨论。
  • 解决所有同学们提出的困难。这里的解决是说指明方向,而不是手把手做出来(1-2-3原则1很好)。
  • 查看大家提交的代码和文档,知道大家是不是在做有用功。
  • 以身作则流程化,把所有的需求,结论,思路整理并跟踪起来,document everything(写文档是给自己捋思路的,技术文档推荐用英文写。用英语会让你写得简单明了,毕竟你词汇量没有大到知道怎么说废话)
  • 做好负载均衡,把事情均匀地分配给同学们,不要让每个人手上有太多并发的任务。每个人应该专注在一两个事情上。
  • 如果发现有人阻塞了,主动疏通

每周

  • 审视整体进度,根据实际情况增加或者延后任务
  • 和产品经理协作,做好任务的拆解,包括提前准备线框图等,确保所有人对任务的理解一致(包括界面细节)
  • 周报:大家本周做了什么,下周要做什么,需要什么帮助

两周

  • 找一个你感兴趣的系统细节,去深入的思考和了解,跟负责这部分的同学深度合作,或者完成框架并找到一个人可以继续完成细节
  • 1:1
    • 新同学:了解需求和问题,改进 onboard 的流程,让新员工更新文档
    • 即将转正的同学:评估他们的工作,给出意见和建议
      • 哪些事情会让你觉得不开心?
      • 我可以通过什么办法知道你不开心了?
      • 在你不开心的时候我可以怎样帮助你?
    • 老同学:
      • 确定目标和给予帮助
        • 对于你来说,什么样的 1:1 是有价值的?
        • 你今年的目标是什么?最近三个月的目标是什么?
        • 你需要从我这里得到什么帮助?
        • 你需要从团队那里得到什么帮助?
        • 你需要从团队外部得到什么帮助?
        • 学习和成长主要有四个方面的需要2是不是都进行得很顺利?有哪个方面你觉得需要加强或者压力太大了(压力太大是因为任务挑战太大,氛围太紧张,管理动作太多吗)?

螺旋上升

管理不是晋升,而是另一个职业通道,需要去学习,去发展相应技能。如果你干了一段时间觉得你都会了,又有兴趣做技术了,怎么办?

实际上,在工程团队里面的优秀管理者基本上都会有一个螺旋上升的过程:最好的工程师往往是做过一些管理的,因为他们会更懂得沟通,更有成本意识,更注重交付。最好的管理者往往是 2-3 年内还在一线做过技术的,因为他们会更有手感。

如果你从心里面接受管理不是晋升,就容易接受从管理做回工程师不是「降级」。

我的建议就是,开心的干,让员工开心,让自己开心。有天不开心了,就换个跑道再学习一下。

  1. 1-2-3 原则:遇到问题 1 个小时搞不定,就找队友。如果和队友 2 小时没有任何思路,就要上升到团队。团队 3 个小时搞不定,就找外援(确保大的技术障碍尽快出现在团队视野) 

  2. 这四方面是:有新的有挑战的事情可做,主动交流沟通互助的团队,公平向上开放进取的氛围,定期定时的清楚明确的绩效反馈