第一次體驗專案管理

我是去年剛剛畢業的，畢業之後從事的是“軟體開發工作”，作為一個女生，在一般人看來做“開發”是很累而且沒什麼前途的，不過從我入職到現在，將近一年的感受來說，感覺作為開發並沒有“普遍”認為的那樣辛苦，當然在大學中的基礎知識不夠紮實，確實為工作帶來了很多困難，不過隨著攻克每一個困難，自己的知識和技能都有了很大的提高。

作為一名女程式員，我給自己的定位是向“專案管理方面”發展，但是作為剛剛入職的人員來說，這樣的機會是很少的，一般情況下都是做一個大型軟體或者項目中的一部分，所以很少有機會體會項目的管理，不過幸運的是，又到了一年一度的畢業季，一大批剛剛畢業的學生來公司實習，我和另一名同事負責我們部門的畢業生的項目實踐環節，主要涉及到“講解任務”、“人員安排”、“工作迭代安排”及“團隊組建”等工作，實在是體驗了一次“專案管理”。

在做這件事的時候正好自己也在看相關方面的書，於是“專案計劃”、“專案管理”、“項目品質”以及“項目風險”等內容就在實際中驗證了一下，總體來說還是給了一些指導的方向。但是真實的項目中有很多事都需要考證，不能盲目的決斷或者依靠自己個人的經驗。

舉一個很小的例子，當時“項目實踐”最初的計劃是30天，後來由於時間有變，將30天縮短到25天，由於開始我們進行了時間上的風險預估，所以當得知時間有變時，感覺自己已經做了這部分的考慮，而且自己稍微審查了一下安排，覺得沒有改的必要，實踐的結論就是，時間變化還是帶來了任務量的緊張。（期間，我們的部門經理還特意告知，時間的變化，就一定要仔細審查任務——這就是經驗啊！）

說一下項目的相關情況，項目是實現一個思維導圖一樣的協助人們梳理思路的軟體（和Xmand很類似），最初的想法是實現和xmand一樣的簡潔的圖形化的操作，後期由於人員對於這部分知識掌握程度不高以及時間上比較緊，選擇了替代方案，使用表格來梳理思路。項目最終在規定的時間內完成了，雖然有些指標可能沒有達到，但總體來說達到了預期對人員培養的目的。

項目中感觸最大的就是交流問題，技術什麼的都是可以找“大神”協助的，但是“團隊的建設”是誰都替代不了的。

項目中出現的最嚴重和最頻繁的問題有如下幾個：

（1）有組長，安排我幹什麼就幹什麼；出現什麼問題組長會承擔責任，與我無關；反正問題和組長說了，組長解決不解決，無所謂了

（2）我比較內向，別人怎麼說我就怎麼做吧；別人的想法不是最好的方案，算了，就這麼做吧，大家都覺得可行

（3）別人的技術或者想法都沒我好，我拿主意吧，需要誰幫忙就誰幹；我的技術痛點，別人研究解決就行，其他的我全權處理

（4）彙報任務時，理想狀態比較好，就這樣彙報了，實際執行產生了拖遝；每天的任務可能完不成，一直堆積，進度不斷拖延。

（5）明天審核代碼，今天就是簡單整理代碼或者修改bug，任務進度先都放放

（6）bug1好改，我改bug1，另一個也改bug1，結果兩個人幹了同一件事情，分工不明確；沒有很好的項目組態管理

（7）這部分代碼實在想不懂了，寫不下去了，那也不找別人，自己慢慢幹

其實這些問題都是團隊建設不好或者是任務宣貫（目標宣貫）時沒有達成統一心態的原因，如果是一個已經親如兄弟的團隊，沒有了責任的推卸，每個人都以高品質的完成任務為目標，結果肯定不會是這樣，當然其中也需要一些方法或者制度，例如bug修改這樣的，需要有bug的管理制度。

後期，我們的逐個面談、平時交流時針對於每個人的問題有意識的點出，的確有所改善，慢慢的隨著彼此的熟悉，團隊中形成了一種比較好的溝通方式和工作、學習氛圍。

這裡還要提出的就是自己在整個項目期間做的不是很好的幾點：
（1）沒有及早的將發現的問題解決：有些人可能暴露了問題但是有些人可能沒有暴露，但是問題存在，所以應該發現問題就及時解決，就像編程中的“壞味道”一樣

（2）沒有及早的建立和團隊成員進行交流，較早和及時的交流，能夠調整團隊成員的心態，和對待項目的認知，同時能夠更好的讓團隊成員融合在一起

（3）沒有很好的建立獎懲機制

（4）由於自己對項目瞭解也不是很深入，有時給出的需求比較模糊，導致任務拖延

（5）項目中對於每一個迭代中任務的監控不是很到位，發現了問題沒有及時說明，或者是對於制定任務或者人員安排時沒有自己進行事前的預估和計劃

（6）沒有很好的掌控時間，當出現一些特殊情況時，沒有及時反饋

當然現在這些問題在項目期間就找到了相應的辦法或者有了應對策略，不過發現的比較晚，所以任務總體上還是有了一定的拖延。

這是我第一次接觸“專案管理”的一些感受，與大家分享，有什麼不準確或者錯誤的地方，望大家批評指正。