Codes 開源研發專案管理平臺——生成式全域性看板的創新實現

繼上一回合瀑布與敏捷的融合創新實現後，本篇我們來講一講 Codes 生成式全域性看板的創新實現。

市面上所有的研發管理軟體，看板模式的專案，都是物理看板的電子化，好像也沒什麼問題，但是在使用過程中體驗非常不好，為什麼呢？

第一、老闆或管理人員想看看板時，咋辦？也要他自己建嗎？就算不用管理人員自建，但不同的專案組，不同的部門等都有不同的看板，老闆或管理人員去看的時候，需要一個一個切換，就像現實中要一一走到各物理看板跟前，才能看到。平臺化了，還這樣，非常不友好，增加了管理人員的使用負擔。

第二、即然看板都資訊化在平臺中了，各自建看板，如同線下每個人，都用小本本把一些東西記下來，這不就是逆平臺化嗎？等價於，教條的把物理看板，電子化時，也是分散式的，不是平臺化的集中式。

第三、到處建看板，會有卡片密集恐懼症，且一點不方便。人人都建看板，也要花時間；不同的事項，建不同的看板也要花時間，增加了使用成本。

** 第四、** 看板和其他模式完全可以融合，那融合時看板滿天飛，也非常不利於融合的實現，反而因融合把功能複雜化了。

看到這裡可能學院派有話要說，說我們小題大做，沒事找事圖片。

Codes 產品團隊以化繁為簡的方式，不走尋常路，不死板的限定在理論中，也不固守陳規，擁抱零基思維，且看下述需求分析過程。

1、需求分析過程如下：

從上面描述的背景中可以明確的看出來，通常的做法，不管是對於基層員工，還是對於中層管理者，以及老闆都帶來了使用複雜度，一點都不方便，有更方便的實現方式為什麼不可以採用呢？那我們就要大道致簡，做成一個（1）全域性的看板，省去了頁面切換操作；（2）不同的事項，雖然有不同的狀態，完全可以泛化為看板上共同的幾個泳道所對應的狀態；（3）都平臺化了，資料也集中了，根本沒必要再各自建看板，且建看板的工作量，遠大於我們以逆向的方式，也就是透過定義查詢條件的方式，來生成看板，相比於主動建立看板的方式，套個時髦的術語，我們叫它為“生成式”看板圖片。

Codes 就是不按套路出牌，怎麼讓使用者爽，就怎麼來，從不拘泥於別人咋實現，也不去抄誰，有自己的認知（不做只會跟風的 “小屁孩”），只要確認讓使用者爽就是對的。有圖有真相，請看下述功能實現介紹。

2、功能實現之全域性看板，一板走天下：

所謂的全域性就是無需選單或頁面切換，所有人員都在同一個頁面上看看板，只是不同的人可以根據不同的查詢，或是定製（儲存查詢）顯示不同的看板內容；預設把當前專案事項顯示在看板上，且可以處理看板上所有事項。

需求、任務、需求評審、用例、缺陷把它們各自的不同狀態，泛化為：規劃中、進行中，已完成，終止｜暫停這幾種狀態，並顯示在對應的看板泳道中。

3、功能實現之生成式看板，反向生成看板 ，方便快捷

看板頭上，有如下查詢條件，可實時查詢；也可儲存特定條件，然後取一個和條件相關的有意義的名字，生成式的看板就這樣生成了，後續直接選擇定製看板名（查詢名），快速生成看板內容。相比於建看板，再在看板上放事項，生成式看板省時省事，事半功倍，何樂而不為呢圖片！

專案，對於管理員可選所有專案或特定專案，對於普通人可以選所參與的所有專案或特定的專案。

事項，可以是迭代、待批需求、需求、任務、用例以及缺陷。

比如下面是定製的幾個 “生成式” 看板，如果不是常用看板，現查詢來生成看板也很方便。

4、功能實現之看板分組，方便同一維度間橫向對比

好多同類產品中的看板，雖然也支援分組，但是大多數是在泳道內再二次分組，不便於基於分組的維度進行橫向對比。所以 Codes 中的實現為，先分組，以便於分組間資料對比，各分組再有不同的看板。

可按人員、專案和迭代進行分組，如下圖第一維度，只顯示各分組的資料

然後可以隨意展開任意分組的看板

另外，看板中能處理所有顯示的事項，如延期也會有標識

最後打個總結：生成式全域性看板，確實化繁為簡，之前 Codes 完美的實現了敏捷和瀑布的融合,現在又實現了與輕量看板模式融合，難能可貴的是並沒有增加使用者使用上的複雜度；創新不是為了玩新奇，是為了解決問題，下一次我們來聊聊另一個創新點，也是很酷的功能，欲知後事如何，且看下回分解圖片。匠心打磨，持續創新是 Codes 的產品基因。

有客官可能不知道 Codes 是什麼，小 C 在這裡最後補一句：

Codes 重新定義 SaaS 模式的一站式研發管理平臺

雲端認證 + 程式及資料本地安裝 + 不限功能 +30 人免費

掃碼檢視詳細介紹