> 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-hant/2021/w03-digital-workflow.md).

# W03-數字化工作流

最近在做2021的規劃，Jerry問了我一個問題，怎麼去衡量大家對業務的理解能力。

我大概想了幾個角度。從結果上來看，可以是架構對業務的支撐能力，技術規劃的合理性，從工程的角度優化了多少業務上的問題。從過程上來看，在業務領域的學習上投入了多少時間，需求或者規劃的相關討論中，參與的投入度是否足夠，或者看來自其他職能同學的反饋。很明顯，以上的維度，都不夠SMART。如此抽象的一個能力，想要具化成一個可衡量的指標，的確很難。

由此我發現一個頗為滑稽的現象。從事數字化工作的我們，自己的數字化程度卻不夠高。數字化程度不夠，就無法很好的進行抽象和標準化，進而無法規模化。無法萃取和普及優秀員工的工作經驗，也很難去構建像業務理解這樣的能力模型。

從組織管理上看，目前，對於每個人的精力分配，我們只能看到需求維度的數據。非需求的精力分配我們基本沒有數字化。

就拿需求維度來說，每個完整的需求，其經歷的基本動作會是一個很長的鏈路。包括需求評審，技術方案設計，編碼，聯調，code review，自測，環境部署，灰度上線，觀測線上情況。我們每個部分都有數據，但數據的精細化程度不夠，結果數據偏多，過程和行為數據偏少。而且節點間的數據基本沒有打通，以Ones為例，每個需求和任務的狀態全靠人工手動變更，大家總有漏更、遲更的情況，這樣的數據也就只能瞭解個大概。理想情況下，我們作為用戶，Ones這樣的需求管理工具，在大多數場景下應該是不用感知的。

這讓我想到了Cloud IDE，之前不太能理解IDE雲化的價值，但站在組織的角度上去考慮的話，這個事情就不得了了。我認為其最大的價值就是數字化工作流。RD工作中，用的最多的就是IDE，而就是這麼一個重要的工具，大家各用各的、五花八門，其中產生的行為、數據都是離線的。如果IDE雲化，那麼IDE就可以作為一個平臺，去和上下游很多場景做打通，比如分支直接與需求關聯，一鍵提測，一鍵部署等等。光是一些基礎數據就足夠自動更新Ones了。其次還可以解決一些效率和安全問題，比如統一開發環境，解決源碼的保護問題，不落開發者磁盤。

可以暢享一下未來，設計稿通過智能出碼能力，一鍵生成可二次開發的代碼，代碼導入 Cloud IDE 中再進行開發調整， 一鍵構建並部署可以跨端運行的應用。這樣所有的數據與資產都沉澱在了平臺之上，每個節點也都可以通過大量的數據做有針對性的優化。