• 成为会带团队的技术人 做规划:除了交付和稳定性,还要规划什么?


    在大部分公司中,技术团队的规划存在两种情况:公司制度需要做规划上报,Leader 主动做团队规划。如果公司本身就会制定季度规划/半年规划,并要求每个部门和团队都要做,在这种情况下,所得出的规划有一定作用,但是大部分是为了与上一级目标保持一致;反之,如果公司并没有硬性要求,但技术团队负责人主动去做,说明愿意长期去完成一些事情,是好的习惯。

    而有意识地做团队规划价值很高,你可以通过做规划,严肃、完整地重新审视团队的情况和问题;另一方面,随着业务发展和系统迭代,你会发现业务与技术需求都呈几何倍增,但时间、资源、人力、物力却是有限的,这时候该做什么、不该做什么、哪些事儿要加大投入,很大程度上,“团队规划”所确定的内容会作为原则或判断标准。

    所以我认为团队规划解决的核心问题是:让你在有限的时间和资源内,明确怎么去创造最大的技术价值(ROI)。而且在做团队规划的过程中,其实是一个深入思考、梳理的过程,你可以复盘过去、梳理当下、展望未来,少走弯路。

    总之,做团队规划需要一些思考、流程和章法,当然,技术团队的规划流程大同小异,比如从公司、上级部门、业务团队得到一些规划线索,结合团队现状(问题 + 痛点)一起敲定规划范围,从价值优先级的角度不停排序打磨,形成规划初稿分析难点和可执行计划,形成共识并在接下来一段时间内严格执行,阶段性带领相关人员进行复盘。

    今天我这一讲,我会结合经验强调其中三个比较重要的环节,希望你能有所收获。

    做规划要考虑团队现状

    团队规划不是无中生有,需要思考一定的问题,有一定的依据(比如团队现阶段承担的具体职责是什么?今后的发展目标是什么?分哪几个阶段实现……)先定义清晰自己团队的现状再做规划,现状不同、发展目标不同,在规划的选择上就会截然不同。

    针对团队现状的梳理,可以从这几方面切入。

    • 明确定位与职责: 你的职责以及团队的定位是什么?公司对你们的期望是怎样的?你与上一级目标的关联点在哪?

    • 人员情况: 成员能力、团队结构、团队规模以及当前团队负载;

    • 业务情况: 业务当前的侧重点是什么?阶段性目标如何?业务的执行计划是怎样?技术能解决的痛点在哪?

    梳理团队现状之后,你会发现大量的 TODO,并且痛点和问题特别多。这些问题随着时间和业务的发展一直存在,只不过突然把问题放到一起,你会觉得想做的很多,能做的很少。这就很考验 Leader 的决断了,比如什么内容是要列入规划,什么事务并不是重点问题?

    一个可以参考的思路是: 盯着业务目标去延展人员和业务,从而判断哪些是依赖项,哪些是前置项?在大部分公司中,技术很难直接创造商业价值,往往还是要依赖于业务,所以把业务作为第一目标,为了达成某个业务结果,需要调整人员结构,招聘一些更厉害的人汰换一些不行的人,研究并实现一些新技术,这是比较自然的。当然,并不是所有团队都适用这一点,可能有些非常棒的团队已经走在技术驱动业务的道路上了。

    总之规划在开始之初,就应该对优先级(轻重缓急)有一个考量的原则,这样才能在有限的时间内创造更多的价值。这一过程的思考路径和我 “08 | 定目标:让你的方向与公司的方向保持一致”中提到的一些方法大同小异,比如和上级沟通、确定公司方向、探寻周边合作、倾听团队成员反馈等。

    总的来说,深入了解自己的团队,才能针对性地去明确规划核心、丰富规划内容,更容易落地。

    你的规划中包含了什么?

    不同的技术团队,在规划时所拟定的内容都是不同的,但你其实都可以提炼成共性的3 部分。

    • 业务结果: 直白说就是业务层面的战绩,你团队打造了一个公司 GMV 占比超过 50%的商城,或者支撑了某个快速发展业务,这些都是业务结果,用业务数字来说话。

    • 技术创新: 由技术人员发起或完成的所有降本提效的动作,但是同样要看优先级和投入产出比。

    • 团队建设: 让团队可以长期健康发展下去,要在 Backup、人员组成、机制建设等多个方面下功夫。

    除了这 3 维度去思考规划,我还单独划分了第 4 点“自问”,“自问”是我从经验出发,认为需要贯穿这 3 部分,也就是说,在你拟定每一个规划分支时,都需要自问这样几个问题:

    • WHY:为什么做业务目标/技术创新/团队建设的规划?

    • WHAT:是否能说明业务目标/技术创新/团队建设规划解决的问题、价值与作用?

    • WHO:由谁承担?负责人的优势与跌势是什么?

    • WHEN:所做的规划着眼于现在还是未来?能否保证长期有价值?

    • HOW:针对不同的部分,具体的落地细则如何?

    • HOW MUCH:规划要做到什么程度?是否可以形成可衡量的KPI

    业务结果

    现阶段,大部分的技术团队都是用来服务于业务,为了创造更多的业务、商业价值。在此基础上,你要想制定业务价值方面的规划,可以从协作部门的规划、公司整体的战略目标、老板的诉求、团队成员的理解等线索出发。

    比如你要明确现阶段上级领导关注的重点是什么?是转化、流量、留存、还是产品的用户体验?作为技术Leader ,你和团队成员的到达路径是什么?这是线索来源之一。

    这些思考和 08 讲有所雷同,不一样的是目标更多围绕单一有明确的时间点的结果;规划更多着眼于一个时间段内发生的变化以及事务优先级的平衡,如何找出最重要、最值得做的哪些事才是关键。

    技术创新

    技术创新我考虑了“稳定性、效能优化、驱动业务、视野展望”这几个方面,当然,这几点并不固定,比例也可以有所不同,你可以结合公司的业务形态,和团队定位进行调整。比如你所在的团队正在做新的项目,主要目的是验证新的业务场景是否跑得通,那么此时快速验证、通过新技术带来新体验更关键,这时,技术稳定性的比例会稍低(接受犯错),新技术尝试和视野展望的相关事项就会更多。

    稳定性老生常谈,是技术人在做规划时不可缺少的一部分,如果不能确保系统稳定性,剩下的效能优化、驱动业务、视野展望也就成了空谈。

    效能优化在技术规划里也很常见,比如你肯定会听到“优化开发的效率、流程”,但是坦白讲,效能优化是比较难做,除了研发结果量化困难外,研发效率跟人、流程、当前业务状态的绑定非常紧密,牵一发而动全身。尤其是一个业务如果处于不确定的背景下,研发效能优化比较难以寻找合适的着手点,很容易优化来优化去,效率越来越低。

    我建议你从几个最痛的点去着手,看如何通过工具、流程、新技术等手段减少不必要的损耗甚至颠覆现有的开发模式来逐步优化,不要总想着一口吃个胖子。

    技术驱动业务一直是很多同学期望实现的效果,大部分公司也推崇技术同学多了解业务,成为技术和业务都精通的“双面精英”。比如饿了么最早的餐厅菜单是市场工作人员和餐厅老板手动录入的,OCR 图像识别对这个场景就是技术上的“原子弹”,堪称降维打击。很多时候,我们过去一段时间看理所当然的东西,在最开始创造并应用时,会创造出巨大的价值。

    视野展望又可以叫作“团队对新技术的探索”,这一点其实是要求技术 Leader 自己的,你对新技术的敏感和接受程度某种程度上来说,决定了你团队的技术上限。你可以定期关注业内的新技术发展,对于技术趋势你如果不能成为主导或推动者,最起码要紧跟步伐,不让自己成为“前浪”吧?

    团队建设

    在前面管理框架的几讲中,我已经提及了团队建设的一些基础理论和实践方法,比如团队成员的沟通、流程机制的建立、招聘解聘和绩效等。在这里我只想强调这样一个重点:该怎么思考团队建设这件事?团队建设的关键是什么?

    假设你现在带了三个月的团队,开始做团队规划,在团队建设这里的核心重点就在于从未来看现在,从整体到个体,比如团队有 8个人,你的重点是不是考虑“未来怎么把团队的 8 个人用好?怎么安排他们做合适的事情呢?”并不是。

    团队建设的关键不只是知人善用,而是:

    1. 团队未来需要什么样的人?

    2. 目前团队成员需要什么样的状态和能力?

    3. 团队成员需要承担什么样的责任?

    总的来说,你希望未来自己的团队成为怎样的团队?以此推导离理想状态多远?怎么缩小差距?

    而缩小差距的过程就是整体到个体的过程,可能你需要跟张三、李四不断对齐目标,帮助他们调整状态;开除王五;招聘陈六……要记住,团队建设的核心在于思考团队的未来和终态如何,反推每个人、每件事。不然你会发现,所做的每一件工作都是对现状修修补补,很难有质的改变。

    规划落地时的问题与思路

    在明确了规划中需要包括的内容之后,我们还需要正视做规划时,容易出现的问题。

    • 规划不等于计划

    有的同学认为公司业务不定性,经常调整,做规划没有意义。这是因为一些同学将规划与计划画等号。但其实计划是一张时间表,它严丝合缝,不能打乱;规划则是某个阶段内的优先级,做规划是为了让你知道哪些是重要的?性价比高的?值得做的?是盘点和创造技术价值的过程(比如将规划内容按照重要性排序、产出规划 PPT 、产出关键里程碑时间点)并不是执行的过程。

    • 规划内容想得太多,做成的少

    规划并不是囊括万物,需要有落脚点,有要核心解决的问题,并以周/月为单位去调整自己的规划,不要放任不管。

    • 业务压力大,盲盯痛点,忽视目标

    这个问题比较常见,要知道解决痛点最终是为了实现目标,如果你一直盯着痛点的话,会发现自己永远没有目标,只有痛点。

    • 规划最终成了技术Leader的规划

    我之前在 08 讲里提到了类似的场景,目标规划一定要形成 KPI,落到每一个人身上,让每一个人都跟结果息息相关,一定将规划拿出来讲、拿出来看,每周带领团队成员查看进度,同学们一定会重视。

    小结

    做团队规划是一件比较综合宏观的事情,有时哪怕只是几个人的团队,想做好一份规划而非执行计划也很考验 Leader 的思考深度,某种程度来说,规划是你定义一群人在未来一段时间内做什么、怎么做、最终变成什么样。这个过程中需要考量的点非常多,这些深入的思考也会促进你日常的一些行为和结果,对于团队的季度乃至半年规划我是非常推荐你要定期梳理并落地的,有目标和没目标的团队,还是有很大的差别的。

    留个作业吧:你觉得技术团队规划中最有价值的点是什么,为什么你这样觉得?

    怎么做技术团队规划.png


    精选评论

    *鹏:

    您好,能否提供一份规划模版参考一下,谢谢

        讲师回复:

        我一般常用的就是脑图中“规划包含”什么那个结构,可以先罗列所有的点,然后在合并同类项 + 确定优先级

  • 相关阅读:
    【ajax跨域问题解决之jsonp】
    数字签名与数字证书
    java常见集合遍历的空指针情况
    【790. 多米诺和托米诺平铺】
    WeakMap 弱引用 不会被GC所考量
    IDA软件为什么运行不起来
    redis持久化之RDB
    注释之重——程序员与代码可维护性
    鉴源论坛 · 观模丨形式化方法基本原理初探
    Spring MVC 的核心组件有哪些?
  • 原文地址:https://blog.csdn.net/fegus/article/details/126536027