昨天下午總結了一下專案值得注意的地方，記錄在《專案做完了，總結一下（上）》，時間倉促，也沒有總結完全。等有時間，還要細細總結。今天，我主要總結一下專案成功的可能因素，比較膚淺。
雖然專案受很多不利的因素的困擾，但最終還是交付給使用者使用，不管怎麼樣，這中間還是有很多值得思考的方面。
1．專案經理
這個專案經歷過很多的困難，從一開始的人員沒有到位，到被限定的專案時間，再到需求的不完善等。如果不是專案經理超強的全域性把握能力和領導魅力，不論是在封閉期間，還是在那段加班的日子，依然保持團隊的團結和鬥志。因為這個專案經理，團隊核心人員都沒有離去，心甘情願的跟著他把專案完成。有乙個好的專案經理，對專案來說太重要了。當然，專案的每個成員都很重要。
2．團隊的團結
我們這個團隊，是乙個年輕的團隊，因為這個專案而組建的，還有一部分成員是沒有任何開發經驗的。面對很多不利因素，所以能夠完成這個專案，很重要的乙個原因是團隊的團結。封閉的
n個月以及加班的
n個日夜，雖然很艱苦，但是卻是我們團隊最懷念的日子。大家在一起，同甘共苦，一起培訓，一起交流，一起熬夜，一起吃速食麵，一起玩
cs，痛並快樂著。即使中間因為討論而出現過爭吵，但從來沒有影響過成員間的感情。
3．寬鬆的管理
我的意思並不是說管理鬆散，而是專案組的柔性管理。在專案開發期間，我們因為某些事情而無法及時到崗時，都會獲批處理事情，只要在以後的工作中將這次落下的工作及時完成，不影響專案計畫。我感覺這樣的管理方式，至少在我們這個團隊執行的很成功。我們不會偷懶，相反我們會更加勤奮地工作，回報領導的信任和關心。因為解決了後顧之憂，我們還有什麼理由不全身心投入到工作中呢？
4．二次開發平台
5．rup
開發過程
按照以往的軟體開發經驗，專案一般都會採用瀑布模型，未必是嚴格按照瀑布模型的規定的乙個階段的結束是另乙個階段的開始，但大體都是按照這個過程安排專案計畫的。在這次軟體開發中，我們引入了
rup軟體開發過程，採用迭代模型和快速介面原型等開發模型，制定專案里程碑和迭代計畫。雖然並不是嚴格按照
rup規定的迭代進行，因為資源的有限和團隊的年輕而有些變味，但還是有效地解決了一部分專案風險。
6．開發規範
據我了解，還是有一些公司沒有乙個統一的開發規範，**質量的好壞都是由個人的開發經驗決定的，我現在的公司在我來之前就是處於這種狀態。在這個專案中，因為進入開發階段後還在招聘人員，能力參差不齊，而且有一部分是沒有開發經驗的，這就對**質量提出了挑戰。為了能提高**開發質量，我們引入了開發規範，制定了開發過程中的一些規則，所有成員都要求按照這個規範進行開發。雖然成員在剛開始時受制約而感覺有些麻煩，但這樣的開發規範，不管對於專案還是整個公司，都是重要的。
Golang學習 記錄一下下
標誌符 只能以英文本元與 開頭 go語言當中的變數必須宣告了再使用，宣告之後必須使用 函式內部可以使用短變數宣告 函式外部一般使用 var 變數名 型別 值 匿名變數 v 常量使用 const pi 3.14 iota 常量計數器，每次遇到const都會重置為0 const n1 iota 0 n2...
忙裡偷閒，學習了一下下
這兩天，專案趕得不是很近，也沒什麼bug需要修復的，就自己看了點知識 強迫症又犯了，糾結點還是些，有啥區別麼，就是腦子不好 比較雜，負載均衡啊，髒讀啊，索引啊，檢視啊，訪問修飾符啊，好像又沒啥了，看來也沒看多少東西啊，還是效率太低了，這是病得治 想想有什麼印象比較深的哈 想優化就得從小的抓起，建索引...
艾偉也談專案管理，專案做完了，總結一下
在連續封閉n個月以及再後來的n個月的加班後，專案終於以延期n個月的結果結束了。不管曾經發生過什麼，不管專案是否延期，重要的是專案結束了，所有的專案成員都可以松一口氣了。曾經和同事開玩笑說 在我經過過的失敗專案中多了乙個專案，以後就能避免同樣型別的失敗了。同事們聽了，都笑了。在那段時間裡，很久沒有聽到...