《我的專案筆記 #32》開發新產品，請試試「最小可行性產品(MVP)」

出社會大約八年的時間，換過兩間公司，卻從來沒有自己主導過一個產品，直到第三間公司，那時候要舉辦一個大型的行銷活動，需要有新的遊戲主題可以搭配，才有機會自己完全主導這個遊戲的設計和執行過程，很幸運的，成績還算不錯。

就在第三間公司離開後，心想自己必須要有一個從無到有的產品開發經驗，於是花了大約半年的時間，和朋友弄了一個APP，這時候才算是真正讓自己「開發新產品」。

雖然在過往任職過的公司中，有些公司會有「創意提案」，有些會有「產品提案」，但是，真的通過提案後可以落實的，非常非常的少。

那，這些提案不好嗎？

其實並不是提案不好，而是這些提案並無法真正地創造「價值」，簡單講，就是無法創造「直接營收」。

更多的狀況，都是老闆突然就說，我們現在要開發一個「OO系統」，然後某某PM就被交辦這件事，對於老闆來說，這些「OO系統」就是相對可以創造價值的產品，不管是帶入營收也好、或者是滿足某個重要客戶。

如果是這種狀況，我們應該怎麼辦？

通常我們都會聽到一個名詞，就是「最小可行性產品(MVP)」。

十步驟，讓你逐步了解「最小可行性產品」怎麼做

■ 步驟一 - 決定你的「目標市場」

■ 步驟二 - 思考產品可提供的「價值」

■ 步驟三 - 思考產品應用的場域

■ 步驟四 - 思考具商業價值的功能

■ 步驟五 - 注意，產品功能的前後相依關係

■ 步驟六 - 開始收集用戶回饋

■ 步驟七 - 讓目標用戶願意參與「產品驗證」

■ 步驟八 - 取得反饋資料後，進行資料統計與分析

■ 步驟九 - 重新思考方向，再安排優化與修正

■ 步驟十 - 安排版本更新，進行經驗學習

完整文章連結

https://reurl.cc/dDL8OD

#如果覺得這篇文章有幫助

#歡迎分享給更多的朋友知道

#最小可行性產品

#專案管理筆記

#MVP

#開發新產品

《我的專案筆記 #31》六步驟，讓你在維護專案活下來

當我們加入一個軟體的開發專案時，可能會有下列三種情況：

1. 維護舊產品

2. 開發新產品

3. 研發新技術

理想上，我會希望我可以先待在一個「正在開發中的新產品」，然後這個產品，有應用到目前最流行的「主題」，數年前是區塊鏈、或者是VR/AR，而現在就是「ChatGPT」或「AI」。然後這個團隊有一位資深的前輩，可以手把手的教我，跟我說整個系統架構、軟體開發會遇到的狀況。緊接著，完整經歷產品上線的過程，接下來學習產品營運，遇到的各種奇妙狀況，並解決他。

當有了完整的產品開發週期體驗後，安排去主導一個全新的專案，題材有趣、新穎，幻想著上線後取得巨大成就，成為知名的製作人、大PM或產品總監，從此過著幸福快樂的生活。

要發生這種狀況，可能上輩子累積了很多的福報...。

實際狀況應該會是這樣，

你加入了一個專案，而這個專案似乎需要常常加班，加班的理由常常都是有著許多「緊急插件」，也因為如此，導致工作量很多很雜，所以增加了一些缺額，希望可以降低加班的情況。往往加入新人後，加班的狀況並沒有改善。

過了一陣子你會發現，為什麼某位資深的員工突然消失了？原因當然有很多，而你也會意識到，自己好像是來「抓交替」的。但是，你好像不能就這樣離開，因為走了這個專案似乎就掛在自己的手上，基於一個「勇於承擔和負責任的心」，說甚麼也要抓下一個交替後再走...。不是，是讓他有個好結果後再離開。

而這通常會發生在哪一種專案？沒錯，就是「維護舊產品」的專案上。

因為，「開發新產品」和「研發新技術」的開發節奏，始終是慢慢的，不管這個世界運轉的速度多快，只要產品還沒上線，就不會有立即感受的壓力，也就不容易產生各種「緊急插件」，所以只要是軟體開發的同仁，很少不喜歡「開發新產品」和「研發新技術」的。然後，一旦產品上線維運後，就都會想急著下車...，修正，是挑戰下一個專案。

不過，這邊有一個矛盾又有趣的現象。

事實上，產品上線維運後，團隊需要更多有經驗的人才，不管是PM或是工程師，才有足夠的經驗應對緊急狀況。但是，公司還是需要開發其他產品，於是A產品上線後，很多時候都會把A產品的開發工程師，或是負責的PM，調去協助新產品B，反正工程師和PM都還在嘛，有事再問就好了。

於是，後續接手的團隊，就這樣開始了A產品的維護。

正當一切都還在美好的想像時，維護中的A產品開始受到一些駭客攻擊，或是來自老闆和客戶的需求需要處理，後續接手的團隊，在無法掌握整個系統架構或資料流程的狀況下，要處理這些問題，就會耗費更多的時間。接著，老闆或客戶就會開始執意，為什麼處理時間這麼慢？為什麼需要這麼久的時間？

就這樣，內部開始各種檢討會議，討論著要如何改善？客戶的需求要如何滿足？還有，各種的抱怨與不滿。

往往會得到一個答案，那就是「系統掌握度不夠」，接手的團隊對於原本的系統架構，常常是不清楚的，而且產品功能也不一定有人可以全盤掌握。追問下去後，也常常會發現兩個因素「交接不足」和「缺少文件」。

「交接不足」和「缺少文件」往往是一體兩面的。

在傳統的開發思維《瀑布式開發》下，多半有「詳盡的文件」後才開工，但是要先弄出「詳盡的文件」，可能需要花上大半年的時間在寫文件，這段時間又不能讓開發團隊閒置，於是邊開發邊寫文件。

※註：這邊的文件指的是產品的需求文件或是規格文件。

那工程師的技術相關文件呢？不好意思，我普遍知道的工程師，都是不善於寫文件的。加上工程師寫程式都已經會花上許多時間，要讓工程師寫文件，那真的會要他們的命。如果專案過程中，把開發時間也納入工程師寫文件的時間，那可能會花上兩倍的時間...。

於是，《敏捷式開發》的出現，似乎讓工程師有了一個救贖，從此就可以不用寫文件了。但是，這是一個美麗的誤解，雖然《敏捷式開發》強調的是「可用的軟體重於詳盡的文件」，但是不代表就不用寫文件，而是寫「剛剛好的文件」，那什麼是「剛剛好的文件」呢？這就跟看食譜一樣，每次都寫「鹽少許」，什麼是「少許」？於是又多了很多的想像...。

總之，有各種原因，導致「剛剛好的文件」，始終難以產生。

當初始成員逐漸離開團隊，系統掌握度就從100%變80%，80%變60%...。

接著，回過頭來檢討，就又覺得「交接不足」。

但是，原始團隊成員都在其他專案，或已經離開公司，也無法接交。

最後，矛頭就指向「缺少文件」。

團隊就必須面臨「處理上線遇到的緊急狀況」、「開發老闆或客戶新需求」。

然後，還要補上「缺少的文件」，避免團隊每經歷一次調動，就失血一次...。

很不幸的，大多數我們加入的專案，往往都是這種狀況。

那身為一個涉世未深的小小PM，我們該怎麼辦？

想知道如何透過六個步驟，讓你在維護專案時活下來嗎？

點擊下方連結，提升你的存活率!!

https://reurl.cc/v7ggey

也歡迎加入粉絲團，獲取第一手的資訊。

https://www.facebook.com/DigiPRDCoachHeroMi

#如果覺得這篇文章有幫助

#歡迎分享給更多的朋友知道

----

[工商服務]

歡迎在軟體開發產業奮鬥的年輕PM

或是想要成為一位稱職的TPM的朋友

隨時找我一對一諮詢

目前辦公室位置近台北車站，交通方便

若有興趣，請加我LINE 帳號：https://lin.ee/04FrtSO

《我的專案筆記 #30》

前一陣子和之前合作過的年輕PM吃飯，聊聊他們在新公司的狀況，聽下來普遍都有一種現象，那就是「很不踏實」。

這是什麼意思呢？

簡單說，這些年輕的PM感覺現在的工作，就只是把「專案項目放到時程表上」，然後就這樣每天照著排定的進度走，但是那個進度安排，並沒有一定的邏輯，就只是放上去而已，結果就是團隊成員都不知道該怎麼辦，於是都抱持著且戰且走的心態。

而這樣的狀況也不是只發生在一個專案，在很多專案中，也常常會發生這種事情，不管是PM、還是前端或是設計，都常常會有這樣的感受。這到底是為什麼？

在之前分享的文章中，我們可以清楚的知道一個軟體功能的開發，是有許多過程的，例如規格文件撰寫、視覺設計、前端開發、後端開發、API開發、API串接、測試驗證...等，但是這些都只是一個點的功能，如果希望對於時程的掌握度要更高，就需要從點延伸到線，再由線拓展到面。

這樣講可能還是有點模糊，想像自己是一位「婚宴」的主廚，需要思考的就不是「一道料理」，而是「十道以上」的料理，另外，準備的不是1桌，而是20桌，甚至更多。每道料理的烹調時間長短也不一致，為了可以精準控制每道料理的上桌，那些要提前準備、那些必須現場處理，除了經驗外，更多的是不斷的嘗試與調整，最後建立起自己的一套流程。

軟體開發產業的PM，也總是被這樣期許著。

但是，實際上，這位PM可能連一個荷包蛋都弄不出來，雖然這樣講有點誇張，卻又常常是不爭的事實。

以電商平台為例，我們要怎們去規劃電商平台的開發項目呢？

其實在談規劃之前，我們要先清楚理解PM的角色在哪裡，而這個角色取決於產品的階段。

如果想知道更完整的內容，點擊以下連結

https://reurl.cc/Dmz905

歡迎來我的粉絲團走走

https://www.facebook.com/DigiPRDCoachHeroMi

#如果覺得這篇文章有幫助

#歡迎分享給更多的朋友知道

某次的讀書會，一位在醫療體系工作的朋友說到，他們公司現在也要求PM們，要去了解研發的工作流程及相關細節，因為在過往的研發上，PM對於研發說出來的工期和任務，掌握度太低，研發說什麼就是什麼，希望PM們可以更加的了解「研發的流程」。

其實，我也是可以想像這樣的狀況，因為在軟體開發也是常常發生。我接觸過的一些PM，甚至有些資歷都還頗深，對於工程師在做甚麼，都不太清楚，所以某些功能工程師說「5天」，就只能相信是「5天」。這時候，老闆反應說「為什麼要這麼久？」，常常就會看到PM說「這是工程師說的」。

後續老闆的反應，應該就不難猜了。

在之前的文章中，有提到可以透過拆解WBS、設計工作包，和規劃活動，來釐清專案的需求項目。

但是，這邊有一個很有趣的部分，就是「如何規劃活動」？

其實這就像網路上流傳的一張圖「如何畫出一匹馬？」，簡單五步驟畫出一匹馬。

實際上並不是這麼簡單，要畫出一匹馬，需要了解馬的骨架、肌肉紋理等，才有辦法真的畫出來。

其實，「拆解WBS」到「列出活動」這一連串的動作，就跟畫馬的概念是一樣的，要先對「馬的骨骼、肌肉」有概念，才比較有可能畫出「馬」。

如果覺得「畫馬」，還是有點難以理解，那就用做一道「料理」來想想看。

今天我們要自己在家做一道「料理」，會有哪些步驟需要執行？

我們可能會要想菜單、採買、備料、烹煮、擺盤、上菜、享用，然後決定下次去餐廳吃就好。

這樣是不是就更容易理解。

那「軟體開發」，需要執行的步驟有哪些呢?

基本的開發流程就會如下所列：

1. 依據需求撰寫「需求規格書」

2. 將「需求規格書」細化為「系統規格書」

3. 有了「系統規格書」後，就可執行下列動作

(1) 設計師進行視覺設計

(2) 系統工程師與研發人員討論系統架構

(3) 研發人員規劃軟體層面的系統架構

(4) 系統工程師規劃硬體層面的系統架構

(5) 資料庫管理師設計資料庫 (有時候是研發人員進行)

(6) 測試人員準備「測試計畫」及「測試案例」

4. 當視覺設計完成後，若產品是網頁的話，則會由網頁設計師進行「切版」

5. 後端工程師負責進行「後端邏輯開發」，及「API設計」

6. 當API完成後，前端工程師則需要「串接API」，這部分前端工程師與後端工程師會密集溝通

7. 當「串接API」完成後，就會需要進行「測試驗證」，這部分會在所謂的「測試環境」進行

8. 當完成測試，並滿足可交付的限制後，就可進到「交付」的階段。

當然，這只是一個開發流程的基本概念，不同的開發項目，就會有不一樣的流程，例如APP專案，就沒有所謂的切版，又例如遊戲專案，就有可能加入3D建模流程，或是其他的開發流程。只有對產品有一定程度的了解，才能相對完整的規劃「活動」。

拆解軟體開發的「活動」，把握一個原則，就是盡可能的了解團隊工作流程。

當我們對於工作流程的掌握度不高時，要規劃出「活動」，就會相當困難。

#做料理真的不是一件容易的事

如果想知道更完整的內容，點擊以下連結

https://reurl.cc/EG4zNk

歡迎來我的粉絲團走走

https://www.facebook.com/DigiPRDCoachHeroMi

#如果覺得這篇文章有幫助

#歡迎分享給更多的朋友知道

好奇問問大家，當負責新的一個專案項目時，都是怎麼展開工作項目的呢？

年輕時候的我，剛拿到需求就會把需求直接填到工作列表中，然後就會遇到一個問題，這個工作需求好像需要工程師和設計的配合，那怎麼辦？

可是工程師和設計師的工作細節，身為一個菜鳥的我，似乎無法掌握，這個時候主管就說「那就把設計師和工程師的工作追蹤，交由他們各自的主管管理」，於是就這樣變成三分工作的進度追蹤表。

接下來又遇到一種狀況，產品企劃、設計師、工程師之間，突然都不知道對方做的狀況，於是又變回一張表。

光是這樣要維護這個工作進度的表單，就耗盡了我全部的精力，當然，只要中間的需求有些變動，就又要重新確認一次。

然後，這樣痛苦的日子大概過了半年，心想，肯定有更好的方式。當時用來管理專案的工具是「Microsoft Project」，「Microsoft Project」是一個很好用的工具，是我的工作項目管理的觀念，趨近於零，無法駕馭。

於是開始花時間去研究，這時候發現一盞明燈，那就是「工作分解結構(Work Breakdown Structure，簡稱WBS)」。WBS的概念，就用一個相對有結構和層次的方式，針對「需求」進行拆解。

原來拆解需求，就跟切菜一樣。

#其實切菜很不容易

如果想知道更完整的內容，點擊以下連結

https://reurl.cc/1e4OzW

歡迎來我的粉絲團走走

https://www.facebook.com/DigiPRDCoachHeroMi

#如果覺得這篇文章有幫助

#歡迎分享給更多的朋友知道

《我的閱讀筆記 #24》

其實，我是一個充滿焦慮的人。

認識我的朋友都知道，從以前到現在，我會不斷地安排自己進修、學習各種知識，讓自己在工作上可以表現得更加完美，這樣驅動自己的動力，源自於「我的焦慮」。

過去，我一直以為我的「焦慮」來源，是「知識焦慮」。

直到，讀了《人生4千個禮拜》這本書，才發現，真正的焦慮感來源，是「時間焦慮」。

回想當年高中考大學的時代，那時候的壓力其實不在於有很多知識需要學習，而是「在有限時間內」，做大量的學習。

相同是學習，為什麼我學日文的時候，可以連續13年毫不間斷，但是學英文卻總是斷斷續續，無法堅持13年。原以為是因為「學日文是興趣」，所以有強烈的動機；但是「英文」對我來說，應該有更強的目的，因為英文不夠好的關係，有幾次不錯的機會就因此流失。所以，我應該要「好好學英文」才對。

最後，發現最大的差異在於，學日文是沒有設定「時間限制」，而英文總是設定一個「時間限制」。同樣都有設定日文就是要取得JLPT N1的目標，而英文最終目的就是要取得TOEIC的金色證書。只不過，學日文沒有設定何時要取得證書，因此就這樣挑戰11次，考試花了6年的時間挑戰，但是TOEIC就不一樣了，總是會設定20xx年，要取得幾分，像今年就又設定「2023年TOEIC 600分」的目標。

於是，為了達成這個目標，又開始產生了焦慮感，心想，每天要讀點文法、背點單字，也組了英文讀書會，用盡各種方式督促自己前進，導致壓力更大。當然，也有人說「適度的壓力，才能有效成長」，我對這句話也相當認同，因此努力讓自己取得一個平衡。

而29歲，是我人生觀改變的一年，當時面臨30歲這個關卡，心想我要做一些改變。

(1) 廣泛閱讀：開始認真閱讀，曾經1個月看30本書，當時就是泡在書店一直看書。

(2) 健康管理：開始做飲食管理、運動管理、作息調整。

(3) 學習語言：開始進行日文的學習。

(4) 財務管理：開始認真記帳，學習理財知識。

(5) 拓展人際：開始參加各種社團活動，拓展交友圈。

原本以為是「我想改變」，所以，才去做這些事情。當我在看《人生4千個禮拜》的時候，腦中想的，卻是我的很多行動，都是因為感覺到「時間不夠」，而這些「時間不夠」的原因，就是因為我設定了「35歲想幹嘛」、「45歲想做到什麼」，所以產生了「焦慮」。

曾經有段時間，我很害怕去書店，去了書店看到滿滿的新書，感受到的，不是閱讀的喜悅，而是這麼多書，看也看不完的焦慮感。即便我曾經很長一段時間是每週跑書店，看新書、學新知，然後想辦法在工作上實踐，享受那樣的「成就感」，依然很害怕去書店。

過往在職場，總是被時間追著跑，下周要交付什麼版本、下下周又要做到什麼，幾點要開會…等等，於是常常處於一種緊繃的狀態。現在，自己在進行自己的事業，雖然一樣每周都要安排事情執行，但是「時間」的感覺卻逐漸變得模糊。

就像，現在還是有設定「TOEIC 600分」這個目標，但是就只是一個目標，並不會說2023年一定要達成，就像學日文一樣，即便每天只有15分鐘也可以，重點是持續，而不是在短時間內速效，2023年去考檢定，也只是一個測試自己程度的考試。

當然，也不是要推崇「時間焦慮」就是不好，如果想要在短期內有一個成果，適度的「時間壓力」，確實是有幫助的。

就像我在2022年7、8月時，設定要取得PMP國際專案管理師證照，當時的目標就是要在2個月內取得。於是排開所有的事情，專心一致在準備考試，就像回到當年高中考大學一樣的備考狀態，最後結果就是38天考取，也成為當時檢定班第一位考取的學員。為了要達到這個目標，用盡各種方式。

其實，在進行專案的時候，也是有類似的狀況發生。「瀑布式開發」和「敏捷式開發」有一個根本的不同，就在於「瀑布式開發」適用在「相對明確可控的專案」，而「敏捷式開發」適用在「相對不明確的未來」，因為未來是不明確的，需求也就不明確，團隊成員就像是在大海航行，卻沒有羅盤一樣。

在「敏捷式開發」的框架裡，就有了「衝刺」這樣的概念，而每一個「衝刺」就是一個「時間盒」，起碼在每一次的衝刺中，讓團隊的目標是相對明確的。即使遙遠的未來是不明確的，但是當下是明確的，也可以有效地降低「時間的焦慮感」。

那什麼是「時間盒」？簡單來說就是「設定一段時間區間，做指定的事情。」，例如：我設定周一晚上7:00 – 9:00跑步，這就是「時間盒」。

「瀑布式開發」就是一個很龐大的時間盒，然後再逐步切割成小的時間盒。於是當「時間盒明確」，但是「需求相當不明確的時候」，團隊成員就會產生很大的「時間焦慮」，因為「時間有限，需求無限」。

而最近一次強烈感受到「時間焦慮」是什麼時候呢？

答案是「餵小朋友吃飯的時候」，因為總是希望小朋友可以在幾點前吃完飯，然後才能洗澡、睡覺，小朋友卻又總是不會乖乖配合，吃一口玩一下，起初我以為情緒起來的原因是「小朋友不肯配合」，後來才意識到，是「我又設定一個期望時間」，當無法實踐這個時間目標時，就又焦慮了起來。所以，現在轉換心情，雖然一樣有設定時間目標，但是就能用平靜的心，陪小朋友吃飯。

原以為我是因為「知識焦慮」，

才開始大量閱讀、進修上課，

實際上是「時間焦慮」。

歡迎來我的粉絲團走走

https://www.facebook.com/DigiPRDCoachHeroMi

#如果覺得這篇文章有幫助

#歡迎分享給更多的朋友知道

想知道甚麼是UI Guildline嗎？

當看到一個產品，有10種字型、15種字體、

繽紛的配色、和各種大小的按鈕時，你就知道了。

為什麼這麼說？

因為一套產品的開發，通常都不只一位設計師，以過往遊戲開發來說，團隊內常常有5位以上的設計師，甚至還會有外包團隊。這時候，如果沒有一套所謂的「UI Guildline」，來進行規範的話，「字型、字體的不統一」真的是蠻常見的狀況，加上還有風格的問題，就會更加的凌亂。

出社會後，陸續參與一些產品的開發。後來被派去參與一款產品的試用，當時的產品正在進行上市前的準備，但是卻發現，有許多風格不統一的介面、樣式不統一的字型，以及大小不一致的字體，雖然有提出這個問題，也許是因為上線在即，就沒有進行修正，當然之後也就不了了之。這時期的我，也還不明白「一致化的標準」的重要性。

隨著參與的專案越來越多，也更有機會可以主導專案時，才意識到，為什麼會出現這樣的狀況。

舉一個最簡單的例子「系統提示訊息」，請問關閉提示訊息視窗的按鈕，應該要叫什麼？是「確認」、「確定」還是「關閉」？又好像都可以，對吧。因為這三個用語都很常見，因此出現任何一個感覺都沒問題，因此當多人開發的時候，你就會發現，這些用語不斷的交錯出現，並沒有統一的使用方式。常常都是當下的「感覺」來決定。

按鈕的「配色」也會是需要考慮的部分。因為「按鈕」是在介面設計時，很重要的「引導」，其他還有「警示」及「行動呼籲」的功能，因此顏色的搭配及使用，就變得相當重要。

但是，實際進行產品設計的時候，往往會掉入一個陷阱，總是覺得「A按鈕有很重要的資訊」、「B按鈕一定要讓用戶看到」、「C按鈕最希望用戶點擊」，於是「A按鈕是綠色」、「B按鈕是紅色」、「C按鈕是藍色」，整個畫面花花綠綠，最後就失去焦點，因為每個都是重點。

如果想知道更完整的內容，點擊以下連結

https://reurl.cc/Dmn5ne

歡迎來我的粉絲團走走

https://www.facebook.com/DigiPRDCoachHeroMi

#如果覺得這篇文章有幫助

#歡迎分享給更多的朋友知道