首先：歡迎來到我喜歡稱之為“現實生活”的這個小東西。

軟件開發人員總是說，在我們開始一個項目之前，應該從詳細描述中完全確定所有要求。篩選模型的算法，一旦開始開發工作，就不允許進行任何更改。產品交付時，我們當然會糾正與書面要求的任何偏差，但不允許進行涉及要求變更的更改。

是的，這將使軟件開發人員的工作變得更加輕鬆。這是一個荒謬的需求。

想像一下您想購買一輛汽車。因此，您去找汽車經銷商，發現那隻是一個辦公室，一個人在桌子後面。他遞給您一張白紙，說：“在這裡寫下您想要的汽車。我們會找到一輛符合這些要求的汽車，並將其交付給您。一旦您簽署了該文件，我們就會開始搜索對於汽車，因此在那時不允許更改。” “但是，”您說，“我對自己想要的東西有一個大致的了解，但是我當然希望嘗試一些不同的汽車，將它們用於試駕……”“不，對不起，”他說：“這不可能。只要寫下您想要的東西，我們就會為您提供符合這些要求的汽車。”

現在，假設您最重要的是您從未駕駛過汽車。在嘗試之前，您怎麼會知道想要什麼？在紙上看似好主意的事情在實踐中可能效果不佳。

我不會擔心含糊的要求，前提是每個參與人員都知道這些要求含糊不清，將不得不填補空白，並且當他們看到您做出的決定時，將會有一些他們不喜歡的決定，並且必須重新做事。

如果這是一個寬鬆的合作環境，應該沒有問題。您產生一些東西，將其帶去檢查，他們告訴您他們喜歡什麼，不喜歡他們，您進行更改，也許要經過很多周期。我一生中做過很多這樣的項目。通常，用戶必須試用該軟件才能查看實際可行的方法和無效的方法。

如果老闆或客戶提出了不合理的要求，或者您不知道所處的環境是什麼例如，那麼您需要以書面形式保護自己。我一生中做過一些項目，老闆或客戶說：“我不知道所有要求是什麼，您只是做了些什麼”。然後我整理了一些東西，當我把它拿回來時，他們大喊：“什麼！那不是我想要的！你是什麼樣的白痴？很明顯……”，然後繼續提出一堆要求他們以前從未提到過，這對我來說一點都不明顯。在這種環境下-即使沒有大吼大叫，沒有解僱或取消合同的威脅，也許這只是嚴重的失望和沮喪的表情-在這種環境下，撰寫一份描述您打算做什麼的論文，退還給他們批准。如果幸運的話，這將引發對真正需求的討論。在最壞的情況下，他們說“是，是”，然後將其清除。但是至少在此刻，當您再次使用該軟件時，如果他們說“那不是我們想要的”，您可以帶回該文檔並說：“哦，對不起，這就是我們所同意的我應該做。看，它寫在這裡，您已經批准了。”在友善的環境中，您以友善的方式講；在敵對的環境中，您可能必須變得更有力。然後，無論哪種方式，您都說：“好的，您要對需求進行什麼更改？”然後將這些內容寫成書，開始另一個週期。

如果老闆或客戶期望不可能的周轉時間，並且在無法滿足不可能的要求時責怪您，那麼坦白地說，該是時候開始尋找另一份工作或另一位客戶了。或者，如果您非常急切地需要這份工作/客戶，則將其吸納並加以濫用。 （我很想起我老闆問我將公司幾年前建造的大型，複雜系統從一台舊的計算機語言轉換成一種現代語言所花費的時間。我開始嘗試大聲思考一下，我們在另一種產品上做了這樣的翻譯，因此我們有了一些經驗，但是今天公司中沒有人熟悉這種產品，等等，然後他說：“我不需要確切的答案，大概：兩天還是三天？”我很吃驚，“嗯，不，”我說，“問題是多少個月。”他走了喃喃自語。）

您需要後退。在他們的日曆上獲取時間。問問題。問很多問題。問很多問題，他們會厭倦您，並會提供您所需的詳細信息。

如果他們不知道，請提出具體要求並獲得批准。記錄他們的答案，並將答案發送回給他們進行確認。這清楚表明，改變和拖延的原因是他們改變了主意，而不是您的發展。

當他們說“以自己的方式構建”時，他們真正的意思是“做我能做的事看看並改變。”在實施需求之前修改和更改需求要容易得多。

通常來說，當客戶需求非常模糊時，您應該做的是寫下您要做的事情（即技術和功能規範），並讓他們驗證文檔 ​​em>。這樣，如果他們想在項目中進行某些更改，您可以指出這不是商定的，並為此收費。至少同樣重要的是，他們不能以“錯誤的方式”怪罪您。

如果您的項目不太高級，我仍然會盡力做到這一點。短期來看，這似乎是時間上的損失，但它將使您無法實施更改。

如果您快要完成了（顯然要丟棄無數即將出現的更改），那就更複雜了。您正在這裡查看損害控制。讓您的經理最好以書面形式承認這一點。如果項目變得非常混亂，您就不想成為替罪羊。

說穿了，對我來說，這似乎很差。我會和經理談談以避免將來發生這種情況

Marv，我認為​​這些答案大多數都是多餘的。

這不是軟件開發的現實。造成的結果是，對軟件商店的管理不夠好。

需求不是答案，因為需求會發生變化。無論是因為人們簽字同意改變了主意，還是因為他們一開始都不了解想要的東西，這是無關緊要的。甚至企業本身也可以更改優先級，從而迫使需求發生變化。

似乎只有一個人建議敏捷。這是一個好的開始，但是敏捷需要很多人的支持，而這些人必須要做家庭作業。顯然，您不是與不想做家庭作業的人一起工作。

因此，請向Agile借錢。讓這些利益相關者參加對話，以推動故事的創建（ http://www.mountaingoatsoftware.com/agile/user-stories）。將這些定義保留為他們的語言，以便在3個月後進行審核時不會混淆他們所同意的內容。期望進行幾輪的故事製作，一開始將它們保持在高水平/廣度，然後根據需要將故事分解為較小的故事。較小的故事意味著更好的工作範圍，並有助於解決問題。

為您提供了一系列故事，這些故事足夠小，可以讓您進行合理的估算，無論制定什麼項目，您都可以製定時間表並確定優先級有多少利益相關者提供幫助或不提供幫助。確保故事以透明的方式存儲。當人們希望您從“按故事行事”轉變時，然後退後一步。

樣機，提案，PoC，一切都很好，但即使它們也必須來自了解您將要謀生的東西。否則，它只是在黑暗中拍攝，相信有一天您會受到打擊。解決問題吧，如果他們自己不會解決問題，請為他們提供故事板。

“早期失敗，經常失敗。”

當您有最低要求時，請構建一個最小的系統，然後進行展示。始終演示它及其功能，並要求並期望反饋會改變您的軌跡。

是的，許多開發人員都喜歡您想要原始的規範，然後他們會去塔樓，還有一些時間到了，執行正確的方法，準備接收下一個項目。

但是，您已經加入了一家公司和團隊，而您卻希望他們以最少的投入運行，慢跑一點，然後回來問題和演示，然後再慢一點。

此過程的效率低下。但是通常業務需求和需求決定了它。如果他們等待創建完美的規範，那麼該項目將無法及時完成，並且仍然需要進行修改，因為沒人能預測未來。

迭代開發可能不是您的理想之選，但是，您會發現，它比完善的規範開發要普遍得多。

溝通，頻繁的用戶/客戶/主管測試和反饋以及願意隨風而動的意願將成為一項出色的技能。開發它們就擁有了。

在開始一個項目時，您對該項目的了解最少。您的項目的使用者也至少知道他們對此一無所知。

他們可以為您提供“天空中的餡餅”，“這是我認為應該做的，這就是我的方法希望它做到”，但是很有可能它們是錯誤的，特別是在細節上。繼續努力，幾乎可以肯定，您將不會遵循該計劃。零件將比您想像的要難或容易，其他零件將變得毫無意義，而當您從事該項目時，您將在該項目中獲得專業知識。

A一周後，您將對計劃有個更好的了解，並進行很多調整。一個月後，您可能會認為您的計劃很愚蠢。

您的客戶/老闆對他們想要的東西有所了解。他們不是他們想要做的事情的專家：充其量是知道如何解決類似問題的通才，但是要成為創建軟件專家的唯一途徑是創建軟件。如果他們已經創建了該軟件，那麼他們將不需要您。

您的工作是成為創建軟件的專家。最初，該軟件的功能將變得模糊。他們並不真正知道，而您也不真正知道。因此，您需要進行迭代：確定您認為他們想要的東西，詢問他們是否認為合理，然後實施並儘快獲得幫助。根據他們是誰，您可以拋光不同的零件，而保留其他零件未加工。

然後您將獲得反饋。他們會喜歡某些部分，認為其他部分是垃圾，並認為其他部分會浪費時間。開始工作之後，您就更改了軟件-也許您甚至放棄了工作並重新開始（因為現在您在編寫第一部分方面的專業知識變得更好了-您剛剛做到了，並且您可能從中學到了一些東西）並得到了到同一點的速度更快-或者也許只是對其進行調整併添加他們喜歡的東西，然後更改他們想要的東西。

當他們獲得反饋時，讓他們說出他們想要的最重要的東西改善。把它寫下來。詢問更重要的內容（在有序列表中獲取）。假設您在一兩天內會收到原型估算值，並與他們聯繫。猜想將所需的前幾個功能原型化所需的時間，請問他們是否滿意，可以準備在X天內向其中一個頂級功能展示原型（不包括成品版）（包括錯誤緩衝）他們想要的兩件事。

然後向他們展示您的原型，詢問他們是否要完成或從解決方案中刪除。根據他們是誰，您可能希望通過應用程序的行為來明確說明它是原型。到這個時候，您應該已經知道拋光原型需要多長時間。他們可以在“完成”之前要求進行更多更改，或者可以要求對其進行拋光。如果他們要求更多更改，請回到之前的優先事項。

這基本上是開發人員驅動的敏捷，您可以在其中積極地與您的消費者/老闆進行交易。他們經常獲得原型，並被要求經常提供反饋。您必須確保如果他們不要求您拋光任何原型，並且他們知道您的原型離完成的功能還差的話。

這樣做，隨著您開發應用程序，您在編寫應用程序方面的專業知識將會增長，並且他們對真正想要的東西的理解也會增長。

如果您事先要求一個完整的規範，則在之前做出決定，然後知道什麼有效，什麼無效。

軟件團隊不僅需要開發人員，而且還需要需求工程師，測試人員和其他一些角色。在一個小團隊中，同一個人可能一次戴很多帽子。但是請注意，需求工程師的角色需要與開發人員不同的技能。如果您試圖盲目地創建需求，而又不知道正確的方法，那麼效率將會非常低下，基本上會在大多數開發時間內對錯誤的應用程序進行編碼，然後在必須重新編寫時又感到沮喪。

我建議您獲得需求工程師所需的一些技能。在當前的工作中，您將在已完成的任務中變得更好。在以後的工作中，需求規範可以由專門的需求工程師或團隊中的共識來創建，或者由客戶拼湊而成，擁有這種技能（將與您的純淨開發人員角色配合）將使您變得更有價值團隊成員，並可以通過與您更好的溝通來使您的團隊更有效地合作。

最好的入門方法是全面學習教科書。我個人最喜歡的是伊恩·亞歷山大（Ian Alexander）的發現要求，這是一種非常實用的文本，對於初學者來說很容易理解。您列表上的第二讀內容可以是 Lauesen的工程師UI設計。標題聽起來可能很陳舊，但是您現在可以從流行的用戶體驗UX中獲悉，這是您履歷表中的加分項。不，這不僅與界面有關，還涵蓋了用戶可以感知的所有要求（因此包括要包含哪些功能的問題）。

同時，教育您的經理這是真實的工作。這意味著1）如果他們希望您完成一項需要10個小時的需求分析的工作，那麼您只剩下X-10個小時的代碼即可。 2）與其他任何過程一樣，它會將輸入轉換為輸出，並且需要首先訪問輸入，然後才能生成規範：在這種情況下，您可以獲得關於應用程序未來使用的任何信息您正在與。如果不給真實用戶訪問權限，即使是最大的RE專家也無法創造一個好的概念。這些書會告訴您需要訪問哪些資源；嘗試盡可能多地覆蓋其中。

我認為這歸結為對客戶和管理人員的教育。

隨著項目的進行，變更變得更加昂貴

您幾乎可以查閱任何軟件工程教科書，以獲取“修復軟件生命週期圖中錯誤的相對成本”。基本上說，您在項目中走得越遠，進行更改的成本就越高。那麼，為什麼不盡可能在計劃階段解決問題呢？

代碼完成提到項目的大部分成本都在編碼中-因此，如果您需要重複幾次，您的項目成本很容易失控。

針對項目的複雜性進行足夠的計劃

有幾個適用於軟件工程的隱喻。我個人最喜歡的是建築。與建築不同，規劃的數量不必是詳盡無遺的，它只需要足以滿足產品的複雜性即可。

• 如果該項目是微不足道的（如狗窩） ），那麼您可以要求構建者“只要構建它，我們以後就可以更改它”，這很好。更改它很容易。客戶和建築師在建造房屋之前就同意設計。接受計劃後，構建者可以開始。您仍然可以要求建造者完成，但是他需要在開始之前草擬一個粗略的計劃，而當他不得不修理它時，這將花費您更多的錢。

• 如果要構建辦公大樓，最好使用建築師，否則它將崩潰。如果技術嫻熟的建築商設法在沒有計劃的情況下建造辦公大樓，請他添加地下室，因為您忘了停車了，要么昂貴，要么完全不可能。

您不需要在開始之前需要詳盡且完整的規範。您只需要檢查客戶的想法就可以了。

您的構建速度無法比計劃的快

客戶有時會反對計劃花太長時間。我對此的回答是：“您希望我們比計劃的建造速度更快？計劃比建造更快速，更輕鬆，更便宜，因此，如果您認為我們不能在三個月內對此進行計劃，那麼我們絕對可以”請在三個月內完成。”

如果您儘早進行計劃，那麼誤解就很容易解決。如果您不這樣做，那麼以後解決問題就更困難了。

敏捷方法

敏捷採用了截然不同的方法。

• 您將項目分解為一個或兩個星期的迭代，而不是一次採用瀑布方法。

• 您仍然在進行計劃和需求澄清，但要少一些，並且每次迭代都要進行一次。

• 您每次迭代都會得到大量用戶反饋

• 您對可以支持新版本的軟件進行了最簡單的更改呈現給用戶之前的要求

• 您要進行大量的TDD操作，以確保您不會因不斷重構而破壞東西

通過一百萬次更改死亡

有一種用戶喜歡進行大量的小調整。 “此字體應稍大一些。” “此字體應稍小一些。” “使它具有不同的顏色。” “不是將我們這裡擁有的完美東西，而是將它更改為稍有不同的東西。”

如果是這種情況，我的建議是讓客戶首先關注核心功能，首先關注更大的變化。您還應要求他們明確說明小額變更要滿足的要求。

很可能是您根本不了解的請求背後有一個重要要求。如果是這種情況，請了解需求，然後看看您是否可以提出更好地滿足需求的建議。

通常，需求是“一般的易用性”。 “總體易用性”的答案幾乎總是用戶測試。請注意，這不是客戶端測試，而是由最終將使用該系統的大約六個人進行的用戶測試。

當您沒有獲得啟動項目所需的條件時，您需要做的是寫下每個需求，並儘快指定它們。讓他們知道您需要的確切要求，最重要的是，哪些要求會使您無法完成項目。

在執行此操作時，請盡可能使用進行編碼在開始時給出。我不能太強調這一點。 繼續為您提供給您的信息，直到您不再使用。讓他們知道，當您達到一個要點時，您將無法逾越，因為尚未設置要求。

您的老闆可能沒有給出所需的規格，這可能是有正當理由的-他們可能需要完成一次模擬才能了解其功能，但可能沒有，因為您的用戶/業務分析人員正在拖延您需要遵循的確切指標。無論他們有什麼理由，即使這是一個不好的理由，您也應該盡可能多地完成工作。

有時候，要求會發生變化，您對此無能為力。

歡迎來到軟件行業。

處理這樣的事情是工作的一部分。許多答案為您提供了一些更具體的想法。

保持靈活性是您工作的一部分。是的，要製作修補的代碼，但首先要易於理解。隨手可修復。 您的工作

在天空中聽餡餅的請求，做一些編碼，有人說，這不是工作的一部分。編碼方式，以他們想要的方式編碼，這是行不通的。然後返回並按照可行的方式進行操作。 您的工作的一部分

我想不是您的工作真正真正的唯一麻煩的事情就是抱怨這效率低下。我猜，您可以提及它，也可以嘗試將其綁定，當事情越來越晚時，您可以提出某些建議，但這可能真的行不通。

同樣，它將成為處理工作的工作的一部分。而且要好。然後說，好吧，老闆，當整個東西扔進垃圾箱時。並且說，好吧老闆，當整個東西都必須從垃圾箱中拉出，覆蓋在垃圾桶中並重新加工時。

部分工作。如果您真的不喜歡它，我建議您創辦自己的公司，僱用一堆略顯傲慢的程序員，並在您的抱怨者抱怨說，這是修補過的老闆時，向您推銷服務和產品並賺取工資，這不是很漂亮代碼老闆。所以...

我想另一件事是，開展業務的人們經常絕對沒有時間與您開會。如果您能做好自己的工作，那麼您將能夠預料到一些事情，能夠修復您無法解決的問題，並自己完成所有工作。

正如在其他答案中已經提到的那樣，您的“客戶”（那些要求您構建解決方案的人）需要他們可以與他們的要求進行比較的東西，以便全面探索和理解這些要求（購車，踢輪胎比喻）。這就是為什麼他們沒有提供完整的規範並在解決方案開始成形後開始要求更改的原因。

“客戶”意識到這一點後，他們可能會明確要求或允許您構建原型。並根據原型顯示的內容制定更可靠的規範。但是，您最終可能會走同樣的路，而沒有任何人（您或客戶）明確知道它。問題出在當您報價原來是原型的貨品時，客戶希望您的報價適用於成品。

在“神話般的月”中，有一個關於“試點”系統。本質上，一次構建系統（將被丟棄）是為了學習重新構建系統所需的一切，以正確的方式以及它有意發生的頻率。也許您的“試點”系統即將完成，而“真正的”解決方案尚未啟動。

這時也許您最好的辦法就是記錄每個變更請求-確切地理解您的理解要求，以及您對交付它所需要採取的措施的報價-誠實地說。僅憑口頭協議，任何工作都不要花費超過幾個小時的時間。寫下來-即使是非正式的電子郵件也總比沒有好。您可能需要保護自己免受“這不是我要的”和“您沒有告訴我這將花費這麼長時間”。簡單地告訴你的老闆他應該停止要求改變在政治上可能是不好的。讓不斷增長的引用變更描述來告訴您有關事情如何實現的，以及您如何誠實，盡最大的努力來滿足“客戶”的要求。

或者，繪製一張您認為客戶想要的圖表或示意圖。如果他們想要一個具有方程式求解器的程序，則可以在向用戶顯示菜單後繪製該程序的示意圖（UI和全部），然後允許按下按鈕來選擇方程式求解器。然後將方程式輸入到文本框中，然後用戶單擊另一個按鈕告訴程序來求解方程式。

此外，請幫自己一個忙，以書面形式獲得客戶的答复。如果客戶後來說“我不想要那個”，可以把它當作遮住屁股的一種方式。

通信是解決問題的最佳方法。提出問題，他們會厭倦您，並提供您所需的詳細信息。如果他們不知道，請自己提出要求。記錄給出的答案，並將答案發送回去進行確認。通過這種方式，您可以清楚地知道，延遲或更改的原因是由於改變主意。當Mgt。說“以自己的方式構建”，意思是“做一些我可以觀察和改變的事情”。從理論上講，軟件開發建議在開始一個項目之前，應徹底清除所有要求，從算法的詳細描述到屏幕模型。產品交付時，我們當然會糾正與書面要求的任何偏差，但不允許進行涉及要求變更的任何更改。是的，這將使軟件開發人員的生活更加輕鬆。我不會擔心含糊的要求，只要每個參與人員都知道這些要求含糊不清，您將不得不填補空白，並且當他們看到您的決定時，就會有一些決定他們不喜歡的東西，必須重新設計。由老闆/管理層或客戶提出的不合理要求，那麼您需要以書面形式取得保護自己的東西。如果老闆/管理層或客戶期望不可能的周轉時間，並在無法滿足無法滿足的要求時責怪您，那麼坦白地說，該是時候開始尋找另一份工作或另一位客戶了。

給您的老闆最小和最快的解釋，他對您的要求不多，並迅速將其作為已完成的交易提出。

任何將來不清楚的變更請求都應受到質疑，以使之清楚突然出現在您被要求寫自己的東西的地方，現在它正在被任意更改。詢問進行更改的更具體的原因，這樣您就可以發現自己的要求，並告訴老闆他正在拒絕讓您做自己的事情並將其推向失敗的原因。

如果與您老闆的良好關係，他很可能會給您一個發光的機會-要求他提供發現您自己的需求，應用自己並交付的方法！