按照架構(gòu)的定義，做好架構(gòu)首先需要做的就是識別出需要解決的問題。一般來說，如果把真正的問題找到，那么問題就已經(jīng)解決了80%了。這個能力基本上就決定了架構(gòu)師的水平。
那么面對問題有哪些困難呢?
我們先看一則笑話。女主人公：老公，把袋子里的土豆切一半下鍋。結(jié)果老公是把袋子里的每個土豆都削了一半，然后下鍋。
當(dāng)然很多人會說，這個是溝通問題，然后一笑了之。其實(shí)，出現(xiàn)這個現(xiàn)象是由于我們大部分時候過于關(guān)注解決問題，急于完成自己的工作，而不關(guān)心“真正的問題是什么”而造成的。當(dāng)我們?nèi)ソ鉀Q一個問題的時候，一定要先把問題搞清楚。這也是我為什么要單獨(dú)寫一篇文章講這個的原因。去看看軟件開發(fā)工作者的時間分配也可以看出，大家大部分時間花在討論解決方案和實(shí)現(xiàn)的細(xì)節(jié)上，基本都不會花時間去想“問題是什么”?；蛘呒词瓜肓艘稽c(diǎn)點(diǎn)，也是一閃而過，憑自己的直覺下判斷。只有真正投入思考問題是什么的工程師，才可能會真正的成長為架構(gòu)師
以這個笑話為例，看看在我們處理問題的時候，都會犯什么樣的錯誤：
1.被告知要處理一個問題，但是交過來的實(shí)際上是一個解決方案，不是問題本身
2.被告知要處理一個問題，直接通過直覺就有了一個解決方案，馬上考慮解決方案如何落地，或者有幾種解決方案，選哪個合適
那么如何識別問題呢?
所有的概念基本都有一個很大的問題，就是缺乏主語。而我們大家都心照不宣的忽略這個主語，溝通的時候也都以為大家都懂得對方說的主語是誰，結(jié)果大家都一起犯錯誤。識別問題的一個最大的前提就是要搞清楚：是誰的問題。這個搞清楚了，問題的邊界也就跟著確定了，再去討論問題才有意義。
以上面切土豆的例子來分析：
1.女主人提出一個問題，要切土豆下鍋煮。
2.男主人有一個問題，女主人交代了自己必須要完成的一個任務(wù)。
每個人都是優(yōu)先處理自己的問題，自然就選擇了2，完成了這個任務(wù)。這也是大部分軟件工程師處理的方式，以自己認(rèn)為對的方式完成自己的問題，沒什么不對啊，也難怪能得到我們的共鳴。這個里面犯的錯誤是什么呢?
1.女主人公提出的實(shí)際上是解決方案，而不是燒土豆這個問題本身。女主人當(dāng)時執(zhí)行這個解決方案可能有困難，就把執(zhí)行解決方案作為一個任務(wù)，委托給了男主人。
2.男主人得到了一個任務(wù)，盡心盡職地把這個任務(wù)完成了。
最后的結(jié)果是什么呢，每個人都做了很多工作，每個人都認(rèn)為自己做的是對的，因此沒有一個人對結(jié)果滿意。因?yàn)檎嬲膯栴}沒有被發(fā)現(xiàn)，自然也就沒有被解決，那么后續(xù)還得收拾殘局，還要繼續(xù)解決問題。事實(shí)上自己的工作并沒有完成，反而更多了。把原因歸結(jié)為溝通問題也是可以的，但對于解決問題似乎并沒有太多的幫助。因?yàn)橐倪M(jìn)溝通，這也是一個大問題。搞明白目標(biāo)問題“是誰的問題，是什么問題”，當(dāng)然也是需要溝通的。為了幫助自己更快的搞明白，首先要做的事是問正確的問題。架構(gòu)師應(yīng)該問的第一個正確的問題就是：目標(biāo)問題是誰的問題。
當(dāng)我們處理問題的時候，如果發(fā)現(xiàn)自己正在致力于把自己的工作完成，要馬上警惕起來，因?yàn)檫@樣下去會演變成沒有ownership的工作態(tài)度。在面對概念的時候，也會不求甚解，最終會導(dǎo)致沒有真正的理解概念。
作為軟件工程師或者架構(gòu)師，我們大部分時候是要去解決別人的問題，“別人”是誰，是值得好好思考的。在這個故事里面，男主人要解決的，實(shí)際上是這個家庭晚餐需要吃土豆的問題，目標(biāo)問題的主體實(shí)際上是這個家庭的成員。
明白了問題的主體，這個主體就自然會帶來很多邊界約束，比如土豆是要吃的，要給人吃的，而且還是要給自己的家人吃的。“切土豆下鍋”這個問題，因?yàn)樽R別了問題的主體，自然而然的就附帶了這么多的信息。后續(xù)如何煮，是否放高壓鍋煮，放多少水，煮多長時間等等，就自然而然能夠問出來其他問題來了，說不定還能夠識別出來，女主人給的這個解決方案可能是有問題的。這個時候才算是真正的明白了問題?？梢韵胂?，這樣下去最后的結(jié)果一定是大家都滿意的，因?yàn)檎嬲膯栴}解決了。只有真正明白了是誰的問題，才能夠真正地完成自己的任務(wù)，真正地把自己的問題解決掉，而不是反過來。
由上面的分析可以看出，找出問題的主體，是做架構(gòu)的首要問題。這也是我一再強(qiáng)調(diào)的，我們要解決的問題，一定都是人的問題。更進(jìn)一步，架構(gòu)師要解決的，基本都是別人的問題，不是自己的問題。再進(jìn)一步，我們一定要明白，任何找上架構(gòu)師的問題，絕對都不是真正的問題。為什么呢? 因?yàn)槿绻钦嬲膯栴}的話，提問題過來的人肯定都能夠自己解決了，不需要找架構(gòu)師。架構(gòu)師都要有這個自覺：發(fā)現(xiàn)問題永遠(yuǎn)都比解決問題來的更加重要。
當(dāng)問題的主體離架構(gòu)師越遠(yuǎn)，就會讓找出問題主體的過程越加困難，我們再舉一個軟件行業(yè)比較熟悉的例子：用戶給產(chǎn)品經(jīng)理提出要求，想要一把錘子。這是典型的拿解決方案作為問題的。真正的問題的主體是誰，是用戶還是設(shè)計(jì)師還是施工隊(duì)? 如果產(chǎn)品經(jīng)理當(dāng)成是自己的問題，那么毫無疑問就給了錘子了。
我們需要識別：用戶究竟是二傳手，還是問題的真正主體。如果是設(shè)計(jì)師，那么問題的邊界就變成了設(shè)計(jì)師的問題，如果是施工隊(duì)，那么問題就變成了施工隊(duì)的問題，如果是用戶，那么就要看看用戶到底有什么困難，絕對不是要一個錘子這么簡單。這也說明了，問題的主體對問題的邊界確定有多么的重要。
當(dāng)明白了問題的主體，我們才可能真正的認(rèn)識問題是什么。因?yàn)閱栴}的主體是問題的隱含邊界，邊界不確定下來，問題就是不確定的。一旦確定了主體，剩下的就是去搞明白主體有哪些問題。這個就比較直接了，常用的方式就是直接面對主體進(jìn)行訪談，深入到主體的工作生活當(dāng)中，體驗(yàn)并感受這些問題，甚至通過數(shù)據(jù)的反饋來定位問題。這個大家就比較熟悉了，我就不展開了。
一般來說，從問題暴露的點(diǎn)，一點(diǎn)點(diǎn)去溯源查找，一定會找出來誰的問題，以及是什么問題。最壞情況就是當(dāng)我們時間或者能力有限，實(shí)在是無法定位出是誰的問題的時候，比如系統(tǒng)出故障，也就意味著我們無法根本解決問題。這時最好的辦法就是去降低問題發(fā)生所帶來的成本，盡量去隔離問題影響的范圍。給我留出時間和空間去識別真正的問題。
總結(jié)一下，要正確的認(rèn)識問題，需要問兩個問題：
1.這是誰的問題？
2.有什么問題？
當(dāng)?shù)玫降幕卮鹗侵е嵛岬臅r候，我們就知道正確的方向在哪兒，以及需要做哪些事了。以我的經(jīng)驗(yàn)，問題1會花比較多的時間，也是支支吾吾最多的地方，因?yàn)榧軜?gòu)要解決的問題都是人的問題。但是一旦確定了答案，問題2就會變得非常容易?？梢赃@樣說，架構(gòu)師的能力大部分會體現(xiàn)在問題1的識別上。
第三十四屆CIO班招生
北達(dá)軟EXIN網(wǎng)絡(luò)空間與IT安全基礎(chǔ)認(rèn)證培訓(xùn)
北達(dá)軟EXIN DevOps Professional認(rèn)證培訓(xùn)
責(zé)編：yangjun
免責(zé)聲明：本網(wǎng)站（http://www.www.gypb.net/）內(nèi)容主要來自原創(chuàng)、合作媒體供稿和第三方投稿，凡在本網(wǎng)站出現(xiàn)的信息，均僅供參考。本網(wǎng)站將盡力確保所提供信息的準(zhǔn)確性及可靠性，但不保證有關(guān)資料的準(zhǔn)確性及可靠性，讀者在使用前請進(jìn)一步核實(shí)，并對任何自主決定的行為負(fù)責(zé)。本網(wǎng)站對有關(guān)資料所引致的錯誤、不確或遺漏，概不負(fù)任何法律責(zé)任。
本網(wǎng)站刊載的所有內(nèi)容（包括但不僅限文字、圖片、LOGO、音頻、視頻、軟件、程序等）版權(quán)歸原作者所有。任何單位或個人認(rèn)為本網(wǎng)站中的內(nèi)容可能涉嫌侵犯其知識產(chǎn)權(quán)或存在不實(shí)內(nèi)容時，請及時通知本站，予以刪除。
搶沙發(fā)
