如何做好架構之識別問題

来源:http://www.cnblogs.com/8hao/archive/2016/03/02/5234667.html
-Advertisement-
Play Games

按照之前架構的定義,做好架構首先需要做的就是識別出需要解決的問題。一般來說,如果把真正的問題找到,那麼問題就已經解決了80%了。這個能力基本上就決定了架構師的水平。 那麼面對問題有哪些困難呢? 我們先看一則笑話。女主人公:老公,把袋子里的土豆切一半下鍋。結果老公是把袋子里的每個土豆都削了一半,然後下


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

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

我們先看一則笑話。女主人公:老公,把袋子里的土豆切一半下鍋。結果老公是把袋子里的每個土豆都削了一半,然後下鍋。

當然很多人會說,這個是溝通問題,然後一笑了之。其實,出現這個現象是由於我們大部分時候過於關註解決問題,急於完成自己的工作,而不關心“真正的問題是什麼”而造成的。當我們去解決一個問題的時候,一定要先把問題搞清楚。這也是我為什麼要單獨寫一篇文章講這個的原因。去看看軟體開發工作者的時間分配也可以看出,大家大部分時間花在討論解決方案和實現的細節上,基本都不會花時間去想“問題是什麼”。或者即使想了一點點,也是一閃而過,憑自己的直覺下判斷。只有真正投入思考問題是什麼的工程師,才可能會真正的成長為架構師

以這個笑話為例,看看在我們處理問題的時候,都會犯什麼樣的錯誤:

  1. 被告知要處理一個問題,但是交過來的實際上是一個解決方案,不是問題本身
  2. 被告知要處理一個問題,直接通過直覺就有了一個解決方案,馬上考慮解決方案如何落地,或者有幾種解決方案,選哪個合適

那麼如何識別問題呢?

所有的概念基本都有一個很大的問題,就是缺乏主語。而我們大家都心照不宣的忽略這個主語,溝通的時候也都以為大家都懂得對方說的主語是誰,結果大家都一起犯錯誤。識別問題的一個最大的前提就是要搞清楚:是誰的問題。這個搞清楚了,問題的邊界也就跟著確定了,再去討論問題才有意義。

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

  1. 女主人提出一個問題,要切土豆下鍋煮。
  2. 男主人有一個問題,女主人交代了自己必須要完成的一個任務。

每個人都是優先處理自己的問題,自然就選擇了2,完成了這個任務。這也是大部分軟體工程師處理的方式,以自己認為對的方式完成自己的問題,沒什麼不對啊,也難怪能得到我們的共鳴。這個裡面犯的錯誤是什麼呢?

  1. 女主人公提出的實際上是解決方案,而不是燒土豆這個問題本身。女主人當時執行這個解決方案可能有困難,就把執行解決方案作為一個任務,委托給了男主人。

     

     

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

最後的結果是什麼呢,每個人都做了很多工作,每個人都認為自己做的是對的,因此沒有一個人對結果滿意。因為真正的問題沒有被髮現,自然也就沒有被解決,那麼後續還得收拾殘局,還要繼續解決問題。事實上自己的工作並沒有完成,反而更多了。把原因歸結為溝通問題也是可以的,但對於解決問題似乎並沒有太多的幫助。因為要改進溝通,這也是一個大問題。搞明白目標問題“是誰的問題,是什麼問題”,當然也是需要溝通的。為了幫助自己更快的搞明白,首先要做的事是問正確的問題。架構師應該問的第一個正確的問題就是:目標問題是誰的問題。

當我們處理問題的時候,如果發現自己正在致力於把自己的工作完成,要馬上警惕起來,因為這樣下去會演變成沒有ownership的工作態度。在面對概念的時候,也會不求甚解,最終會導致沒有真正的理解概念。

作為軟體工程師或者架構師,我們大部分時候是要去解決別人的問題,“別人”是誰,是值得好好思考的。在這個故事裡面,男主人要解決的,實際上是這個家庭晚餐需要吃土豆的問題,目標問題的主體實際上是這個家庭的成員。

明白了問題的主體,這個主體就自然會帶來很多邊界約束,比如土豆是要吃的,要給人吃的,而且還是要給自己的家人吃的。“切土豆下鍋”這個問題,因為識別了問題的主體,自然而然的就附帶了這麼多的信息。後續如何煮,是否放高壓鍋煮,放多少水,煮多長時間等等,就自然而然能夠問出來其他問題來了,說不定還能夠識別出來,女主人給的這個解決方案可能是有問題的。這個時候才算是真正的明白了問題。可以想象,這樣下去最後的結果一定是大家都滿意的,因為真正的問題解決了。只有真正明白了是誰的問題,才能夠真正地完成自己的任務,真正地把自己的問題解決掉,而不是反過來。

由上面的分析可以看出,找出問題的主體,是做架構的首要問題。這也是我一再強調的,我們要解決的問題,一定都是人的問題。更進一步,架構師要解決的,基本都是別人的問題,不是自己的問題。再進一步,我們一定要明白,任何找上架構師的問題,絕對都不是真正的問題。為什麼呢? 因為如果是真正的問題的話,提問題過來的人肯定都能夠自己解決了,不需要找架構師。架構師都要有這個自覺:發現問題永遠都比解決問題來的更加重要。

當問題的主體離架構師越遠,就會讓找出問題主體的過程越加困難,我們再舉一個軟體行業比較熟悉的例子:用戶給產品經理提出要求,想要一把錘子。這是典型的拿解決方案作為問題的。真正的問題的主體是誰,是用戶還是設計師還是施工隊? 如果產品經理當成是自己的問題,那麼毫無疑問就給了錘子了。

我們需要識別:用戶究竟是二傳手,還是問題的真正主體。如果是設計師,那麼問題的邊界就變成了設計師的問題,如果是施工隊,那麼問題就變成了施工隊的問題,如果是用戶,那麼就要看看用戶到底有什麼困難,絕對不是要一個錘子這麼簡單。這也說明瞭,問題的主體對問題的邊界確定有多麼的重要。

當明白了問題的主體,我們才可能真正的認識問題是什麼。因為問題的主體是問題的隱含邊界,邊界不確定下來,問題就是不確定的。一旦確定了主體,剩下的就是去搞明白主體有哪些問題。這個就比較直接了,常用的方式就是直接面對主體進行訪談,深入到主體的工作生活當中,體驗並感受這些問題,甚至通過數據的反饋來定位問題。這個大家就比較熟悉了,我就不展開了。

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

總結一下,要正確的認識問題,需要問兩個問題:

  1. 這是誰的問題?
  2. 有什麼問題?

當得到的回答是支支吾吾的時候,我們就知道正確的方向在哪兒,以及需要做哪些事了。以我的經驗,問題1會花比較多的時間,也是支支吾吾最多的地方,因為架構要解決的問題都是人的問題。但是一旦確定了答案,問題2就會變得非常容易。可以這樣說,架構師的能力大部分會體現在問題1的識別上。

問啊-一鍵呼叫程式員答題神器,牛人一對一服務,開發者編程必備官方網站:www.wenaaa.com

QQ群290551701 聚集很多互聯網精英,技術總監,架構師,項目經理!開源技術研究,歡迎業內人士,大牛及新手有志於從事IT行業人員進入!


您的分享是我們最大的動力!

-Advertisement-
Play Games
更多相關文章
  • MyEclipse 2016基於Eclipse Mars 1 (4.5.1),除了在Eclipse基礎上做了更新之外,我們還更新了集成在MyEclipse上的第三方工具,比如STS, m2e, BIRT, Webtools, eGit等等。 Mars集成對Java的一些核心進行了改進,比如編譯器的...
  • PDO是一個“資料庫訪問抽象層”,作用是統一各種資料庫的訪問介面,與mysql和mysqli的函數庫相比,PDO讓跨資料庫的使用更具有親和力;與ADODB和MDB2相比,PDO更高效。目前而言,實現“資料庫抽象層”任重而道遠,使用PDO這樣的“資料庫訪問抽象層”是一個不錯的選擇。 PDO中包含三個預
  • 假期本想要嘗試做一些不同的事,卻一直荒廢,偶然看到了幕課,頓時後悔,再借我一個假期,一定在幕課上認真學習。比自己看書效率高很多啊! 於是反正無聊,用了一個晚上瞭解了一下python(僅限於瞭解),總想做點啥有意思的,想來想去還是和抓包聯繫上了。 鑒於Wireshark我是真不怎麼會用,這次抓包用的軟
  • 嘗試過myeclipse10環境下,線上安裝findbugs,插件包是能下載到指定目錄下,可是由於版本問題,findbugs插件是不能使用的。所以才有了下麵的離線安裝
  • 本文來源:https://www.dataquest.io/mission/132/data-visualization-and-exploration 本文數據來源https://github.com/fivethirtyeight/data/blob/master/college-majors/...
  • Java有Maven, Node.js有npm, ROR有gem, 這些語言的程式員在開心地使用包管理工具加速開發效率時,PHPer們還在複製粘貼的黑暗中。PHP在Composer之前,包管理的歷史不堪迴首。 在相當長的一段時間內,如果應用依賴於第三方庫,PHPer需要拷貝這些庫的源代碼, 或者通過
  • 類與實例 對象是一個自包含的實體,用一組可識別特性和行為來標識 簡稱OOP 類就是具有相同的屬性和功能的對象的抽象的集合 ‘class’是便是定義類的關鍵字 (OC中用@interface 類名:繼承類 @end) 第一,類名稱首字母記者要大寫。多個單詞則各個首字母大寫,第二,對外的方法需要用‘pu
  • 1 package com.shejimoshi.behavioral.Command; 2 3 4 /** 5 * 功能:接收命令著者,這個人可以執行多種命令 6 * 時間:2016年3月2日上午11:07:30 7 * 作者:cutter_point 8 */ 9 public class Re
一周排行
    -Advertisement-
    Play Games
  • 一個自定義WPF窗體的解決方案,借鑒了呂毅老師的WPF製作高性能的透明背景的異形視窗一文,併在此基礎上增加了滑鼠穿透的功能。可以使得透明窗體的滑鼠事件穿透到下層,在下層窗體中響應。 ...
  • 在C#中使用RabbitMQ做個簡單的發送郵件小項目 前言 好久沒有做項目了,這次做一個發送郵件的小項目。發郵件是一個比較耗時的操作,之前在我的個人博客裡面回覆評論和友鏈申請是會通過發送郵件來通知對方的,不過當時只是簡單的進行了非同步操作。 那麼這次來使用RabbitMQ去統一發送郵件,我的想法是通過 ...
  • 當你使用Edge等瀏覽器或系統軟體播放媒體時,Windows控制中心就會出現相應的媒體信息以及控制播放的功能,如圖。 SMTC (SystemMediaTransportControls) 是一個Windows App SDK (舊為UWP) 中提供的一個API,用於與系統媒體交互。接入SMTC的好 ...
  • 最近在微軟商店,官方上架了新款Win11風格的WPF版UI框架【WPF Gallery Preview 1.0.0.0】,這款應用引入了前沿的Fluent Design UI設計,為用戶帶來全新的視覺體驗。 ...
  • 1.簡單使用實例 1.1 添加log4net.dll的引用。 在NuGet程式包中搜索log4net並添加,此次我所用版本為2.0.17。如下圖: 1.2 添加配置文件 右鍵項目,添加新建項,搜索選擇應用程式配置文件,命名為log4net.config,步驟如下圖: 1.2.1 log4net.co ...
  • 之前也分享過 Swashbuckle.AspNetCore 的使用,不過版本比較老了,本次演示用的示例版本為 .net core 8.0,從安裝使用開始,到根據命名空間分組顯示,十分的有用 ...
  • 在 Visual Studio 中,至少可以創建三種不同類型的類庫: 類庫(.NET Framework) 類庫(.NET 標準) 類庫 (.NET Core) 雖然第一種是我們多年來一直在使用的,但一直感到困惑的一個主要問題是何時使用 .NET Standard 和 .NET Core 類庫類型。 ...
  • WPF的按鈕提供了Template模板,可以通過修改Template模板中的內容對按鈕的樣式進行自定義。結合資源字典,可以將自定義資源在xaml視窗、自定義控制項或者整個App當中調用 ...
  • 實現了一個支持長短按得按鈕組件,單擊可以觸發Click事件,長按可以觸發LongPressed事件,長按鬆開時觸發LongClick事件。還可以和自定義外觀相結合,實現自定義的按鈕外形。 ...
  • 一、WTM是什麼 WalkingTec.Mvvm框架(簡稱WTM)最早開發與2013年,基於Asp.net MVC3 和 最早的Entity Framework, 當初主要是為瞭解決公司內部開發效率低,代碼風格不統一的問題。2017年9月,將代碼移植到了.Net Core上,併進行了深度優化和重構, ...