如何評價專案的好壞(從客戶角度)
功能：按期，效益，體驗，穩定性(效能)，擴充套件
按期完成功能是一定的，不然會被辭退，績效考核才是最重要的
穩定性的指標：可用性
績效考核指標：(分鐘-故障分鐘)/總分鐘
乙個專案的開發流程：
需求(文件)
->>>原型(需求可行性)
->>>設計（技術選型）(技術，測試人員測試，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，里程...
如何做好專案需求分析？
專案需求分析，看了聽棠的 客戶需求何時休 深有感觸，何曾自己不是被這個問題整天困擾 客戶需求，為什麼總在變阿？做專案真辛苦阿！這樣的感嘆 整天都掛在口上。客戶需求變動確實是乙個軟體開發永遠不變的話題。為什麼小的軟體企業面對經常變動的需求是如此的狼狽？到底要怎麼做才能滿足客戶的需求？聽棠的 客戶需求何...
如何做好「老闆專案」
老闆專案，就是指老闆突然跟你說，我們要做個什麼什麼，然後你只有執行的份兒 的專案。什麼，你們公司所有專案都是老闆專案？很正常，那我們更應該聊聊這個話題了。先來一點科普，做專案的目標無非是多快好省 範圍多 時間短 品質高 資源省。但又要馬兒跑又想馬兒不吃草的事情是沒有的，有理智的老闆也都明白這一點，所...