在還是當一個在還是當一個小企劃的時候，有一些前輩在聊天的時候常常會說一句話，就是「希望專案可以順利完成。」那時候的我，參與的專案還不夠多，不太能體會到這個狀況，直到現在回頭一想，在當時任職的公司，真的有完成上線的遊戲只有兩款，進入時的第一款，和離開時的最後一款，中間還歷經四款，但是專案都沒有走到最後，另外有的專案還在提案階段就直接陣亡。
「希望專案可以順利完成。」現在倒是蠻有感觸的，最近這幾年，做完上不了線的專案，用兩隻手數也數不完，這到底是為什麼呢？
整理下來有幾種可能：
- 市場判斷錯誤，開發到一半發現產品已經不流行，再開發下去也沒人使用，砍。
- 產品開發太久，都開發三年了為什麼還沒做出來？再開發下去只是再燒錢，砍。
- 產品開發一半，業主說不要了，於是專案，砍。
- 產品開發一半，公司縮編，於是成員變少，開發困難，或是直接結束專案，砍。
- 產品開發完成，發現沒有客戶買單，賣不出去，最後打算砍掉重練，於是，砍。
- 產品開發完成，發現不是老闆要的東西，於是老闆一氣之下，成員換掉，砍。
- 產品開發一半，各方利害關係人的願望持續加入，於是專案越滾越大，最後無法收拾，砍。
(下略100種專案上不了線的狀況)
其實要面對這種狀況，身為一名PM，要想清楚幾件事
- 市場要的是什麼？
- 老闆想的是什麼？
- 團隊能的是什麼？
- 公司有的是什麼？
簡單來說，「市場」及「老闆」代表的是需求，「公司」及「團隊」代表的是資源，如下圖所示。
這邊來舉個例，有一間製鞋工廠，可以每個月生產20萬雙球鞋，某天有一張來自法國的訂單，但是需要增加產能到每個月200萬雙，如果可以搶下該筆訂單，則可以帶來相當可觀的營收，那這個時候，要接下這筆訂單嗎？
如果這個時候的老闆，想的是要搶下這筆訂單，那勢必需要擴廠、增人、添購設備，那這些成本都是必須先投入進去，才能應付這張訂單，但是，這種訂單也不是天天都有的，可能久久來一次，那後續的設備維護、人力閒置，這些成本都會是一種浪費。
另外有一種老闆的做法，會先盤點手上現有的資源，若是每個月透過加班，增加短期合約的人手，讓產線想辦法達到24小時運轉，三班輪休，再加上六日的趕工，假使推估可以讓產能衝到每個月100萬雙球鞋，這樣也只能滿足50%的需求，於是可能會開始找工會、同業或其他廠商合作，組成聯合陣線，一起吃下這個訂單。只是這種做法在品質控管上就會是另一種隱憂。
第三種老闆，評估一下，發現手上的資源根本無法接下超出負荷的訂單，就會索性放棄。
其實在做專案開發也是一樣的狀況。
在2019年的時候，台灣團隊剛成立時，需要建立新的開發團隊，當時的需求是以PHP為主，因此招募的工程師幾乎都是PHP工程師，但是專案開發到一半的時候，遇到一個狀況，總公司想要改以JAVA為主，希望台灣團隊可以改用JAVA，這在當時的衝擊是非常大的。因為團隊內部懂JAVA的成員不多，加上要熟悉一個新的程式語言，不是今天說，明天就可以上工的。這個時候我做的第一件事情，其實不是讓工程師馬上去學習JAVA，而是先去理解「為什麼要用JAVA？」。
後來發現總公司要台灣團隊使用JAVA的原因，其實是因為目前使用的系統為JAVA，而且相關的工程師陸續離職，在當地要找到適合的工程師也需要時間，因此希望台灣團隊可以當作備案。
一旦知道原因後，那事情就好處理了，因為要承接總公司的後續維護和目前手上的開發案，並不衝突，可以有兩個方向進行。
- 現有的工程師，挑選幾名適合的夥伴當作該系統承接專案的核心成員，安排學習JAVA，現有專案仍然持續進行，有受到影響的部分，則由其他工程師接手或是延後開發。
- 陸續從外部招募熟悉JAVA的工程師，加入團隊。
如果在當時，沒有理解改用JAVA的原因，貿然的直接讓工程師轉向使用JAVA，可能會面臨幾個挑戰。
- 對於JAVA的熟悉度不高，即便承接了總公司的系統維護，在後續維護上會沒有效率，對於BUG的敏銳度也會很低。
- 已經習慣PHP的開發方式，對於JAVA的學習會充滿抗拒，有些成員或許會因此離職。
- 現有的專案勢必中止開發，對於團隊的士氣打擊會非常巨大。
剛踏入職場的第一份工作，其實就已經面臨過產品中止的狀況，那時候公司希望做一個「遊戲與學習結合」的產品，在當時覺得老闆這個概念蠻棒的，於是就加入該專案的開發。該專案進行了大約一年多，進展緩慢，最後老闆就中止該項目。現在想想，當時其實有很多的問題，只是當年的我看不到。
- 風格想抄襲當年很紅的遊戲，但是手上的美術只有2名，人力和技術力根本無法實現。
- 公司的本業是做互動式的學習，主要的工具為「Flash」，索性就使用「Flash」來進行開發，並未評估過「Flash」是不是適合作遊戲開發的工具。
- 沒有進行專案管理，走到哪做到哪，雖然有寫工作日誌，但是並沒有明確的專案結束日期，看不到專案的終點。
- 專案負責人和其他部門關係緊張，無法好好的取得其他部門的協助。
- 沒有專心在產品的開發，而是為了讓老闆看滿意的展示，花更多的時間在做展示影片。
原以為第一份工作的狀況，應該是一個特例，但是在往後的職涯中，只能說原來這是一個普遍的現象，不管到哪間公司，都會有類似的狀況。
那身處在專案開發的我們，該怎麼面對這樣的狀況？以下有幾點建議
如果是專案還沒開始時，請務必了解該專案的需求，包含：
- 產品需求：該專案要做的產品是什麼，要做的是工具、遊戲、還是平台網站
- 技術需求：該專案要使用的技術是什麼，是網頁還是手機APP
- 市場需求：該專案的目標市場在哪，目標客戶是誰
- 內部資源：團隊的熟悉的技術能力、設計架構、開發工具…等
那如果專案已經在開發中，其實很多時後，專案都不是突然就喊停的，更多的時候都是有些跡象，例如，專案負責人是不是在進度報告會議上如實報告，如果進度報告上的內容，和專案開發的內容，有落差，而且落差越來越大，基本上該專案開天窗的機會可能會非常的高。又如果，專案的里程碑完成時，拿不出一個可以被測試驗證的版本，而是看到一個製作精美的影片或簡報，那表示這個里程碑只是時程表上的完成只是一個美麗的假象，而不是真的可以被驗證的版本，最後做不出來的機會一樣非常高。
另外，有一種狀況更是需要注意，如果這個專案負責人報告進度時，永遠都是在時程上、如期完成、沒有延遲，那這種狀況更加危險，因為不可能有一個專案是真的可以每次都如期完成的，更多的時候時程會是有時候超前、有時後落後，這才是正常的狀況，專案報告時更有可能的是「因為XXX的原因，導致本次的目標稍微落後，但是，團隊透過OOO的方式，有將進度追上。另外，針對原因XXX，我們事後有做了△△△的處理和修正…」，這樣會是比較合理的。如果每次的報告都是進度上，通常這樣的專案都是在最後一刻才會爆炸，不可不慎。
最後，專案其實是處於一個高度變動的狀態，專案管理其實就是在嘗試管理這些「高度變動的不確定因子」，盡量不要讓專案失控的一門技藝，但是專案管理做得好，會不會保證專案從此就不會腰斬？答案是「不會」。
因為一個專案的中止，有太多的因素所造成，更多時候，專案中止很有可能是要降低「沉沒成本」的損失，老闆、股東、出資者想的會是「如果持續開發下去，我還要投入OO年，OOOO萬元」，只要信心指數不夠，無法確保這個專案完成後可以帶來的效益，那多半就會直接中止，然後投入下一個專案。所以，還在專案開發載浮載沉的各位，請放開心胸的接受，專案突然被中止或許不是一件壞事，對公司來說，更有可能是一件好事。
若你在PM這條路上感到迷茫，
或想更清楚了解自己的能力與定位，
歡迎試試這份《PM產品／專案雙軌分析報告》。
它不為了定義你，而是幫助你更看清自己。
歡迎關注：
官網：https://unityprosper.com/
部落格：https://hero-mi.com/
FB：https://www.facebook.com/DigiPRDCoachHeroMi
LINE OA：@hero-mi
《歡迎加我LINE，一起破局未來》
留言