如何應對客戶頻繁但簡單的需求變動？

01-21

有這樣一個場景
客戶提出的需求，2天就能改完。但是客戶每半個月或者1周提出一次。這種需求又算不上新功能。只是原有功能的完善不算新增加功能。而且提出的也合理，修改後能提高用戶體驗。但這樣會增加項目成本和時間。如何避免這樣的情況呢？
在項目前期，應該如何避免這樣的情況出現。有哪些標準流程可以規避這樣的場景。

謝邀。

這樣的現象非常常見。我們可以分析一下產生這種現象的原因。用戶為什麼不一次將所有的需求都說完？很顯然他沒有這樣的能力或者說在項目開始的時候他根本也不知道自己最終需要什麼。需求的變更是貫穿項目始終的，是不可避免的，這隨著時間發展而必然發生的。

解決的方法有很多。不同流派的軟體過程都會有相應的滿足需求變化的內容。我談幾個我想到的關鍵詞吧：

延遲決策：在用戶確定他的需求之前不要替用戶做任何預先的決定，當你不明確需求時，很可能就是用戶將來需求變更的地方。

時間盒子：跟用戶做一個時間上的約定，在一個給定的時間內通常是一周到兩周不接受用戶的需求變更，但是在時間盒子的中間允許用戶提交他的變更。

變更成本透明：你需要準確的評估用戶需求變更所帶來的成本，並把這樣的成本準確無誤地告知你的客戶，讓他和你一起承擔由於需求變更所帶來的後果。

儘早交付：儘早讓你的客戶看到最終的軟體而不是需求規格說明書。除了最終的軟體之外任何文檔圖表都可能產生誤解，而誤解是需求變更的重要來源。另一方面很多需求的細化是在客戶看到最初的軟體原型後才會被提出的。

以上說的重要但不全面，大部分是敏捷軟體開發的核心內容。

1. 既然客戶提出的需求是合理的，也能夠帶來更好的用戶體驗，這樣需求做起來還是很有價值的。

2. 可以在討論需求的時候，提前挖掘下用戶的想法。在開發過程中也注意一些細節的問題。

3. 程序架構保留一定的靈活度，可以靈活的適應用戶的這種變化。

4. 加強和用戶的溝通，做好優先順序的排序。

其實這是敏捷開發會遇到的非常典型的應用場景，也有非常成熟的手段來處理。說到底的話，還是擁抱變化，和客戶溝通合作，做好代碼的質量，快速交付，快速響應。

需求變動都算入成本啊。

這種情況挺多，不是只有新功能才算需求，完善功能、易用性調整也算需求；既然是需求就應該增加工作時間，大部分情況下應該讓領導爭取到更多的開發時間

這個屬於項目變更的範疇。

成熟的公司，任何的變更都得遵循一定的程序。你說的雖然沒有增加新功能，但是模式有相應的更新，也屬於變更。

變更有很多來源，現在主要針對來源為客戶變更談一談。

在項目初始階段，就需要和客戶確定好項目範圍，這個範圍並不僅限定於功能，涉及到細節問題。如果敲定好的項目範圍，客戶要求改動，這個就可以商談：交付時間是否延遲，成本增加是否需要修改合同金額等。如果項目範圍之前沒有定好，這個待定的範圍是不用先做的，或者在項目初期項目經理就得預留時間和資金來應對這塊的變更，因為這個屬於風險管理範疇了。

一定的程序指的是什麼

謝謝邀請。

個人感覺主要還是商務層面的談判環節要把關好吧？

商務那邊亂放水，再猛的開發也未必堵得住的。