按照架構(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)容時,請及時通知本站,予以刪除。