1. 程式人生 > >架構漫談(三):如何做好架構之識別問題

架構漫談(三):如何做好架構之識別問題

答案 跟著 發生 做了 解決 長時間 一閃而過 開發 問題解決

按照之前架構的定義,做好架構首先需要做的就是識別出需要解決的問題。一般來說,如果把真正的問題找到,那麽問題就已經解決了80%了。這個能力基本上就決定了架構師的水平。

那麽面對問題有哪些困難呢?

我們先看一則笑話。女主人公:老公,把袋子裏的土豆切一半下鍋。結果老公是把袋子裏的每個土豆都削了一半,然後下鍋。 當然很多人會說,這個是溝通問題,然後一笑了之。其實,出現這個現象是由於我們大部分時候過於關註解決問題,急於完成自己的工作,而不關心“真正的問題是什麽”而造成的。當我們去解決一個問題的時候,一定要先把問題搞清楚。這也是我為什麽要單獨寫一篇文章講這個的原因。去看看軟件開發工作者的時間分配也可以看出,大家大部分時間花在討論解決方案和實現的細節上,基本都不會花時間去想“問題是什麽”。或者即使想了一點點,也是一閃而過,憑自己的直覺下判斷。只有真正投入思考問題是什麽的工程師,才可能會真正的成長為架構師 以這個笑話為例,看看在我們處理問題的時候,都會犯什麽樣的錯誤:
  1. 被告知要處理一個問題,但是交過來的實際上是一個解決方案,不是問題本身
  2. 被告知要處理一個問題,直接通過直覺就有了一個解決方案,馬上考慮解決方案如何落地,或者有幾種解決方案,選哪個合適

那麽如何識別問題呢?

所有的概念基本都有一個很大的問題,就是缺乏主語。而我們大家都心照不宣的忽略這個主語,溝通的時候也都以為大家都懂得對方說的主語是誰,結果大家都一起犯錯誤。識別問題的一個最大的前提就是要搞清楚:是誰的問題。這個搞清楚了,問題的邊界也就跟著確定了,再去討論問題才有意義。 以上面切土豆的例子來分析:
  1. 女主人提出一個問題,要切土豆下鍋煮。
  2. 男主人有一個問題,女主人交代了自己必須要完成的一個任務。
每個人都是優先處理自己的問題,自然就選擇了2,完成了這個任務。這也是大部分軟件工程師處理的方式,以自己認為對的方式完成自己的問題,沒什麽不對啊,也難怪能得到我們的共鳴。這個裏面犯的錯誤是什麽呢?
  1. 女主人公提出的實際上是解決方案,而不是燒土豆這個問題本身。女主人當時執行這個解決方案可能有困難,就把執行解決方案作為一個任務,委托給了男主人。

  2. 男主人得到了一個任務,盡心盡職地把這個任務完成了。

最後的結果是什麽呢,每個人都做了很多工作,每個人都認為自己做的是對的,因此沒有一個人對結果滿意。因為真正的問題沒有被發現,自然也就沒有被解決,那麽後續還得收拾殘局,還要繼續解決問題。事實上自己的工作並沒有完成,反而更多了。把原因歸結為溝通問題也是可以的,但對於解決問題似乎並沒有太多的幫助。因為要改進溝通,這也是一個大問題。搞明白目標問題“是誰的問題,是什麽問題”,當然也是需要溝通的。為了幫助自己更快的搞明白,首先要做的事是問正確的問題。架構師應該問的第一個正確的問題就是:目標問題是誰的問題。 當我們處理問題的時候,如果發現自己正在致力於把自己的工作完成,要馬上警惕起來,因為這樣下去會演變成沒有ownership的工作態度。在面對概念的時候,也會不求甚解,最終會導致沒有真正的理解概念。 作為軟件工程師或者架構師,我們大部分時候是要去解決別人的問題,“別人”是誰,是值得好好思考的。在這個故事裏面,男主人要解決的,實際上是這個家庭晚餐需要吃土豆的問題,目標問題的主體實際上是這個家庭的成員。 明白了問題的主體,這個主體就自然會帶來很多邊界約束,比如土豆是要吃的,要給人吃的,而且還是要給自己的家人吃的。“切土豆下鍋”這個問題,因為識別了問題的主體,自然而然的就附帶了這麽多的信息。後續如何煮,是否放高壓鍋煮,放多少水,煮多長時間等等,就自然而然能夠問出來其他問題來了,說不定還能夠識別出來,女主人給的這個解決方案可能是有問題的。這個時候才算是真正的明白了問題。可以想象,這樣下去最後的結果一定是大家都滿意的,因為真正的問題解決了。只有真正明白了是誰的問題,才能夠真正地完成自己的任務,真正地把自己的問題解決掉,而不是反過來。 由上面的分析可以看出,找出問題的主體,是做架構的首要問題。這也是我一再強調的,我們要解決的問題,一定都是人的問題。更進一步,架構師要解決的,基本都是別人的問題,不是自己的問題。再進一步,我們一定要明白,任何找上架構師的問題,絕對都不是真正的問題。為什麽呢? 因為如果是真正的問題的話,提問題過來的人肯定都能夠自己解決了,不需要找架構師。架構師都要有這個自覺:發現問題永遠都比解決問題來的更加重要。 當問題的主體離架構師越遠,就會讓找出問題主體的過程越加困難,我們再舉一個軟件行業比較熟悉的例子:用戶給產品經理提出要求,想要一把錘子。這是典型的拿解決方案作為問題的。真正的問題的主體是誰,是用戶還是設計師還是施工隊? 如果產品經理當成是自己的問題,那麽毫無疑問就給了錘子了。 我們需要識別:用戶究竟是二傳手,還是問題的真正主體。如果是設計師,那麽問題的邊界就變成了設計師的問題,如果是施工隊,那麽問題就變成了施工隊的問題,如果是用戶,那麽就要看看用戶到底有什麽困難,絕對不是要一個錘子這麽簡單。這也說明了,問題的主體對問題的邊界確定有多麽的重要。 當明白了問題的主體,我們才可能真正的認識問題是什麽。因為問題的主體是問題的隱含邊界,邊界不確定下來,問題就是不確定的。一旦確定了主體,剩下的就是去搞明白主體有哪些問題。這個就比較直接了,常用的方式就是直接面對主體進行訪談,深入到主體的工作生活當中,體驗並感受這些問題,甚至通過數據的反饋來定位問題。這個大家就比較熟悉了,我就不展開了。 一般來說,從問題暴露的點,一點點去溯源查找,一定會找出來誰的問題,以及是什麽問題。最壞情況就是當我們時間或者能力有限,實在是無法定位出是誰的問題的時候,比如系統出故障,也就意味著我們無法根本解決問題。這時最好的辦法就是去降低問題發生所帶來的成本,盡量去隔離問題影響的範圍。給我留出時間和空間去識別真正的問題。 總結一下,要正確的認識問題,需要問兩個問題:
  1. 這是誰的問題?
  2. 有什麽問題?
當得到的回答是支支吾吾的時候,我們就知道正確的方向在哪兒,以及需要做哪些事了。以我的經驗,問題1會花比較多的時間,也是支支吾吾最多的地方,因為架構要解決的問題都是人的問題。但是一旦確定了答案,問題2就會變得非常容易。可以這樣說,架構師的能力大部分會體現在問題1的識別上。

架構漫談(三):如何做好架構之識別問題