工程師思維，做不出好產品？
這不是一個雞湯文，也不是警世文，這文章沒什麼結論和重點，你不會從這篇文章中獲得什麼領悟。
恭喜你，你選擇繼續往下看，代表你對這標題也有一定程度的好奇，或許你也有同樣的疑惑？
「你的想法太工程師了，不適用在「一般」使用者上，怎麼可能用一般使用者的角度去思考產品呢？」會這樣說可能是你就是從事市場或和技術半毛關係都沒有的崗位上。
我覺得這個指控實在很莫名其妙，農夫講出關於種樹的話，漁夫講出關於撈魚的話，本該是天經地義的事，然後現在我們要進森林開墾，憑什麼漁夫說的就是道理，農夫說的就是歪理呢。
況且重點還是，最後要操刀的是農夫啊！
世間上的事，都不是完全都是兩極化的對與錯，一件事通常面向都會超過一個，就取決於那是站在那一面觀看，我要說的正是，軟體工程師如何設計好產品。
馬雲說過一句差不多這樣的話，他說：他就是 QA，他不會用的產品，大概就不是什麼好產品，因為大部分人都和他一樣，是一個不懂技術的人。
就單憑這句話，很多人就會拋開技術思維，拋開一切，就只想自己要做的「大方向」就好，那是當然的，做為一個領導，作為一艘船的導航，確實需要一個明確的方向，大家就盡力前進。但前進的動力來自哪裡呢？你可以知道人家背後有多少水手不斷研究划船的方法，才可以說出這句那麼鏗鏘有力的話。
「我考第一名，我從來不念書！」
馬雲那番話字面上理解，那個思維是成立的，但事實上，越是簡單的產品，RD 就必須花更多的時間和精力去思考，如果做出「簡單」而產品的「直覺和簡單」僅僅只是技術演進的結果罷了，千萬不要忽略過程。
我只想要飛，就往斷崖跳，就肯定會死的。想要飛的心情我理解，但我們能不能坐下來談談如何辦到「飛」這回事呢？
而越簡單的東西，越難做出來。
有一個箱子，裡面很冷，食物不會壞；一個箱子，裡面有畫面，哎！箱子好佔空間，做到跟牆一樣薄行不行？我想要一個放在口袋的電腦，看到的臉就開鎖，啊，要確保一定會開喔，不要讓我 demo 的時候開不了。
概念誰都會說，根本不需要花很多時間在這個地方上。
一個好產品，重點是要解決問題，是不是廢話？是。
那麼要解決問題，要靠技術？還是靠想法？…
你開始質疑自己了吧，你沒有馬上選技術，或者你選了想法？
因為一般人是不會有這個認知的。你不用懷疑，好產品解決問題的重點，就是技術。不是想法。這兩者有什麼區別？會講不會做，就叫做想法；會講也會做，那是技術。但產品人員最愛放在嘴巴的一句話就是「技術不難，可以做得出來」、「技術可以辦到」大部分的概念都是來自於別家產品，至於如何實現，還是一種跟網戀一樣的概念，還沒見過本人，但是照片看起來還不錯。
時至今日要找出，只要好點子，就有好活路的故事太少了，技術突破不了，就是一個「和別人差不多」的東西。既然是差不多，就沒有必要多一個，面對消費者，你要怎麼說服人家用你家的產品呢？
我寫了一大堆都是在靠北，沒什麼重點，那我先講一個重點。
「講 HOW 不要講 WHAT 和 WHY」
一個組織要做什麼事，應該不難決定，那就是一個決定。
試想想，最近我有個朋友在想開餐廳的事，我就默默的觀察，他會如何思考開餐廳的流程。
他從選單一路講到店面，從行銷和定位，說到 SWOT 和五力分析。都還沒說到，如何做飯這個點上。雖然只是比喻，但是你可以想像餐廳本身最關鍵的除了價格，就是味道，好吃！最直接的競爭力，就是要
「HOW 做到很好吃」一個點就好。
而 HOW 的精髓，就是技術（技巧），做菜需要技巧；寫程式也需要技巧，如何用什麼工具解決什麼問題（這是重點，我只是沒有特別強調）是很重要的一個概念。
就跟為什麼這個控肉飯那麼好吃，它是怎麼辦到的？！靠，那就是靠技術啊，每天做研究啊，研究又試做啊，然後失敗又再來啊，不然你以為咧。
至於說，技術本身是沒有意義的，除非它用來解決問題。
那就是一個重點了，要講出問題在哪裡（WHAT），和為什麼會發生（WHY），即便這些很有可能都是在猜的，要講出幾個點那也不是一件難的差事，只差你願不願意面對而已，因為就算你說錯了，也沒有什麼證據證明你是錯的，你頂多只能懷疑，這個傢伙在胡說。
技術本身是沒有意義的，就讓我想起一個名人說的話，錢本身是沒有意義的，除非你利用它！說到我帳戶有幾萬千還沒開始「利用」一樣。那個重點不是這句話，重點是我沒有錢啊！
技術本身有沒有價值，我不好說，但重點是，我們要先研究出技術啊！
而很多時候，我們只需要一個選單，就那麼簡單。但是可怕的事還不是沒有選單，而是有選單還有一疊厚厚的明細，隨著不懂做菜的人進廚房，然後還幫你為每個做菜步驟列名時間和順序，然後當你仔細一看，那個根本不是做菜步驟，是上菜和吃飯的步驟，裡面寫的跟做菜一點屁關係都沒有。
這群人根本不在乎怎麼做菜啊。
但不要誤會，半點也沒有怪他們「為何不關心」做菜這事上。
因為很多時候，甚至極大部分時候，工程師也是不關心如何「上菜」的，也不關心味道如何，只要時間內上菜，老闆沒有埋怨，客戶沒有中毒死，更也別說口碑好不好，有的廚師本來就是抱著能吃就好的心情做菜，竟然吃不死，就是好料理啦。
但這主題是說「好產品」就不是能吃就好的東西了，要對味道和整個用餐過程都很有要求。
就算不是五星，也要老闆親切啊，服務態度 UX 要好，UX 不是一個人的工作，UX 是一個團隊的工作，一個集體帶來的效益。大部分團隊就是設計出圖，PM 畫 flow，RD 寫 code；就跟打傳說有人坦克，有人輸出，有人牽制，但如果要勝出，就可能互相幫打，坦克輸出會補刀，輸出火力也要幫忙牽制，但是如果規定了坦克就只能捱打，牽制就只能在那邊躲起來發功，那就死定了。
分工的結果就如參加一個比賽，的確是順利的把比賽結束了，但也別想說有什麼驚喜的表現。
寫程式的人就會用工具了，尤其是前端，現在光是設一個開發環境，就用了一堆東西，有些太久沒有用它還更新改版了，有天有個朋友請我幫忙做個事，我就拿著筆電狂 Key，滴滴答答的，一個多小時之後，我就「yeah」喊了一聲，他就問「你弄好咯，感謝啦」
我說「還沒，但可以開始弄了！yeah」
但我以一個消費者的立場，做出產品，至於好不好，是消費者自己的看法。千萬不要一直和我說你東西有多好吃，我自己有嘴巴好嘛！如果不好吃，你和我說一百遍也不會好吃啊。
相關推薦
工程師思維，做不出好產品？
這不是一個雞湯文，也不是警世文，這文章沒什麼結論和重點，你不會從這篇文章中獲得什麼領悟。 恭喜你，你選擇繼續往下看，代表你對這標題也有一定程度的好奇，或許你也有同樣的疑惑？ 「你的想法太工程師了，不適用在「一般」使用者上，怎麼可能用一般使用者的角度去思考產品呢？」會
好的程式設計師做不出好的軟體設計
你不能看到一個程式設計師還不錯，就把他推到系統分析師、軟體設計師或軟體架構師的位置上。 如果你在團隊或公司裡尋找一個能勝任軟體架構師或設計師這樣重要位置的人時，首先出現在腦子裡的想法通常是在程式設計師中選一個最好的。別這麼幹。這樣的位置不是隨意的找個不錯的程式設計師就能勝任的。把你最資深的程式設計師晉升到這
幻想迷宮（或無限迷宮）——因為邏輯不清而做不出的典型
open while closed div set sta click memset tdi 我是復制了三塊原矩陣。開始時復制了四個，一個方向一個，過了樣例但四十分。後來調來調去，判斷能否脫出的條件也換了又換，終於…… 1 #in
神戶制鋼坑了500家企業 百年老店為何走上邪路?（企業經營再艱難，也不能降低產品質量，甚至偷工減料，同樣適用於IT行業）
目前 海外 自己 不銹鋼 但是 amp 數據 熱鬧 2015年 神戶制鋼這顆爛蘿蔔，拔出它之後帶出的泥越來越多。上周五社長川崎博也又開了記者會，再次道歉，而受到其數據造假影響的客戶數量也從200家飆升到500家。日本政府給神戶制鋼兩周時間調查，還要在一個月內公布原因和對策。
AC自動機--summer-work之我連模板題都做不出
aca cstring 指導 www. sum gets font 兩個 deb 這章對現在的我來說有點難，要是不寫點東西，三天後怕是就一無所有了。 但寫這個沒有營養的blog的目的真的不是做題或提升，只是學習學習代碼和理解一些概念。 現在對AC自動機的理解還十分淺薄，
Sublime Text3執行python時，顯示不出影象
版本：python3 解決方法： 找到exec.py檔案 路徑： 我的是：…\Sublime Text 3\Packages\Default C:\Users\apple\AppData\Roaming\Sublime Text 3\Packages\Defa
以匠人之心，做最完美的產品
匠人精神在我看來就是：一生只做一件事，並將這件事做到極致，在我看來，用心去做好一件事比做了很多很多的的事情更重要。這也是我對自己的要求與鼓勵。 可能會有人問，“如果堅持了一輩子，卻沒有名利雙收，這樣的堅持還算成功嗎？”“如果堅持了一輩子，最後依然默默無聞，這樣
數字滾動效果，臨時寫的，可能不太好
<!DOCTYPE html> <html lang="en"> <head> <meta charset="UTF-8"> <title>數字滾動</title> </head> <body>
沒有在2016年當過前端程式設計師的設計師不是好產品經理
黑客與畫家——UI設計師的故事 今年我那個不知道我曾經學過繪畫的技術宅男票過生日的時候，我把我倆一幅合影畫了出來送給他，他明顯被理工女的手繪水平嚇壞了。我過生日的時候他一臉壞笑送我一本《黑客與畫家》，還說“我是泡看雪的黑客，你是泡站酷的畫家” 公司的UI妹子回老家相親去了，改行嫁人似乎是IT女的宿命，然而前
為什麼程式設計師寫不出好程式碼？
每個開發者在編碼時，都希望程式碼像水管的水一樣源源不斷的流出，思緒不被打斷。但在現實開發中，經常會由於一些事情突然中止或停下。本文就總結了現實工作中，影響編碼進度的15個“攔路虎”。 1.開會 停止手頭的編碼工作，去參加會議。程式設計師或許不會相信，他們可能已經在會議室花費了數週或數年
android studio 點選執行按鈕無反應，調不出模擬器
最近發現個問題，在用AS時發現，點選執行或者debug按鈕時，沒能像以前一樣，正常彈出模擬器。 找了很多辦法也沒有解決。後來，索性刪除模擬器重建，問題得到解決。 刪除方法： 刪除 C:\Us
AndroidStudio 百度地圖在打包後失效，顯示不出地圖。
今天下午碰到的，我簽名後的apk，一切都正常，但是到地圖這一塊的時候就出現了問題，地圖老是顯示不出來。顯示的是網格。我在網上找了好多的資料。最後整合各位前輩的經驗，以下就是我的解決方案：
nagios能正常啟動的情況下，發不出郵件
一. 檢查sendmail或其他郵件服務能否正常發郵件（如果sendmail發郵件異常慢，則看我“網路服務的一篇文章http://blog.csdn.net/miltonzhong/article/details/10951347”） 二. 確定nagios配置檔案正確
為什麽學習C語言這麽久，看的懂代碼，做不出題沒項目
量變 技術 題目 而且 學c++ 運行時 暫時 功夫 自己的 我看得懂別人的程序，可是我自己卻寫不出來，我應該怎麽辦啊？你了解這些嘛？ 你只是能從別人書寫的代碼知道每一步都做些什麽吧？ 你明白別人的解題思路嗎？ 你知道別人為什麽要用那樣的算法嗎？ 如果你看著題目，你能寫出實
現在做前端的人那麼多，好的前端工資到底有多高，看了這個圖，當場說不出話！
首先,現在軟體行業發展趨勢，其次，一個軟體都快飽和的年代，人們的要求不再只是停留在功能上，更多的是體驗感，不只停留在html，更加追求在css，js上的效果和效能。所以：首當其衝的是樣貌——前端。在這裡我還是要推薦下我自己建的web前端開發學習群：617327703，群裡都是
產品經理如何與強勢的技術溝通？ 技術比較有資歷，會以技術無法實現等方面的原因拒絕處理產品提出的需求。 你們是否遇到這樣的技術？ 產品懂技術的話，是不是會好一些，因為可以和技術說“行話”了，並且產品懂技術就不會被忽悠了。
intern 世界 自己人 做好自己 最重要的 叠代開發 對比 不一定 制造 PM在YY...作為強勢的技術來回答一下吧。說明白WHY，HOW，WHAT就好了。 我想點兩個贊，u can u up，no can no bb 什麽的。 微軟的win8之父年輕時候也是一個PM應
不想做架構師的程式設計師不是好碼農，擡高身價36招只取一招
工作了挺久，發現有個挺有意思的現象，從程式設計師、高階程式設計師，到現在掛著架構師、專家之類的頭銜，伴隨著技術和能力的提高，想不明白的事情反而越來越多了。 文末有面試題以及架構資料，需要的可以去領取 一、來自架構師對架構的解讀 架構師是一個充滿挑戰的
不懂業務創新的工程師，不是好的架構師 | 深度
阿里妹導讀：對於高階的工程師來說，光有持續交付價值的能力還不夠，我們必須保證交付的東西是有用的，能帶來真正的價值。持續交付和業務創新是相互關聯，相輔相成的。持續交付是業務創新的基礎，而持續交付的收益最後要落實到業務創新中去。 如何在深刻了解業務的基礎上，完成有效的業務創新？下面為
想不出一個好的標題，就用這個吧
問題描述： 某城市最高的樓只有一部電梯。該電梯和一般電梯不同的是它依照輸入樓層數的先後次序執行。電梯最初在0層。執行完一個輸入序列後就停止在該樓層，不返回0層。編寫程式計算電梯執行一個序列的時間。每