從開始上班到現在我已經工作了快5年了，換了3次工作，在不同的工作環境中學習到了不少的知識，但是也發現了在專案開發中的一些弊病，主要在於需求方面，其實編碼沒有太大的難度，難的是怎樣保證需求不會在短時間內發生頻繁的變更，所以整理了一下專案開發的流程和其中需要注意的問題。
一般交付性專案的流程分為以下幾個步驟
1、 調研需求
2、 簽訂合同
3、 架構師搭建專案框架
4、 程式開發
5、 專案進度管理
6、 專案測試
7、 交付
一、需求調研
所有的專案最根本的是需求，無需求無專案，所以乙個專案的好壞跟需求調研結果的好壞有直接的關係。
我現在所在的公司開發部門的人員劃分開發和實施兩部分，開發有18人，實施有差不多10多人，實施中包含專案經理，而且專案經理的素質偏低，需求制定的模糊不清不說，在專案進度把控上也存在很大的瑕疵。往往都是問道他這個需求後，他想一會又去問客戶，平時專案任務和計畫都幾乎沒有制定，失職之甚。當然客戶方面也有一定的問題，但並不是導致現在開發緩慢的主要原因。
要制定需求要綜合考慮各方面的因素，比如：業務程式、工具習慣、未來業務變動可能。
1） 業務程式
這個是最重要的部分，要做需求就要先從客戶的需求出發，將客戶日常工作中每個過程都考慮到，這個要做到細心，沒有別的轍。
2） 工具習慣
這次在**設計院跟客戶的溝通中，發現原來客戶本身就有乙個**系統，而且是使用多年了，他們已經有了濃重的使用習慣，而我們的需求中並未考慮到**的操作方式，這是失誤的一點。
3） 未來業務變動
專案要做的完美，不僅要覆蓋住當前的業務邏輯，而且還要根據客戶的業務對其長遠考慮，想到他們將來的部分可能需求，必要的時候給客戶一些意見，融合客戶需求並引導他們向我們的建議上來。
二、簽訂合同
另一方面，專案合同的簽訂人需要有技術部門的參與才能簽訂，如果一味的交於銷售，結果很有可能會演變成他們為了追求業績，不顧現實情況簽訂合同。
總體來說，合同簽訂是需要在需求確定的基礎上才可以。需求確定主要指的是以下幾點：
1） 一致基礎框架協議，多指前台的框架基本確定
2） 模組細化不算是需求變更，新增模組才是需求變更
3） 業務邏輯變換也不算是需求變更
還有一點就是專案**上，原來是以人天來計算的，理論上應該是計畫工時上浮30%。
三、架構師搭建專案框架
四、程式開發
程式開發肯定設計到技術問題，很多人在每次開發之前都在想到底用什麼新技術，什麼比較好的技術，由此帶來一波又一波的比較、學習，說實話，你不覺得這是在浪費時間嗎，每項技術都有其存在的價值，都有優缺點，元件、技術上的比較在開發之前是沒有任何意義的，這類東西都是沒有最好，只有更好，你不可能找到乙個很好的東西來用的，所以停止那些毫無意義的比較吧。
我建議乙個開發團隊，應該有一套至少穩定在1年以上的元件和技術，這樣會減少時間成本和技術學習成本。
程式開發真的是需要乙個好的領頭人來做，不然會死的很慘。
1）文件要求：開發每個模組之前需要寫好詳細設計說明，在用時上文件：開發應該是2：1的關係，再次強調，**開發其實沒有難度，難的還是整體的邏輯思路。
2）編碼的注釋習慣：每個類、方法、介面以及比較難懂的**段都需要進行注釋，類、方法和介面用段落注釋，標明方法用途，方法的每個引數也要注釋，
3）協同工具使用：svn git tfs每次提交需要有固定的格式
五、專案進度管理
關於專案管理首先要細化功能點，然後和開發人員共同預估時間，每天需要立會詳細了解專案進度，每天都要整理進度計畫。
六、專案測試
測試需要準備測試文件，測試文件需要依據功能詳細設計功能制定。
七、專案交付
交付的時候預計也會受到客戶方的指摘，這時候可能要跟客戶在需求框架協議裡面細談了。
關於課題專案的一些想法
一 網格計算與雲計算 1.零碎的想法 各自的特點與應用場景不同和可以借鑑的地方 網格計算興起的原因，要解決的問題，相關 中提出要解決的問題是否已經解決了？已經過了十多年？雲計算興起的原因，要解決的問題，相關 中提出的問題 關於資料庫應用系統測試的 一些初步的構想 雲市場？是否有實現，發展的方向和當時...
關於許可權角色管理的一些想法
我們在系統需要定義以下幾種型別 group,user,role,perssion,resource 可是物件object或者是操作operation 1.group 使用者組 一些特定任務所組成的使用者集合。2.user 使用者 對應到我們的系統的使用者，也就是人 乙個使用者可以在不同的使用者組扮演...
團隊管理 關於技術團隊管理的一些想法
做lead programmer已經4，5年時間了，從雲日誌扒了些以前的感想寫在這兒。主程的主要工作是 1,評估並執行程式組的計畫。在程式組開始制定milestone，sprint的計畫時，應該已經和design團隊有明確的溝通，定義 了功能的具體需求和優先順序，一定要不要等到做團隊計畫時才來定需求...