終於做完了兩個專案，幾乎用了近兩年的時間，應該好好總結一下了，要不然這麼好的經驗就白白浪費了。我做的專案都是企業定製開發的，所以總結也是側重於定製開發的專案，可能並不適合成型產品的專案。
1、簽合同
合同裡面關於專案功能的地方要盡可能的詳細，範圍要盡可能的縮小。如果功能比較模糊，而範圍有比較大的話，那麼就很危險了，因為客戶會在這個範圍內不斷的增加內容，「加深」功能。這些足以讓預期的時間和工作量成倍的增加。
當然，想要在合同裡把專案的功能給說細了，並不是一件很容易的事情，除非對客戶的行業和客戶的情況很了解，或者說我們做的就是乙個產品。如果我們是給企業定製開發的軟體，而我們有對客戶的業務流程不太了解，那麼要把合同裡的功能確定好了，確實很不容易，但是也要盡力的去做。這個很大程度上要看經驗了。
2、調研
有些情況是先調研後簽合同（至少我就遇到了一次），當然大多是還是先簽合同然後再做調研。好了，不管誰先誰後了，我們先說調研。
一般呢是專案經理帶著幾個人去客戶那裡去了解客戶的需求和客戶業務邏輯，這時呢，大多數情況是只和客戶的「領導級別」的人打交道，比如大老闆、各部門的經理等。我們也許會有乙個誤區：「領導級別」的人說的就是準確的，就是全部的業務邏輯了，只要按照領導說的功能去做，實現了領導想要的就可以了。但是實際上往往沒有那麼簡單。
因為領導嘛，自然不會去關心細節，對於業務流程也不見得就100%正確。我就遇到了機會，領導說要這麼做，但是到了錄入資料的人員那裡就變樣了，要麼是一些細節被領導忽略了，要麼就是領導的要求根本就不能實現！
不要認為當出現這種問題的時候，一定是錄入資料的人員「遵從」意見，我就很點背的遇到了幾回，居然是領導「讓步」了。沒辦法，我只好改程式了。
所以調研的時候，不僅要聽領導怎麼說，還要看看錄入資料的人員的現在的做法，也就是在沒有軟體的時候客戶是如何做的，最好能夠跟著客戶完成乙個完整的業務流程。
和大老闆溝通的時候，要注意他的真實需求，他要上這個軟體的真實目的；
有的時候，大老闆是想用這個軟體來重新規劃一下業務流程，堵住一些漏洞，如果是這樣的話，那麼就會和一些人的利益有些衝突，這時就要萬分小心了！
和部門經理溝通的時候要注意他們對於業務邏輯的了解和掌握程度，還要看他的描述的能力；
和錄入人員溝通的時候，要注意他們的對電腦操作的熟練程度，現在的操作習慣是什麼，對於什麼樣的「操作形式」可以接受。
還有就是年齡段，一般年輕人是比較「聽話」的，而有些人就比較很難改變他們現有的操作習慣，就是說不容易接受新的操作方式。
每個人都是只關心自己的工作量，總是希望自己的工作可以很簡單、很輕鬆的完成。
其實決定乙個軟體是否好用，往往是錄入人員「說的算」。正所謂「三人說虎」，乙個人說這個軟體不好用，領導不一定會信；兩個人說，領導會有所懷疑；三個人說，領導就會很懷疑。而帶著懷疑的眼光看乙個事物的時候，問題就會被擴大，就會滿眼都是bug。再有，領導哪會有時間詳細的看你的軟體呀？領導只關心報表，而報表的資料是要有錄入人員錄進來的，沒有資料，或者資料不準確，那領導看什麼呀？
所以我覺的不僅要和領導打好關係，錄入人員也不能忽視！
3、設計
這裡就有分歧的地方了，我是習慣以資料庫為主，用表和表的關係來體現業務邏輯。而ooer喜歡先畫乙個uml，設計領域模型，設計實體類等等。不管使用什麼方式，設計好的東東要盡快讓客戶確認。避免出現理解錯誤的情況。
4、編碼
如果在編碼前就能確定，我們寫的就是客戶想要的，那該多好哇。如果能夠實現那自然是好，但是對於企業定製開發的專案來說，要做到這一點好像異常的艱難！修改似乎是在所難免的，所謂「唯一不變的是變化本身」。那麼如何才能確定自己實現的功能就是客戶所取要的，或者說客戶的需求變了，我們如何才能盡快的、盡量簡單的修改就是實現？這裡似乎又有很多的分歧，每個人都有各自的應對方法吧。
這裡好像沒有什麼具體的建議了，一切靠經驗吧。
5、物件導向的問題
先舉個例子吧。50公尺開外有乙個靶子，目的是命中靶心，可以選擇**有弓箭和槍。相信您一定會選擇槍吧，槍對於弓箭來說確實準確度、射程、易操作性都高了很多。但是並不意味著，你使用了槍就一定會命中靶心！如果您是第一次使用槍打靶，第一槍很可能會脫吧，經過一段時間的聯絡後，可能達到槍槍打中靶子，但是想要達到槍槍命中靶心，就必須要經過艱苦的訓練才行。
我想要說的是，並不是說使用了物件導向這樣的「先進**」，就可以很輕鬆的實現傳說中的那些好處！必須要多多練習、用心練習才行！
6、物件導向的威力。
還是先舉個例子。假設有乙個一噸重的石頭塑像需要換乙個地方。由於它太重了，乙個人搬是不可能的，那麼就多找幾個人吧，找十個人，每個人承擔100公斤的重量就可以了，但是這樣的大力士並不是隨便就能找齊的，那麼怎麼辦？再加人。找二十個人，每個人只需要承擔50公斤就可以了。這個視乎容易多了，但是這麼多的人如何來配合工作呢？塑像的底座周長比較小，人多了申不上手。
如果有乙個神奇的分割方法，可以把這個塑像分成100份，每乙份只有10公斤重了，這樣一來就容易多了，找一百個人，一人一塊就走了。找五十個人，一人兩塊也行。當然他的神奇之處不在於分割，而在於「組合」。當到達目的地之後，這個神奇的分割方法又會把小塊恢復如初，達到「無縫連線」的效果。
這個「神奇的分割方法」就是物件導向，他會把乙個大的專案分成n份，然後找n個人來完成，然後再把每乙個人做好的「組合」起來。這個就是物件導向的威力吧。
您可能會有乙個疑問，移動塑像一定要用人力嗎？用起重機不行嗎？這樣就可以整體移動了呀。如果有起重器可用的話，用起重機是更好了。這樣找乙個會駕駛起重機的，再找乙個司機就ok了。
不過話有說回來了，如果這個塑像有1000噸重，顯然乙個起重機是搞不定的，起重機多了就又有了乙個如何配合的問題了。
ps:您可能會問，這裡怎麼沒有測試呢？因為這兩個專案比較特殊，直接讓客戶去測試了。但是這個也只能是乙個特例，所以也就不多說了。
專案總結 我的體會
專案的開展需要學會自主的學習，這是此次實訓與課堂學習最大的不同與收穫。平時的課堂學習，老師都會給我們強調什麼是學習的重點，同時又通過課下作業進行強化，把握知識相對較容易 但是在專案中，遇到的問題往往需要寬廣的知識面及一定的開發經歷解決，沒有人能直接的告訴你問題原因所在，不能及時的解決問題。在這種情況...
我的手遊專案總結
專案日誌 2014年4月專案啟動，啟動時專案2個人，乙個客戶端，乙個伺服器端。客戶端用u3d，在這個專案之前，他使用過u3d 3.x的版本，對早期的u3d有很深的了解，所以，上手的第一步是重寫了乙個ui系統，沒有使用ngui或者ugui。伺服器端是我開發，我重構了上乙個專案的 將之前網路層的 從c ...
我參與的乙個專案總結
最近參與的乙個專案階段性結束了，從去年9月到今年2月，進行了整整5個月。下面是我的總結。一 1 比較完整地參與到專案中來，進行了需求分析 概要設計 編碼實現 測試等環節，對軟體工程的科學性有了更進一步的認識。2 有幸成為方案負責人，專案實施過程中，與各個不同的職能部門進行交流溝通，鍛鍊了口頭表達能力...