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

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

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

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

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

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

? ??看到這里可能學院派有話要說，說我們小題大做，沒事找事

。

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

1、需求分析過程如下：

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

。

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

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

? ??所謂的全局就是無需菜單或頁面切換，所有人員都在同一個頁面上看看板，只是不同的人可以根據不同的查詢，或是定制（保存查詢）顯示不同的看板內容；缺省把當前項目事項顯示在看板上，且可以處理看板上所有事項。

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

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

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

！

? ? ?項目，對于管理員可選所有項目或特定項目，對于普通人可以選所參與的所有項目或特定的項目。

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

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

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

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

可按人員、項目和迭代進行分組，如下圖第一維度，只顯示各分組的數據

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

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

最后打個總結：生成式全局看板，確實化繁為簡，之前 Codes 完美的實現了敏捷和瀑布的融合，現在又實現了與輕量看板模式融合，難能可貴的是并沒有增加用戶使用上的復雜度；創新不是為了玩新奇，是為了解決問題，下一次我們來聊聊另一個創新點，也是很酷的功能，欲知后事如何，且看下回分解

。匠心打磨，持續創新是 Codes 的產品基因。

有客官可能不知道 Codes 是什么，小 C 在這里最后補一句：

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

云端認證 + 程序及數據本地安裝 + 不限功能 + 30 人免費

?掃碼查看詳細介紹