在過去幾年的工作經驗中，有機會參加了一些不同的活動，其中包括均一的教育設計工作坊、矽谷阿雅分享的專案管理經驗談以及 Marty Cagan 分享的 Product Is Hard，這些經歷讓我能以不同的角度來看待我的職業生涯和參與的專案。
產品一次一次的迭代，職涯中一次次的轉換，人生一次一次的嘗試，在長大的過程，選擇了什麼? 放棄了什麼? 如果把生涯當成一個產品，我們當時相信的那些事情，如今是不是有成為了人生路途中的美麗風景?
從專案演變的角度來看，整個故事線應該會是從規畫走到執行，現在讓我們來深入了解看看整個迭代流程該是什麼樣子。
首先，我們需要確定我們的目標是什麼，以及如何做出決策？
我的職涯旅途中目標可能包括每天七點前回家吃晚餐、轉向純前端工程師職位、回台南休養生息、到大城市體驗生活並利用其學習資源快速成長。
對於一個網站的每個活動或專案，目標可能是增加曝光和使用者黏度或增加行銷活動營業額。在教育科技領域，目的可能是討論新型態的教學工具對學生的影響與成效，參與人員包括實際在使用線上教育平台的老師和開發者。
明確了解需要解決的問題是什麼？可能需要解決的問題包括求學和工作遠離家鄉太久，需要更多家庭時間，或者不擅熬夜無法常態性加班。
在網站設計方面，我們可能需要將設計和工程師置身於使用者的角度，體驗使用者的痛點，使用工具如 Persona (人物誌) 或 User Journey Map (用戶旅程)。
以電子商務網站為例，問題可能包括網頁速度很慢、使用者不容易找到自己想要的東西或購買流程複雜。
目的是讓人真實的感受到使用者，增加開發團隊的同理心，協助解讀行為和需求，更關注在使用者和產品互動的方式與情緒。
與其說是定義目標對象，倒不如說是過程中的一個資訊視覺化工具，協助大家在討論的過程中，盡量進入人物的感受與體驗。
我們直接從教育的角度切入，底下是當時均一歸納出來的 Persona：
當我們確定了各種問題之後，在有限的資源和時間內，我們需要決定首先解決哪個問題。
專案上，要考慮的可能會是:
接下來，我們需要列出各種可能的解決方案，並以最簡單的方式驗證這些方案是否能夠解決我們定義的問題，以轉職來說
針對一個活動或專案，可能的解決方案包括:
無論解決方案是什麼，我們都需要清楚地了解我們的預期結果 (Outcome)，並確保結果能符合我們當時選擇的準則 (Selecting Criteria)。
儘管過程很重要，但結果更重要，重要的是要確保結果符合我們的目標，否則就只是一堆隔靴搔癢無意義的成果 (Output)。
以未來的教育科技來說
為什麼會需要取捨，因為功能不是越多越好，多了必定有其他是下降的，定目標時，要有另外一個可能減少的項目來評估。像是減少優惠折扣時，但使用者同時也不能少太多。
工作、睡眠、運動、家庭、朋友，五選三，人生會好過一點
各種可能方法除了依照 Selecting Criteria 外也要綜合的去評估，有能力的員工只會知道最終的 Outcome，剩下的就要靠員工們自行去尋找與實作，最終這個團隊就會變成一個 Accountable 的團隊，可以由 Outcome 來進行檢視，而不是看寫了幾行程式碼。
時間有限的情況下只做基本的，只有我能做，也對目標有幫助的，最會做也不得不做的事情，最重要的是與 Mission 要一致，英文會是底下幾個單字:
商業的專案可能還要考慮的因素:
以教育來說，從學生行為、思考方法、來分析問題
在解決問題之前，不急著修復，首先分析可能的問題，並將問題範圍縮小到最小，接著是建立問題的漏斗，並理解背後的動機。
數據可以告訴我們問題出現在哪裡，但無法解釋為什麼是問題
雖然還不能明確知道未來的樣子，但還是要為自己在短期內找到一個理想的樣貌，這樣也才會知道還缺少什麼，在目前和接下來的人生中也才知道要培養什麼。
滿分的解決方案並不會出現，所以我們需要去做取捨，最重要的事情是，我們的 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.
在被沒有制度的團隊雷過以後，即使覺得打文件對自己來說並沒有什麼太大的幫助，我還是開始在團隊裡開始主動寫文件，像是開發時程、評估、重要的邏輯、參考資料等等，時間許可的情況下都盡可能把事情簡單的交代清楚。
後來發現乍看之下也許花時間，但比起來回的確認問題、回覆解答，那為什麼不練習一開始就把文件寫清楚? 這也許才是最有效率的方法。文件可以呈現的方法有很多：
處理一件事情的流程通常包括以下步驟，完成、刪去、分派、延後
流程管理的 PDCA 循環 Plan → Do → Check → Action → Plan
就好像鐵人賽三十天一樣，過程中每天不斷計畫、修正然後持續不斷的閱讀和寫作。
三十天過後不論成果如何，最後成長的一定會包含你自己
iThome鐵人賽
看影片追技術