這是我對知乎上題為「乙個產品經理怎麼跟工程師溝通時間進度問題？」的問題給出的回答。原帖在這裡
我對如何估算分配給我的任務需要花多長時間一直心存疑慮，每次我的經理問我這個問題的時候我都沒法自信滿滿給出乙個讓我覺得有把握又不浪費的時間。
我在目前的公司做開發9年了，幾乎沒出現過延遲交付，很少需要靠加班來避免延遲。但是我還是對準確估算時間這件事感到困惑，因為我感覺能夠達到上面效果的一大因素是，我所服務的公司並不是乙個節奏很快，壓力很大的公司。在這樣的氣氛下允許開發人員給出乙個相對安全的估算時間，相對的我覺得付出的代價就是開發效率有些低下。下面說一些我認為對準確估算時間有幫助的建議吧。
第一，先達成前提再開始估算。我覺得開始進行時間估算的前提有兩項，一明確需求，二明確採取的方案。明確做什麼和怎麼做之後才能談花多少時間的問題。對於技術人員來說有過相關經驗的任務可能很快就能確定技術方案。但是對於缺乏相關經驗的全新任務提出可能的技術方案，驗證可行性本身就是乙個耗時的過程。這個時候乙個選擇是交給更有經驗的人來確定技術方案。另乙個選擇是先別忙著估計時間，先安排乙個調研任務吧。給出乙個限定的時間，1周，2周，1個月。如果在限定時間之後對於怎麼完成預期的目標還沒有什麼靠譜的想法的話，放棄這個這個專案不見得是什麼壞事。
第二，誰去幹活就交給誰去估計，不同開發人員之間的效率可能相差幾十倍。
第三，大任務分解成小任務進行估算，但是要為把小任務整合起來預留時間。我覺得任務的粒度分解到1至2天比較合適。
第四，工作效率是有彈性的，壓力大一點，可能效率能高一點。但是效率不可能隨著壓力無限提高。壓力下的完成時間不見得是個準確的時間，這次完成了，下次不一定能完成。這次完成了，過程很痛苦，下一次也許就不願意完成。對效率的追求應該是整個團隊的價值觀層面的事情，通過讓團隊成員分享高效率帶來的成果，讓團隊成員自發主動的在估算的時候給出乙個盡量準確的時間，而不是乙個盡量「安全」的時間。
對創業團隊的一點想法
本人 沒有強大的技術，沒有廣闊的人脈，沒有超前的遠見，只因在創業團隊中待過一年，有了一些想法，即記錄下來。這裡對給我這次機會的公司表示感謝！這裡說提網際網路及軟體方向的創業團隊。1.不宜過早制度化 當然，對於打卡這樣的制度並不排斥。但是對於對上百人團隊的管理方法，不宜過早產生。比如詳細區分不同部門，...
對專案目標的一點想法
公司已經有乙個比較成熟的產品了，而且銷售情況也不錯。現在作的專案是該產品的後續產品，但是並不是簡單的公升級，如果僅僅是用.net來把以前的vb作的東西來實現一遍，就沒有什麼實際的意義了。由於要和先前的產品相比有質的飛躍，所以從結構和業務上幾乎都是重新設計，但是由於新的架構的實現難度比較大，造成現有的...
對使用破解軟體的一點想法
當我們不知道正版概念的時候，我們也不知道盜版，更不知道破解背後更深層的問題。今天進了國內的乙個php技術論壇，看到裡面推了叫enterprise architect的東西，起初還以為是一種開發模式，欣喜若狂，感覺很強。嗚呼，技術很大程度上不在於工具軟體，而在於人本身的思維。當然，也許我也是十步笑百步...