一次病態專案程序的發展與變遷

「老大，開發他們要對資料庫進行調整，近期不能送測『改版需求』了。」我詢問完開發主管後，隨即就向我的老大匯報了這個情況。

「那這樣的話，我們也沒辦法了」老大語重心長地告訴我，「這個功能可能會中斷，你不覺得這個新版頁面看上去很醜嗎？」聽完，我差點暈了我過去~

但是咱們反饋問題，還是要按事實說話。在平復情緒後，我決定對過往的專案工作進行梳理，萬一這孩子真的夭折了也能撫慰其在天之靈。就在梳理專案工作的過程中，問題也慢慢浮現了……

這個「改版需求」的專案是8月14日開始的……

我將「改版需求」時間線內自己負責的所有需求都統計了一遍，並放在乙個時間軸內（下圖最左側豎線），並對「改版需求」的重要節點進行了標註（包括時間+事件描述，下圖最右側豎線與文字）；

將「改版需求」及其時間線內進行的需求專案，以矩形的方式分別列出，頭部標註開始時間，底部標註結束時間；

已經上線的需求專案用綠色邊框標識，其餘狀態（包括：設計中、開發中、測試中等狀態）用紅色邊框標識。

分析一：產品同步任務過載

如果拿出一條橫線在時間軸上移動時，會明顯的看到我在進行改版需求的過程中總共負責6個需求的工作。

分析二：週期停滯嚴重

有的需求上線了，有的需求停滯了，特別是在「改變需求」專案週期內插入的需求，還有不少已經上線了。

分析三：需求多次變更

除此之外，我們在上圖左側的節點描述中還能發現以下主要問題：

2017/09/04 因為新功能需要對頁面進行修改，所以選擇啟動「改版需求」

2017/10/16 對新版頁面進行修改（2017/09/06 ui已經完成新版頁面）

2017/12/05 指出頁面不好看

分析四：開發同步任務過載

看到自己單方面的任務混亂後，我查詢了「改版需求」專案週期內開發哥哥的其他任務：

web端需求任務共13個：

移動端需求任務共16個（除去改版需求）：

根據兩張圖的狀態可以發現，開發哥哥中間穿插的很多需求專案也已經上線了。

在專案梳理過程中發現很多問題後，我開始靜下來回顧過往的工作流程，終於意識到出現這樣的問題是「合情合理」的。

後來我向我的一位同事描述了自己的問題，她告訴我在開發前她總會拉著開發過一遍需求，對比一下開發理解的與自己想的是否一致。是啊，如果當時自己能夠拉開發哥哥一起過一下需求，或許就會減少像9月4日的那樣的事故。

（1）需求評審缺失

雖然主動找開發單獨過一遍需求是必要的，但是如果在流程上定下規則是不是會更有效呢？平時的工作流程是這樣的：產品們每次完成需求文件在系統上提交需求後，開發主管大致瀏覽一遍，就分配給開發哥哥進行研發了。正是缺少了需求評審使得開發者沒有及**估需求，如果僅僅依靠每個產品的自身意識去驅動，並不是什麼長久之計。

（2）專案管理缺失

看到我和開發哥哥在工作穿插了多個任務，且有的已經上線後，我不禁想反問一下團隊：「到底哪個是緊急的？」「需求專案的deadline是什麼時候？」沒人告訴我，因為現實中截至時間是開發主管隨意定的，而緊急度的高低也沒有具體的指標，有時候甚至和人有著很大的關係。沒有需求評審、沒有明確的優先順序界定，所以需求總是變變變，任務也可以隨意穿插。

從書中、論壇找了很多解決辦法，要麼過於高深不適應現在的部門，要麼就是太概括，缺乏可以實施的細節。在這裡要特別感謝一下粒粒橙老師，在諮詢完相關問題後，她詳細地介紹了自己部門的工作流程，主要部分整理如下：

專案立項：

乙個月或者2週為乙個開發周期，每個開發周期內，產品需要提出自己的需求。根據需求優先順序（問題嚴重性、roa值（資產回報率）高低、對使用者的體驗是否提公升、對公司是否產生收益、是否增加內部人員的效率、技術成本是否會降低……）決定本期開發的需求；

方案評審：

需求是重要的，但是設計的方案不一定是最有效的，參與討論實現功能過程的可行性；

互動評審：

（互動）設計師加入，參與細節的互動設計；

開發評審：

開發、測試人員等加入評審，評估需求實現可行性，以及實現的週期；

至此，終於意識到平日的需求（專案）工作流程都是結果導向，而非目標導向，所以團隊通常情況下都沒有好好重視中間的過程。

發現問題、找到可以嘗試的解決方案後，我內心非常開心，畢竟自己的「孩子」可能不會夭折了。當我正想給老大發郵件描述這一系列問題時，我打住了，產生了一些顧慮：難道就我想到了這些？難道之前就沒有人「上諫」過？

可能進入社會時間久了，自然就沒了學生時代的無所無懼。但是，錯了就是錯了。於是心裡突然冒出了「要麼你變革，要麼我走人」的想法，最終我還是把所有的問題、現象和整理的一些建議通過郵件發給了老大……

聽完後，我差點激動得跳了起來。但還是故作鎮定地說了一句「i do！」哦漏！是「ok！」

後來，我們部門開始把所有新的或者還未送測的需求全都拿了過來進行評審，大家也真正體會到人多力量大的益處。在需求評審中，我和我的小夥伴們也切實體會到了自己設計中不合理或者不完善的地方。因為公司內部的管理系統缺乏專案程序的管理，我們部門也開始嘗試用一些管理軟體比如「禪道」等作為優先順序、週期等的管理。

時至今日，部門的工作流程已經發生了天翻地覆的變化，例如：標準化的需求評審從0實現到了100%。

一次成功的突破之後，後面還會出現其他的阻力。當產品和技術部門沒有統一的管理，即使使用有效的專案管理軟體，所謂的deadline也不過是單純的數字罷了。或許又要等待漫長的時間，才能夠通過資料讓一些人選擇改變……

同時，徹底的變革無異於刮骨療傷，當自己滿心歡喜覺得在做著對的事情時，是否又給他人造成了一些煩惱呢？此時，與其想著方式的對錯，倒不如想著如何把這件事更好的繼續進行下去吧。最後，送給自己和所有小夥伴們一碗雞湯，正如影片《熔爐》裡所說：「我們一路奮戰，不是為了改變世界，而是為了不讓世界改變我們！」

一次難忘的專案經歷

記自己的一些反思與總結 在這一月有餘的時間裡。自己參與製作的專案又完畢了乙個。每一次專案的開始與結束，都會讓自己的內心極度的不平靜。由於在專案開始時，自己的心中腦中都興奮異常。牢牢謹記之前犯過的錯誤。總結的經驗，準備在新一次的專案開發過程中大顯身手。盡力做出好的產品，努力得到很多其它的成長。然而在專...

記錄一次抽取程序的合併

此合併操作需要程序內無長事物同步時進行，如程序有延遲，需要等待長事物同步完畢後操作，且合併操作會有重複操作，目標端會出現重複資料。1.stop 抽取程序 ggsci stop 2.記錄源端需要合併的抽取程序的最早時間和產生的trail檔案編號。ggsci info detail 3.抽取程序執行et...

我的第一次專案管理 一次慘痛的教訓

最近總想發點時間寫些東西但抽不出時間，趁著放年假並且今天剛開完專案的年前回顧會議趕緊寫出來，其實挺不好意思講的，有點尷尬。由於公司逐步發展，專案越來越多，沒有人有時間來負責這個專案，我的老闆們可能看我比較順眼於是便讓我來負責這次的專案開發，於是我便莫名其妙的變成了專案負責人，一開始我是拒絕的，讓乙個...