軟件開發難，恐怕大家都覺得最難的是搞清楚需求；但是其實更難的是管理需求。今天在北京.NET俱樂部上又有人提出了這樣的問題，主要的難點是他的開發團隊是為了自己的領導們服務的，幾個領導都有自己的想法，而且不停的在開發過程中提各種個樣的問題；開發進度無法保證，開發的結果總是滿足不了要求……
其實這樣的問題大家都遇到過，而對于普通的開發人員來說我們往往不去關心，認為這是項目經理的事情，但是其實不然，這樣的問題涉及軟件開發的各個環節，就算你是出于最底層的開發人員，一樣需要控制項目經理交給你的任務。其實這里最重需要把握的一點就是：把任務控制在你能控制的范圍之內。總結一下，我的經驗如下：
第一：無論你的客戶是誰，我們永遠需要一個中介來接受需求；你首先需要和客戶有個協議，需要他們制定某一個人來提所有的需求，這個人不需要是很高職位的人，而且往往最好的選擇是中層的技術管理人員；用戶的所有需求必須通過這個人的認可，就算是對方老總提出的要求，如果沒有這個人的認可我們也不執行。這點非常重要，可是替我們減少許多麻煩。
第二：無論是什么樣的軟件開發過程理論現在都承認一個問題，那就是軟件開發需要迭代。而且我們一定要面對一個現實，就是軟件開發的過程是在不斷的變化中尋找平衡的過程，我們的需求永遠不會結束，我們的軟件永遠都在被修改；修改不是壞事，但是我們必須要保證在一定的時候可以拿出成果。
所以，控制迭代的增量就是非常重要的。一般我們公司的做法是，以兩周為一個周期最為一個Release，一旦這個Release開始以后，任何用戶的新需求就都需要放到后面的Release；我們不會決絕客戶的需求，但是我們必須管理我們可以承受的進度。這樣做的最大好處在于，在兩周的時間內，我們一定可以為客戶提供一個更好的版本，這可能不是客戶現在心目中的最終結果（因為很多新需求都在后面的Release中），但是我們至少完成了我們在兩周前所承諾的結果，客戶得到他們想要的東西（當然不是全部），我們也可以很明確的告訴客戶，我們完成什么樣的需求。
而且在這樣一個迭代的過程中，我們會發現很多需求中的不完善之處，每兩周的時間我們都可以針對開發方向作相應調整。最終的結果是保證了客戶的滿意度，同時也保證了產品的按期交付。
在這里，我們需要明確的區分修改bug的需求和新功能的需求，bug應該是那些對軟件主要功能造成決定性影響的缺陷，這些東西無論是我們開發人員自己發現的還是客戶反饋的，都必須在當前的Release處理完；而新需求則必須放到后面的Release中去。明確區分這兩種不同需求對軟件項目的成功起到決定性作用。
第三：我們需要學會管理客戶。可能有人覺得我在胡扯，客戶怎么可能被管理，他們是上帝啊？？！！其實上帝也是人，而且是通事理的人。我們對客戶永遠不應該是100%的服從，正確的方式是控制用戶對開發進度的期望值，盡量使他們一致。當然有些時候我們需要更強硬一點點，比如我就經常很直接的告訴我的老板，這個需求屬于新功能，必須放到后面的Release中去。
English » | | | | | | | | |
Text-to-speech function is limited to 100 characters