項目上線有一段時間了，上線後大家忙着改bug，忙着彙報，忙着二期的規劃，一直沒有坐下來一起聊聊。
上週，我還是決定花費大家半天的時間，組織開了迭代回顧會。
迭代回顧會對於敏捷來講，是一個很重要的實踐，但其實不提敏捷的時候，我們也在做，只是有個更普通的名字，叫項目總結會。(迭代回顧會的實踐方法見文章最後)
會上，當我們回顧了項目過程時，發現一個重要問題，這個問題就是：經常性的，我們忽略了或忘了目標，這裏的目標應該有但不限於以下內容。
一、 業務目標
說出來，大家可能都覺得不可思議，沒有目標，那項目組最終要交付什麼樣的系統？項目組又在爲了什麼而忙？
可事實就是如此，很多時候，我們盲目的就開始了一個項目，然後盲目的就做出一堆功能。
真實情況是這樣的，我們的研發團隊不是一個真正的互聯網產品團隊，雖然有產品經理的角色，也基本是技術主管或經理擔當的，結果就是我們更關注的是要做哪些功能。
例如，我們規劃要做一個公有云系統，產品經理就會看世面上的公有云產品：華爲雲，阿里雲，亞馬遜等，然後去參考他們的界面，去試用他們的功能，恨不得copy一個類似的產品出來。
實際上，我們並沒有想清楚，華爲雲，阿里雲已經做起來了，我們爲什麼還要做這個系統？我們是比他們有更強大的技術能力，能快速的仿造出一個公有云系統，跟他們抗衡或分一杯羹？還是我們的資源比人家便宜？還是我們的安全性或服務可以做的比他們好，讓客戶覺得更有保障？
可是，至少從目前看，我們的技術實力並不比人家強；據我瞭解，亞馬遜本來就是因爲那些資源閒着也是閒着，才做了個公有云來處理閒置的資源，其他的市面上單獨賣I層資源的，都是在做賠本生意；還有，公司內部的環境還存在各種單點，無容災系統等問題；
那我們爲什麼要做這個系統？我們的客戶是誰？客戶的使用場景是什麼？我們能爲他們解決什麼問題？這點就決定了我們的業務目標是什麼、產品和服務是如何定義的，也決定了我們的產品跟其他的競爭對手的差異性。
所以，做一個產品，我們核心要明確業務目標，確定目標用戶、梳理業務場景並進行產品定義。
開發都啓動了，纔有人點撥我們，我們差不多花了整整一個月才從想到想明白，造成了部分返工。
二、進度目標
需求清楚了後，技術負責人將需求轉化成開發計劃，接下來就可以開發了。
開發計劃的坑同樣很多，完全依賴於技術負責人對需求的理解，以及將需求轉化爲開發的設計能力。對需求的不理解或理解偏差，以及較差的設計能力導致系統擴展能力不足，都會導致不必要的返工，並且可能會低估工作難度，導致計劃評估不準。
於是，在開發階段，又有一個很容易迷失的目標：進度目標。因爲以上主要原因，就算計劃做的再詳盡，人員再穩定，計劃和實際執行也是很難一致。
加上公司內部的系統，沒有客戶抽着鞭子催你，項目經理也很容易做着做着被現實屈服，做到哪，算到哪，不停的變更發佈計劃。
首先，要解決的是需求到設計的轉化，形成雙向評審機制。產品經理除了輸出業務流程和原型外，還要輸出需求文檔，並且需求文檔要能細化到功能點，包括界面的字段說明，長度等，技術負責人評審確認；而當技術負責人完成設計後，產品經理要反向的參與進來評審。
然後，要嚴肅計劃，計劃是每個人的承諾，不是完全不可變，但是一旦定下來，大家就要嚴格執行，無法完成的就自己想辦法，要不加班，要不優化提高個人生產率。
三 、測試目標
很多系統測試，最注重的還是功能測試，而且偏向於功能點的測試，忽略了貫穿測試。
所以，一開始就要確認測試的目標，要包括功能測試，安全測試，靜態代碼掃描等，還要有兼容性測試，一開始在ue開始做靜態頁面的時候就要明確好要支持的瀏覽器版本，省的理解不同，還要做改造才能向下兼容。
性能測試指標也要一開始就跟測試人員確定好，多少用戶量，滿足多少tps，響應時間最長多少等必須明確。
四、 個人目標
做每個項目，除了達成項目的目標外，我們也要給自己設定一個目標。比如，我想通過這個項目讓老闆對我刮目相看，想在公司中揚名立業，讓大家都知道，這麼牛的系統是我帶隊開發的。
或者我想通過這個項目達到堅持每日過進度，有效管理項目計劃的目的。
或者，我想通過這個項目實踐我剛剛學習到的溝通技巧，在面對衝突時，或關鍵對話時。
或者，我想按照敏捷的方法試一下項目管理過程，更或者特別微小的，就是想試試敏捷的生產率評估或持續集成。
作爲開發人員，你可以定的目標是瞭解整個項目的業務，而不是隻關心自己開發的那部分功能，或者是要學會使用一種前臺框架，或者熟悉redis，或者學會部署監控系統，日誌系統。
附： 迭代回顧
每個迭代完成後，項目經理要組織產品經理以及技術經理在內的項目團隊一起進行迭代回顧。
項目經理可以回顧下整個迭代過程，大家輪流發言，每個人都回顧一下他認爲哪些是做的好的，哪些可以做的更好， 哪些需要在下個迭代中改變，具體有什麼建議。
要注意的是，通過回顧，你會發現需要改進的點很多，都改過來變得很困難，所以，結束前，還是要跟大家一起商量出下個迭代優先要解決的TOP5。
迭代回顧特別重要，否則，你就會發現在下一個迭代中，團隊還是在不斷重犯同樣的錯誤。尤其提醒的是，氛圍也很重要，不要把迭代回顧變成批鬥大會，因爲我們的目標是爲了在下一個迭代能夠做的更好，而不是讓大家自我否定，退縮，失望。