做項目其實很簡單

做項目其實很簡單
    做項目其實很簡單,任何事情基本上都是有規律可循的，作為一個專案經理或多重專案管理者要想指揮千軍萬馬，必須有方法。
怎樣才能輕鬆地做項目呢。下面是我的一些經驗方法與大家分享。
商務談判暫且不說，從專案經理拿到客戶提交的需求說起。拿到需求後怎麼辦？
我需要幾個文件範本。1.需求規格說明書。2.詳細設計文檔。3.資料庫設計文檔。4.技術實施指南。5.部署手冊。6.操作手冊。
只要把這六個文檔寫好就足夠了。就能很好的指揮管理整個項目。如果還需要其他文檔都可以從這幾個文檔上衍生，文檔寫多了就成了垃圾文檔。
下面就詳細告訴大家怎麼寫。
1.需求規格說明書
  拿到使用者需求後，首先通讀一遍。先從整體上把握一下。使用者的目標，範圍，解決的關鍵問題。
第一步，先理出一個功能清單。然後將功能分類劃分出子功能模組。
第二步，從6方面入手分析。構建需求規格說明書。
  1.初始化
   1）基礎資料
  2.商務程序
   1）流程
   2）狀態控制碼
  3.資料邏輯關係（各個功能模組之間邏輯關係）
  4.商務邏輯控制（邏輯控制點，輸入限制，按鈕許可權限制），關鍵演算法，編碼規則等。
    1）時間維度控制。以時間為主線驅動業務（例如銀行中貸款按天計息，到期處理等）
    2）流程維度控制。例如：各種表單審批次程序等。
    3）金額維度控制。例如：銀行計息，隨著時間的增加往往金額也會累加，累計達到一定的額度上限就會驅動其他商務程序。
  5.資料存放區（台賬-通知單儲存）
   單表格儲存體，主從表格儲存體（1-N），多表關聯儲存（N-N）。
  6.功能介面（介面約束）。

 需求規格說明書內容組織：
 1，功能清單
 2，各個功能說明
   1）功能描述，2）功能介面，3）功能約束，4）輸入，5）處理過程，6）輸出，7）資料存放區，8）演算法
 再配合上的項目的目的，範圍，商務程序圖，就能圖文並茂的寫出規範的，貼近實際使用者需求的規格說明書。

2.詳細設計文檔
 詳細設計文檔是建立在需求的規格說明書基礎之上的進一步細化，換一種方式描述更貼近技術而已。
細化到什麼程度合適呢，我的標準是程式員看到這個文檔某一功能，就知道怎麼去寫代碼。一目瞭然很明確該幹什麼，怎麼用代碼實現此功能，
他可以對此業務不懂。但知道怎麼實現其中的功能點。格式大同小異。如果項目比較大，可以需求的規格說明書基礎之上寫一個概要設計說明書。
再細化概要設計說明書，就成了詳細設計文檔。
3.資料庫設計文檔
 資料庫設計文檔這個文檔實際上是詳細設計文檔的一個附件。
 是對資料存放區的詳細說明，重點是表之間的關係。表分類：分控製表，業務表（再按功能模組分類），基礎資料表等。
 表和欄位的命名盡量用英文，盡量要做到觀其名知其意。寫上詳細的欄位說明。
4.技術實施指南
這個文檔一般是項目中技術主力或技術經理寫。主要應包括
1）系統架構分層，例如：基於資料的項目一般分層
UI（介面層）：常用控制項的用法例如Web介面DropDawnlist，treeView，gridView等常用控制項的應用示範代碼。
BLL（商務邏輯層）：商務邏輯的書寫代碼規範樣本。
DAL（資料訪問層）：對資料的增刪改查，交易處理基本操作。例如：微軟企業庫，ADO.NETEntity Framework的應用或OR/Maping工具產生的程式碼。
Model（資料實體層）：資料庫表到對象的映射。
Command（跟項目有關的公用群組件或第三方組件介面）：例如：Tlog等。
2）關鍵演算法。
3）公用群組件調用方法範例程式碼。
4）一般常用代碼。
5）核心功能模組設計思路及代碼實現思路。
6）技術痛點解決思路。
7）關鍵商務程序的控制。
8）程式管理要求。
9）第三方組件的應用樣本。例如：調用Log4NetTlog程式碼範例。
5.部署手冊
項目做完後寫部署手冊，嚴格按照部署手冊安裝部署程式。不足之處要及時修補。
寫清楚，程式怎麼部署，資料庫怎麼部署等。
6.操作手冊
操作手冊基於規格誰明書中功能清單，一個個描述清楚就是一個很好的使用者手冊。
言簡意賅，配合抓圖介面就能夠把功能操作說的很清楚。
一般主要內容格式：
1）功能清單
2）各個功能說明
  A) 功能描述。
  B）功能入口，功能介面。
  C）介面操作說明。
  D）注意事項。
其他外圍文檔還有很多，有些也很重要比如專案計劃文檔，這些文檔其實是為了給領導看的。如果我說的上面六個文檔都寫的很好，其他的工作開展就很容易。
因為，業務搞清楚了文檔寫好了，開發代碼很簡單。一般來說任何一個合格的程式員看到文檔都能實現。你找一個人把工作分下去，每個人報周報，讓程式員自己報工作任務清單。
每周檢查任務完成情況就行了。
最後你用一個工具（例如：微軟的VSS）把所有文檔包括項目代碼管理起來，你就會很輕鬆的控制項目。
最後告誡：專案經理或主管要充當教練的角色。指導，而不是直接上場當替補。