首頁 > EA > 正文

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

2018-08-02 09:44:41  來源:網絡 作者:王概凱

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

第二十八屆CIO班招生
法國布雷斯特商學院MBA班招生
法國布雷斯特商學院碩士班招生
責編:yangjun
日本熟妇色在线视频