摘要：XXX 作為一名架構師從程序員轉到分析設計員再就爬到了架構師群體。當然架構師也分很多種比如應用級架構師，信息架構師等，從應用級架構師又可進一步發展到企業級架構師和平臺架構師。當然你可能對這些不以為然，但這卻是一個架構師的發展之路。本筆記是在XX培訓時的體會，說實話本人在這領域也是菜的要死，不過我的研究方向是這個，以后繼續努力，請大牛們多多指導。
正文：
有人說不要提前進入架構領域，過高的理論層次只能使你懸在半空，結果大家都知道....。不過理論先學并不裨益。就像我們學 TDD,DDD,AP 一樣，雖然用到的機會不多，但他的思想會影響我們以后的軟件之路。
對于應用級架構師來說除了對一些模塊分割，框架選擇，關鍵技術設計等的決策，在有比較難處理的就這需求，如果你是從程序員上來的，想必已經工作了很多年，習慣了研發室里一坐幾天的感覺，很不適應和那些摳門的領導狡猾的客戶們攀談，做什么都繞圈子，很費精力，稍不留神就被套一番。所以說一般在需求調研時都會有架構師，領域專家和項目經理參加，可能這也是一個比較好的組合。
需求開發的主要困難與對策
1.知識技能問題
– 應用域的知識是無邊無際的，任何人都不可能是“萬事通”。俗話說“隔行如隔山”，需求分析員可能是某一領域的專家，但
當他接手陌生的業務時，他可能是個“無知”者。一個企業要謀求發展，不能總在做老的業務。人一生中會有許多充
滿挫折的“第一次”，不可以逃避。
– 最好請既懂軟件又懂應用域知識的行家來幫忙。
– 當需求分析員缺乏應用域知識時，他該怎么辦？
• 快速獲取領域知識，借助于互聯網；
• 與領域專家交流獲取領域知識；
• 與跨互訪不斷交流獲取。
2.用戶說不清楚需求
– 用戶說不清楚需求是普遍現象，這是讓開發人員頭痛的大問題。
– 有些用戶真的不知道需求是什么，或者對需求只有朦朧的感覺，他當然說不清楚需求。
• 例如開發方的營銷人員水平比較高，他能夠在用戶不清楚自己要什么的情況下引導用戶“消費”。
• 例如前些年全國各地的很多政府機構大搞網絡建設。這些機構的領導和辦公人員大多數
不清楚網絡干什么用，就讓開發人員替他們設想需求吧，反正是花公家的錢。
– 有些用戶雖然心里明白想要什么，但卻說不清楚需求。
• 比如說買鞋子。我們非常了解自已的腳，但很難用語言說清楚腳的大小和形狀。通常拿
鞋子去試，試穿時感覺到舒服才會買鞋。
– 需求分析員絕不能以用戶說不清楚需求為借口而草率地對待需求開發工作，否則會連累整個開發團隊的。
– 無論是什么原因導致用戶說不清楚需求，需求分析員必須設法搞清楚用戶真正的需求，這是需求分析員的職責，也是職業的挑
戰。
3.雙方誤解需求
– 人們在交流的時候，經常會發生“問非所求，答非所問”的事情。
– 有時用戶會把開發人員的建議或答復給想歪了：
• 有一個軟件開發人員滔滔不絕地向用戶講解在“信息高速公路上做廣告”的種種好處，用
戶聽得津津有味。最后，心動的用戶對軟件開發人員說：“好得很，就讓我們馬上行動起
來吧。請您決定廣告牌的尺寸和放在哪條高速公路上，我立即派人去做。”
– 而用戶表達的需求，不同的開發人員可能有不同的理解。如果需求分析員誤解了需求，那會導致后續的不少開發人員將錯就
錯、白干活。就像作文寫跑題了，寫得再好也白搭。這類錯誤連 高智商的外星人都不能避免：
• 有個外星人間諜潛伏到地球刺探情報，它給上司寫了一份報告：“主宰地球的是車。它們喝汽油，靠四個輪子滾動前進。嗓
門極大，在夜里雙眼能射出強光。……有趣的是，車里住著一種叫作‘人’的寄生蟲，這些寄生蟲完全控制了車。”
– 不論是復雜的項目還是簡單的項目，需求分析員和用戶都有可能誤解需求。所以需求確認工作（屬于需求管理）必不可少。
4.用戶經常變更需求
– 需求變更通常會對項目的進度、人力資源、經費產生很大的影響，這是開發商非常畏懼的問題
– 如果在項目開發的初始階段，開發人員和用戶沒有搞清楚需求或者搞錯了需求，到了項目開發后期才將需求糾正過來，導致產
品的部分內容需要重新開發。毫無疑問，這種需求變更將使項目付出額外的代價。這種損失是由于雙方工作失誤造成的，雙方
應當好好反省，認真學習需求開發和管理的方法，避免再犯相似的錯誤。
– 如果由于市場變化而導致產品需求發生變更，開發商大可不必為此煩惱，應當高興才對。倘若市場靜如死水，那么開發商吃了
“上一頓”就沒有“下一頓”。正因為市場在變化，才會產生更多商機，聰明的開發商才會有活干，有錢賺。
– 其實需求變更并不可怕，可怕的是需求變更失去控制，導致項目混亂。所以需求變更控制是需求工程的重要活動。
本博客為學習交流用，凡未注明引用的均為本人作品，轉載請注明出處，如有版權問題請及時通知。由于博客時間倉促，錯誤之處敬請諒解，有任何意見可給我留言，愿共同學習進步。