当前的做的迭代的需求、流程、依赖以及其他的疑问理清楚，让项目组可以顺利推进的时候，项目经理不应该再专注在当前的迭代，而是要开始想整理下一个迭代的事情，让大家在完成当前迭代的时候，不需要暂停在那边，去等待梳理下一个迭代的问题。
举一个例子，当前的迭代我们在做用户登录的功能，做完这个迭代，接下去我们就要做登录完的首页展示。开发组在做登录的时候，项目经理也跟着在那 边捣腾登录的细节。等下一个迭代开始的时候，项目组才发现首页展示只有原型图，UI 跟HTML都还没做出来，而其他功能更没有准备。于是项目组就只好花两三天的在那边等UI和HTML。
九、 固定的项目组成员
这是一个很简单的要求，但是并不是所有的人都会重视。正如随便加一个开发人员进来并不能够立刻让整个项目进展加快，换一个人的话，整个进展肯定也会受影响。
十、 组员潜力
每一个程序员、测试人员、美工、产品经理，都比你想像的要聪明。如果你没有对你组员的能力有个清晰的认识，那你可以尝试给他的任务增加一些难度，超过你原来的预期一点点。他能完成，你以后可以再增加一些难度。直到他直接跟你说他搞不定。如果你觉得你已经有个清晰的认识了，那你也应该记得，只是 你觉得。
我们有一个项目，里面有个很棒的程序员Joy，平常是个很低调的人。项目经理分任务的时候，就给他几个特定的模块让他完成。他也坚守岗位，做好他份内的事。项目因为种种原因，不断的拖延。但是Joy还是很诚实的做好他的本分。
后来有人跟Joy讲，你以后要把自己当dev lead看，所有开发的事情你统筹。Joy还是一个很低调的人，他继续做他本分的事情，只不过这次的本分就是统筹负责所有的开发问题。
接下去就是项目的问题一个接一个的被快速解决掉，其他程序员也得到强有力的帮助，快速处理到自己手头中的bug。项目进展很快赶上了原来的计划。你真的很好的发挥了你组员的潜力了吗？
十一、人人看到全盘
项目经理能够很好的分配好任务，让各个组员可以较独立的工作，这是不错，但也不见得就是好事。因为软件开发是一个团体的工作，各个人做的事情之间都有交叉。我做的功能，接下去就要调用你的接口。你做的页面，接下去就要跳转到我的。
Bruce做一个功能，是要显示公司人员信息的列表。里面有个操作，选择一个人员计算出勤率。这个操作不是Bruce完成了，他只要直接调用Lisa的页面，Lisa的页面会直接计算出勤率并显示出来。Bruce认识，他只要简单传一个人员的ID过去就可以了。
Lisa做这个出勤率的页面，因为这个人员是属于业务人员，经常要在分公司跑，所以只能计算他在某一个分公司的出勤情况。她以为大家都知道。等 大家都完成了，QA在测试的时候，发现在人员信息列表里面点进去，显示不了出勤页面。整个流程都走不通了。后来才发现有2个问题没解决好，一个人员信息跳转到出勤页面前要传递当前的分公司信息，一个是出勤页面还要增加选择分公司的功能。这2个问题一个是QA测出Bug，一个是需求还有不足。而这本来是应该在开发周期内就可以发现并解决的问题。
根源就在于，Bruce跟Lisa在做手头任务的时候，都没有去考虑跟其他人的关联。而他们2个人都没有去考虑的话，其他人更不会去考虑了。如果