1. 首頁 > 生活百科 > >

規劃文本的定義

生活百科項目


規劃文本的定義

文章插圖
規劃文本的定義如下：
1．規劃成果包含文本、圖紙、附件三部分，附件包括說明書、專題報告、基礎資料匯編等 。文本是規劃中最簡練、最重要的文字說明 。
2，“規劃文本”是用來表達規劃的意圖、目標和對規劃的有關內容提出的規定性要求。
類似于法律文件的，對城市空間資源和土地資源進行管理和控制的條文，一般具有法律意義 。
我國城市規劃編制辦法要求，規劃成果包含文本、圖紙、附件三部分，附件包括說明書、專題報告、基礎資料匯編等 。文本是規劃中最簡練、最重要的文字說明 。
總體原則和目標：
首先，需要有明確項目背景，目標，以及核心需求分析
方案規劃設計文檔的好壞，幾乎完全取決于這一部分內容 。但多數同學在這一部分內容身上，往往花費的時間卻是最少的，常見的方式，就是“直奔主題”，上來就寫具體要做的事
項目背景和目標
項目背景不是讓你寫一堆無關痛癢的鋪墊材料 。實際上，項目背景的作用是：
Why？為什么要在這個時候做這個項目？
換句話說，就是這個項目從產品或業務的角度，最核心的推動力是什么？再換句話說，痛點是什么？
有痛點自然就有目標，你希望項目最終以什么方式解決問題，能達成什么目標 。
背景和目標的闡述，必須要能夠自然合理的推導出下一部分內容：項目的核心需求/功能是什么 。
如果項目背景，目標的描述不能起到這個作用，那這一節內容就沒寫好，因為項目方案文檔就缺乏了根本的出發點，后續的內容都沒有了好壞對錯判斷的基本依據 。
項目核心需求
項目核心需求和項目目標有什么區別？實際上沒有嚴格的區別，只是對需要解決的問題的概括抽象程度的不同，或者描述角度的不同 。
目標可以理解為希望達到的一個狀態，是抽象的，和技術方案無關的偏結果角度的表述方式 。
而項目核心需求，可以理解為了解決背景描述的問題，為了實現那幾個目標，進一步推導出來的，在當前系統環境或方案框架體系中：必須要提供的產品功能形態，或者是必須滿足的關鍵特性，又或著是不能違背的約束條件 。你也可以理解為用更技術的語言進行細化描述的項目目標 。因為目標和背景的不同，可能同一件事推導出來的核心需求也不同 。
這么說比較抽象 。舉個例子，如果我想構建一個數據交換服務或ETL系統，那么上述各環節的內容可能是（簡化的寫）：
背景 ： 當前數據ETL鏈路極端難用，效率低下，穩定性差，維護代價高，用戶抱怨多等等 。
目標 ： 用戶全自助，簡單易用；可維護性好；性能高；可靠性好 。
核心需求 ：比如針對“用戶全自助，簡單易用”這點（其它目標可以類似分析推理），可能是：
提供統一的，標準化的配置后臺：用配置的形式表達ETL業務語意，屏蔽下層實現細節 。
提供完善的錯誤反饋信息/機制：讓用戶能自助解決使用中遇到的問題 。
ETL業務流程標準化：將最佳實踐沉淀下來，通過配置的方式讓用戶選擇，減少重復工作，降低用戶開發的難度，規避使用姿勢錯誤可能造成的問題 。
講完區別，繼續回來講，這部分內容的要求 。很多同學在寫這部分方案的時候，很容易把需求和實現手段混為一談 。所以：
核心需求的重點是：本質上需要提供什么能力，而不是具體實現上要做什么
換個角度說，核心需求的描述方式是：要做成什么樣，是功能目標而不是實現手段 。
在完整的項目文檔中，顯然目標和手段都需要，但是
目標必須先于手段，而非相反
原因也很簡單，脫離了目標談手段是沒有意義的，很容易導致方向做偏，使得最終的結果產出背離了項目最初真正的需求出發點 。
實踐中，做成什么樣和怎么做有時候很難絕對分開 。一句話的描述方式可能既包含了目標需求也包含了實現手段 。那么，怎么判斷這部分內容寫得是否滿足要求呢 。
如果你描述的側重點只是需求的一種實現方式，而這個需求可能還有更多的其它實現方式，或者即使真的只有一種實現方式，你所描述的內容的也只是因果關系中，間接的因而非直接的果，那么很可能你描述的就只是手段而非目標 。
如果看文檔的同學看完只知道你要做什么，而不知道做這些是為了什么？是否做這些就足夠了，還應該做點別的？是否有別的解決方案，又或者做完了到底有什么用 。那么也很可能是因為你把需求和實現手段混為一談了 。

推薦閱讀