团队架构

博客分类: 江河计划

团队架构

算法

二叉树的层次遍历

给定一个二叉树,返回其按层次遍历的节点值。 (即逐层地,从左到右访问所有节点)。

例如: 给定二叉树: [3,9,20,null,null,15,7],

    3
   / \
  9  20
    /  \
   15   7

返回其层次遍历结果:

[
  [3],
  [9,20],
  [15,7]
]

我的解法是遍历,逐渐增加深度,依次传递下去,Leecode 解法都类似。

var levelOrder = function(root) {
    if(!root) return [];
    var arr = [];
    inOrder(root, 0 , arr);
    return arr
};

const inOrder = (root, deep, arr) => {
    if(!root) return;
    if(!arr[deep]){
        arr[deep] = [];
    }
    arr[deep].push(root.val);
    root.left && inOrder(root.left, deep + 1, arr);
    root.right && inOrder(root.right, deep + 1, arr);
}

将有序数组转换为二叉搜索树

将一个按照升序排列的有序数组,转换为一棵高度平衡二叉搜索树。

本题中,一个高度平衡二叉树是指一个二叉树每个节点 的左右两个子树的高度差的绝对值不超过 1。

示例:

给定有序数组: [-10,-3,0,5,9],

一个可能的答案是:[0,-3,9,-10,null,5],它可以表示下面这个高度平衡二叉搜索树:

      0
     / \
   -3   9
   /   /
 -10  5

我的解法是递归的过程中加入二分

var sortedArrayToBST = function(nums) {
    if(nums.length === 0) {
        return null;
    }
    if(nums.length === 1) {
        return new TreeNode(nums[0]);
    }
    var mid = parseInt(nums.length / 2);
    var root = new TreeNode(nums[mid]);
    root.left = sortedArrayToBST(nums.slice(0, mid));
    root.right = sortedArrayToBST(nums.slice(mid + 1));
    return root;
};

团队架构

在我的架构认知中,我觉得团队是根本,固根才能培本,团队不同的阶段是需要不同的方法去带的。

目前了解两种团队架构,资源型:将前端业务全部收拢,然后统一调配分配给现阶段空闲且最适应当前业务的同学,这种架构一般是业务数多于现有资源人数,主要适合初创阶段,这个时候多数业务都是属于探索型,可能不会经常维护,每个业务都投入相关的人力会造成人员浪费,最好将资源收拢统一调配。

业务型:根据现有稳定的大业务,分配不同的同学一直跟随业务迭代,在这个阶段一般属于业务已经稳定,不断的在投入资源开发,在大公司情况比较多,这个时候需要有同学对业务有一定的了解,提升开发效率和提高业务认知程度。

在某些阶段我们也需要混合使用。已经成型并且不断有业务需求的业务采用业务型,留出一些资源作为资源型支持一些探索型的业务。

不同团队阶段

团队在三五人阶段的时候,这个阶段主要的是考虑团队对于业务的输出,并且人员较少,可以采用人盯人的方式,这个阶段自身能力其实和团队成员差距并不大,负责的相关业务也会相对较少,所以现在这个阶段还不需要考虑团队架构,事事都过自己的手是很有必要的,比如需求最好都是自己亲自带着做,代码一定要做 review,一方面会巩固自己的能力,另一方面这个阶段对外输出的质量和效率尤为重要,所以在这个阶段要做好,就需要有细致的把控能力。

团队在十人左右的时候,这个时候就得需要考虑如何最大化的输出团队的能力,需要对现有团队进行划分,这个时候对每个成员都要有一定的了解,明确了解到每个团队成员的优势和劣势,然后将团队成员进行划分,这个时候应该考虑一下团队架构,在这个阶段如果是在小公司一个完整的 team 建议采用资源型,在大公司一般负责一两条业务线采用业务型更好,这个时候就需要注意一些团队划分,将每个人放在合适的位置上,让他们发挥出自己最大的价值从而让整个团队发挥出最大的价值,更多的是执行明确的目标,达成明确的目标,团队更多的是输出。

团队扩张到 20-50 人时,这个阶段我还没有能力经历,我构想一下这个阶段的能力,首先需要认知能力读懂一些决策带来的行业影响,并能有足够的技术积累应对决策所带来的变化。团队层面已经能运用一些方法论对业务构建进行合理化的拆分和协作,将这个关系能很好的和团队映射起来,并且将核心内容进行合理的拆解,到不同的 TL 手上,不一定要按照业务拆分,在这个层面很多时候达成的目标已经不像小团队的时候那么细致了,这个时候可能有很多潜在的需求是需要领导者挖掘的,并且可能已经不能通过直接的划分达到目的,很可能需要一些和现在业务没有什么关系的团队去完成,比如组件、效率工具、底层架构、技术调研这些也需要单独的组去承担,所以这个阶段更多的思考如何合理的拆解目标达成目标,这个时候更多是思考定位,团队的定位,业务的定位,然后合理的拆解并通过一些方法论去管理得到最终的输出,更多的能力输出在于拆解和对最终结果的关注。

上一百人的团队就是我意淫了,更多的是看自己的认知力对于行业的理解,已经统一团队的思想,制定目标团队的目标,这个目标更多的时候要一定程度影响行业,主导行业的走向,就不瞎扯了,实在还没有到这个高度。

团队培养

前面已经有所提及对于团队能力的培养这块,团队完成需求的能力和知道为什么要这么去完成完成的能力应该是在五个人的时候,这个时候考虑更多的是输出,细节和质量的把控。

前端技术的全面性和技术深度是十人团队成长过程中的成果,也是一定程度的基础,在这个阶段已经有全面的业务负责了,团队的技术能力一定要覆盖住这个阶段的业务需求水平,这个阶段还应该有一定的意识培养核心团队开发人员,他们需要承担一定上一个阶段的管理能力,领导者在这个阶段也更多的是对于设计的把控,不需要太关注细节了,细节方面更多是需要下面的人去提高的能力。每个人在不同的阶段是需要不同的成长。

团队的稳定性

团队的稳定性在于技术稳定性、业务稳定性、团队稳定性,前两种就不细聊了。团队稳定性我觉得最重要的是成长,薪资的成长和能力的成长,前者能决定的比较少,后者一定要做到,每个人有不同的未来预期,现在的阶段,以及天赋,上述不同的情况也就意味着需要根据每个人的情况做一些计划。

技术上的提升可以做统一的,但核心的同学就要去成长一些管理,一些技术架构的能力。这些是需要根据自己的情况去制定一些团队成长计划,让每个人都有成长,并且有适合自己兴趣点的业务做,就不会考虑太多离职。能力成长了一定要有对应的薪资体现,因为能力成长的证明就是做出了对应的贡献,管理团队一定要树立目标,达成目标,奖惩,来让团队有良性竞争。

一定要有淘汰,这方面可能是不太擅长的,但是团队不同成员有不同的能力输出,要让团队一直保持竞争和成长,环境不能太安逸,也是一个必要的方式。

当各方面都更好的时候团队有自我的成长,并且团队树立了一些公信力之后会不断地吸引更优秀的同学加入加上淘汰,团队会一直保持正向的循环。