專案管理覆蓋整個專案生命週期，管理制度就是落實到管理過程中的一些基本要素，這裡我們將其概括為三項基本業務：
ⅰ、專案計畫
① 指明要取得的各種結果
② 指定進度表
③ 估計所需資源
ⅱ、專案組織
落實專案體系中的角色配置與角色的職責
ⅲ、專案管理
① 約束
② 任務分解與分目標制定
③ 進度檢查與質量評估
④ 應對一些突發事件（協調與調整）
⑤ 與有利害關係的人共享資訊
專案計畫的結果體現為「專案開發計畫」書面形式，其中要對開發過程中各項工作的負責人、開發進度、進度衡量的標準、完成進度所需經費預算以及所需軟、硬體條件等問題詳盡的羅列出來，以便根據本計畫開展和檢查本專案的開發工作。附錄4-1給出計畫書模板。
專案組織包括專案角色定義、角色責任定義、角色間關係定義。角色定義是根據專案需求配置（調配、招聘）具備相應素質與能力的成員。角色責任定義就是將具體的任務分解到每個角色；角色間關係定義指明報告與檢查體系；一般情況下為**組織：
業務與商務協調組一般由客我雙方成員共同組成，負責專案的總體需求、總體目標、里程碑，關鍵技術路徑定義。在制定專案總體目標、里程碑定義與關鍵技術路徑時候要與開發經理聯合統籌，並以專案經理意見為主。
開發組的責任人是開發經理，系統體系結構與框架由開發經理與開發組主力程式設計師聯合統籌，並以開發經理意見為主，具體功能實現一般以主力程式設計師（系統分析員、高階程式設計師）意見為主。「系統支援」屬於臨時調配，很可能是外部資源，但工作質量由開發經理檢查。
質量控制由質量經理、開發經理、專案經理聯合統籌，以質量經理意見為主。
整個專案生命週期中一般角色責任定義如下：
這裡只是給出我司軟體開發必須遵從的原則，具體內容應該由專案經理或開發經理根據具體專案制定詳盡約定。在羅列規範之前，開發組織（團隊）必須遵從乙個最基本的約定——統一開發環境：
os:作業系統;
ide：整合開發工具;
debug：除錯工具;
sc：源**控制器；
im:即時交流工具；
dd:文件工具（計畫，任務，報告）；
asm:間接交流工具，一般以mail為主。
另外還要為團隊固定一些一些角色，builder / server administrator（dba&osa）。
嚴格區分開發平台與生產平台之間的界限（安全、測試、效能）
a) 資料庫與資料庫物件命名;
b) 開發語言的元素命名(類、物件、檔案、命名空間、元件、函式、方法等)；
c) 頁面與頁面元素命名.
d) 檔案目錄體系
縮排、換行、塊大小、檔案大小、注釋
元件類別、大小、前景、背景、字型、滑鼠敏感、邊框、布局
建立許可權、建立分之許可權、更新頻度、提交準則。
嚮導設定、資料校驗、提示資訊、響應時間與響應方式
鑑於使用者需求的不容易澄清性與變動頻繁這一特點，所有專案均採用迭代開發方法。這就是說不要指望在明確的需求調研階段能把問題搞清楚，弄清楚個大概即可，以不超過兩周的迭代間隔快速的互動原型，以便反饋更進一步的需求、這樣一步步逼近使用者的真實想法。這裡要特別強調的是多與使用者交流，專案組內有關設計方法與策略也要頻繁地交流。
純粹從開發的角度我們將專案週期劃分為兩個階段，每個階段要完成的的如下：
專案組每週至少要進行不少於兩次的集體交流，否則就是開發經理或專案經理失職（交流不限制時間長短、方式、內容可以從需要到設計到實現、甚至是抱怨）。
小組內成員必須開展互測，專案經理要督促進行。如果一般性的缺陷被質量組測試發現，專案經理可以作出警告、取消休假、扣發獎金等處理措施。專案經理或開發經理可抽查成員**，對比規範作出人員基本技術素養評測，計入期末（專案結束）考核（去留）。
應用系統的所有資料[**（程式、指令碼塊、資料庫指令碼）、文件、資料]，除了資料以外，全部納入源**控制系統。資料每天備份一次[媒介是磁碟]，**（程式指令碼、資料庫指令碼）、文件每週一次[媒介是磁碟]，所有資訊每月備份一次[媒介是光碟]。
沒有文件的軟體是一種災難。**不是傳達系統原理和結構的理想媒介；開發團隊更需要編制易於閱讀的文擋，來對系統及其設計決策的依據進行描述。
然而，過多的文件比過少的文件更糟。編制眾多的文件需要花費大量的時間，並且要使這些文件和**保持同步：就要花費更多的時間。
如果文件和**之間失去同步，那麼文件就會變成龐大的、複雜的謊言．會造成重大的誤導；
對於團隊來說，編寫並維護乙份系統原理和結構方而的文擋將總是乙個好主慝，但是那份文件應該是短小、突出主題的。為此我們擬定所有專案都必須編制以下文件。
1《專案開發計畫書》，模板見附錄4-1
2《軟體需求說明書》，模板見附錄4-2
3《詳細設計說明書》，模板見附錄4-3
4《使用者手冊》，模板見附錄4-4
5《資料庫需求說明》，模板見附錄4-5
6《專案開發總結報告》，模板見附錄4-6
軟體交付[應用，源**]
文件交付[視技術合同要求交付的內容而定]
執行維護技術交付：系統、資料庫、應用的日常管理與維護。
系統安全**付：作業系統管理與應用賬號、資料庫管理與應用開發賬號、應用伺服器的管理與應用開發賬號。
專案執行過程的所有資料[程式、指令碼、資料、文件]以光碟作媒介，並附上資料清單，交給公司行政部。
組織中的負責人負責具體的任務分解並落實到組織中的每個人。形式如下：
軟體開發任務單
專案名稱任務編號
軟體開發人員的績效考評是所有軟體公司都深感棘手但又必須面對的問題。棘手的原因是既不能進行計時處理、也不能進行計件處理。計時會造成出工不出力，計件（一般按**條數）會挫傷優秀軟體人員的積極性（同樣實現乙個功能，差的軟體人員成百上千行，而優秀軟體人員只有幾十行，且好用）。
但是只要尊重一些必要的原則，還是能夠加以評估的。這裡提出六條原則：
1、 被考核物件必須有明確的任務
專案經理或開發經理必須發出明確的任務書：任務書中指定任務名稱、任務內容、完成時限之、考核標準、向誰負責、任務的難易程度（業務與技術兩個方面）。難易程度由專案組成員集體評價。
沒有明確的任務當然就無法考評（見表4-2）。
2、 考評標準要綜合計量量與非計量量。
計量量如：完成時間、完成了對少功能、測試出多少缺陷等，非計量量如：使用者接受程度如何、專案組合作情況如何等等，要將這些因素綜合考慮。
3、 要體現多勞多得、獎勤罰懶。
高效、高質完成任務的人員必須得到區別對待（調資、休假、獎金）。
4、 考評結果要及時與被考評物件溝通，容許爭議協調。
5、 考評時間不得跨度太大，一般為兩周一次，不符合這種週期的，專案經理與開發經理需要適當對任務做進一步分解。
軟體公司專案建設合同
省 市 系統 專案建設合同 建設單位 甲方 承建單位 乙方 公司 合同編號 簽約地點 簽約日期 目錄一 專案名稱 內容及 2 二 付款方式及期限 2 三 專案變更 3 四 到貨 安裝除錯 開通執行 系統驗收 對賬 4 五 系統保修和維護 6 六 專案培訓 6 七 違約與賠償責任 6 八 保密 7 九...
軟體公司社會實踐報告 實用
仰望星空與腳踏實地 為了能更切身的感受社會實際中的職業狀態，在7月15日的下午開始了為期半個月的暑期社會實踐活動，經過介紹作為分散實踐個人，終於聯絡到了一家以軟體開發為主的公司並參與實習。而緊接著的幾天則開始了真正感悟生活與工作的日子。實踐地點位於xx市資訊工程職業學院中的創業孵化園的一家名為xx的...
軟體公司薪酬制度
適用範圍 1 總經理辦公會成員 2 總部助理部長以上職員 市場本部及下屬部門除外 行政薪酬 技術系列 營銷系列 3 總經辦 行政人事部 財務部 審計部 物料 部所有職員 4 研究部 工業設計部 技術工程部 生產技術部 質量管理部 生產部從事非專業技術工作的職員 5 研究部 薪酬設計部 技術工程部 生...