有一天隨手拿起床頭的＜人月神話＞翻看到『為什麼巴比侖塔會失敗？』這一章，關聯到我現在在做的專案，覺得有非常多的不足。
在擁有清晰的目標、足夠的資源下，專案失敗了。這就是我們看到的『巴比侖塔』專案結果。原因很簡單，引用一下原文：
'為什麼專案還會失敗呢？他們還缺乏些什麼？兩個方面——交流，以及交流的結果——組織。『
嗯，『交流』，每個人都認同這一點非常的重要。
但是，怎麼交流才算是交流，或是『有效的』交流呢？再引用一下原文
1. 非正式途徑
清晰定義小組內部的相互關係和充分利用**，能鼓勵大量的**溝通，從而達到對所書寫文件的共同理解。
2. 會議
常規專案會議。會議中，團隊乙個接乙個地進行簡要的技術陳述。這種方式非常有用，能澄清成百上千的細小誤解。
3. 工作手冊。
在專案的開始階段，應該準備正式的專案工作手冊。理所應當，我們專門用一節來討論它。
對應到目前的專案：
正式/非正式的交流：非常缺乏。連基本的周例會也在進行了幾次後取消（即上面所說的第二點『會議』）。同時，應為專案需要與海外團隊的合作，本身有交流上不便，更加上有些事宜沒有epl來確定（拍板），甚至出現了到現在（已經是release階段）還有各做各的情況（當然，這一般情況下是溝通問題。anyway,在接下來的一段時間，某一方必定需要重寫對應的邏輯功能來符合另一方才能使流程運轉起來）。
關於工作手冊：在專案一開始就明確了一點：因為專案緊，所以，一切文件從簡或略。
軟體專案不同於建築專案，一旦圖紙確定下來，找來建築工人即可以順利完工，只要不出現『壓力太大』的問題，呵呵。但是，軟體專案，特別是沒有類似軟體的開發經驗的專案，希望按照schedule來完成任務，就特別需要團隊的合作。從可行性分析、軟體架構、模組劃分、模組介面定義等等，都需要充分的交流（這個與『人月』中的另一章『貴族**、民主政治和系統設計』是不衝突的），盡量的減少開發過程中某部分人員的『不爽』的問題。比如：某些模組負擔過分的重，有些則過輕;架構設計時，輕視的某一部分，導致此模組開發起來感覺極不『優雅』等。個人認為，這個問題的解決能力，很大程度上就體現了epl的管理能力了
巴比倫塔的失敗
據 創世紀 記載，巴比倫塔是人類繼諾亞方舟之後的第二大工程壯舉，但巴比倫塔同時也是第乙個徹底失敗的工程。為何擁有了清晰的目標，充足的人力和物力資源的專案最後仍然失敗，巴比倫塔給我們的管理教訓就是它們缺乏溝通和交流，以及交流的結果 組織。他們無法相互交談，從而無法合作。當合作無法進行時，工作陷入了停頓...
巴比倫塔 小強版
include include include include using namespace std int w,n,v,r,t,i,maxn,j multimapmps multimap iterator it2 int state 100 vectorvt void f int num,int...
動態規劃 巴比倫塔
做了一道zoj上的題目，發現是一道經典原題的改編 只改了題目背景。資料都一樣 zoj problem set 1093 解題報告 題目分類 動態規劃 題目大意 有n種木塊，每種都是無限提供，木塊可以隨意擺放 即每條邊都可能為高 當某一塊木塊的長和寬都小於下面的木塊時，才能疊在上面。要求最高能疊多高。...