【細品架構3/100】架構之問題識別

本文主要是繼續研讀了資深架構師王概凱Kevin執筆的《架構漫談》系列的《架構漫談（三）：如何作好架構之識別問題》的心得感覺。王概凱Kevin結合本身多年的架構經驗，經過不一樣的視角，從新審視架構的本質，從而產生一力做《架構漫談》系列，做者但願可以拋出本身從實踐中得出的一些觀點，並引起你們的一些思考，歡迎你們溝通討論。

如須要閱讀原文，請關注公衆號「聊聊架構」，從歷史文章中獲取《架構漫談》系列。

本文內容結構圖：

 

 

1.  

按照以前的架構定義，架構就是要不斷解決人遇到的問題，然而作好架構首先須要作的就是識別出須要解決的真實問題。通常來講，若是把真正的問題可以找到，那麼問題就已經解決了80%。這個能力基本上就決定了架構師的水平。

1.  

一則笑話：

女主人公：老公，把袋子裏的土豆切一半下鍋。結果老公是把袋子裏的每一個土豆都削了一半，而後下鍋。

固然不少人會說，這個是溝通問題，而後一笑了之。其實，出現這個現象是因爲咱們大部分時候過於關注解決問題，急於完成本身的工做，而不關心「真正的問題是什麼」而形成的。當咱們去解決一個問題的時候，必定要先把問題搞清楚。

去看看軟件開發工做者的時間分配也能夠看出，你們大部分時間花在討論解決方案和實現的細節上，基本都不會花時間去想「問題是什麼」。或者即便想了一點點，也是一閃而過，憑本身的直覺下判斷。只有真正投入思考問題是什麼的工程師，纔可能會真正的成長爲架構師。

以這個笑話爲例，看看在咱們處理問題的時候，都會犯什麼樣的慣性錯誤：

被告知要處理一個問題，可是交過來的其實是一個解決方案，不是問題自己。

被告知要處理一個問題，直接經過直覺就有了一個解決方案，立刻考慮解決方案如何落地，或者有幾種解決方案，選哪一個合適。

1.  

如何識別問題主體呢?

全部的概念基本都有一個很大的問題，就是缺少主語。而咱們你們都心領神會的忽略這個主語，溝通的時候也都覺得你們都懂得對方說的主語是誰，結果你們都一塊兒犯錯誤。識別問題的一個最大的前提就是要搞清楚：是誰的問題。這個搞清楚了，問題的邊界也就跟着肯定了，再去討論問題纔有意義。

以上面切土豆的例子來分析：

1. 女主人提出一個問題，要切土豆下鍋煮。

2. 男主人有一個問題，女主人交代了本身必需要完成的一個任務。

每一個人都是優先處理本身的問題，天然就選擇了2，完成了這個任務。這也是大部分軟件工程師處理的方式，以本身認爲對的方式完成本身的問題，沒什麼不對啊，也難怪能獲得咱們的共鳴。這個裏面犯的錯誤是什麼呢?

首先，女主人公提出的其實是解決方案，而不是燒土豆這個問題自己。女主人當時執行這個解決方案可能有困難，就把執行解決方案做爲一個任務，委託給了男主人。

其次，男主人獲得了一個任務，盡心盡職地把這個任務完成了。

最後的結果是什麼呢，每一個人都作了不少工做，每一個人都認爲本身作的是對的，所以沒有一我的對結果滿意。由於真正的問題沒有被發現，天然也就沒有被解決，那麼後續還得收拾殘局，還要繼續解決問題。事實上本身的工做並無完成，反而更多了。把緣由歸結爲溝通問題也是能夠的，但對於解決問題彷佛並無太多的幫助。由於要改進溝通，這也是一個大問題。搞明白目標問題「是誰的問題，是什麼問題」，固然也是須要溝通的。爲了幫助本身更快的搞明白，首先要作的事是問正確的問題。架構師應該問的第一個正確的問題就是：目標問題是誰的問題。

因此得出：

當咱們處理問題的時候，若是發現本身正在致力於把本身的工做完成，要立刻警戒起來，由於這樣下去會演變成沒有ownership的工做態度。在面對概念的時候，也會不求甚解，最終會致使沒有真正的理解概念。

做爲軟件工程師或者架構師，咱們大部分時候是要去解決別人的問題，「別人」是誰，是值得好好思考的。在上面故事裏面，男主人要解決的，其實是這個家庭晚餐須要吃土豆的問題，目標問題的主體其實是這個家庭的成員。

1.  

如何識別問題邊界呢?

明白了問題的主體，這個主體就天然會帶來不少邊界約束，好比土豆是要吃的，要給人吃的，並且仍是要給本身的家人吃的。「切土豆下鍋」這個問題，由於識別了問題的主體，天然而然的就附帶了這麼多的信息。

後續如何煮，是否放高壓鍋煮，放多少水，煮多長時間等等，就天然而然可以問出來其餘問題來了，說不定還可以識別出來，女主人給的這個解決方案多是有問題的。這個時候纔算是真正的明白了問題。能夠想象，這樣下去最後的結果必定是你們都滿意的，由於真正的問題解決了。只有真正明白了是誰的問題，纔可以真正地完成本身的任務，真正地把本身的問題解決掉，而不是反過來。

由上面的分析能夠看出，找出問題的主體，是作架構的首要問題。這也是我一再強調的，咱們要解決的問題，必定都是人的問題。進一步，架構師要解決的，基本都是別人的問題，不是本身的問題。

再進一步，咱們必定要明白，任何找上架構師的問題，絕對都不是真正的問題。爲何呢? 由於若是是真正的問題的話，提問題過來的人確定都可以本身解決了，不須要找架構師。架構師都要有這個自覺：發現問題永遠都比解決問題來的更加劇要。

當問題的主體離架構師越遠，就會讓找出問題主體的過程越加困難，咱們再舉一個軟件行業比較熟悉的例子：用戶給產品經理提出要求，想要一把錘子。這是典型的拿解決方案做爲問題的。真正的問題的主體是誰，是用戶仍是設計師仍是施工隊? 若是產品經理當成是本身的問題，那麼毫無疑問就給了錘子了。

咱們須要識別：用戶到底是二傳手，仍是問題的真正主體。若是是設計師，那麼問題的邊界就變成了設計師的問題，若是是施工隊，那麼問題就變成了施工隊的問題，若是是用戶，那麼就要看看用戶到底有什麼困難，絕對不是要一個錘子這麼簡單。這也說明了，問題的主體對問題的邊界肯定有多麼的重要。

當明白了問題的主體，咱們纔可能真正的認識問題是什麼。由於問題的主體是問題的隱含邊界，邊界不肯定下來，問題就是不肯定的。一旦肯定了主體，剩下的就是去搞明白主體有哪些問題。

通常來講，從問題暴露的點，一點點去溯源查找，必定會找出來誰的問題，以及是什麼問題。最壞狀況就是當咱們時間或者能力有限，實在是沒法定位出是誰的問題的時候，好比系統出故障，也就意味着咱們沒法根本解決問題。這時最好的辦法就是去下降問題發生所帶來的成本，儘可能去隔離問題影響的範圍。給我留出時間和空間去識別真正的問題。

1.  

總結一下，要正確的認識問題，須要問兩個問題：

1. 這是誰的問題？

2. 有什麼問題？

當獲得的回答是支支吾吾的時候，咱們就知道正確的方向在哪兒，以及須要作哪些事了。問題1會花比較多的時間，也是支支吾吾最多的地方，由於架構要解決的問題都是人的問題。可是一旦肯定了答案，問題2就會變得很是容易。能夠這樣說，架構師的能力大部分會體如今問題1的識別上。

在實際工做中存在不少的狀況，都只是在完成本身的問題或任務，而忽略了問題或任務的根本：誰的問題、什麼問題。做爲架構師，不只是架構師，在面對問題時，而要更多的找出問題是什麼，問題的主體是什麼，從而只有有了主體，纔可以肯定問題的邊界，最終纔會肯定出真正的問題所在。

做者：猿碼道 連接：https://juejin.im/post/5b36e55d51882574dc41e948 來源：掘金 著做權歸做者全部。商業轉載請聯繫做者得到受權，非商業轉載請註明出處。