導讀
先從背景問題講起，再來看Codes 創新解決思路，最後通過功能演示説明來體驗感受。也就是拋問題，給思路，看落地實現。
背景
在項目或產品實施過程中，下面這兩個需求管理的問題很普遍：
1、需求整合：重用難導致重複建設與資產浪費
需求重複開發：不同項目間存在30%-50% 的重複需求（如用户登錄、權限管理），缺乏共享機制，導致重複造輪子，資源浪費嚴重。
能力複用不足：通用組件、模塊、接口未沉澱為企業資產，各項目獨立開發，技術債務累積
2、需求不好追蹤：變更傳導成 “災難”：
同一業務領域相同或類似需求分散在產品的不同分支或不同項目中，難以掌握需求和產品或項目間的關係，特別是變更時不好評估受影響範圍
3、雖然早就有需求池的概念，但是沒有具像化的落地實現
從售前、客户等其他非產品人員渠道來源的需求，不可能立馬定位到具體產品或項目上 ，如何管理這些需求
4、傳統的產品型項目，項目型項目管理模式太繁瑣
從交付的角度來看，不管是作產品還是項目，本質都是做項目。且把他們分區來管理時，人為帶來了需求管理的複雜度，多了不必要的層級關係，增加了學習成本。
Codes的解決思路
Codes 產品團隊以化繁為簡的方式，不走尋常路，不死板的限定在理論中，也不固守陳規，擁抱零基思維。下面來先來看我們的解決思路，
首先具像化的需求池落地實現，用於對需求進行統籌管理，把3、4兩個問題以簡捷的方式解決了
需求池是一個大容器，需求一來就扔到池子裏。需求池中的需求沒有項目屬性，通過他的分類來管理需求池中需求。需求分類可以從不同的維度來建，如業務線，功能線，然後下面再按區域分類，如華南售前等。
我們設計了需求池管理的兩條主線，也就是兩個需求池需求的查看視圖。前面説的屬於職能線，職能線用於各職能的人員查看和維護需求；另一條線我們叫產品線，主要方便產品人員從產品的維度來區分和維護需求。
產品線變成了需求池中需求的一個下拉選擇的屬性，從交付角度不存在產品型項目了，都是項目，把它以一個查看的視圖來簡化了但又沒丟失從產品維度來管理需求。第4個問題解決了！
同時我們不再區分用户需求，研發需求，也不區分史詩、特性和用户故事，而是通過需求模板以及需求的拆分來解決 ，比如最上層的一個抽像的用户需求，然後拆分為研發可用的研發需求就行了，不需要明顯的去人為把他們分出來，這增加了使用上的複雜度，所以我們這樣來簡化管理。
再圍繞這個“池”並借用JAVA工程maven 管理Jar 包的思路，解決共享和複用的問題。
針對複用和共享我們用了“引用”這個概念來處理，具體來説就是：一個需求可以被多個項目引用，但是隻能一個項目中實現，這就是複用型的共享模式，在實現項目中填進度，然後在需求池和其他引用該需求的項目中能同步查看進度信息。
對於只共享不復用，我們用“導入”這個概念來處理，具體來説就是：一個需求被多個項目導入，然後每個項目各自實現。舉個不太恰當例子同一需求，在不同端都要實現，實現方式不一樣。
引用和導入的區別：引用他就是隻在一個項目中實現，其他引用項目中共用一分實現且能同步實現項目中的進度，除了實現項目外在其他單純只是引用項目中只能看不能做其他動作；導入就是在不同項目中他們分別是不同的需求副本，各自有自己的實現，在某個項目中修改導入的需求時，需求池中的原始需求以及導入這個需求的其他項目不會同步這個修改。也就是説導入是維護某些需求的原始共同來源。
需求池中的某個需求，在一個項目中他要麼被引用，要麼被導入，不能又導入又引用。某一個需求池需求 ，也可以同時被不同的項目引用和導入。
需求池很好的解決需求溯源的問題
需求池，作為一個容納任何需求的容器，從源頭上作為需求的統一出處，然後通過引用和導入和項目產生聯繫，然後根據導入和引用的規則來實施需求的實現。少了需求池這一層，單純的把需求導入到項目中，確實減少了重複錄入。但是後續沒法追蹤。有了需求池之後，當變更時，能很清晰的知道影響的範圍。需求池+引用+導入，建立了需求和項目間的依賴關係 ，隨時可通過這些依賴關係來梳理需求在項目中的發散或裂變和共享。
需求池+引用+導入三板斧創新實現落地功能演示
界面説明
需求池主界面，左邊是需求分類，缺省是職能線視圖，可以換到到產品線視圖，產品線視圖左則目錄顯示產品的層級關係
需求分類的權限可按分類目錄單獨授權
創建需求池需求時，沒有項目屬性，可以用應需求模板
在需求池中能查看到需求在實現項目中的進度，只有被引用到項目中且指定了實現項目，才能在需求池及其他所有引用了該需求的非實現項目中，同步該需求的實現項目中的進度，被引用和導入後顯示項目跟蹤，
需求池需求引用或導入到項目
一次可以選多個需求然後引用或導入到多個項目中
在需求池中跟蹤需求
項目跟蹤，顯示引用和導入關係，也就是該需注被哪些項目引用了，被哪需項目導入了。下圖中需求池中需求，被兩個項目引用，且在codes中實現，在demo軟件這個項目中被引用，他們的進度在需求池中和項目中都有顯示。
下圖顯示上圖中的需求被哪個項目中導入了 ，導入時每個項目有各自的實現，所以各自都有各自的進度。
在項目中跟蹤需求池需求
在項目中需求編號有G# 表示引用需求中的需求R#表示在當前項目中的需求編號
在引用關係時時只能在實現項目中能分解需求和建任務以及填寫進度，且進度會同步到所有引用他的項目中；導入關係時每個項目中是一份獨立的實現，所以都可以分解和建任務及填進度。
最後打個總結：
Codes 採用需求池+引用+導入，這三板斧，確實以創新簡化的方式，解決需求跟蹤和共享、重用的着問題。這三招也踐行Codes 設計理念：”以便捷的方式給管理人員提供抓手，使管理抓得住，抓得好；以不增加負擔的方式讓執行人員聚焦業務，專注本職工作、高效協同“。需求池為輕IPD打了基礎，下一次我們來聊聊 Codes 輕IPD的創新實現。匠心打磨，持續創新是 Codes 的產品基因。
有客官可能不知道 Codes 是什麼，小 C 在這裏最後補一句：
Codes 重新定義 SaaS 模式的一站式研發管理平台
雲端認證 + 程序及數據本地安裝 + 不限功能 +15 人免費
