背景
剛剛畢業半年，我在公司程式設計師馬拉松比賽中冒出了一個小小idea, 最後帶著團隊熬了兩天兩夜搞出來一個demo, 還幸運的拿到了二等獎。
後來領導決定讓這個idea變成公司常態化的業務，我也有幸體驗了一次專案經理。
在半個月的時間內，從最初的需求評審，到技術方案確定，到程式碼開發，到冒煙測試，最後終於加班加點讓專案如期上線。
這段經歷給我帶來最大的感觸是——從一個程式設計師到專案經理的轉變
從單兵作戰到團隊協助
這點是我感觸非常深的。
還沒畢業在學校時，往往會習慣了單打獨鬥，彷彿只要給我足夠多的時間，我就可以學會某一特定的知識點。
但是作為專案經理，我不僅僅要保證自己的產出最大化，還要思考如何讓整個團隊的產出最大化。
跨邊界非職權的領導力
作為專案經理進入一個新團隊的時候，你可以清晰的看到團隊中無處不在的邊界。雖然各個角色和職能是完整的，但是斷裂非常明顯，很難順利開展工作。這些接縫的地方往往容易出現問題，形成了一個個大家都避而遠之的坑洞。比如說，設計同學同學出完設計稿，上傳到共享地址裡面，就完成了他的職責。
從這個角度來說，“專案經理”其實是一個背鍋俠。
這個時候專案經理需要用自己的肉身，去把這些洞補上，成為那個跨越邊界的連線力量。
設計稿有問題？需求點頻繁變更？打點資料異常？ 這些問題不解決，專案就會推動不下去的，就必須把這些鍋背下來，去不斷的推進。
幸好團隊裡面的每一個成員都很給力，只要流程梳理好，劃分好職責和干係人，大家都傾入了非常大的精力和熱情，最終保證了專案的如期上線。
最基本的還是技術能力
作為專案經理，還是要好好錘鍊自己的技術深度和視野：
- 技術能力高，更具有話語權
- 技術能力決定了填坑能力，如果有技術難題無法解決，專案無法推進下去。
- 技術能力決心了技術選型的能力，前期的技術選型失誤，會導致後期專案可維護性差。
- 技能能力越多，越容易發現專案推進中的風險點。
暴露出來的問題
-
平時經常寫業務程式碼，對各種輪子的使用很熟悉，對頁面的效能很熟悉，但是對輪子的內部研究較少，對本質知識研究較少。
最典型的兩個例子：
- 不熟悉微信登陸體系和公司賬戶體系的登陸流程。平時只是呼叫api, 很少關心背後的流程。輪子要是出了問題，就兩眼一抹黑。
- 不熟悉垃圾域名系統。微信封了垃圾域名後，在更換垃圾域名的過程中暴露出很多問題。
解決思路：
- 不去寫重複的應用程式碼，去做新的或者更低層的程式碼研究。
-
由於開發時間緊張，自己關注於自己程式碼的如何實現，而對其他人的業務邏輯沒有梳理清楚。
印象深刻的是，被領導問到某一處業務邏輯時，不是很熟悉，場面一度十分尷尬。
解決思路：
- 需要熟悉更多業務和程式碼，不管是不是你寫的
- 多和其他同學溝通，瞭解他們的想法和思路
-
沒有藉助公司其他同事的力量。這點是非常值得我反思的，回想起之前的經歷，成長最快的階段，都是在同事們的幫助下和支援下。如果不熟悉輪子裡面的邏輯，可以找到輪子的作者聊一聊，如果不理解之前的業務，可以找當時的同事溝通一下。
解決思路：
- 三人行必有我師焉。遇到很難解決抓耳撓腮的問題，可能一個大佬兩句話就可以輕鬆解決。虛心請教不僅可以讓自己學到更多，也是對專案更負責的態度。