Bruce或者Lida在做任务的时候，去想想他们彼此怎么串联起来，这问题本身就很简单了。

项目组的每个人，可以重点在自己手头的任务，但是思路必须是在全盘，大家脑子里面都要经常去想想，整个系统是什么样子的，我的功能前后的依赖是什么样的。项目经理平常要引导大家这样想。

十二、一定要分成每一个小迭代

步伐迈得太大了，你就不知道你迈得对不对，迈得够不够快。项目是不可能一步到位的。把一个大目标分解成每一个小目标，整个项目工期分成若干个短 迭代，一个一个的完成。每一个完成的小目标都能帮助你理清整个项目的进度，方向，帮助你审核一下目前的思路是对的还是错的，出错了，也能够及时的调整。

十三、不做一半的功能

如果我们做了2个功能，但是我们每个功能都做了一半没全部完成，那目前为止我们总计完成了多少个功能？1个？不是的，完成了0个。一个功能除非真正完成并且通过产品经理的检查，不然你永远不能确定这个功能是不是还有一些遗漏的地方。

100个完成度为90%的功能合起来，完成的功能还是0个。你很兴奋你的程序里面有很多功能，但是你试了一个又一个，结果发现每个功能都是半成品，没有一个功能可以正确解决你的问题。对于半成品的功能：

1. 你其实并不知道你还剩多少工作量，因为已经“完成“的工作不能验证说是真正完成的。

2. 你没法给业务部门或者客户做演示，因为这些功能没做完。

3. 如果业务部门让你暂停一下，就先按照目前已有的功能去让客户测试一下，你会哑巴吃黄莲，有苦说不出。所以我们做功能的时候，要确保我们在做的功能已经是真正完成了，我们再去接着做下一个功能。

十四、不让细节影响你的目标

项目组的人很容易沉浸在功能的细节当中，为一些友好美观的显示，炫丽的功能或者很酷的设计浪费大把的时间，忘记了这个项目的最终目标是什么。其他人可以投入，但是项目经理一定要能够抽身事外，专注在项目的全局。沉浸在细节当中很容易让人忘记工期，忘记项目的最终目标。

我这个提示信息的颜色会不会太淡了？

要不要再调深一些？我这个按钮是不是可以往左边移10像素，这样更好看？

这个地方要不要来一个自动提示，这样会更友好一点？

我这个面板的显示要不要使用渐变的？1秒内渐变完成会不会太快？用户会不会还没看够？

你先把功能完成再说好吗？以后有的是大把的时间美化这些。

十五、正确的里程碑要点

我们碰过一个项目，项目经理的报告说，目前的状态是开发完成。结果一看，这样说的依据是分配到所有开发人员的任务，开发人员都认定为完成了。于是大家就认为目前是开发完成，进入QA测试的阶段。结果QA报怨测试不下去，流程都走不通。

产品经理进去看了一下，也说很多地方功能缺失。根本不能认定为开发完成。

1. 一个项目，或者一个短迭代，应该先列出一个所有人都认同的里程碑列表。比如，分为框架设计完成；分解出来的需求已经可用于开发；子任务划分完成；子任务已经分配并预估完成；各子任务完成；开发人员整合测试完成；产品经理检查通过；QA测试通过。

2. 每个里程碑的完成要有大家都认同的验证方式比如如何判断开发人员整合测试完成，是不是开发人员坐在一起或者开发组长把所有流程都走过一遍，然后发现没有什么大的问题？

十六、自我管理

前面讲了这么多，弄得好像项目经理很重要，缺了这个项目经理整个项目就不转了。如果项目经理的手下是固定的，只不过做的项目不一样，那我建议项目经理在完成项目的基础上，一定要考虑这样一个目标：

建立一套流程，一套大家都熟悉并且会遵守的流程。这个流程可以保证整个项目组在项目经理不在的情形下，也可以运转得很好。目前项目处在什么阶段，这个阶段大家要做什么，下一个阶段是什么；这个阶段有什么任务要做；每个阶段碰到问题要怎么处理；每种任务或者问题由谁来处理。这些并不是很难学会的东西。项目的成员经历过几次，很容易就可以理解要怎么做。

项目经理除了推进项目以外，还要在项目的过程中把流程的思路，解决各种问题的思路教给大家，同时明确每个人的职责，达到项目组可以自我管理的程度。一个可以自我管理的项目组，才是一个稳定高效的项目组。项目经理才可以抽身出来，同时去做一些其他的对部门，对公司同时也对自己有利的事情。