當時相信的專案規劃，能夠一如期待? 三分鐘斷捨離，讓每天都早點下班

在過去幾年的工作經驗中，有機會參加了一些不同的活動，其中包括均一的教育設計工作坊、矽谷阿雅分享的專案管理經驗談以及 Marty Cagan 分享的 Product Is Hard，這些經歷讓我能以不同的角度來看待我的職業生涯和參與的專案。

產品一次一次的迭代，職涯中一次次的轉換，人生一次一次的嘗試，在長大的過程，選擇了什麼? 放棄了什麼? 如果把生涯當成一個產品，我們當時相信的那些事情，如今是不是有成為了人生路途中的美麗風景?

從專案演變的角度來看，整個故事線應該會是從規畫走到執行，現在讓我們來深入了解看看整個迭代流程該是什麼樣子。

• 規劃: 定義目標 → 定義問題 → 選擇準則 → 解決方案 → 取捨
• 執行: 專案時程評估 → 專案難度評估 → 專案成效評估

定義目標 (Objective)

首先，我們需要確定我們的目標是什麼，以及如何做出決策？

我的職涯旅途中目標可能包括每天七點前回家吃晚餐、轉向純前端工程師職位、回台南休養生息、到大城市體驗生活並利用其學習資源快速成長。

對於一個網站的每個活動或專案，目標可能是增加曝光和使用者黏度或增加行銷活動營業額。在教育科技領域，目的可能是討論新型態的教學工具對學生的影響與成效，參與人員包括實際在使用線上教育平台的老師和開發者。

定義問題 (People Problem)

明確了解需要解決的問題是什麼？可能需要解決的問題包括求學和工作遠離家鄉太久，需要更多家庭時間，或者不擅熬夜無法常態性加班。

在網站設計方面，我們可能需要將設計和工程師置身於使用者的角度，體驗使用者的痛點，使用工具如 Persona (人物誌) 或 User Journey Map (用戶旅程)。

以電子商務網站為例，問題可能包括網頁速度很慢、使用者不容易找到自己想要的東西或購買流程複雜。

Persona 人物誌

目的是讓人真實的感受到使用者，增加開發團隊的同理心，協助解讀行為和需求，更關注在使用者和產品互動的方式與情緒。

與其說是定義目標對象，倒不如說是過程中的一個資訊視覺化工具，協助大家在討論的過程中，盡量進入人物的感受與體驗。

我們直接從教育的角度切入，底下是當時均一歸納出來的 Persona：

• 學習態度
  • 快速學習: 像是考古題、速解，想得到考試成績不用懂也可以
  • 慢速學習: 解決問題的方法
• 學習動機
  • 理解差異: 理解到每個人都可以有自己的學習速度，可以用不同的速度前進
  • 找到自信: 學著從容易的部分開始一步一步前進，找到阻力最小的方式累積成就
  • 維持專注: 乾淨的引擎才有力量，心靈也是，心思有空間也才可以放進去新東西
  • 重要貢獻: 從接受知識的人成為分享知識的人
  • 自主選擇: 學習成為一種選項
• 學習環境
  • 講者互動
  • 同儕互動
  • 自己學習
    • 依照進度各自學習，藉由導入資訊系統，前後測評估，自行選擇難度

選擇準則 (Selecting Criteria)

當我們確定了各種問題之後，在有限的資源和時間內，我們需要決定首先解決哪個問題。

• 釐清個人價值觀與願景
• 考量薪水
• 考量可點的技能
• 考慮未來職涯發展，下下一份工作想做什麼

專案上，要考慮的可能會是:

• 專案是否符合公司的願景
• 用戶族群年齡
• 使用情境 (能夠離線使用嗎)
• 成本 (會需要跟其他團隊來回溝通嗎)

解決方案 (Solution)

接下來，我們需要列出各種可能的解決方案，並以最簡單的方式驗證這些方案是否能夠解決我們定義的問題，以轉職來說

• 精進面試和工作能力
• 在面試中表達不願意長時間加班的意願（我確實這樣做過）
• 向同學或朋友詢問有關公司內部情況的建議
• 使用網路論壇或線上資源進行調查

針對一個活動或專案，可能的解決方案包括:

• 響應式網頁
• 開發應用程式
• 電子報

無論解決方案是什麼，我們都需要清楚地了解我們的預期結果 (Outcome)，並確保結果能符合我們當時選擇的準則 (Selecting Criteria)。

儘管過程很重要，但結果更重要，重要的是要確保結果符合我們的目標，否則就只是一堆隔靴搔癢無意義的成果 (Output)。

• Output 是發現了然後解決定義的 People Problem，程式上只是解 Issue 跟 Commit code
• Outcome 是透過理解問題並決定我們想要得到，增加 5% 的營業額透過擺平某幾個 People Problem 來解決

以未來的教育科技來說

• 促進溝通: 通訊軟體
• 學習社群: Facebook 社團、讀書會
• 即時回饋: 資訊系統回饋
• 個人化學習: 按照個體學習速度前進
• 無邊界學習: 網路教學與練習
• 平台解決方案
  • 均一
  • 達學堂
  • Quizlet
  • Zuvio

取捨 (Trade-off)

為什麼會需要取捨，因為功能不是越多越好，多了必定有其他是下降的，定目標時，要有另外一個可能減少的項目來評估。像是減少優惠折扣時，但使用者同時也不能少太多。

工作、睡眠、運動、家庭、朋友，五選三，人生會好過一點

各種可能方法除了依照 Selecting Criteria 外也要綜合的去評估，有能力的員工只會知道最終的 Outcome，剩下的就要靠員工們自行去尋找與實作，最終這個團隊就會變成一個 Accountable 的團隊，可以由 Outcome 來進行檢視，而不是看寫了幾行程式碼。

時間有限的情況下只做基本的，只有我能做，也對目標有幫助的，最會做也不得不做的事情，最重要的是與 Mission 要一致，英文會是底下幾個單字:

• Value
• Usability
• Feasibility
• Viability

商業的專案可能還要考慮的因素:

• 了解消費者
• 了解產品商業模式 (了解老闆)
• 了解消費者產生的資料
• 了解這個產業

以教育來說，從學生行為、思考方法、來分析問題

1. 學生行為優化: 透過引導的方式，讓問題是被發現而非被指出
   • 垃圾無法投到垃圾袋中，請大家討論出好的方案
   • 排隊去科任課，上課前班長集合困難，走過去學生會很吵，大家一起想出可以講話又可以準時到的方法
2. 思考方法優化: 協助 XXX 在 XXX 情境達成 XXX 的目的，將討論的結果，用八格漫畫去說好一個完整的故事，但如果要小學生討論主題太大的時候，怎麼找到開始的方法、蒐集資料、收斂資訊、組織與口語輸出？
   • 偏鄉學生: 家庭功能不足，從陪伴與較低侵入感的學習系統開始培養學習習慣與信心
   • 城市學生: 有資源，所以可以藉由提供工具、給予機會進行組織溝通、口語表達的機會

在解決問題之前，不急著修復，首先分析可能的問題，並將問題範圍縮小到最小，接著是建立問題的漏斗，並理解背後的動機。

數據可以告訴我們問題出現在哪裡，但無法解釋為什麼是問題

雖然還不能明確知道未來的樣子，但還是要為自己在短期內找到一個理想的樣貌，這樣也才會知道還缺少什麼，在目前和接下來的人生中也才知道要培養什麼。

滿分的解決方案並不會出現，所以我們需要去做取捨，最重要的事情是，我們的 Objective 是什麼？

專案時程評估

時程評估問題，在工作初期就開始被主管要求，但那時無法合理的評估，問題是對自身及專案的掌握程度都不夠完整，也不知道有哪些方法，主管建議的就是儘可能多查資料增加掌握程度。

在讀了人月神話之後，發現除了沒有先後關係也不需要討論的任務，其他專案時程確實會有時程估計上的困難，尤其在溝通成本過高的團隊中，這樣的問題會更明顯。

圖片來源: https://cdn-images-1.medium.com/max/2600/1*1ytrUVfjjOh7rJDorSj8eA.png

專案難度評估

後來看了另外一本書 SCRUM：用一半的時間做兩倍的事，裡面建議不是去評估時間，而是用斐波那契數列去評估難度(2 3 5 8 13)，這種數列好處是可以差異化分差。

在決定難度的過程中，可以用投票的方式，其中比起舉手表決使用牌卡進行投票，會是一個比較不會受他人影響的方法，牌卡的數字結果也就代表這個問題的難度。

如果大家的分差過大或不一致怎麼辦？就再進行討論，討論為什麼簡單？為什麼困難？為什麼需要花時間？這樣估計的準度就會大為提高，也方便分派任務，且只有當每個人都發揮所長的時候，團隊的效率才有機會高於個人。

在這個方法中，感覺工時的估計可能不是重點，大家共同決定的點數才是，同類型的專案在團隊經過一段時間的磨合後，大概就可以看出團隊可以在一段時間內解掉多少的點數，時程的預估也才有參考的依據也更為真實。

專案執行成效評估

在個人的成效管理上，由於軟體工程師的工作性質關係，會是需要在專心的情況下才容易有產出，所以要儘可能去減少溝通成本。

缺乏軟體開發團隊經驗的人，很可能會以為在口頭分配並得到口頭回覆後，就只需要心裡想著發大財或時不時的走去詢(打)問(擾)成員作事，所有待解問題就會迎刃而解，專案就會自動完成發大財然後放眼台灣、征服宇宙。

網路上也就出現了下面的玩笑話：

Go away or I will replace you with a very small shell script.

在被沒有制度的團隊雷過以後，即使覺得打文件對自己來說並沒有什麼太大的幫助，我還是開始在團隊裡開始主動寫文件，像是開發時程、評估、重要的邏輯、參考資料等等，時間許可的情況下都盡可能把事情簡單的交代清楚。

後來發現乍看之下也許花時間，但比起來回的確認問題、回覆解答，那為什麼不練習一開始就把文件寫清楚? 這也許才是最有效率的方法。文件可以呈現的方法有很多：

• 任務的卡片：每張卡片等於一個 User Story，List 則用狀態分類。ex 卡片處在開發中 List
• Google Doc：更詳細的文件
• Google Sheet：開發時程
• README.md：專案怎麼跑起來

處理一件事情的流程通常包括以下步驟，完成、刪去、分派、延後

• 完成： 評估正在處理的事情是否可以立即完成，如果有時間和資源就盡早完成
• 刪去： 在清單上的任務但不再需要處理或不再追蹤就可以刪除
• 分派： 任務更適合他人處理，則可將其分派給適當的人
• 延後： 若需要更多時間、資源或資訊或不是優先事項，可將其延後

流程管理的 PDCA 循環 Plan → Do → Check → Action → Plan

• Plan (計畫): 在開會前就該把相關的資訊整理清楚，跳過只需要閱讀的部分，需要討論的才進行討論，畢竟開一個會把有產出的人關在同一個地方，成本是很高的，所以主持會議的人也要控制問題不要發散
• Do (當天要做的事項): 每次討論的目的在能快速的修正及同步訊息
• Check (確認): 大家的進度、方向、遇到的問題
• Action (更好的方法): 能夠趁今天試看看? 怎麼找出答案? 可優化的有哪些?

就好像鐵人賽三十天一樣，過程中每天不斷計畫、修正然後持續不斷的閱讀和寫作。

三十天過後不論成果如何，最後成長的一定會包含你自己

• ← 上一篇
• 下一篇 →