「 MVP思維實戰 」- 策略化實踐職涯的產品迭代!

Pierce Shih
皮爾斯的自學旅程
20 min readOct 9, 2019

職涯如同打造一個產品,每走一步都是經驗的累積,也迭代出更好的自己。

前言

筆者在將近一年的程式自學旅程中,主要以 JavaScript 實作全端(Full-Stack)網站開發,力行自我產品迭代,也累積技術筆記和作品集,落實個人品牌的經營。

下一步目標,以軟體工程師的角色,加入一間具有長期企業使命的新創公司,鎖定雲端軟體(SaaS)產業、教育科技產業、電商產業,更期許自己未來透過「商業」、「產品」、「技術」的跨領域整合,解決更多的問題。

因此,我希望陸續透過下列五篇文章跟大家分享我是誰,包含我的轉職初衷、過往 SaaS 軟體職涯經驗、如何運用 MVP 思維迭代更好的自己、我的產品開發經驗、做事方式和團隊角色定位,以及未來的職涯目標和想法。

4. 「 新創 SaaS 實戰 」- 紙上談兵,不如血淋淋的作戰經驗!(10 月中旬)

3. 「 電商專案實戰 」- 原來產品開發是這麼一回事!

2.「 MVP思維實戰 」- 策略化實踐職涯的產品迭代!(本篇)

1.「願景驅動改變」- 當能力撐不起野心,歸零學習創造一條新的路

核心用意是幫助大家從中了解我的經驗和故事,也希望有機會為你所處的團隊帶來更多價值,如果有興趣交流聊聊,歡迎隨時與我聯繫 :D

Photo Credit by Perry Grone from unsplash

職涯產品迭代

截至今日,大約是 400 天以前,我勇於跳脫自我的舒適圈,從零開始重新建立自己的職涯第二曲線,而透過數字化的統計,也讓我更清楚時間的複利效果,可以帶來如此大的改變與自我成長。

因此,期待透過本篇文章與大家分享,我是如何將職涯視為一個產品來經營,過程中又是如何逐步完成階段性目標,同時,也提供有意開啟自己職涯第二曲線的人作為參考。

本文章將分成下列幾點跟大家分享我的心路歷程,分別是:

・MVP 思維的職涯實驗室

・MVP 產品的成果展現

・專案週迭代執行細節(目標、策略、規劃、落地、覆盤)

・結語

MVP 思維的職涯實驗室

此篇文章不會提到當初轉職的故事,如果有興趣的話,歡迎查看延伸閱讀。

延伸閱讀:「願景驅動改變」- 當能力撐不起野心,歸零學習創造一條新的路

那我這邊想分享的是,為什麼我會把職涯和 MVP 思維結合的小故事。

過去的職涯都是在新創圈打滾,一直有聽聞 MVP 產品的觀點,也理解它的好處與優勢所在,而長期的職涯目標,也是打造一個軟體產品來解決教育領域的問題,但卻沒有親身走過這樣的歷程,實在是有點可惜。因此,當決定要轉職為軟體工程師時,我心想如果把 MVP 思維的概念結合個人職涯來經營,相信會是一件非常好玩的事情!

藉由打造自身職涯的第二曲線,不僅有機會累積自身在技術領域的技能樹和實戰經驗,也能「親身」體會 MVP 思維的落地應用是怎麼一回事。

所以,我決定把轉職的歷程,當成一個產品來經營,透過不斷與市場互動,收集用戶回饋,過程中不僅逐步修正,也釐清我對於軟體工程師職涯的想法與目標。

不追求完美的一百分,但確保持續進步與成長!

如此一來,引導自己更加符合市場需求,養成具備解決問題的能力,才能真正創造企業價值的實踐。

MVP 產品的成果展現

在軟體工程師領域,作品集往往勝過一切,因為它就是你能力的最佳展現!

去年的我,不是很明白這句話的意思,直到近期的某一天,我才明白了這句話的真諦。

所幸始終保持,先相信,再看見的態度!

這個小故事是這樣的~

某天我麻煩朋友幫忙引薦 XXX 電商公司的軟體工程師,希望有機會先碰面交流,從中尋求業界的回饋,讓自己更有方向來準備。但事情就是如此奇妙,當你想準備好再上的時候,機會就主動來敲門了。對方請我先把履歷給他看一下,這樣會比較有效率,當時心中其實有點小緊張,想說自己還沒準備到 100 分,會不會一給出去,這個機會就此 say goodbye 了呢XD但後來轉換一個想法,其實就更有自信了,與其追求完美的 100 分,不如就讓市場來驗證自己這將近 400 天的努力和成果吧,畢竟這才是 MVP 產品的思維呀!不過,這不是鼓勵大家給出一個不及格的東西,因為你必須調整成你自己也滿意的成品啊!好險結果沒有太差,至少有讓對方留下正面的印象,對我而言,也是一個莫大的肯定 :D

而這邊也跟大家分享,我是透過哪些作品展現職涯第二曲線的 MVP 產品,大致分為兩個部分,如下:

1. 皮爾斯的作品集( GitHub)

GitHub 是軟體工程師用來管理程式碼的協作平台,不僅是你展現技術能力的管道,也是記錄從寫爛 code 到慢慢進步的歷程,如果沒有 GitHub,那你大概不用混了XD

目前我主要完成 3 個團隊專案,包含 2 個前端 和 1 個後端,代表性作品為前後端分離的「電商網站」與「籃球訓練營形象網站」,分別與設計師、工程師都有合作經驗,詳情可見:皮爾斯的作品集

而這邊想分享一個我覺得成就感很大的專案,因為它讓我真的體會到:

原來我學的這一切,都是在幫助我,完成我想要做的事情!

這是一個籃球訓練營的形象網站,也是我第一個網站外包案子。

圖一:籃球訓練營形象網站(QD-basketball-academy)

之所以說它給我的成就感很大,這是因為我用了我的方式,回饋給這位曾為台灣籃壇貢獻良多的台灣選手 Quincy Davis 戴維斯

故事是這樣的~Quincy Davis 戴維斯,在過去 8 年代表台灣出征各大國際的籃球賽事,也於 2013 年歸化為新台灣人,更帶給台灣籃球迷許多難忘的經典戰役,如同 13 年亞錦賽逆轉擊敗世界強權菲律賓和中國的經典賽事。縱使近年來已逐漸退出國際賽場,但身為台灣人的他,持續用他的方式回饋這片他熱愛的土地,這也是全台灣球迷為什麼會如此感念他的原因,我也不例外。回想起來,有機會透過籃球形象網站的合作,以自身的「技術」能力幫助熱愛台灣的籃球員 戴維斯,此刻依舊非常興奮,縱使初期有點擔心無法滿足其開發需求,但還是如期完成了專案。最後,我發現收穫最多的人其實是我,不僅從中累積和設計師成功合作的網站開發經驗,也從中更加熟練技術的應用,甚至學會一些新的東西。更重要的是,過去的我無法幫上忙,因為我不懂技術,但透過這個專案,它讓我體會了「原來我學的這一切(技術),都是在幫助我,完成我想要做的事情!」

專案詳細介紹可見:籃球訓練營形象網站(QD-basketball-academy)

圖二:籃球訓練營形象網站(QD-basketball-academy)

2. 皮爾斯的自學旅程(Medium 部落格)

許多轉職文章都很鼓勵新手工程師,經營個人部落格,紀錄自己的學習歷程,整體來說,優點超多( Z>B),這邊不多加描述。

經營部落格至今,目前已超過 6 個多月,累積 42 篇文章,超過 1,700 次拍手數(claps),內容以「前後端技術」、「職涯經歷」、「產業訪談」的分享為主。

對我而言,部落格就是在經營我的個人品牌,如何透過有策略的佈局,不只讓人看見你學習技術的過程,也幫助大家理解你過往的職涯經驗、產業知識,甚至是做事方法,這些都有助提升你個人品牌的亮點。

延伸閱讀:「產業探索之旅」- SaaS 雲端軟體服務

延伸閱讀:「產業探索之旅」- 電子商務

讓我來分享一個小故事吧~

在今年七月時,我的 Github 作品集,還沒有個人的代表作品,頂多就是一些小專案,但令我意外的是,有公司主動上門聯繫,希望進一步邀約面試,當時有點受寵若驚,也很好奇對方的想法,希望尋求一些建議與回饋,後來也得到了答案。雖然全世界都知道,寫部落格是絕對加分的事情,但實務上並不是每個人都會落實執行。老實說,撰寫技術筆記這件事情沒有想像中那麼簡單,光是要構思文章架構,上網爬資料,甚至寫完整篇內容,我平均每篇文章都花了將近 2 個小時,有的甚至更多。而上述過程,不僅是你日常研究新知的成果展現,也可以當成你是否具備快速學習能力的判斷依據!

因此,當你真的開始著手經營,有紀律地持續產出文章,輔以數據佐證經營成果,那自然而然,你就會從一大群 junior 工程師脫穎而出,獲得更多職涯的新機會。

Photo Credit by Ant Rozetsky from unsplash
感謝你完成 1/4 的內容閱讀囉~如果你喜歡我的分享,也相信我有機會為你的團隊帶來貢獻。
歡迎隨時留言或是來信至 pierceshih@gmail.com 與我分享~
非常期待與更多優秀的夥伴交流成長,有機會也能一起打造更好的產品!----------如果願意給我一些小小鼓勵,請給我 1–20 個拍手;
如果覺得文章對你有點幫助,請給我 21-30 個拍手;
如果想看更多職涯的相關文章,請長按拍手按鈕(50個拍好拍滿)讓我知道哦 👏🏻歡迎繼續往下查看內容呦~

前面分享了 MVP 思維的職涯應用和成果展現~

接下來,我會分享如何結合「敏捷思維」和「專案管理」,以週為單位進行自我產品迭代,一步一步打造自身職涯的第二成長曲線。

如何透過週迭代,有計劃轉職前端工程師

圖示:自我迭代執行脈絡

首先,讓我們透過上圖瞭解「週迭代」整體的執行脈絡,而這也是一個不斷循環與進化的過程,流程如下:

・Step 1:目標設定

・Step 2:策略擬定

・Step 3:專案規劃

・Step 4:落地執行

・Step 5:覆盤修正

深入來瞭解,我的轉職案例吧~~~

#1 職涯產品迭代(目標與策略設定)

首先,我確立我的最終目標是要成功轉職為一位「前端工程師」,接著,開始聚焦到每一個月的目標與策略設定,如下圖所示:

圖示:專案目標與與核心策略

由於目標是要證明我具備「前端工程師」的專業能力和產業知識。

因此,我採用「成果導向」的核心策略,透過不同關鍵指標衡量自己是否有完成該月的目標設定。

舉例來說:經營部落格,不僅有助於我完成當月的目標,長期來說,更有機會讓我實踐最終的轉職目標。當時,我在研究前端框架 Vue 的相關知識,不只希望它是一個 input 的過程,也希望將所學的內容,以我的架構和思維轉為 output,透過文章的形式完整記錄下來。因此,我為自己設定當月文章產出的數量為 14 篇,拆分至每週的目標則為 3-4 篇,而每當完成一篇文章,心中會很清楚,我離目標又靠近了一步,整體而言,也會更有動力和成就感。

#2 職涯產品迭代(專案規劃)

相信大家都有相同的經驗,不論是在工作層面或是個人學習層面,特別是當我們訂立目標之後,卻不知道如何拆解,將它轉換成一個又一個可被落地執行的專案。

觀眾:齁呦~該怎麼辦拉XD

我說:別急,讓我們繼續看下去

接著,我會以上述 Vue 自學筆記專案跟大家分享目標拆解的邏輯,如下圖:

圖示:目標拆解與專案規劃

首先,讓我們掌握「大框架抓整體性,小細項看可行性,動態彈性調整」的三大原則。

A: 大框架抓整體性

當我在評估一個專案需要的執行時間時,我會先研究所選定的主題,範疇有多少,大致有多少內容,進而掌握整個專案的整體性。

如果你擔心沒有經驗要怎麼評估,那你可以放一百個心,因為我們絕對不會是第一個撰寫 Vue 自學筆記的人,網路上肯定有許多案例可以參考。

舉例來說:當初我看了幾個 Vue 前端框架的分享文章,整體評估下來,我大概需要寫 18 篇文章才能介紹完一些基本的觀念,此時,我們心中就會有個整體性的概念。Okay,如果我要寫的話,大概需要寫 18 篇文章。

B: 小細項看可行性

當我們得知需要寫 18 篇文章時,那就要思考每一篇文章需要花費多少時間,同時,回答出為什麼需要這個時間,從中判斷該事項的可行性。

舉例來說:專案初期,我預估 1 篇文章,大概會花費我 2 個小時完成,其中 0.5 小時負責擬定文章大綱,剩餘 1.5 小時則是專心完成文章內容。假設我 1 篇文章要花費 2 個小時,那 18 篇文章就是 36 個小時。接著,讓我們來思考看看執行面的可行性~如果以每週 3 篇來說,每週需要投入 6 小時的時間,整體而言會是 6 週的專案。聽起來蠻明確的,落實到每週執行,也不會太天方夜譚,有機會如期完成!

C: 動態彈性調整

對於專案規劃,我們要有一個健康的心態,變動是正常的情況,而專案規劃本身是一個動態調整的過程,它的存在是為了讓你因應不同的變化,迅速做出最適當的調整,幫助你如期完成核心目標。

舉例來說:落地到執行面時,我大致上都能在 2 個小時左右完成一篇文章,反覆驗證了 4-5 篇內容後,我發現這是最適合我的專案預估時間。但我的案例不一定適用在其他人的情況,有可能你天資聰穎,只需要 1 個小時的時間,也有可能你需要 3 個小時的時間。不管結果如何,請大家都要盡可能去找出最適合自己的時間,進而發揮自身工作的最大效率。

小結

透過這個規劃,你就會很清楚知道你手中有哪些專案在跑,如下圖:

圖示:專案規劃全貌

1. 每個專案什麼時候開始&什麼時候結束。

2. 掌握未來幾週你該著重在哪些專案上。

因此,我非常鼓勵大家將目標拆解的思維落實到你的工作日常,甚至是個人成長的學習計畫上,相信我們都能一起變得更好。

Photo Credit by Fezbot2000 from unsplash
感謝你完成 2/4 的內容閱讀囉~如果你喜歡我的分享,也相信我有機會為你的團隊帶來貢獻。
歡迎隨時留言或是來信至 pierceshih@gmail.com 與我分享~
非常期待與更多優秀的夥伴交流成長,有機會也能一起打造更好的產品!----------如果願意給我一些小小鼓勵,請給我 1–20 個拍手;
如果覺得文章對你有點幫助,請給我 21-30 個拍手;
如果想看更多職涯的相關文章,請長按拍手按鈕(50個拍好拍滿)讓我知道哦 👏🏻歡迎繼續往下查看內容呦~

前面分享了大方向的目標與策略設定,也將目標拆解成不同的專案。

接下來,讓我透過一週的專案計畫分享專案「落地執行」的細節!

#3 職涯產品迭代(落地執行)

俗話說:「 執行力才是一切」,即使你有一份完美的計劃,但沒有強大的執行力,那一切都將變成空談。

不過,我後來發現「成就感」才是驅動每個人前進的最大動能!

相信你一定有類似的經驗,常常有一個大目標想達成,或是想學習一個新專長,但往往過了 1-2 週,熱情沒了,這件事情就隨風而去了QQ。

觀眾:安安~你說的是減肥嗎(毆飛XDDD)

筆者:那是你說的喔 >..<

以轉職成為軟體工程師來說,它其實算是一件超級大的目標,可能是 3-6 個月,甚至長達一年的專案。聽到這裡,你是不是很難想像,也覺得自己沒辦法做到呢QQ不過,若我們將這個專案,拆解成每一週的小任務(To-do List),每週專注完成 10-15 個小任務,一步一腳印前進,透過時間長期累積。經過 3 個月,或許就完成 180 個小任務,離最終目標也前進 1/3 了,而完成每一個小任務,不僅能獲得源源不絕的成就感,也讓你清楚看見個人的成長,更有動力往前邁進喔!

接下來,讓我們看看每週專案的落地執行吧。 Let’s go !!!

下列案例將由 3 個步驟的整體脈絡切入,搭配執行細節的說明~~~

Step 1:盤點當月核心目標與專案,擬定當週執行計劃

圖示:當週專案計畫

如上圖所示,在每週一上午,我會預估各個專案所需要的時間,再彙整成當週總共需要投入的時間。

以 ALPHA CAMP 學期四的課程專案來說,當週共有 8 個小任務要完成,逐一預估每個小任務所需要的時間,最終我會得到此專案需要投入共 15 個小時。Okay,依此類推,其餘專案也比照辦理,抓出執行時數,我就會知道本週至少需要投入 42 個小時,才能完成上述所有的小任務。

當我們知道本週有多少小任務之後,我會透過 Google 行事曆和 Trello 專案管理工具,進行自我管理與進度安排。

Step 2:善用 Google 行事曆,輕鬆掌握當週的工作時程。

圖示:當週行事曆

我認為將每一個小任務放進行事曆,有下列三個好處:

(1) 幫助我們評估本週計畫是否可行,若行事曆排不下原訂的所有任務,代表計畫不可行,需要重新擬定。

舉例來說~如果你發現自己每週可以負荷的工作時數是 35 個小時,那如果你預估出來每週需要投入約 45 個小時,那代表這個計畫還沒執行,就肯定會有任務無法完成了。此時,我們就需要回到前面的專案拆解步驟,將專案時程拉長(6週 > 8 週),也將該專案每週所需要投入的時間下修(8 小時 > 6 小時),如此一來,才能順利完成專案目標。

(2) 理解自己何時產能最高,何時產能最低,長期來看,有助於我們將重要的任務排在產值最高的時段來完成。

以過往經驗來說,我每週最適當的工作時數約 40 - 45 個小時,如果連續三週超過 50 個小時,那我的產值就會大幅降低,甚至是開始排斥執行原先的計劃。從過程中我學習到,我早上產值最高,下午則依情況而定,晚上容易文思泉湧。因此,我將會將每週最重要的 5 個任務排在早上來完成,而寫文章的任務則會放在晚上 9 點後來完成,接著,再陸續排入其他的任務,極大化自己的產能。

(3) 引導我們掌握本週什麼時間點該聚焦做什麼事情,一週結束後,也會得到每件事情最後實際花費的時間,用來進行專案覆盤(後面會談)。

Step 3:使用 Trello 自我管理與追蹤專案進度

前面 Google 行事曆 的時間管理,Trello 則是幫助我管理每一個小任務的執行進度,視覺化掌握未來幾週所有的專案任務,若任務完成後,我會將 ticket 移動到 Done。

圖示:Trello 專案總覽

而最重要的事情是,當完成一個小任務後,透過「勾選」行為強化個人成就感。

圖示:Trello 專案細節(聚焦看 AC 專案)

最終,你就會看見自身的成長與累積!

圖示:Trello 專案成果
感謝你完成 3/4 的內容閱讀囉~如果你喜歡我的分享,也相信我有機會為你的團隊帶來貢獻。
歡迎隨時留言或是來信至 pierceshih@gmail.com 與我分享~
非常期待與更多優秀的夥伴交流成長,有機會也能一起打造更好的產品!----------如果願意給我一些小小鼓勵,請給我 1–20 個拍手;
如果覺得文章對你有點幫助,請給我 21-30 個拍手;
如果想看更多職涯的相關文章,請長按拍手按鈕(50個拍好拍滿)讓我知道哦 👏🏻歡迎繼續往下查看內容呦~

打造產品的過程,除了專案規劃和落地執行外,最關鍵的莫過於「覆盤與修正」,透過自我對話與反思,從嘗試中學習,從錯誤中成長。

我將以執行後的專案週計畫,跟大家分享「覆盤修正」的思維與邏輯!

#4 職涯產品迭代(覆盤修正)

曾經有人問我是如何覆盤,思考哪些做得好,哪邊需要調整。

其實核心策略就是「數據化」覆盤,透過每週一排定的週計畫和行事曆,完整記錄所有的執行時間,到了每週日覆盤時,你將會一眼掌握當週的執行情況,有意識地去思考(預期 vs. 實際)的落差原因,如下圖:

圖示:專案覆盤

接著,讓我們分享兩個真實案例,好好感受覆盤的核心價值。

案例一:AC 更新 User Profile 任務超時完成

對於專案時程的預估,一開始我們會盡可能考量所有情況,抓出一個合理的執行時間,但落地到執行面後,往往很多不確定性因素會產生。

舉例來說~~若以更新 User Profile 任務來說,當初我預估自己可以在 1 個小時左右完成,但最終卻花費了我 4 個小時,即使任務還是完成了,但這是個很明顯的時程預估錯誤。那從這件事情當中,我們就可以去思考為什麼會有 delay 完成的情況產生。後來我得到一個結論,由於它是一個延伸「挑戰題」,所以我需要花費額外的研究時間去理解該如何實作,可是當初預估時程時,卻忽略了這一點,導致最終超時完成的結果。因此,在下一次遇到類似案例時,我就會把「研究」時間加進去,幫助自己抓出一個合理的時程,避免專案超時的情況再次產生。

案例二:決定執行臨時插單的 QD 網站專案

如同前面所提,專案計畫都要具備彈性調整的思維,而決定是否要彈性調整的原則,取決我們對於專案「價值高低」的評估。

如此一來,當變動發生時,我們才能在第一時間做出決策,降低變動所帶來的額外風險。

舉例來說~套用到臨時插單的 QD 網站專案,從上圖中可以看到我暫緩原訂要執行的「The F2E 挑戰」專案與「大神來六角」的學習專案。那之所以我會做這個決定的原因,主要是回歸到我的核心目標,是要證明自己具備「前端工程師」的專業能力。因此,當下評估與其將時間花費在「練習思維」的專案,不如專心投入「業界規格」的專案上。整體來說,價值高出許多,包含作品集故事性、與設計師的合作經驗,還有實戰經驗累積...等等。

因此,透過每週日的「數據覆盤」,不僅有助於我們盤點每一週的執行情況,也能從實戰案例中思考(預期 vs. 實際)的落差原因,反覆執行一段時間後,更會訓練到我們專案時程預估、專案價值訂定與自我調整的經驗和反應能力。

結語

走過 400 多個日子,我知道這一切不容易,但感謝當初勇於跨出舒適圈的自己,才有機會為我的人生寫下另一段寶貴與難忘的回憶。

不僅親身經歷打造「職涯 MVP 產品」的過程,也成功建立第二職涯的專業技能,更有機會以「電商網站」與「籃球訓練營形象網站」作品與大家分享我的成長故事。

過程中,我也認識了許多優秀的前輩和夥伴,大家來自多元的背景,擁有不同的故事,卻擁有共同的信念,用自己的方式為一個更好的世界而奮鬥。

最後,這是我職涯的產品迭代故事,希望我的經驗有幫助到你,如果你看到了文章尾聲,再次感謝你的參與,也讓我們一起努力持續成為更好的自己!

謝謝你的閱讀!如果你喜歡我的分享,也相信我有機會為你的團隊帶來貢獻。
歡迎隨時留言或是來信至 pierceshih@gmail.com 與我分享~
非常期待與更多優秀的夥伴交流成長,有機會也能一起打造更好的產品!----------如果願意給我一些小小鼓勵,請給我 1–20 個拍手;
如果覺得文章對你有點幫助,請給我 21-30 個拍手;
如果想看更多職涯的相關文章,請長按拍手按鈕(50個拍好拍滿)讓我知道哦 👏🏻
最後,若希望持續追蹤我的最新文章,別忘了追蹤 皮爾斯的自學旅程 唷,乾溫 :D

--

--

Pierce Shih
皮爾斯的自學旅程

Leading business growth with product mindset and technical perspective