按照之前架構的定義，做好架構首先需要做的就是識別出需要解決的問題。一般來說，如果把真正的問題找到，那麼問題就已經解決80%了。這個能力基本上就決定了架構師的水平。
那麼面對問題有哪些困難呢?
我們先看一則笑話。女主人公：老公，把袋子裡的土豆切一半下鍋。結果老公是把袋子裡的每個土豆都削了一半，然後下鍋。
當然很多人會說，這個是溝通問題，然後一笑了之。其實，出現這個現象是由於我們大部分時候過於關注解決問題，急於完成自己的工作，而不關心「真正的問題是什麼」而造成的。當我們去解決乙個問題的時候，一定要先把問題搞清楚。這也是我為什麼要單獨寫一篇文章講這個的原因。去看看軟體開發工作者的時間分配也可以看出，大家大部分時間花在討論解決方案和實現的細節上，基本都不會花時間去想「問題是什麼」。或者即使想了一點點，也是一閃而過，憑自己的直覺下判斷。只有真正投入思考問題是什麼的工程師，才可能會真正的成長為架構師
以這個笑話為例，看看在我們處理問題的時候，都會犯什麼樣的錯誤：
被告知要處理乙個問題，但是交過來的實際上是乙個解決方案，不是問題本身。
被告知要處理乙個問題，直接通過直覺就有了乙個解決方案，馬上考慮解決方案如何落地，或者有幾種解決方案，選哪個合適。
那麼如何識別問題呢?
所有的概念基本都有乙個很大的問題，就是缺乏主語。而我們大家都心照不宣的忽略這個主語，溝通的時候也都以為大家都懂得對方說的主語是誰，結果大家都一起犯錯誤。識別問題的乙個最大的前提就是要搞清楚：是誰的問題。這個搞清楚了，問題的邊界也就跟著確定了，再去討論問題才有意義。
以上面切土豆的例子來分析：
女主人提出乙個問題，要切土豆下鍋煮。
男主人有乙個問題，女主人交代了自己必須要完成的乙個任務。
每個人都是優先處理自己的問題，自然就選擇了2，完成了這個任務。這也是大部分軟體工程師處理的方式，以自己認為對的方式完成自己的問題，沒什麼不對啊，也難怪能得到我們的共鳴。這個裡面犯的錯誤是什麼呢?
女主人公提出的實際上是解決方案，而不是燒土豆這個問題本身。女主人當時執行這個解決方案可能有困難，就把執行解決方案作為乙個任務，委託給了男主人。
男主人得到了乙個任務，盡心盡職地把這個任務完成了。
最後的結果是什麼呢，每個人都做了很多任務作，每個人都認為自己做的是對的，因此沒有乙個人對結果滿意。因為真正的問題沒有被發現，自然也就沒有被解決，那麼後續還得收拾殘局，還要繼續解決問題。事實上自己的工作並沒有完成，反而更多了。把原因歸結為溝通問題也是可以的，但對於解決問題似乎並沒有太多的幫助。因為要改進溝通，這也是乙個大問題。搞明白目標問題「是誰的問題，是什麼問題」，當然也是需要溝通的。為了幫助自己更快的搞明白，首先要做的事是問正確的問題。架構師應該問的第乙個正確的問題就是：目標問題是誰的問題。
當我們處理問題的時候，如果發現自己正在致力於把自己的工作完成，要馬上警惕起來，因為這樣下去會演變成沒有ownership的工作態度。在面對概念的時候，也會不求甚解，最終會導致沒有真正的理解概念。
作為軟體工程師或者架構師，我們大部分時候是要去解決別人的問題，「別人」是誰，是值得好好思考的。在這個故事裡面，男主人要解決的，實際上是這個家庭晚餐需要吃土豆的問題，目標問題的主體實際上是這個家庭的成員。
明白了問題的主體，這個主體就自然會帶來很多邊界約束，比如土豆是要吃的，要給人吃的，而且還是要給自己的家人吃的。「切土豆下鍋」這個問題，因為識別了問題的主體，自然而然的就附帶了這麼多的資訊。後續如何煮，是否放高壓鍋煮，放多少水，煮多長時間等等，就自然而然能夠問出來其他問題來了，說不定還能夠識別出來，女主人給的這個解決方案可能是有問題的。這個時候才算是真正的明白了問題。可以想象，這樣下去最後的結果一定是大家都滿意的，因為真正的問題解決了。只有真正明白了是誰的問題，才能夠真正地完成自己的任務，真正地把自己的問題解決掉，而不是反過來。
由上面的分析可以看出，找出問題的主體，是做架構的首要問題。這也是我一再強調的，我們要解決的問題，一定都是人的問題。更進一步，架構師要解決的，基本都是別人的問題，不是自己的問題。再進一步，我們一定要明白，任何找上架構師的問題，絕對都不是真正的問題。為什麼呢? 因為如果是真正的問題的話，提問題過來的人肯定都能夠自己解決了，不需要找架構師。架構師都要有這個自覺：發現問題永遠都比解決問題來的更加重要。
當問題的主體離架構師越遠，就會讓找出問題主體的過程越加困難，我們再舉乙個軟體行業比較熟悉的例子：使用者給產品經理提出要求，想要一把錘子。這是典型的拿解決方案作為問題的。真正的問題的主體是誰，是使用者還是設計師還是施工隊? 如果產品經理當成是自己的問題，那麼毫無疑問就給了錘子了。
我們需要識別：使用者究竟是二傳手，還是問題的真正主體。如果是設計師，那麼問題的邊界就變成了設計師的問題；如果是施工隊，那麼問題就變成了施工隊的問題；如果是使用者，那麼就要看看使用者到底有什麼困難，絕對不是要乙個錘子這麼簡單。這也說明了，問題的主體對問題的邊界確定有多麼的重要。
當明白了問題的主體，我們才可能真正的認識問題是什麼。因為問題的主體是問題的隱含邊界，邊界不確定下來，問題就是不確定的。一旦確定了主體，剩下的就是去搞明白主體有哪些問題。這個就比較直接了，常用的方式就是直接面對主體進行訪談，深入到主體的工作生活當中，體驗並感受這些問題，甚至通過資料的反饋來定位問題。這個大家就比較熟悉了，我就不展開了。
一般來說，從問題暴露的點，一點點去溯源查詢，一定會找出來誰的問題，以及是什麼問題。最壞情況就是當我們時間或者能力有限，實在是無法定位出是誰的問題的時候，比如系統出故障，也就意味著我們無法根本解決問題。這時最好的辦法就是去降低問題發生所帶來的成本，盡量去隔離問題影響的範圍。給我留出時間和空間去識別真正的問題。
總結一下，要正確的認識問題，需要問兩個問題：
這是誰的問題？
有什麼問題？
當得到的回答是支支吾吾的時候，我們就知道正確的方向在哪兒，以及需要做哪些事了。以我的經驗，問題1會花比較多的時間，也是支支吾吾最多的地方，因為架構要解決的問題都是人的問題。但是一旦確定了答案，問題2就會變得非常容易。可以這樣說，架構師的能力大部分會體現在問題1的識別上。
架構漫談（三） 如何做好架構之識別問題
按照之前架構的定義，做好架構首先需要做的就是識別出需要解決的問題。一般來說，如果把真正的問題找到，那麼問題就已經解決了80 了。這個能力基本上就決定了架構師的水平。我們先看一則笑話。女主人公 老公，把袋子裡的土豆切一半下鍋。結果老公是把袋子裡的每個土豆都削了一半，然後下鍋。當然很多人會說，這個是溝通...
架構漫談（三） 如何做好架構之識別問題
按照之前架構的定義，做好架構首先需要做的就是識別出需要解決的問題。一般來說，如果把真正的問題找到，那麼問題就已經解決80 了。這個能力基本上就決定了架構師的水平。那麼面對問題有哪些困難呢?我們先看一則笑話。女主人公 老公，把袋子裡的土豆切一半下鍋。結果老公是把袋子裡的每個土豆都削了一半，然後下鍋。當...
架構漫談（三） 如何做好架構之識別問題
按照之前架構的定義，做好架構首先需要做的就是識別出需要解決的問題。一般來說，如果把真正的問題找到，那麼問題就已經解決了80 了。這個能力基本上就決定了架構師的水平。我們先看一則笑話。女主人公 老公，把袋子裡的土豆切一半下鍋。結果老公是把袋子裡的每個土豆都削了一半，然後下鍋。當然很多人會說，這個是溝通...