你可能玩過小遊戲“羊了個羊”、“跳一跳”、“泡泡射手”，但是你可能不知道，在一家遊戲公司，可能有上千個“羊了個羊”在同時開發。相比大型遊戲，單個小遊戲的開發週期短、人員少；但同時因為競爭激烈，需要大量開發，敏捷試錯。這就意味着，小遊戲的項目管理方式，不同於傳統項目。遊戲項目很多，管理人員很少，如何破解挑戰，確保遊戲上線的“量”和“質”？
小遊戲一個月上線，同時管理上千個非典型項目
什麼叫非典型項目？大家去年可能玩過一個微信小遊戲，叫“跳一跳”。在遊戲行業，這種小遊戲的研發，就是一種非典型項目。
首先，這類遊戲玩法很簡單，所以整體產研週期短，涉及人員也不多。有時候，研發甚至就一個人
然後，市面上有很多這類小遊戲，所以競爭很激烈，不確定性很高。有很多小遊戲你壓根沒聽過；有的遊戲甚至都沒機會出現在你面前，一個項目從立項到結束就一個月，發現效果不好就不試了，這種情況非常多。
所以，哪怕是一個不大的遊戲公司，一年做幾千款遊戲都是很常見的。這時就會出現一個問題：遊戲項目很多，但是管理人員是有限的。
傳統項目，不論是面向政府或企業的大項目，互聯網產品或大型遊戲項目，團隊成員都相對固定，項目目標和時間都有約束，發佈節奏也是定好的；相比之下，小遊戲就是非典型項目：項目週期短，人員少；並行項目多，人員切換頻繁；業務流程長，涉及信息繁多。
舉個例子，做一款小遊戲，要發佈4-5個渠道；如果同時有100個項目推進，這個事情就要乘100，信息量就會很大，管理成本就會很高。
調整目標，梳理項目管理的“三條線”
一個小遊戲公司有10個研發、10個測試、10個美術、10個策劃。這些人，接下來兩星期要做的所有事情和任務，就是項目組的管理對象。也就是，把團隊成員的時間安排，當成項目來管理。
傳統的項目怎麼管的？情況可能是，研發人員小明正負責項目A 1.0版本的開發，做着做着需要切換到項目B，做一個發佈任務；然後項目C來了用户反饋，問題很嚴重，他也要緊急處理。這種管理就導致，研發人員在各種任務之間切來切去，很多項目進度都不理想。
那麼，將人員和人力當作項目來管理，項目和任務變成資源分配給人呢？一切都迎刃而解。讓項目圍繞人運轉，讓人圍繞工具節奏運轉，成功實現了“幹掉項目經理”的願景。
現在，我們把項目拆成三條線：價值線、產研線、發佈線。
-
價值線主要是產品經理負責，從需求分析、評審到產品規劃，要確保大家做有價值的產品。
-
產研線需要項目經理和產研的協作：研發專注具體的交付任務，在固定週期內完成開發，項目經理更專注協作效率和持續交付。這個過程中，項目經理把大家的時間當作管理對象。
-
發佈線主要是市場人員來協調，確保交付內容一定可以發佈，並根據市場需求來安排發佈節奏。
這樣，驅動我們的都是外部因素，而不是我們自身的規劃。這其實要求大團隊，對市場有更前置的思考。
非典型項目的標準化、透明化
傳統的管理就是很多張表：驗收反饋、用户反饋、發佈渠道、發佈計劃......很多時候，我們在表裏找到一個產品名字，但是在另一張表換了個名字，就找不到了。
使用飛書項目，就把這些七七八八的表，轉成了一個工作空間：有需求、有發佈、有bug、有迭代......而且，這些信息都能聯動，當你看到產品某一個維度的數據，就能順着瞭解整個項目的數據，確保有清晰的上下文。
節點流模式，可以根據業務場景靈活拆解和裁剪，幫助項目經理橫向把控項目進展。
項目經理通過配置不同團隊的人員視圖，能夠全面瞭解當前人員佔用情況，快速為團隊分配項目和任務，也能更加公平地衡量每個人的投入與產出收益。
通過建立跨部門的關聯關係，將渠道、版本等與產研流程一對一綁定，橫向拉通多方信息，跨部門、跨業務、跨項目各自獨立又互通有無；同時，字段、人員、排期自動同步，不再需要費勁扒表格、人肉追蹤來定位責任人，真正實現產研與市場流程“你中有我，我中有你”。
