這一段時間來，一直在考慮快速改進產品的事情。web 產品的改進是個麻煩事情。遠不是收集一大推需求列表，然後三下五除二修改上線那麼簡單。
產品的改進，也是個不停作選擇的過程，不要被使用者牽著走，尤其注意那些專家型使用者的意見，是很好的參考，要尊重他們，盡快給他們反饋，但未必要全盤採納。如果真的存在易用性問題，使用者會從更廣範的角度不停的反饋給你。不能看競爭對手的，因為他們可能在跟你學呢。
改進的前後，資料收集的豐富性將影響最後改進的結果。但不能完全跟著資料走，因為你收集的資料可能不是準確的。此外要記住，不要事先定一些資料上的指標，比如註冊增長多少啦，流失率減少多少啦，沒有意義。有些改進，內部資料上未必會好看，但使用者會叫好。要知道，越大的公司，資料越是用來唬人的。反正決策層沒幾個人懂資料。
針對產品改進，要想做出正確的決定，只有對產品本身的熟悉程度是不夠的。其實越了解自己的產品，越容易做出有失偏頗的決定。而如果能對使用者加深了解，會有助於做正確的事情。但必須承認，了解使用者可不那麼容易。
既然是改進，就不是翻新，就不要做大專案，」大山臨盆」的事情常有，只是失敗過後沒有人好意思說。快速上線，快速反饋，不但使用者容易接受，團隊也會從中受益。
好的技術人，能讓產品變得更好。而團隊越大，產品會變得越糟。三個和尚沒水喝的故事永遠都適用。
說到底，都是可意會不可言傳的廢話。如人飲水，冷暖自知。
–eof–
災難究竟要多麼慘痛，才能不讓它再次發生？我的朋友們阿，答案在風中飄揚。
google+
產品原型Web展示
前言 當產品原型設計出來後，會放置在linux伺服器上的路徑下，為了讓相關的研發人員檢視到需求，進行相應的作業，需要搭建訪問其原型路徑的httpd服務 搭建httpd流程 前提產品原型放置在阿里雲ecs伺服器上 產品原型文件路徑 root nature docs pwd mnt web www pr...
不斷的測試，產品就會不斷的改進
什麼是軟體測試？關於軟體測試的定義，比較權威的是ieee在1983年提出的 使用人工或自動手段來執行或測定某個系統的過程，其目的在於檢驗它是否滿足規定的需求或是弄清預期結果與實際結果之間的差別。軟體測試的目的？第一 確認軟體的質量，確認你所期望軟體所做的事情和確認軟體以正確的方式來做了這件事情 第二...
Web產品的常見問題
15.安全考慮 直接url鏈結檢查 在web系統中，匿名在位址列直接輸入各個功能頁面的url位址，檢查系統是否處理了許可權控制 預防方法 開發 走查的方式確認所有頁面的具有許可權驗證邏輯 測試 獲取所有系統url，在非登入情況下進行遍歷截圖，或關鍵字判斷，驗證非登入狀態下無法訪問具有訪問許可權限定的...