傳統的看板實現方式存在諸多不便，從管理人員的使用負擔到操作復雜性都大大降低了效率。本文將介紹Codes如何通過創新的全局看板和生成式看板，重新定義研發管理，使項目管理更加直觀、便捷。

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

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

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

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

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

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

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

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

一、需求分析過程如下

從上面描述的背景中可以明確的看出來，通常的做法，不管是對于基層員工，還是對于中層管理者，以及老板都帶來了使用復雜度，一點都不方便，有更方便的實現方式為什么不可以采用呢？

那我們就要大道致簡，做成一個

（1）全局的看板，省去了頁面切換操作；

（2）不同的事項，雖然有不同的狀態，完全可以泛化為看板上共同的幾個泳道所對應的狀態；

（3）都平臺化了，數據也集中了，根本沒必要再各自建看板，且建看板的工作量，遠大于我們以逆向的方式，也就是通過定義查詢條件的方式，來生成看板，相比于主動創建看板的方式，套個時髦的術語，我們叫它為“生成式”看板。

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

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

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

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

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

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

• 項目，對于管理員可選所有項目或特定項目，對于普通人可以選所參與的所有項目或特定的項目。
• 事項，可以是迭代、待批需求、需求、任務、用例以及缺陷。

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

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

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

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

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

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

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