1.重大的專案決策由超過大多數的專案參與人員討論決定，小的決策可以由負責這個方面的領導做出，但是不能觸及個人利益，一旦觸及個人利益就要由涉及範圍內的所有人參與討論，最後才能執行。這樣做的必要性並不侷限於集中大家的智慧型，降低決策由少數人做出而產生的風險，更重要的是另一方面讓參與者產生自己在專案的運作中有發言權的感覺，調動專案參與者的積極性。
2.專案的運作方式或者是公司的運作方式盡量做到不讓人反感（雖然這個說起都知道，但是很少有專案管理者能做到）。但是肯定會有一些位置無法做到，專案管理者要及時察覺，並做出合理的處理（解釋，說服或者補償等，比如必要的加班）。
3.專案目標的透明化，專案目標要得到組員的認同才能使參與者有按時完成目標的信心。
4.專案的任務分配，並不一定要遵循等量的原則，因為個人的特長與效率不同，而應該根據組員的特長與效率進行指定，保證同一階段的並行任務在時間上能較一致的完成（比如在編碼階段，對與a，b兩人，a編碼效率是b的一倍，這時就應該在這個編碼階段給a分配編碼量差不多兩倍的任務量，這樣在這個階段a和b就能基本上在同乙個時間完成，這樣不耽誤下個階段的工作，保證流水線的暢通）。這樣做其實並不讓人反感，因為一般來說多寫**能多拿錢，而且編碼效率高不一定他費得腦袋就多，對於編碼效率高的人來言關鍵特徵是善於抽象，這樣其編碼效率才會比其他人高，對他們而言並不覺得費勁，還會覺得有挑戰性。當然這樣的任務分配要明確的表達給接受者，讓其覺得理所應當。
關於認同感就先分析這些，肯定還有許多位置需要深思熟慮的。
然後是任務的分配，上面的第四點中也有所涉及，但是主要講的是分配權重的問題，另一方面是任務分配的粒度的問題。粒度就是任務分配的最小單位，可以是文件中的哪一章，或者是**中的乙個類，等等。在我認為粒度應該是根據組的層次來有所區別的。
在最下層，也就是專案組的葉子節點上，粒度應該是非常小的，比如文件中的哪一章，**中的乙個類這樣的粒度。而在上一層，也就是小組的組長這一層，負責的應該是乙個文件或者乙個模組的完成情況的監管者。在上面粒度就更加粗，這樣分布的，就如地圖中的不同縮放比例尺上看到的景象是不同的一樣。
查閱了一下專案管理的工具，發現如今專案管理工具的部署很多都b/s化了，國內有一家做的挺不錯的專案管理工作，而且是開源的，名字叫禪道，英文名zentao。
禪道的功能列表：
1. 產品管理：包括產品、需求、計畫、發布、路線圖等功能。
2. 專案管理：包括專案、任務、團隊、build、燃盡圖等功能。
3. 質量管理：包括bug、測試用例、測試任務、測試結果等功能。
4. 文件管理：包括產品文件庫、專案文件庫、自定義文件庫等功能。
5. 事務管理：包括todo管理，我的任務、我的bug、我的需求、我的專案等個人事務管理功能。
6. 組織管理：包括部門、使用者、分組、許可權等功能。
7. 統計功能：豐富的統計表。
8. 搜尋功能：強大的搜尋，幫助您找到相應的資料。
9. 靈活的擴充套件機制，幾乎可以對禪道的任何地方進行擴充套件。
10. 強大的api機制，方便與其他系統整合。
系統分析與設計作業（一）
1.軟體工程的定義 軟體工程是 1 將系統化 規範化 可度量的方法應用於軟體開發 執行和維護，即將工程化方法應用於軟軟體。2 在 1 中所述方法的研究。2.解釋 software crisis cocomo 模型 software crisis 軟體危機是指落後的軟體生產方式無法滿足迅速增長的計算機...
系統分析與設計 作業一
1 軟體工程的定義 軟體工程就是將工程化的思想應用在軟體開發和維護中，把經實踐檢驗的工程管理技術和當前可得的最好的技術方法結合起來，系統 規範 可量化地開發出高質量的軟體並有效維護。2 解釋導致 software crisis 本質原因 表現，述說克服軟體危機的方法 軟體危機的本質原因是計算機的快速...
系統分析與設計作業一
1 簡答題 軟體工程是 1 將系統化的 規範的 可度 量的方法應用於軟體的開發 執行和維護，即將工程化方法應用於軟體 2 在 1 中所述方法的研究 導致軟體危機的本質原因 軟體本質上具有一致性 複雜性 可變性 不可視性。需要面對的各種設計風險，不僅要能滿足軟體的變化，而且軟體的非功能性需求的實現成本...