如何評價專案的好壞(從客戶角度)功能：按期，效益，體驗，穩定性(效能)，擴充套件按期完成功能是一定的，不然會被辭退，績效考核才是最重要的
穩定性的指標：可用性績效考核指標：(分鐘-故障分鐘)/總分鐘
乙個專案的開發流程：需求(文件)
->>>原型(需求可行性)
->>>設計（技術選型）(技術，測試人員測試，ui設計) ui，里程碑，原型對客戶重要，影響體驗
->>>分工開發(分階段，里程碑，哪個階段完成哪些東西)
怎樣把專案做好（高質量）客戶認同
最重要的是要讓客戶看到專案的可控性，需要做到以下三點
1.需求階段：
三家公司，都能做到，選哪乙個
抓住客戶的需求，如何做到
業務決定技術(乙個好的架構師很重要)
認同客戶想法：
哪些要砍掉，哪些保留，哪個ui適合你
不是只是完成技術任務，那是初級開發人員幹的
好的程式設計師是告訴你需求，自己去處理
2. 原型階段：
生成草圖，可能只是某個控制項，如何跳轉，布局
理清流程，整個流程過一遍
3. 設計
ui：使用者喜歡，和潮流符合，不落後
動畫，特效
技術：安全性、業務邏輯序列圖看得懂
功能可以橫向擴充套件
不會導致系統完全崩潰,如資料庫資料丟失
可測試的
做到上面三點，讓客戶明白團隊在專案的每乙個環節都把控的很好，也就會放心了。
出故障如何快速解決問題：按分鐘算故障，自己能不能公升值很重要如何避免？1. 入口校驗，資料進入時校驗,也就是伺服器校驗
有人說客戶端校驗就行，用所謂的提高效能來說話，其實這種說法是大錯特錯的。
如果乙個專案是因為進行了伺服器校驗拉低效能，那這個專案一點是搞笑的，連**層面上的故障都不能排除，還能幹什麼呢？
或者說，明知道錯誤的資料很有可能容易出現故障，可以及時處理，但是就是不處理，這是多麼的愚蠢，難道要等到以後出錯了才處理嗎？
2. 異常：日誌，可查
日誌是一定要有的，在可能出錯的地方都給打算日誌。
3. 專案流程方案部署文件清晰，知道是哪個地方有問題，部署架構圖一定要有
部署架構圖有什麼用？能讓我們了解這個專案的架構，通過日誌能夠知道定位出錯位置
cpu佔用率飆公升，磁碟空間達到90% ，jdk full gc消耗時間長，響應時間變長
使用者數新增的減少(註冊故障)
如何監控：涉及呼叫鏈，每個介面的呼叫數記錄，智慧型攔截ip，每個過程跟蹤
記得開會的時候有人說專門找人定時檢視日誌，leader反問：你覺得可能實現嗎？他自己都笑著說不能。
所以說監控系統是很重要的，大家很容易忽略
如何快速解決？1. 制定應急方案，備份：每個部分都有備份(熱備)，可以回滾
灰度發布，有100萬，用1萬使用者用到新發布的版本上，其他用舊的，幾天沒問題，轉為50%，最後再100%
2. 異常日誌：能打的都打，日誌不僅要包含業務的，還有檢視與sql連通日誌 ，gc日誌
我們最常見的就時聽到夥伴說在我這裡還跑的好好的，到你那裡就不行了。
不允許e.printstack();
3. **
解決使用者的什麼問題
講解專案內容是有方法的，不要這講一塊，那講一塊，不僅別人不懂，連自己都搞懵了。
如何做好專案？
如何評價專案的好壞 從客戶角度 功能 按期，效益，體驗，穩定性 效能 擴充套件 按期完成功能是一定的，不然會被辭退，績效考核才是最重要的 穩定性的指標 可用性 績效考核指標 分鐘 故障分鐘 總分鐘 乙個專案的開發流程 需求 文件 原型 需求可行性 設計 技術選型 技術，測試人員測試，ui設計 ui，...
如何做好專案需求分析？
專案需求分析，看了聽棠的 客戶需求何時休 深有感觸，何曾自己不是被這個問題整天困擾 客戶需求，為什麼總在變阿？做專案真辛苦阿！這樣的感嘆 整天都掛在口上。客戶需求變動確實是乙個軟體開發永遠不變的話題。為什麼小的軟體企業面對經常變動的需求是如此的狼狽？到底要怎麼做才能滿足客戶的需求？聽棠的 客戶需求何...
如何做好「老闆專案」
老闆專案，就是指老闆突然跟你說，我們要做個什麼什麼，然後你只有執行的份兒 的專案。什麼，你們公司所有專案都是老闆專案？很正常，那我們更應該聊聊這個話題了。先來一點科普，做專案的目標無非是多快好省 範圍多 時間短 品質高 資源省。但又要馬兒跑又想馬兒不吃草的事情是沒有的，有理智的老闆也都明白這一點，所...