一、使用敏捷開發
敏捷開發，這是現在非常時興的一個詞，聽起來挺牛的，敏捷，讓我們感覺用了它就會“快”。在被這種開發模式折磨了一年多的我想說，其實它跟其他所有的事情都一樣，它有自己適用的領域，假如錯誤的以爲任何專案用敏捷開發都能敏捷，那就是自找苦吃。
爲什麽？敏捷開發的特點就是根據用戶的需求迭代，一個迭代解决一個迭代的問題，對於一個對於架構清晰的專案來說，這樣每一個迭代都會有一些成果。而對於有些專案而言，比如說殺毒軟體，磁盤分析器等等，對於這種産品類的專案，很多時候它的需求都是一開始需要定義清楚的，客戶名義上是廣大的PC用戶，實際上是PM或是PGM，PM說這個專案裏面我們要做3個功能，那我們就需要做3個功能，多一個不行，少一個也不行，如果PGM在你做了3個功能後告訴你，要加一個功能，而且這個功能在舊的架構上是很難實現的，那麽這個PGM就是不合格的，爲什麽？因爲他加大了專案的成本。
所以，我想說的是，如果需求是由我們自己定義，而且我們很清楚要做一個什麽東西的時候了，采用敏捷開發的風險可能會加大，因爲它過多的依賴於“迭代”，認爲迭代可以解决大多數的問題，可是實際情况遠不如此樂觀!當你的PM對你我們要加這個新功能，之前的定義的功能不行這個迭代要改的時候，作爲一個程序員，我們能做什麽呢?去跟PM說，對不起，我們之前的底層架構不支持這種變態的需求，PM會告訴你，我就是代表客戶，這個功能就得這麽做，我說了算，爲什麽不支持，我們不是採用的敏捷開發嗎，敏捷開發的特點不是迭代來解决問題嗎?
老實說，瀑布模型的好處之一，就是你的PM可以少幾個變需求的理由，PM一個星期變一次需求，我們程序員就沒有幸福可言了，所以，我想勸有些專案經理，別拿需求的變更當做理所應當的，你不是一個嬌生慣養的小孩，沒有必要變的需求就不要變，如果你把敏捷開發的需求變更當做是你隔三差五變需求的理由，那下個專案，當你的程序員聽說你要用敏捷開發，肯定想抱頭痛哭。你是産品的設計師，這個産品的外觀功能，應該一開始就定義好，不要前一個月說要做個電飯煲，這個月又說要在電飯煲加個微波爐的功能，如果你手下的程序員任勞任怨，把微波爐的功能真的加進了電飯煲，那只能說PM幸運，碰到了技術牛人，並且技術確實是可行的，但是如果功能實現不了，那麽PM可能就怪開發者，覺得他們技術不行，心想我用的是敏捷開發，爲什麽我給了你們時間缺不能解决問題呢？
時間確實是可以解决問題，但是作爲開發者更希望把時間多花在需求分析階段，而不是修改舊的代碼上。開發模型只是一種工具，依賴敏捷開發這個工具，並不是解决所有問題的萬金油。
作爲專案經理，你不光要對客戶負責，更需要對産品負責，對你手下的程序員負責。其實，假如做不到後面兩點第一點也不好做到，因爲專案很可能經常delay，到最後客戶不滿意，或者産品上綫的時候早已經落於市場上其他的産品。
二、角色分配
角色分配的問題在整個軟件開發過程也是很重要的，說簡單點就是分工要明確，按照博弈論的觀點，假如我們每個人的目標都是合理的，那麽我們通過相互的制約很好的推進專案的周期，但是如果角色分配的不合理，比如說職責重複，缺少角色等等，那麽開發的過程中就會遇到很多利益衝突，解决不好，就容易導致團隊不和諧，沒有凝聚力等等，最嚴重的情况就是大家各自爲政，都聽不進別人的意見，大家都是會爲別人著想的人，但是有時候想得太多，總是會覺得不合理，不公平，難免影響工作情緒。
在我現在這個專案就有類似的問題，首先，就是沒有一個架構設計人員，經驗豐富的開發和經驗較淺的開發做的事情是差不多的，整體架構的設計名義上是大家一起來做，但是在開發過程中就發現了問題，對於一個架構變動，沒有人有决策能力，TM只會說，有問題跟我說，然後你發現了問題告訴他，他却不知道和誰來商量，經過和一個個的開發者進行了討論，認爲這個架構的變更確實是必須並且可行的時候又要開一次會，來討論怎麽來做這個變更，由誰來負責這個變更，所以說，SD是必須的。而在一次會議上我聽別人說做SD必須要有10年的經驗，我覺得有點可笑，有很多優秀的開發在很早就做上了架構師，我認識的人裡面就有一個，其實我覺得邏輯思維能力較强，有整體架構思想，並且對專案中使用技術有一定研究就可以做SD了，倒是我不明白現在爲什麽很多軟件公司都特別在乎工作年限，認爲做了10年IT就是萬金油了，什麽事情都可以解决，真是大錯特錯。
ˋ
我認爲，做什麽事情都有一個精與不精的區別，假如那句什麽語言不重要，重要的是思想，一通百通的話我覺得真是沒什麽意義。我們都知道C和JAVA.NET的側重點不一樣，一個偏向底層，一個偏向應用，讓一個做C做了10的人去做一個網站可能都做不好，爲什麽?因爲他沒有對網站應用根本就不瞭解，用戶需要什麽他都不知道，他腦袋想的只是如何使用戶體驗更加的絢，但是卻不知道網頁上能不能實現這個效果，網頁上上傳做個進度條能不能實現，實現的難度大不大，他都不知道，這樣的架構師能做好網站嗎。同樣讓NET程序員去做JAVA的事情也不一定做的好。聞道有先後，術業有專攻，這句話是有道理滴。
角色分配的問題還體現在我們不能越庖代厨，如果你是RD，你就不要過多的去擺弄需求，覺得需求不該這麽做，因爲這個問題不該你想，想這個問題只是浪費時間，如果你是PM，你就不要過問架構和技術細節，因爲你始終不如開發瞭解實際的問題，如果你是一個做了十幾年開發的PM，自己手下的技術不如自己，硬要按照自己的想法去做事，那麽不要做PM，你可以做個SD。我以前就碰到過這樣一個PM，讓我去做一個圖片處理的程序，他想讓我把一張圖變清晰，我覺得一張從100K壓縮成了10K的圖你還想讓他變清晰仿佛是不可能的事情，用脚趾頭想問題也知道那丟的90K是幹什麽的，PM要我多測試幾次，經過測試確實是不可行的，但是PM不相信，因爲他做了一年多的開發，於是中午不吃飯跑到我的機器上寫代碼，口中還念念有詞的，等我吃完飯睡好午覺，他終於認輸了，雖然如此，但是從這件事上我就覺得有點不痛快，多的就不想說了。
文章截錄：中國項目管理者聯盟
ProjectClub 專案俱樂部為一群專案經理人組成的平台，網站分享專案運作的各種專案管理手法與實用專案工具，並分享如何提昇職場人的軟技巧與硬實力。
