> For the complete documentation index, see [llms.txt](https://weekly-essay.mikey.wang/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://weekly-essay.mikey.wang/zh/2021-nian/w03-shu-zi-hua-gong-zuo-liu.md).

# W03-数字化工作流

最近在做2021的规划，Jerry问了我一个问题，怎么去衡量大家对业务的理解能力。

我大概想了几个角度。从结果上来看，可以是架构对业务的支撑能力，技术规划的合理性，从工程的角度优化了多少业务上的问题。从过程上来看，在业务领域的学习上投入了多少时间，需求或者规划的相关讨论中，参与的投入度是否足够，或者看来自其他职能同学的反馈。很明显，以上的维度，都不够SMART。如此抽象的一个能力，想要具化成一个可衡量的指标，的确很难。

由此我发现一个颇为滑稽的现象。从事数字化工作的我们，自己的数字化程度却不够高。数字化程度不够，就无法很好的进行抽象和标准化，进而无法规模化。无法萃取和普及优秀员工的工作经验，也很难去构建像业务理解这样的能力模型。

从组织管理上看，目前，对于每个人的精力分配，我们只能看到需求维度的数据。非需求的精力分配我们基本没有数字化。

就拿需求维度来说，每个完整的需求，其经历的基本动作会是一个很长的链路。包括需求评审，技术方案设计，编码，联调，code review，自测，环境部署，灰度上线，观测线上情况。我们每个部分都有数据，但数据的精细化程度不够，结果数据偏多，过程和行为数据偏少。而且节点间的数据基本没有打通，以Ones为例，每个需求和任务的状态全靠人工手动变更，大家总有漏更、迟更的情况，这样的数据也就只能了解个大概。理想情况下，我们作为用户，Ones这样的需求管理工具，在大多数场景下应该是不用感知的。

这让我想到了Cloud IDE，之前不太能理解IDE云化的价值，但站在组织的角度上去考虑的话，这个事情就不得了了。我认为其最大的价值就是数字化工作流。RD工作中，用的最多的就是IDE，而就是这么一个重要的工具，大家各用各的、五花八门，其中产生的行为、数据都是离线的。如果IDE云化，那么IDE就可以作为一个平台，去和上下游很多场景做打通，比如分支直接与需求关联，一键提测，一键部署等等。光是一些基础数据就足够自动更新Ones了。其次还可以解决一些效率和安全问题，比如统一开发环境，解决源码的保护问题，不落开发者磁盘。

可以畅享一下未来，设计稿通过智能出码能力，一键生成可二次开发的代码，代码导入 Cloud IDE 中再进行开发调整， 一键构建并部署可以跨端运行的应用。这样所有的数据与资产都沉淀在了平台之上，每个节点也都可以通过大量的数据做有针对性的优化。