首页
学习
活动
专区
工具
TVP
发布
社区首页 >专栏 >研发之路:结构化的思维体系

研发之路:结构化的思维体系

作者头像
木东居士
发布2020-08-03 15:14:39
9600
发布2020-08-03 15:14:39
举报

研发之路结构化的思维体系

每次写周报、作汇报、发文章,都难免要讲到自己的日常工作,如何说清楚是一个不小的挑战,非常挑战结构化思维体系。

|0x00 如何形成结构化的思维

形成结构化思维,首先要有一个定义:“建立中心化的要素,并能够对中心进行逐步的分解,形成分类子结构。以一定的方法论对分类子结构进行分析,寻找对策,制定行动计划”。

例如,当我们接手一项任务时,应当首先思考任务的核心目的是什么:

  1. 任务的当前目标是什么?(事)
  2. 为什么这个任务交给我?(人)

从事、人两个维度向上推导,思考这个任务,在整个业务、团队中,是在什么层次和分类上,从全局的角度看,这个任务被赋予了怎样的期望。

先思考事,再思考人,最后向上推导,思考“价值”。这样就建立起了结构化思维体系的“中心”。

当形成“中心”后,再反向对任务进行拆解,通过一定的方法论,分析任务的有效解决方法。

例如SWOT方法,通过Strengths 优势 / Weaknesses 劣势 / Opportunities 机会 / Threats威胁,四类象限,能够两两组合得到不同的分析思路。最早用于进行企业竞争态势分析,对个人而言用于分析自身的竞争态势也是极佳的。

例如AHP方法,将与决策总是有关的元素分解成目标、准则、方案等层次,在此基础之上进行定性和定量分析的决策方法。

有了分析问题的思路,再用Xmind等软件进行任务可视化,一条清晰的路径,就展示了出来。

但这还不够,因为“事情是无限的,而人的精力是有限的”。如果认知的高度不够,那么总会陷入“战术勤奋、战略懒惰”的陷阱。那么就有必要清理任务中的噪点,让精力更加专注。

主要有三个方法:

  • 泛化:对客观事实进行抽象,精简维度。
  • 补漏:补充缺失的关键信息,避免误差。
  • 剪枝:去除非核心的影响因素,聚焦精力。

最后,结构化思维,就是一个非常清晰的方法论:

  1. 从人、事出发,推导主要价值,形成中心思想;
  2. 以中心思想出发,拆解任务结构;
  3. 通过一定的方法论对子任务进行分析,寻找对策;
  4. 制定行动计划。

|0x01 思考力、知识树

技术人通常有误区:只要努力了,就会有结果。这是不对的。成长这件事,取决于每个人对于重复性劳动的思考成果,换句话说,思考力是能力的最重要影响因素。

例如:

  • 为什么要建数据中台,中台一旦拖累了业务发展,应该如何取舍;
  • 为什么工作中要有“一号位”意识,业务兜底会带来什么影响;
  • 业务系统这么复杂,是否一定有必要提炼中心思想?

现代互联网技术的飞速发展,带来的业务增长是空前绝后的,知识的记忆量也已经爆炸到了一定的地步。但“万变不离其宗”,其实技术原理一定是数量可控的。

例如单纯学习Dubbo怎么用,其实对于业务系统帮助并不大。但如果了解了Dubbo对于寻址、容灾、扩展的核心思想后,这套中间件思维,就可以复制到其他场景中。

所以,对于每个人而言,都应该形成属于自己的知识树。如果对于每件事情,都能够有一种习惯性总结的方法,那么再复杂的业务,也能够快速的通过方法论来提炼要点。可以说,思考力,能够充实个人的知识树,是结构化思维的底座,决定了结构化思维的扩展能力。

如何培养,道理简单,就看个人的坚持程度:

  1. 保持对自己的信息,时常反思工作;
  2. 放低自己的姿态,对新技术、新思想持开发心态;
  3. 学会组织碎片时间,学会平衡看消息与做事情的节奏;
  4. 用好工具,锻炼好习惯;
  5. 多交流、读书、分享。

|0x02 结构化思维在研发工作中的应用

形成了结构化思维,回看日常的工作,无非就是:技术、业务、管理,这三大类。

对于技术而言,通常关注如下几个核心点:

  • 技术基本功:对于数据而言,就是SQL的熟练程度,以及思考问题的反应速度;
  • 架构经验:用过哪些大数据框架,特点如何,优劣势如何;大公司里,即便是一个小需求,也会涉及到非常多的系统,这个过程中项目的协同与推进会远比想象中的有难度,架构经验非常有用;
  • 项目经历:数仓结构设计、技术架构设计、模型抽象能力等;技术都是有债务的,如果给自己挖了坑,早晚都要有填上的一天;
  • 质量与稳定性:做出来的东西,如何保证不出问题;这是一个先有意识再有能力的问题,千万不要在故障复盘会上,体现你的风采。

对于业务而言,核心点如下:

  • 技术规划源于业务:技术同学在做规划的时候往往有一个习惯,那就是先写现状与痛点,再写对应的解决方法,最后展望未来;但往往总结下来,发现部门的业务规划跟自己的规划没什么关系,于是干脆自己搞自己的,矛盾也就起来了;其实在写规划的时候,慢一点,先跟平级的团队,包括产品和运营,聊一聊,了解其他团队,以及大部门的重点是什么,然后再平衡自己的规划,这样来的更加实在一些;
  • 比PD更懂业务:这个道理很简单,就是避免成为“工具人”,做到业务上的“向上兼容”;
  • 系统边界:团队协作,总是避免不了“纠纷”,系统的边界纠纷会一直存在,在实际的开发中我们做不到至臻完美;所以需求评审的时候,一定要聚焦一下“解耦”的工作,把东西拆到足够清晰,减少可能的矛盾点;

对于管理而言,要注意这些事:

  • 计划不如变化快:大多数情况下,“加人”并不能解决团队困境,因为未来是变化的;平时多打听打听,培养一种面对变化的敏感性,如果能在在变化到来之前主动发起变化,那么化被动为主动是最好的;
  • 生产力与生产关系:大公司通常有比较好的生产力,但生产关系比较混乱;生产关系的梳理要依赖于业务本身的定义和发展的预判,最终要体现在明确的权责和协作效率上;
  • “向上”兼容:“向上”,本质是要求和老板达成一致的目标和互相认可的结果,很多问题,也只有老板能推得动。

简单列了一下,不具体展开。

碰到问题,先基于上述的三个方向,理解问题,并且总结抽象,把关键点拆分出来,并根据方法论,做计划和执行,最后补全自己的知识树。

|0xFF 写在最后

归根结底,技术人员的成长路线上,大多数人,还是要成为“复合型人才”。学会学习的能力,不断实践,经验变成能力,能力促成结果,在结果中积累信心,深化能力。有的时候,能力只是坚持的结果,仅此而已。

本文参与 腾讯云自媒体分享计划,分享自微信公众号。
原始发表:2020-07-30,如有侵权请联系 cloudcommunity@tencent.com 删除

本文分享自 木东居士 微信公众号,前往查看

如有侵权,请联系 cloudcommunity@tencent.com 删除。

本文参与 腾讯云自媒体分享计划  ,欢迎热爱写作的你一起参与!

评论
登录后参与评论
0 条评论
热度
最新
推荐阅读
目录
  • 研发之路结构化的思维体系
    • |0x00 如何形成结构化的思维
      • |0x01 思考力、知识树
        • |0x02 结构化思维在研发工作中的应用
          • |0xFF 写在最后
          相关产品与服务
          消息队列 TDMQ
          消息队列 TDMQ (Tencent Distributed Message Queue)是腾讯基于 Apache Pulsar 自研的一个云原生消息中间件系列,其中包含兼容Pulsar、RabbitMQ、RocketMQ 等协议的消息队列子产品,得益于其底层计算与存储分离的架构,TDMQ 具备良好的弹性伸缩以及故障恢复能力。
          领券
          问题归档专栏文章快讯文章归档关键词归档开发者手册归档开发者手册 Section 归档