在專案
開始的前期
階段，我
總是能列出很詳細的
專案計畫。但隨著專案的
進行，新任
務不斷出現，任
務的狀態也需要不斷跟蹤。只要一兩天忘記跟蹤
計畫，這個
計畫基本上就已經殘
廢了，不再有實用價
值。在六年裡，我試過三
種計畫跟蹤的方法。第一種是主
動地向專案
團隊獲得專案
進展的資訊。方法是
每天上班後花10分
鐘開個早會，明確一下
每個人當天的工作任
務，然後我更新並發布
專案計畫。
每天下班前花15分
鐘，了解
每個人的工作進度，
記錄遇到的
問題，並把進度同
步到專案
計畫中。
——這種
方式，在某
種程度上扼殺了
團隊的主觀能
動性，可能管得太死，專案
團隊有牴觸情緒。
問題：因
為大家並沒有及時地
記錄下處理任
務的時間，收集到的任務的
實際工期的精度比
較低。另外，早會
還好，但下班前的會
經常由於打斷開發人
員的工作或思路，召集的
時間甚至
長過匯報時間
。大家抱怨每天浪
費時間這
半個小時常常導
致大家被迫加班。我個人稍微估算了一下，
0.5小
時x 10
人x 200
天= 4.2人·
月，浪費
的時間還
真是很可觀。
第二種，由項
目團隊主動
用email、**
或口頭向我匯報每
天的工作
進展。方法是
每個人在接受到
團隊其他人
轉出的任
務，（比如
測試、文件等），遇到
問題，以及完成某項任
務時，及時以各
種方式通知我。
——集中
匯報給我乙個人的方式，造成我是
監工的事實。
對於天生
愛自由和害羞的專案
團隊而言，無異於暴露個人隱私。
問題：很快，我就
發現並不是
每個人都能很主動的
匯報。我
經常會不知道專案
團隊在處理什
麼樣的事情。有
時候直到
問題積累到一定程度，爆
發出來的
時候，我才了解到。第三種
，白板方式。在專案
團隊的視線範
圍之內放置一塊
白板，分左右兩欄。左
欄列舉整個
專案的概況，比如
關鍵的幾個里程碑或者
階段，並
標出當前
階段的位置。右
欄標明當前（當天、本週或者本月）的努力方向作
為標題。然後在下面列出當前正在
進行的任務項、
問題。大家隨
時更新相關的任
務和問題。
——由於將個人監督
擴充套件為群眾
監督，執行起來阻力很小。甚至，白板也逐漸成
為團隊文化培
養的基地，大家會在白板的空白處抒
發個人的感想，或者感激他人的言辭。所以，
這也是我目前一直在使用的方式。
問題：白板的容量有限，所以，我
們不得不定期清除已
經完成的任務，已
經解決的
問題等。沒有很好地將這些寶
貴的財富留
給後人以及我
們自己未來的專案
開發及管理。很浪
費呀！（感嘆……
）
專案計畫與專案進度跟蹤
軟體專案交付延期是比較常見的問題，主要的原因包括外部和內部兩方面，外部包括客戶的原因，或者第三方的原因，這個是比較難預料和控制的，我這裡主要 內部的原因和相應的對策 1.專案估算和專案計畫本身的問題。如果專案實際需要100個人月，但是估算只有90個人月，另外10個人月的工作量就需要額外的人力和時間來...
PostgreSQL跟蹤函式內部執行計畫方法
很多人可能在使用pg時會碰到這樣的問題 乙個sql單獨拿出來執行很快，但是放到函式裡面執行就很慢，想要知道函式裡面究竟慢在 但是卻無從下手。因為我們沒辦法像對單個sql一樣直接explain來獲取執行計畫。例如在oracle中我們可以通過例如10046trace這種方式來看看函式內部慢在 那麼在pg...
人像跟蹤專案流水
新建立camoperation類，負責採集影象和分發影象資料 結構 多執行緒類workqueue，攝像頭操作類camoperation 方法 攝像頭初始化 framegrabber.init 0,true 在mainframe中初始化中不適合，新建立乙個攝像頭操作類，實現攝像頭的初始化和執行緒啟動。...