當前的做的迭代的需求、流程、依賴以及其他的疑問理清楚，讓項目組可以順利推進的時候，項目經(jīng)理不應該再專注在當前的迭代，而是要開始想整理下一個迭代的事情，讓大家在完成當前迭代的時候，不需要暫停在那邊，去等待梳理下一個迭代的問題。

舉一個例子，當前的迭代我們在做用戶登錄的功能，做完這個迭代，接下去我們就要做登錄完的首頁展示。開發(fā)組在做登錄的時候，項目經(jīng)理也跟著在那 邊搗騰登錄的細節(jié)。等下一個迭代開始的時候，項目組才發(fā)現(xiàn)首頁展示只有原型圖，UI 跟HTML都還沒做出來，而其他功能更沒有準備。于是項目組就只好花兩三天的在那邊等UI和HTML。

九、 固定的項目組成員

這是一個很簡單的要求，但是并不是所有的人都會重視。正如隨便加一個開發(fā)人員進來并不能夠立刻讓整個項目進展加快，換一個人的話，整個進展肯定也會受影響。

十、 組員潛力

每一個程序員、測試人員、美工、產品經(jīng)理，都比你想像的要聰明。如果你沒有對你組員的能力有個清晰的認識，那你可以嘗試給他的任務增加一些難度，超過你原來的預期一點點。他能完成，你以后可以再增加一些難度。直到他直接跟你說他搞不定。如果你覺得你已經(jīng)有個清晰的認識了，那你也應該記得，只是 你覺得。

我們有一個項目，里面有個很棒的程序員Joy，平常是個很低調的人。項目經(jīng)理分任務的時候，就給他幾個特定的模塊讓他完成。他也堅守崗位，做好他份內的事。項目因為種種原因，不斷的拖延。但是Joy還是很誠實的做好他的本分。

后來有人跟Joy講，你以后要把自己當dev lead看，所有開發(fā)的事情你統(tǒng)籌。Joy還是一個很低調的人，他繼續(xù)做他本分的事情，只不過這次的本分就是統(tǒng)籌負責所有的開發(fā)問題。

接下去就是項目的問題一個接一個的被快速解決掉，其他程序員也得到強有力的幫助，快速處理到自己手頭中的bug。項目進展很快趕上了原來的計劃。你真的很好的發(fā)揮了你組員的潛力了嗎？

十一、人人看到全盤

項目經(jīng)理能夠很好的分配好任務，讓各個組員可以較獨立的工作，這是不錯，但也不見得就是好事。因為軟件開發(fā)是一個團體的工作，各個人做的事情之間都有交叉。我做的功能，接下去就要調用你的接口。你做的頁面，接下去就要跳轉到我的。

Bruce做一個功能，是要顯示公司人員信息的列表。里面有個操作，選擇一個人員計算出勤率。這個操作不是Bruce完成了，他只要直接調用Lisa的頁面，Lisa的頁面會直接計算出勤率并顯示出來。Bruce認識，他只要簡單傳一個人員的ID過去就可以了。

Lisa做這個出勤率的頁面，因為這個人員是屬于業(yè)務人員，經(jīng)常要在分公司跑，所以只能計算他在某一個分公司的出勤情況。她以為大家都知道。等 大家都完成了，QA在測試的時候，發(fā)現(xiàn)在人員信息列表里面點進去，顯示不了出勤頁面。整個流程都走不通了。后來才發(fā)現(xiàn)有2個問題沒解決好，一個人員信息跳轉到出勤頁面前要傳遞當前的分公司信息，一個是出勤頁面還要增加選擇分公司的功能。這2個問題一個是QA測出Bug，一個是需求還有不足。而這本來是應該在開發(fā)周期內就可以發(fā)現(xiàn)并解決的問題。

根源就在于，Bruce跟Lisa在做手頭任務的時候，都沒有去考慮跟其他人的關聯(lián)。而他們2個人都沒有去考慮的話，其他人更不會去考慮了。如果