覆盤之前遇到的兩個問題：
1. 為什麼視覺設計稿很漂亮，產品做出來體驗差？
2. 為什麼我們覺得沒問題，而其他人都在擔心。
終極原因是：沒有考慮到最壞的情況，所看到的想到的，可以認為都是最好的情況。
第乙個問題：為什麼視覺稿設計得很漂亮，做出來的體驗差？
視覺稿實際上是呈現了「最正常」、「最美」的一面，而實際做出來的，往往不在這乙個狀態。這就像開演唱會時，整個足球場上萬人，而大家關注的只是那個明星，但是明星不能代表普通觀眾，而視覺稿是這個明星，是最閃耀的點，而產品是整個足球場。閃耀的點可能是無瑕疵的，但是整個足球場肯定是亂糟糟的，可能近距離說話的聽不到。再模擬一下，整個產品是乙個線段，而視覺稿僅僅是0.618的這個**分割點。
實際例子就是，對於乙個平台軟體，比如監控部分，比例條的顯示，如果四個比例條放到一起，互動是長短不一，但是確是最好的排布，看起來非常美觀。而實際情況可能是其中乙個很短，另外乙個極長。那麼實際顯示效果就不如互動那麼美觀。如果這個比例條同時用了漸變，那麼美觀程度會進一步下降，甚至顯得雜亂。
第二個問題：為什麼我們整合測過通過，系統測試通過，別人還不敢用？
可用性上：這個問題實際上也是同樣的答案，整合測試、系統測試都不是最壞的情況，最壞的情況永遠都在意料之外：比如一些基礎軟體平台，出了問題如何第一時間響應？不出問題如何放心？斷電能否正常恢復？恢復不了怎麼辦？資料是否會丟失？丟失了怎麼找回來？是不是每一部分都具有高可用性？
功能上：這些功能是研發認為「應該有的」，還是「使用者真正需要的」？資源投進去使用者認不認可？消耗多少資源帶來多少收益？風口過了沒有？產品做出來風口還在不在？外部的阻力是什麼？內部的阻力是什麼？ 可能根本還到不了競爭對手這個層面，就會被別的因素拍死。就像要想代表中國桌球隊出征奧運會，得先把自己隊友都打趴下。內部矛盾、阻力、資源、支援是第一位解決的，很多產品不是死在競爭對手手中，而是死在襁褓中。不要想著長大後如何和別人打架，想想著怎麼活下來，怎麼活到一歲，怎麼活到兩歲，怎麼活到4歲......
做產品重要的一點：把最壞的情況列舉出來，想全面。不要想好的一面，想最壞的一面。
產品經理初體驗 需求的誕生
這段時間深刻的感受到了需求的誕生簡直是無所不在！之所以有這種感觸，是因為接到了人行的紅標頭檔案。在這些檔案中，真的是有無窮多本來認為沒有需求的地方，出現了各種各樣的需求。有的甚至是可以開出一條產品線！由於我是做傳統銀行軟體的，所以對於人行的紅標頭檔案那是見得多了。本次說的這份檔案還是去年下發的。下發...
Get和Post初體驗
http定義了與伺服器互動的不同方法，最基本的是四種，分別為 get post delete put。代表著對伺服器資源的查改刪增。在專案中，我主要接觸post get，這次就整理這兩個。一 post 1 post一般用於提交資料塊，上傳檔案，放在http包中。2 post的content type...
阿里雲產品公測 雲引擎ACE初體驗
第一步，在阿里雲管理控制台頁面申請公測許可權！耐心等待許可權通過，進入雲引擎管理控制台jgn2ql 進入應用列表 點選右上交的按鈕xj jdch 這是我建立的例項 hx p4 l 建立實體 i h9v 然後是建立版本，上傳 包an lk 上傳成功後，就可以到 應用中心，部署應用了。需要等幾分鐘。我上...