表达不明白，往往是想的不明白-轻识

很多同学在讲一件事情的时候，讲不明白或者没有逻辑，往往会归因为表达能力差。

但我观察下来，大部分所谓表达能力差的背后，是他没有想明白。

比如很多同学找我CR代码或者聊技术方案的时候，经常会东一句西一句的。逻辑上漏洞很多，追问几个问题，大概率是吞吞吐吐说不明白。

那我会追问下，你是怎么理解这个需求的。

他大概率也是聊不清楚需求背后的价值的，或是被需求表象欺骗了，或是被现状绑架了。

我们可以简单抽象下，表达视作输出，输出有问题，往前捋，有处理环节和输入环节。

所以输出有问题，大概率是处理端或输入端有问题。

写代码，做架构方案其实是一种表达，是一种输出的结果。

但，如何写好代码或者如何做好的架构的基础，是你如何理解需求，也就是输入端。以及你如何挖掘到需求本质做必要的抽象与扩展，也就是处理端。

比如有的需求看似很复杂，其实是因为大家没有很好的抽象，大家在一团乱麻中各聊各的，就会显得非常无序。

一旦没有在复杂问题中找到关键问题，并深挖到问题本质的能力，想要用简洁语言表达这个复杂问题就不成立了。

最近做了一个技术评审，讲了一个希望用低代码解决过去研发投入成本的问题。

简单来说，就是过去研发需要投入一定的成本，配合需求的开发、改造。新方案想通过低代码方式把这部分成本直接交给运营或产品自己操作闭环，省掉研发成本。

低代码某种程度上可以解决研发成本问题，但关键点有两个：

低代码的低，不在于技术，而在于体验，就是如何以用户视角看用户的操作。

比如完全没有技术背景的人，你让他挂接api，让他通过json解析response data这事就不太成立，你并没有降低这部分成本，而是成本转移了。

同时，也不是所有的场景都适合引入低代码解决方案，我们很多时候用低代码，就是抱着用后即弃的想法的。而且低代码用不好，会导致大量的业务逻辑碎片化，和我们软件中“高内聚、低耦合”的要求南辕北辙了。

同时，如果你提出了，后续业务方自己不断抽象优化这个低代码配置出来的工具这事就比较难搞。因为大家在低代码定位、以及解决的问题上并没有形成共识。

没有共识就很难达成统一解决方案。这某种程度上不是个技术问题了，而是一种生产关系问题，如何让多方有责任、有意识地协作起来，需要考虑背后的职责与激励机制。

这个技术方案其实就有些拿着锤子找钉子的感觉了。

拿着低代码这个工具，去不断找需求场景去碰，而不是站在场景下看用户需求和用户痛点。

既没有看到用户的核心需求，也没有看到用户真正的痛点，也没用看到低代码上了之后真正把这部分成本省掉了。

如果用俞军说的：

新体验 > 旧体验 + 切换成本

这个方案反而没有降低用户成本，而是徒增了新的学习成本。

整个方案的行文看下来就很空洞，有很多逻辑不自洽的地方，也容易被挑战，方案自然很难通过。

那如何想明白呢？

可以简单分为【道】和【术】两个层面。

我见很多人在行文结构上追求格式的正确性，但我觉得这是【术】的层面，只是锦上添花。

一个小目标往往是从一个大目标拆解下来的，如果你连大目标是什么都不清楚，就在小目标上兜兜转转，再好的行文格式，都会让人感觉有些逻辑混乱或逻辑不自洽。

归根结底在于你是如何认知这件事的，这才是【道】的层面。

行文正确性、规范性这件事，主要参考金字塔原理即可，注重格式的统一与内容的连续性，大概率可以应对90%的场景。

提升认知这件事，目前看起来没有特别通用的方法，简单提几个抽象的要求。

a）多问why，比如5why分析法，不断深挖。但如果方向问错了，反而容易带沟里去。

b）要有深度思考能力，不要停留在问题表面想方案，而是要做归纳与抽象。

c）要建立多种思维模型，从不同的切面看问题，比如有的是生产力问题、有的是生产关系问题、有的是生产要素问题。如果错位了就显得没有逻辑。

d）要有批判性思维，批判性思维不是挑刺，而是挑战自己的思维框架，可以从新的角度观察问题，并提出不一样的想法。

e）掌握这个行业或领域的知识，太阳底下无新事，你要不屈不挠，总能看到很多人，已经前赴后继的尝试过各种方法解决这个问题了。

f）同理心，简单来说就是站在对方视角看问题，实事求是、躬身入局，而不是站在帷幔之后猜问题并将其合理化。

g）逆向思维，比如你正向想不到如何保障系统不被打垮，可以反着想，怎么把系统搞挂了，这样你就得到最务实的保护系统的手段了。

h）逻辑思维，逻辑上要一环扣一环，不要让一个环节脱节了，不要侥幸心理作祟想要忽略，要走在问题的主线上。

i）充分了解目标和约束条件。