專案進度控制
bi專案其實與軟體專案結構也大同小異，模型相當於資料庫層，etl相當於業務邏輯層，essbase與前端相當於應用層。
業務邏輯在軟體中表現為類，而在bi專案中表現為sql語句或儲存過程。
前端有兩種展現方式，
多維：用工具實現
報表：用bi.office實現
對於前端，可以先設計錶樣出來，不用等模型。
錶樣，無非兩樣，一樣為樣式，一樣為內容
前端模型與後台模型分開同時設計，前端模型**於後台模型。
前端模型側重於應用，後端模型側重於組織準備資料。
前端模型包括星型、報表層、供數層
後端模型包括彙總層、補錄層
這樣，整個專案就有兩根線，乙個前端，乙個後端。二者同時進行，並相互影響。
這樣，專案的進度必然會以更快的速度向前開展。但這種方式需要兩個懂模型的人才能實現，但專案中一般只配乙個模型人員，若隨便找乙個人來頂，則會出現強弱差，導致乙個模型負責人領導另外乙個模型負責人的情況。一般而言，後端模型人員的能力會超過前端模型人員的能力，這樣可能前端模型人員先設計出模型，然後再要後端模型人員來修改指正。要實現這一點也要兩個模型人員的配合。
所以我認為，在沒有兩個模型人員的情況下，前端組人員不要過早進入專案，後台模型設計到80%的時候，etl人員可以開始進入，前端模型設計到50%時，前端人員可以進入。
開發80%的時候，測試人員可以進入。
在此之前，需求組的人員最先進，模型人員最好也參與到需求中。以便更好地設計模型。
人員是這樣安排的：
需求組先進入專案組，完成後，可以撤掉，但必須最少留下一人。
之後模型組進入，進行資料調研，再之後進行模型開發。
上面是乙個大原則，針對具體的工作又有方法來進行優化。
對於essbase而言，開發流程如下：
1．olap設計，
1．開發outline
2．開發 rule
3．開發排程指令碼
4．優化cube
5．測試cube
對於前端而言，開發流程如下：
1．製作錶樣（在需求中就要談好錶樣，可能有些遺留下來的問題）
2．開發sql或儲存過程
3．整合錶樣與sql/儲存過程
4．測試
在做任何一步時，之前都要進行設計，包括概要與詳細設計。
而設計的依據有兩個，需求與業務知識。
需求可以通過需求規格說明書或業務人員處獲取。
業務知識可以從業務人員或平時積累處獲取。
為什麼需要業務知識，只有知道了業務知識，才能明白業務的整個流程，才能知識業務最需要什麼，才能更好地實現需求，擴充需求。
下面是提高專案進度總結的一些方法：
提高專案進度方法
1．找到乙個介面，使各組開發人員可以同時進行。
2．前端模型與後端模型同時開發。
3．人員進入專案的時間不同，需求先進，之後是模型，之後是etl，之後是前端
4．先進行設計後進行開發
5．利用規範來控制，可以提高進度，也可以提高質量。
6．各工作之間必須有介面人，一般為小組組長。小組組長必須懂需求，同時需要知道業務知識。
7．必須有乙個人貫穿專案始終，最好是專案經理。
專案進度控制的技術
專案進度控制是專案經理的一項重要職責。俗語說的 時間就是金錢 在這裡體現得再明顯不過了。專案管理和自駕車回老家過年是相同的，實際上按照專案的定義，自駕車回老家過年 也是乙個不折不扣的專案，只是它更貼合大家的生活，更容易引起共鳴，我們就拿它來做例子說明。從乘客的角度，如果坐車很久，但是沒有達到預期的目...
關於專案進度控制的思考
思考源於最近的工作經歷。去年下半年開始的乙個大專案，我作為其中乙個子專案的專案經理。因為外部因素，專案整體進度延後，何時上線並不明朗。我負責的子專案在3月份按照初始設計完成功能開發和測試，之後一直進行修改和完善。但進度一直很不如意，分配的任務總是延期。最近插入乙個新專案，只有三周時間要完成開發和上線...
有效控制專案進度的幾點技巧
文 白天 軟體開發的專案週期大體分為3個階段 獲取需求和定義產品 開發和測試 部署和運維。在獲取需求和定義產品階段，需要防止 的不是進度太慢而是過快 過草率。特別是對於創業公司的產品經理來說，很可能因為看到開發人員無事可做而感到壓力，所以盡快完成產品定義，而沒有充分了解 市場和競爭對手資訊，沒有與合...