1. 程式人生 > >專案經理注意事項(2)——敏捷開發中的頭兒

專案經理注意事項(2)——敏捷開發中的頭兒

俗話說兵熊熊一個將熊熊一窩,跟對頭兒絕對是一件振奮人心的事兒。之前寫過一篇關於《專案經理注意事項》(千萬別要點)的部落格,當時所在團隊的開發模式是一般的瀑布模式開發,其實說白了就是類似於作坊式的開發,經理去和客戶談需求(我會告訴你主要是去談錢嗎?)然後拿回來一堆他(她)認為的需求就開始讓我們做了,很多時候無理的要求讓開發人員不知所措,比如說讓把網頁上的多選框顏色改變,或者選中的樣式從打鉤改成打叉。你跟他說這是html這個語言內部的規定,不同的瀏覽器解析出不同的結果。(其實後面這半句是演到肚子裡的),他(準確的說是她)會給你扯你的水平問題。

其實遇到不懂技術的經理也有好處,具體的理由就不在贅述了,可以參考之前的《

關於專案經理不懂技術》。自從換了團隊,換了不同的開發模式,不得不說敏捷開發的確是目前最好的模式沒有之一。但是相對的,敏捷開發對人員的要求也高了很多,一個開發人員應是多面手;對應的,一個敏捷團隊的領導者絕不僅僅是領導者。他應該具有一般領導的特徵再加上敏捷當中領導的獨有屬性。用計算機的語言描述就是:敏捷開發當中的領導extends一般領導。

對專案——明若指掌

其實這是父類的一個屬性,一般的組長都會知道系統的核心,至於細枝末節的東西可能不甚瞭解。但是對於敏捷開發來說這是萬萬不行的,因為雖說敏捷開發中用例是估點兒得來的,但是大部分用例的粒度卻是組長決定的,一個20天的工作量愣是給拆分了兩個用例,你說讓開發人員怎麼進行估點兒?更恐怖的是在真正動手實現之前開發人員是不清楚這個用例到底是幹嘛的。這就好比是一群瞎子在聊從回龍觀到亦莊需要步行多長時間一樣,這種不瞭解細節盲目設計用例粒度的行為讓“估點兒”變成了一個擺設,沒有絲毫的作用。最終的結果只能是分解用例不合理,專案進度把控的不準確。

對下屬——打成一片

相信很多組長都有著傲人的氣勢,有著不可比擬的優越感,這完全可以理解,因為手下有兵了嘛!幹活不用自己動手了,可以對別人指手畫腳了。於是淘寶、論壇、微博成為了時間的主要消費物件。弟兄們乾的帶勁,你消遣的優哉遊哉,難免會引起民憤。

首先肯定的是每個敏捷開發當中的組長都不是空降的,但是如果成為領導之後不再關心技術那麼和下面的關係就會越來越遠系統的實現上上也會被架空(其實這個時候與空降的領導就沒有什麼區別了),導致上面說的,分解用例不合理,專案進度把控的不準確。更重要的是你手下的兵會有情緒,再往後就是眾所周知的三部曲了:要麼忍,要麼狠,要麼滾。

“或勞心,或勞力;勞心者治人,勞力者治於人;治於人者食人,天下之通義也。”——《孟子˙滕文公上》

對事——有責任,有擔當

按照正常的流程實現是在需求被充分理解之後才能開始的,但是世界上哪有那麼多正常的流程,不正常是常態。由於開發人員在敏捷開發當中擔當了設計+實現的角色,所以很多時候都會遇到開發人員實現完成後與需求大相徑庭,開發人員可能會抱怨(這不是一個優秀的開發人員)於是類似下面的話出現了。

“啊?原來需求是這樣的啊!那這怎麼實現啊”

“你問我,我哪知道”或者“你隨便,我不管”

這種及其不負責任的話只會讓幹活的人心裡罵娘,起不到一點點兒積極的作用。你可是組長啊,你怎麼能不知道,你怎麼能不管!難道你的任務僅僅就是催促進度?“你這倆用例今天能做完嗎?”“這個星期能把你頭上的bug修完嗎”做完你妹啊,修你妹啊。遇到了困難不敢面對,遇到責任不敢承擔,這樣的頭兒不跟也罷。

最後

看過一個很經典的關於領導力的視訊,領導絕不是隻分配任務,領導是將自己的能力放大,那麼怎樣才能放大?

第一種領導:“***你這麼聰明你把***做了吧”

下屬的感覺:我要是真如你說的那麼聰明我就代替你了,還用你來指揮我?

第二種領導:“***你去做一下這個吧,做的時候可能會遇到***問題你可以去***網站上查一下資料,解決不了咱倆再一起研究一下。”

下屬的感覺:淚奔哇~