這週開始在聽專案管理 12 項原則的上半部，前四項包含 Stewardship, Team, Stakeholders, Value。
*Stewardship 在聽的時候，感覺像是在描述善良、盡責管理人的概念，但不知道中文對應的字詞是什麼，剛才查了一下，管理領域似乎會以「忠僕管理」來做翻譯。
比較印象深刻的，是有關 Value 的說明
當我們在執行一項專案的時候，它帶來的價值是什麼？團隊成員看到的，是一項項尚待完成的功能清單？還是最終整個服務希望帶給使用者的體驗？
如果在規劃和執行的過程中，已經忘記打造出這個產品的目的，就有可能只是盲目地將拆解後的功能逐一做出，卻拼湊成一個無法真正符合使用者需求的產品。
最近開始在工作中執行第一次的資訊專案企劃，確實也感覺到當中許多不易，看似簡單、生活中常見的功能，其實有各種規劃和設計的不同考量。最初主管在交辦時，有談到程式效能負荷上的極限，但在逐步規劃的過程，我也參考了其他競品、考量到如何更貼近現在使用者的習慣，希望能將更直觀方便的使用方式規劃進去。
但在進一步和主管討論後，也發現考量到現在產品的使用人數、現況可負擔的效能，確實無法將使用者的方便性擺在第一位，不斷讓伺服器發送大量通知訊息。這樣的情況下，要如何在有限的提示訊息中，真正帶給使用者價值？這些訊息對使用者的意義是什麼？收到後又希望他們採取什麼行動呢？發現其實有許多根本核心的why，如果無法理解，是難以在規劃中做出適當決策的。
目前我的職位角色，還沒辦法那麼直接地接觸到使用者，所以不容易回答這些問題。但也希望在接下來了解這個領域生態的過程中，更加清楚使用者會有怎樣的需求、或是有機會在這個體系中和使用者直接接觸，讓自己的規劃不會流於其實偏差許多的想像。
除了產品的規劃，Value其實也可能影響著團隊合作
在最近的分享中，一位前輩說到希望工程團隊面對在做的產品，有不同的「心態」
他想說的這份心態，和Value的概念很像，希望工程團隊不只是把交辦到手上的待辦，當成不明所以的一項項獨立功能，只是把程式碼寫出來。因為當這些功能組合在一起時，其實希望的是幫助使用者達成一項「目的」，如果沒能多想一下、合理地將各個功能組合安排在一起，其實就很容易產出流程上卡關、驗收時不順利的產品。他也分享到，一些願意了解一下產品背後商業邏輯的工程部門，做出來的成品其實就很順暢，在自行QA檢測時，就能發現使用上不合理的地方並加以排除。
目前我還沒實際開始和跨單位的夥伴溝通，但也從這樣的案例，發現到未來在和整個團隊溝通專案的工作時，如何將專案的價值傳達給所有夥伴，相信也是重要的課題。
