二、區塊鏈身份驗證專案

在大學的專題做類似面向的，以一個剛成為PMP的我回顧當時在此專案兼任開發者與PM角色，如和將所學用在此專案上？

1.學生做專案的痛點

通常我們做專案最頭痛的工作是定義範疇。除了經驗不足之外，加之以專案採用的技術尚在發展階段（我們採用以太Solidity智能合約技術，在2017年才0.4.20beta版）。另我們都知道通常在實務上，專案時程往往被要求要壓縮，是很稀鬆平常的。一般，若是專案時程被壓縮，首當其衝的往往都是發展時程那邊要不斷去看壓縮時程，又不提高風險。因而，造成專案規劃欠周延、未完整之下，就趕著進入執行階段，讓專案團隊抱怨，讓上級或顧客抱怨，讓PM疲於奔命，軟體品質也同時因為不斷地進行趕工，造成品質低落，要花費更多的內部失效成本進行更改，以免被客戶拒收。

2.整合管理要做好，以達專案的逐步完善性

PMP的訓練提供了很好的啟發；我們可在執行專案前，從更高的策略高點來看。首先為專案團隊建立整個專案該如做專案的專案管理計畫書，接著告知團隊有任何問題就寫議題記錄，大家要一起管理專案知識，把學到的東西寫進經驗學習記錄表，如果遇到問題要改變作法或是客戶要增加功能，就一定要進行整合變更管制。

相信透過這樣的執行，也會讓學生團隊成為標準的業界專案團隊。（因為我現在帶的業餘專案團隊依此方式做專案，已成功結案3個超過50萬以上的專案）。

3.關於撰寫文件一事

在接觸專案管理的洗禮後，對於撰寫專案文件的時機與必要性思維更為清楚，內容的邏輯架構與鋪陳也能具層次感，透過「逐步完善」的專案規劃觀念，讓專案文件的內容時時保持為最新版本，特別是學生團隊很難集中辦公，透過選擇所寫好的文件可以幫虛擬團隊做好R&R之外，也能有文件來知道專案的狀況。

4.時程管理

當時做這個專題，時間是完全沒有彈性的，因為沒做完就不能畢業，因此在這個專案，第一重限制便是時程，再來我們都知道專案有六重限制，故其中包括範疇、品質、資源等面向皆須考慮，以確認這些限制不會使專案無法平順地進行，在定義活動這方面要考慮最多。

5.管理利害關係人參與

這個專案實際上是當時的指導教授與民間公司合作的一個專案，所以在關係人方面，除了要滿足民間公司對於身份辨識的功能需求與期望之外，也要主動蒐集並滿足教授對於專題要學生學會的面向，所以除了每週的進度會議之外，平日也要適當地與指導教授進行溝通，使教授對於專案進度感到放心，並且是專題成功機率提高。

即使是一個平淡無奇的功能開發，應用同樣的原理，向開發團隊蒐集需求，例如某位工程師喜歡寫一些可以炫技的程式的期望，將其適當地融合在開發中，也可以讓該成員更能參與專案。如此一來，花費時間經營關注利害關係人的參與，既省時，也能達到雙鸁的目的。

6.管理專案知識

專案期間應想辦法為團隊設計形成各種專案或技能知識之分享規劃，並且促動團隊其他人主動分享知識，除與專案團隊建立關係之外，也可以嘗試、感受衝擊。專案團隊可從分享、學習和互動環境中了解區塊鏈技術帶來的新的衝擊之外，並且知道如何讓專案團隊主動自我組織

7.管理團隊

即使是學生的專題，也是有許多溝通要進行，特別對跨技能間分工的灰色地帶，常會有同學互推責的情況，除了R&R要做好與調整之外，這時也可以使用衝突管理的技術來解決。例如：透過會議來降低將程式碼邏輯寫死的問題，提高軟體產品品質。雖然會造成工程師的反彈，透過「合作」的方式，例如告知該位同學如果好好的配合程式碼品質政策，可以減少麻煩等。我認為衝突管理可依事件的不同情況、專案團隊團員的性格，採用不同的策略來化解。

8.經驗學習

專題所做的發明或研究，通常都鮮少有過往的資料做參照，一來是學生沒有被教授要求，二是學生沒有做文件的習慣。當時在這個專案結案的過程中，我花了約10%的時間撰寫文件，其中包括製作未來可供參考的工作報告或文件範本。期許這些文件能使後來的人做類似專案能事半功倍，不因學生畢業時，沒有相關資料作為經驗傳承的參考，造成後手無前手的專案報告，發生嚴重的經驗流失。

結論

生活中，或是工作中，都可以應用專案管理的知識，將它們做的更好。回顧該次專案經驗，供大家參考我在專案中可以做什麼，希望藉此和專案管理的前輩們一同分享與成長。

>>點選連結，加入台灣敏捷部落大群，推薦人寫: Roger老師, 通關密語: TAT： https://bit.ly/3cLEhce

▲史荳芮頻道突破2500訂閱啦！快點擊圖片跟史荳芮分享你的心得！

感謝大家的支持讓史荳芮頻道訂閱數突破2500人，總觀看數時數突破4800小時！

能有今天的小成就都是因為有您的支持~希望藉由大家的學習經驗，給予真誠的回饋，幫助史荳芮頻道越來越好。