做軟件開發，其實就是用軟件的手段完成業務需求，而業務需求一定是用來解決某些問題的，用戶的問題、老板的問題、運營的問題等等。軟件工程師常常疲于奔命，開發各種需求，但是這些需求到底想要解決什么問題，開發完成以后是否真的解決了問題，實現了功能的自身價值。對于這些問題，很多開發者常常既不了解，也不關心。 我們講一個小故事吧。北歐有一個度假勝地，是歐洲人民夏天避暑度假的好去處，去度假勝地需要經過一個長長的隧道，隧道的工程師為了保證隧道的安全使用，在隧道入口處立了一塊牌子，寫著：請打開車燈。 游客們開著汽車，打開車燈，穿過隧道，到達度假勝地，愉快地去玩耍了。而等他們要回去的時候，有些人卻發現車子無法啟動——他們忘記關閉車燈，汽車電池耗盡了。小鎮的警察們只好開著自己的警車四處為游客們充電，疲憊不堪。而沮喪的游客們則在回去以后四處抱怨，分享他們糟糕的旅游經驗，導致小鎮旅游業大受影響，鎮長壓力山大。 于是人們找到隧道的工程師，要求他在隧道的盡頭再立一塊牌子，寫上：請關閉車燈。工程師照做了以后，卻發現麻煩來了：夜晚穿過隧道的游客看到牌子，雖然非常疑惑，但還是按照指示關閉了車燈，結果卻發生了車禍，麻煩更大了。于是工程師不得不寫上：如果是白天，請關閉車燈。結果有的游客沒看到隧道入口的牌子，卻看到了隧道出口的牌子，同樣疑惑。為了解決新問題，工程師不得不在牌子上繼續寫下去?? 這個場景和軟件工程師們日常的工作場景是不是很相似？總有客戶、老板、產品經理過來跟你說，這里需要這樣一個按鈕，那里需要這樣一個功能。你照做了以后，發現帶來了更多的麻煩，為此，你不得不在代碼里不斷地寫 if/else。你不是在解決問題，而是在制造問題。 回到這個故事，我們重新思考一下：這是誰的問題？誰能夠解決這個問題？如果這是鎮長的問題，那么能不能讓鎮長在停車場修建充電樁讓游客們充電？如果這是警察的問題，那么能不能多招一個警察，專門幫游客充電。如果這是游客的問題，能不能在隧道出口立一塊牌子，寫上：你的燈亮著嗎？提醒他們問題的存在，讓他們自己去解決問題。 所以，你在每次解決問題的時候，是否想清楚了問題的本質究竟是什么？這是誰的問題？誰能解決這個問題？你在為誰解決問題？這些問題決定了你是否能真正解決問題，為公司創造價值，也決定了你是否能選擇最合適的技術去解決問題，進而提升自己的技術能力以及自己的技術影響力。 作為一個軟件工程師，如果只是聽從別人的指令開發代碼，卻不了解這些代碼究竟想要解決什么問題，那么很多時候你是在制造問題，而不是解決問題，你加班加點辛苦工作只是在為公司制造麻煩。而對于你自己而言，日復一日重復執行解決方案，距離你成為一個技術專家也越來越遠。 關于如何發現真正的問題，這里有幾個小的建議，供你參考。 ## 不要把解決方案當作問題的定義，而忽略了真正要解決的問題是什么 我工作這么多年來，經歷過很多公司，參加過很多次技術會議，就我所見，幾乎所有的技術會議都沒有有意識地討論過一個主題：這個會要解決的問題是什么？ 很多時候，會議一開始就討論解決方案。有的會議上，產品經理上來就說我們需要一個什么樣的功能，請技術部門給一個技術方案和工作量評估，至于這個功能用來解決什么問題，給用戶或者公司帶來什么價值，幾乎很少說明。有的會議上，架構師上來就說我們打算推廣一個什么樣的技術，請相關技術團隊配合，至于這個技術用來解決什么問題，給用戶或者公司帶來什么價值，也幾乎很少說明。 所以，這樣的會議，討論的重點就是解決方案本身：這個功能怎么做，這個技術怎么應用落地。而不是討論真正的問題是什么：為了解決真正的問題，這個功能是不是必須要做，有沒有更好的解決辦法；這個技術是不是必須要上，能不能帶來足夠的價值。 這樣的會議，即使有爭論，爭論的也是解決方案本身，而不是問題。關于解決方案的爭論又往往陷入各種細節之中，經過一番討論，更加不知道要解決的問題是什么了。 所以，以后參加技術會議的時候，也許不需要急于參與到討論之中，而是要多思考：這次會議把要解決的問題說清楚了嗎？需求背后真正要解決的問題是什么？當前討論的內容真的能解決問題嗎？ 想清楚了這些，你會對當前的局面有更加清晰的認識，你會發現其他與會者的激烈爭論，都是在盲人摸象，自說自話，彼此的關注點根本不在同一個問題上。 這個時候，你出手把大家拉回到問題本身，主導會議的討論方向，你就會成為最有技術影響力的那個人。 ## 你不需要去解決別人的問題，你只需要提醒他問題的存在 在有關育兒教育的經典書籍中，對于如何面對嬰幼兒的哭鬧，比如小孩子摔倒了，開始哭鬧的時候，給出的解決方案是，不要立即鼓勵小孩子，要讓他們勇敢一點，自己爬起來。更不要斥責他沒出息，走路不小心什么的，而是把他抱在懷里，輕輕在他耳邊說，（爸爸）媽媽知道你摔疼了。重復這句話，直到小孩子不哭了，然后再跟他說，你是個勇敢的孩子，你可以自己面對的，下次你可以自己爬起來。 在這個例子中，小孩子摔倒了哭，是誰的問題？當然是小孩子自己的問題，但是他太小，又處在巨大的挫折之中，無法獨自解決問題。所以，父母這時候要做的是，安撫好孩子的情緒，告訴孩子，爸爸媽媽和你在一起，理解你的痛苦。等他從挫折中恢復過來，不哭了，然后鼓勵他，讓他自己解決問題。 我們開篇那個隧道車燈的故事也是如此，忘了關閉車燈導致汽車無法啟動是誰的問題？是游客自己的問題。誰最適合解決問題？是游客自己，他只需要關閉車燈就可以了。所以鎮長設立充電樁，多招一個警察幫游客充電，都使問題更加復雜。但是游客又沒有意識到問題的存在，所以不去解決問題。那么要做的事情就不是去幫游客解決問題，而是提醒他問題的存在：你的燈亮著嗎？游客意識到問題的存在，他就會自己解決問題。 軟件需求開發中，也有很多幫用戶解決問題的場景。日常開發中，產品、運營、開發、測試、運維，也有很多交互合作，需要互相幫助；哪些問題對方可以輕易解決，哪些問題應該通過修改軟件功能來解決，應該思考清楚。 ## 魚是最后一個看到水的，身處問題之中的人往往并不覺得有問題 身處問題之中的人常常并不能感知到問題的存在，正如身在水中的魚兒看不到水一樣。太多的問題被人們的適應能力忽略掉了，直到有人解決了這些問題，身處其中的人才恍然，原來過去的方式都是有問題的。 所以，如果你到一個新環境中，發現存在著一些問題，而身處其中的人卻熟視無睹，往往不是他們有問題，也不是你有問題，可能只是他們已經適應了問題的存在，而你還沒有適應。 關于問題的定義有個公式：問題 = 期望 - 體驗。 到一個新環境中，大家體驗差不多，但是你的期望和其他人不同，你就會感受到問題。而這種感受則可能是你出人頭地的機會：如果你解決了這些問題，其他人也會明白過去的方式是有問題的，而你就是那個解決問題的人。 ## 小結 一個技術，是不是真的能解決問題，是衡量一個技術是否有效的主要標準。而業務究竟遇到了什么問題，用什么樣的技術才能真正有效地解決問題，是工程師在進行技術落地之前必須要考慮清楚的事情。 不去思考，真正地面對問題，總是試圖用自己擅長的技術，或者業界熱門的技術解決工作中看似一樣，其實大不相同的業務問題，既不能夠真正解決問題，為公司創造價值，也不能夠提升自己的技術水平，獲得真正的進步。 如果自己用技術總是能有效解決問題，在這個過程中，也會不斷增強自己的技術自信，知道自己用技術可以創造真正的價值，自己可通過技術參與到改造世界的過程中，也會樹立起技術的信仰。不會總是猶豫，自己是不是要轉管理，是不是要轉行。