在軟體專家對話模式系列文章的第一部分中，你已經了解到業務人員需要什麼以及如何在收集使用者故事的過程中識別需求。在那篇文章裡，我還描述了使用者故事模板：\\
這兩種模板可以使開發人員能夠注意到預期功能背後的需求。第一部分的其中乙個主要觀點就是，在收集使用者故事的過程中，談論業務人員想要什麼或者預期功能是什麼更容易，但確定目標，即這些預期背後的業務需求，要困難許多。
\\ 當你開啟一次使用者故事會話並開始談**能時，你一定會注意到，你的談話物件經常使用「類似需求」的詞語。在這些需求裡，哪些才是真正的需求？
\\\\
問題是尋找恰當的業務需求的第乙個工具。如果你提出了乙個高明的問題，那麼它會讓你獲得相關資訊。我深信，如果正在同你交談的業務人員沒有提供你正在尋找的資訊，那意味著你在錯誤的時間提出了乙個錯誤的問題。
\\ 請把前面那句話再讀一遍。這揭示了支撐軟體專家對話模式的其中乙個關鍵假設。假設你應該完全負責對話的展開，你是將要提供軟體的專家，你就是知道需要什麼資訊的那個人。如果沒有這種假設，就很容易由業務人員承擔對話失敗的責任——並認為他們無法有效交流。在業務人員身上尋找這些問題的原因並不能通向任何有意義的解決方案——而是要明白，這是你自身的不足！這就是為什麼這項假設如此重要。
\\ 因為有兩種不同層次的業務需求：需要避免的問題和希望獲得的利益，所以也有兩組問題來幫助你發現這些需求。
\\ 在以你的談話物件試圖避免的問題這樣乙個形式進行需求挖掘時，基本問題是「為什麼」。試圖回答「為什麼」的問題，我們通常側重於過去的問題。類似的結果可以通過使用一些更具體的問題來探索需要解決的問題領域得以實現：\\
這類問題的主要目的在於，弄清楚你的談話物件想要這項功能的動機，或者，換句話說：他們為這項功能賦予了什麼樣的價值。或者，簡單來說，這項功能有什麼業務價值。
\\ 要找出可以獲得的利益，基本問題是「為了什麼」。當我們回答這個問題的時候，我們通常關注未來的利益，正如下面這些更具體的問題，它們就屬於這一類：\\
現在，你可能想知道，如何知道在**尋找需求。這是避免問題的方向，還是獲得利益的方向？答案非常簡單：聽聽你的談話物件說什麼。你可以借助一些中立問題開始對話：
\\\\
——是什麼使你想要這項功能？
\\ ——噢,感覺有那項功能會很酷！
\\ 好吧，它可能確實「會很酷」，但跟業務需求沒有一點關係。這時，一組精確問題會很有用：\\
精確問題的語境有助於鼓勵談話物件根據所謂的「語義具體化（semantical concretism）」規則明確地進行表述。「具體化（concretism）」是由tadeusz kotarbiński開拓出的哲學領域之一。根據該規則，句子中包含的名稱要能夠指代現實世界中存在的東西，只有這樣的句子才是正確的。因此，句子「它會很酷」從語義具體化的意義上講是不正確的，而句子「人員x將會把訂貨單傳送給我們」是正確的。
\\\\
這個簡短列表中的部分條目將會轉化成一項功能，但不是全部，因為它們中部分條目已經超出了it系統的範圍。
\\\\
尋找那些讓你的業務談話物件想站起來大喊的需求，「是的！那就是我想要的!」。這些需求才是應該寫進使用者故事的需求。要決定哪個需求最接近業務人員真正想要傳達的東西，你可以使用下列問題：\\
一方面，這些問題能夠幫助我們得到滿足這些業務需求的結果；另一方面，幫助我們設定優先順序，確定最重要的需求。
\\\\
現在，讓我們綜合所有關於需求發現的資訊。我們將以業務人員和開發人員之間的對話為例。這樣的對話經常發生，而且一般說來，遵循同樣的模式：\\
團隊提出的問題似乎沒什麼特別的——它們只是一些深入的精確問題。通常，情景語境是關鍵。在像上面這樣的情況下，為了說「不！」，團隊使用了大量詳細的問題，有時還是技術問題。
\\ 當與團隊中的某個成員交談時，這個列表中的問題相當不錯，因為你的談話物件完全有能力回答它們。當使用同樣的問題與沒有準備好回答它們的人交談時，因為他或她沒有該領域的適當知識，團隊的反應可能被視為故意帶有攻擊性。因此，如果你想說「不！」，就直接說「不」。這樣當然更果斷，而不是用許多不可理解的問題折磨你的談話物件。此外，這樣的對話經常出現的結局是，雙方互相說服對方，一項特定的互動功能有用還是沒用。
\\ 那是不是說同業務人員接觸的時候通常應該避免這種型別的問題呢？當然不是！在某些時候，你最終還是不得不問他們。重要的是，首先發現需求，然後提一些更具體的或更偏技術的問題。
\\ 我在這裡描述的對話會如何進行下去呢？\\
這時，一項業務需求已經被列為乙個需要避免的問題：「我想要避免在月底等待銷售圖表」。
\\ 有了這項需求，就可以繼續定義驗收標準了。換句話說，必須確定你的談話物件如何知道問題已經解決或者利益已經獲得。為什麼制訂驗收標準如此重要？稍後我們會談論這個問題。\\
如果團隊想要總結他們剛剛從客戶那裡了解到的內容，那會是像這樣的東西：「我想要避免在月底等待銷售圖表。如果我能夠一周兩次看到關鍵客戶的銷售圖表，那麼我就能避免這一點。」有了這些知識，團隊就可以繼續對話了。\\
為了能夠提供可選的方案建議，團隊努力識別需求，並確定驗收標準。這就是需求背後的秘密。針對新功能不「符合」架構的情況，最常用的策略是：提出證據，說服，並竭力提出自己的想法。當你把關注需求放在第一位時，你就能找到乙個可選的解決方案。一方面，它能讓業務人員滿意；另一方面，團隊也能接受。
\\ 在軟體專家對話模式系列文章的第三篇，我們將重點討論如何自覺地運用詞語以及如何管理對話流程。
michal bartyzel——目前為止，我從事解決開發團隊效率問題已經有十年的時間了。我致力於改進應用程式的架構和重構應用程式，以及改進我們所說的業務人員與開發團隊之間的合作關係。目前為止，我已經對波蘭最好的開發團隊提供了500多天的培訓和諮詢。我得出這樣乙個結論，語言技巧是軟體工藝的關鍵。這既適用於與業務人員的合作，也適用於開發人員的工作，我在我設計的、側重於重構、**及架構修改的培訓中對此進行過闡釋。我在這裡對我目前為止研究得出的許多技術進行了描述。在眾多會議期間，我還在我的部落格和programista雜誌上分享了我目前正在研究的一些新技術。
\\\\
檢視英文原文：conversation patterns for software professionals. part 2
軟體專家的對話模式（第二部分）
在軟體專家對話模式系列文章的第一部分中，你已經了解到業務人員需要什麼以及如何在收集使用者故事的過程中識別需求。在那篇文章裡，我還描述了使用者故事模板 這兩種模板可以使開發人員能夠注意到預期功能背後的需求。第一部分的其中乙個主要觀點就是，在收集使用者故事的過程中，談論業務人員想要什麼或者預期功能是什麼...
Web API 第二部分
web api 第二部分 元素偏移量 offset element.offsettop element.offsetleft element.offsetwidth 可以得到元素的大小 寬度和高度 是包含padding border width element.offsetheight elemen...
redux 第二部分
redux 的使用方法，為什麼使用 action.js 檔案，進行優化 將其分開，然後我們通過工廠函式的每次返回不同的物件，由於引數是固定的，每次返回的都是事件型別和事件資料，所以我們可以使用乙個函式，通過其返回值來返回乙個物件，讓後傳遞給 action 我們的 reducer 函式有兩個引數，引數...