第一次作項目經理的感觸和啓發

背景

剛剛畢業半年，我在公司程序員馬拉松比賽中冒出了一個小小idea, 最後帶着團隊熬了兩天兩夜搞出來一個demo, 還幸運的拿到了二等獎。

後來領導決定讓這個idea變成公司常態化的業務，我也有幸體驗了一次項目經理。

在半個月的時間內，從最初的需求評審，到技術方案肯定，到代碼開發，到冒煙測試，最後終於加班加點讓項目如期上線。

這段經歷給我帶來最大的感觸是——從一個程序員到項目經理的轉變

從單兵做戰到團隊協助

這點是我感觸很是深的。

還沒畢業在學校時，每每會習慣了單打獨鬥，彷彿只要給我足夠多的時間，我就能夠學會某一特定的知識點。

可是做爲項目經理，我不只僅要保證本身的產出最大化，還要思考如何讓整個團隊的產出最大化。

跨邊界非職權的領導力

做爲項目經理進入一個新團隊的時候，你能夠清晰的看到團隊中無處不在的邊界。雖然各個角色和職能是完整的，可是斷裂很是明顯，很難順利開展工做。這些接縫的地方每每容易出現問題，造成了一個個你們都避而遠之的坑洞。好比說，設計同窗同窗出完設計稿，上傳到共享地址裏面，就完成了他的職責。

從這個角度來講，「項目經理」實際上是一個背鍋俠。

這個時候項目經理須要用本身的肉身，去把這些洞補上，成爲那個跨越邊界的鏈接力量。

設計稿有問題？需求點頻繁變動？打點數據異常？ 這些問題不解決，項目就會推進不下去的，就必須把這些鍋背下來，去不斷的推動。

幸虧團隊裏面的每個成員都很給力，只要流程梳理好，劃分好職責和干係人，你們都傾入了很是大的精力和熱情，最終保證了項目的如期上線。

最基本的仍是技術能力

做爲項目經理，仍是要好好錘鍊本身的技術深度和視野：

1. 技術能力高，更具備話語權
2. 技術能力決定了填坑能力，若是有技術難題沒法解決，項目沒法推動下去。
3. 技術能力決心了技術選型的能力，前期的技術選型失誤，會致使後期項目可維護性差。
4. 技能能力越多，越容易發現項目推動中的風險點。

暴露出來的問題

1. 平時常常寫業務代碼，對各類輪子的使用很熟悉，對頁面的性能很熟悉，可是對輪子的內部研究較少，對本質知識研究較少。

   最典型的兩個例子：

   • 不熟悉微信登錄體系和公司帳戶體系的登錄流程。平時只是調用api, 不多關心背後的流程。輪子要是出了問題，就兩眼一抹黑。
   • 不熟悉垃圾域名系統。微信封了垃圾域名後，在更換垃圾域名的過程當中暴露出不少問題。

   解決思路：

   • 不去寫重複的應用代碼，去作新的或者更低層的代碼研究。

2. 因爲開發時間緊張，本身關注於本身代碼的如何實現，而對其餘人的業務邏輯沒有梳理清楚。

   印象深入的是，被領導問到某一處業務邏輯時，不是很熟悉，場面一度十分尷尬。

   解決思路：

   • 須要熟悉更多業務和代碼，不論是不是你寫的
   • 多和其餘同窗溝通，瞭解他們的想法和思路

3. 沒有藉助公司其餘同事的力量。這點是很是值得我反思的，回想起以前的經歷，成長最快的階段，都是在同事們的幫助下和支持下。若是不熟悉輪子裏面的邏輯，能夠找到輪子的做者聊一聊，若是不理解以前的業務，能夠找當時的同事溝通一下。

   解決思路：

   • 三人行必有我師焉。遇到很難解決抓耳撓腮的問題，可能一個大佬兩句話就能夠輕鬆解決。虛心請教不只可讓本身學到更多，也是對項目更負責的態度。