1. 程式人生 > >淺談團隊專案管理

淺談團隊專案管理

我的工作經驗其實算不上長,但呆過的團隊其實挺多了的了。在我看來一個團隊是否有戰鬥力,或者說是否能夠做事情,領導者很關鍵。一般網際網路公司,以專案來劃分的話,這個所謂的領導者,也就是pm,當然我指的是Project Manager,而不是產品經理。

確實,如何將不同崗位不同性格的人撮合在一起,讓他們一起去做一件事情來創造這個團隊該創造的價值是件聽上去很簡單但做起來還是很麻煩的事。接下來就談談我作為一個團隊主要成員這幾年所看到的以及一些想法,有些地方可能純屬yy ,僅供參考。

好多PM 都是技術出身,技術出身的有很多情況下就會都有一個通病,就是瘋狂的專注於技術,對業務瞭解程度也還算深,但很多時候在業務邏輯,或者頁面邏輯上就會更多的從技術程度去考慮,效能方面考慮,而對一些產品邏輯問題置若罔聞。之前有次跟朋友閒聊,他跟我說他們pm 就是這種,平時工作就是哪裡不會幫哪裡,哪裡出bug 了修哪裡。從技術角度來說,這是個全才,但我覺得從團隊本身來說,這有很大問題。團隊之所以為團隊,區別於個人,因為他有各方面專業得人存在。leader不應該是幫成員擦屁股的存在,而是需要更好的去規劃統籌。在我看來,pm 應該更關注於產品本身,一個團隊存在的根本意義就在於做出來的產品,一本書裡是這樣定義的,產品是能夠提供給市場,供使用者使用或消費,同時為企業帶來盈利商業價值的東西。如果一個產品做得不好,首先背鍋的肯定是pm。所以在我看來寫程式碼的pm做得遠遠不夠。

時間,這個在網際網路行業中很關鍵的東西。網際網路行業日新月異,誰能夠在更短的時間裡把自己的idea 落實做出來,誰就有可能在市場上佔據先機。產品是允許犯錯的,但是怎麼樣在最短的時間內把嘗試的錯誤修改回來,就是一個問題了。我喜歡時間觀念強的人,說了什麼時候上線就什麼時候上線,但我又不喜歡讓我自己來根據需求評估時間。在我看來,人都是有惰性的,自己評估時間肯定會給自己留有比較大的餘地。這裡我就很喜歡之前leader 的做法,在一個迭代週期開始之前,他會根據需求優先順序的排列,羅列出團隊裡各個成員在這個迭代期要完成哪些東西。這裡其實就需要pm 再各個方向上的專業技能了,排太緊會造成團隊負面情緒爆炸,排太送不利於專案本身。而且我個人建議是先緊後鬆的狀態,pm先把迭代需求排得緊一些,看看團隊得戰鬥力,然後再進行適度的調整,經過一段時間的磨合調整,肯定是效率不斷提升的過程。

團隊之間的配合也是很重要的,1加1不一定等於2,人多了溝通成本也就上去了。對於一個正常的開發迭代來說,工作其實是階梯式的下去的。產品提出需求,需要設計就交給設計去畫圖,然後交給研發,研發完成了交給測試提測以及產品ui 走查。這中間就會出現一個問題,就比如測試資源就會出現在一個迭代週期裡先鬆後緊的狀態。前面幾天工作就像天堂,後面幾天工作如同地獄,這樣子的節奏絕對是不利於團隊和諧的。所以怎麼樣讓研發小而靈活的提測也是pm 要考慮的問題之一,至於產品和設計在我看來是另一個迭代,跟研發週期措開,不同的節奏能確保所有人的節奏都能保持平穩,也不會出現資源浪費的現象。

當然,成員間坦誠相待是有必要的。就跟戀人一樣,我一直覺得兩個人之間相處,如果出現問題,就直接說清楚,否則藏著掖著反而會使矛盾激化,越來越嚴重。團隊之間也是一樣的,適當的開迭代總結會,大家說出迭代得問題,有什麼不爽的地方都心平氣和的說出來,然後提出大家都認可的解決方案,不僅能讓團隊成員之間更和諧,而且會更有戰鬥力。到也要注意開這個會的頻率,多了也可能造成負面影響,過猶不及莫。

阿里文化裡總是談到這麼一個詞,補位,也就是說你不光自己的事做完了就可以了,也要去關心幫助別人的事。其實在我看來這只是中國傳統美德罷了,互幫互助。leader可以去在團隊裡形成這麼一種文化,精神食糧還是必須的嘛!在產品這塊上,這一點尤其明顯,當然這樣子也會造成一種情況,就是每個人都有自己的看法,經常會出現僵持不下各有各自看法的情況,這個時候leader要做的就是做一個拍板人,做決定。

最後來談談人,人的性格很關鍵。有句話是這麼說的,決定一個人是否能夠取得成功智商不是關鍵,情商才是關鍵。人總是喜歡跟情商高的人來往,因為謙讓禮貌,很舒服。所以我覺得招聘的時候專業技能並不是關鍵,是否跟團隊裡的人適合並且處得來尤其關鍵。當然,如果有個逗比那就錦上添花了,無論是工作還是生活,總是需要這類人給我們帶來快樂的。

總的來說,我認為一個好的pm所要做的就是明確權責,建立團隊間的溝通渠道,建立工作基準個目標,制定可行,餘地的工作計劃,並對計劃進行溝通,檢查,反饋,分析,對風險點進行溝通,評估,調整,並對一些突發情況進行解決等。

一個狼性的團隊,首領很關鍵。深夜yy一波,發表些想法,希望以前的領導看到了不會打我,哈哈。

我的微信公共賬號, 歡迎關注