最近和好友們一起談到項目開發的體會。聽到了一個隊友很值得思考的觀點。
領導安排隊友做一個略有難度的程序模塊(注意是略有)，規定時間是8天。於是到了第七天,領導便按慣例惶恐不安弱弱的來問隊友是否差不多了，第八天是否能准時完成。
據悉 隊友當時給領導的回復差點讓領導昏厥了過去,隊友回復領導該模塊還沒做，原因是花了7天時間做了思考並且設計思路和架構，打算明天花1天時間來完成。
以下省略 領導和隊友激烈的爭執細節，結果是事已至此，只能按隊友的思路做。
上述一個小故事看似很平常，卻體現了兩個不同角度的觀點。
對於隊友：
1.已經厭煩了提前完成程序后，隨后幾天噩夢般的修改與返工.
2.隊友更注重了開發前的設計和思考
3.深入的領會了“磨刀不誤砍柴工”的精髓
4.既然工期是8天，那就不折不扣的利用工期，保證量的同時還應該保證質。
對於領導：
1.隊友的行為有消極怠工的嫌疑。
2.原來8天的工期如果3天做完，后面5天可以用來測試和完善。領導認為這這種方式是最好的方式。
3.萬一前7天做的思路是有問題的或者根本就是錯的，那么第八天將會功虧一簣。
4.認為IT行業，尤其是應用級項目的開發，同時還是國內的一些中小型企業，“磨刀誤砍柴工”，領導認為根據實際情況來安排1+7 還是7+1才是對的，往往我們需要邊砍柴邊磨刀。
上述兩方其實各有道理，確實從中小型企業來講 領導的觀點更為穩妥，特殊大型企業或產品化成熟度較高的企業，隊友的觀點更為有效。
1+7還是7+1 還是要根據企業、團隊、產品化程度來定，不過呢，寫到這很多網友肯定要噴，既然要按實際情況來定那么還寫這個文章干嗎。
為了滿足有些噴友的需要，其實從我個人不成熟的角度來講 我更傾向於領導觀點的改良版。
往往一個項目的上線或者一個產品的推出，邊砍柴邊磨刀的例子實在太多（想想微軟吧）,作為項目化的開發團隊7+1是不符合實際情況的，產品化的團隊1+7是不負責任的。
因此結合整體情況，很可能我們更需要的是7個1 ，而不是任何的1+7還是2+5或3+ 4.
也就是說作為項目經理， 制定大時間計划是對的。但是作為具體實施的項目組長或開發人員應該把工期切分為以天為單位的進度計划（同時每天要有一個下述關系的成果關聯性）:第二天
用來驗證第一天的成果，第三天驗證第一和第二天的成果，第四天驗證第二和第三天的成功(此時第一天的成果一定要保證無需驗證)。用數列可以顯示 1,1,2,3,5,8,13,聰明的你一定會看出這
個規律，這是個斐波那契數列。
當我們使用這種方法來安排8天的計划時，會確保每天安排計划所產生成果的連貫性和健壯性，如果中間某個環節出現問題不會影響到所有環節，只會影響相鄰的3個環節而已。
最后要說明的是，無論1+7 還是7+1或者 上述的數列理論，都有失效的時候，世界本是就是不完美的，完美只能 “力求”而不能強取，希望本文對各位項目管理者有啟發和幫助。
