项目上线有一段时间了，上线后大家忙着改bug，忙着汇报，忙着二期的规划，一直没有坐下来一起聊聊。

上周，我还是决定花费大家半天的时间，组织开了迭代回顾会。

迭代回顾会对于敏捷来讲，是一个很重要的实践，但其实不提敏捷的时候，我们也在做，只是有个更普通的名字，叫项目总结会。(迭代回顾会的实践方法见文章最后)

会上，当我们回顾了项目过程时，发现一个重要问题，这个问题就是：经常性的，我们忽略了或忘了目标，这里的目标应该有但不限于以下内容。

一、 业务目标

说出来，大家可能都觉得不可思议，没有目标，那项目组最终要交付什么样的系统？项目组又在为了什么而忙？

可事实就是如此，很多时候，我们盲目的就开始了一个项目，然后盲目的就做出一堆功能。

真实情况是这样的，我们的研发团队不是一个真正的互联网产品团队，虽然有产品经理的角色，也基本是技术主管或经理担当的，结果就是我们更关注的是要做哪些功能。

例如，我们规划要做一个公有云系统，产品经理就会看世面上的公有云产品：华为云，阿里云，亚马逊等，然后去参考他们的界面，去试用他们的功能，恨不得copy一个类似的产品出来。

实际上，我们并没有想清楚，华为云，阿里云已经做起来了，我们为什么还要做这个系统？我们是比他们有更强大的技术能力，能快速的仿造出一个公有云系统，跟他们抗衡或分一杯羹？还是我们的资源比人家便宜？还是我们的安全性或服务可以做的比他们好，让客户觉得更有保障？

可是，至少从目前看，我们的技术实力并不比人家强；据我了解，亚马逊本来就是因为那些资源闲着也是闲着，才做了个公有云来处理闲置的资源，其他的市面上单独卖I层资源的，都是在做赔本生意；还有，公司内部的环境还存在各种单点，无容灾系统等问题；

那我们为什么要做这个系统？我们的客户是谁？客户的使用场景是什么？我们能为他们解决什么问题？这点就决定了我们的业务目标是什么、产品和服务是如何定义的，也决定了我们的产品跟其他的竞争对手的差异性。

所以，做一个产品，我们核心要明确业务目标，确定目标用户、梳理业务场景并进行产品定义。

开发都启动了，才有人点拨我们，我们差不多花了整整一个月才从想到想明白，造成了部分返工。


二、进度目标

需求清楚了后，技术负责人将需求转化成开发计划，接下来就可以开发了。

开发计划的坑同样很多，完全依赖于技术负责人对需求的理解，以及将需求转化为开发的设计能力。对需求的不理解或理解偏差，以及较差的设计能力导致系统扩展能力不足，都会导致不必要的返工，并且可能会低估工作难度，导致计划评估不准。

于是，在开发阶段，又有一个很容易迷失的目标：进度目标。因为以上主要原因，就算计划做的再详尽，人员再稳定，计划和实际执行也是很难一致。

加上公司内部的系统，没有客户抽着鞭子催你，项目经理也很容易做着做着被现实屈服，做到哪，算到哪，不停的变更发布计划。

首先，要解决的是需求到设计的转化，形成双向评审机制。产品经理除了输出业务流程和原型外，还要输出需求文档，并且需求文档要能细化到功能点，包括界面的字段说明，长度等，技术负责人评审确认；而当技术负责人完成设计后，产品经理要反向的参与进来评审。

然后，要严肃计划，计划是每个人的承诺，不是完全不可变，但是一旦定下来，大家就要严格执行，无法完成的就自己想办法，要不加班，要不优化提高个人生产率。


三 、测试目标

很多系统测试，最注重的还是功能测试，而且偏向于功能点的测试，忽略了贯穿测试。

所以，一开始就要确认测试的目标，要包括功能测试，安全测试，静态代码扫描等，还要有兼容性测试，一开始在ue开始做静态页面的时候就要明确好要支持的浏览器版本，省的理解不同，还要做改造才能向下兼容。

性能测试指标也要一开始就跟测试人员确定好，多少用户量，满足多少tps，响应时间最长多少等必须明确。


四、 个人目标

做每个项目，除了达成项目的目标外，我们也要给自己设定一个目标。比如，我想通过这个项目让老板对我刮目相看，想在公司中扬名立业，让大家都知道，这么牛的系统是我带队开发的。

或者我想通过这个项目达到坚持每日过进度，有效管理项目计划的目的。

或者，我想通过这个项目实践我刚刚学习到的沟通技巧，在面对冲突时，或关键对话时。

或者，我想按照敏捷的方法试一下项目管理过程，更或者特别微小的，就是想试试敏捷的生产率评估或持续集成。

作为开发人员，你可以定的目标是了解整个项目的业务，而不是只关心自己开发的那部分功能，或者是要学会使用一种前台框架，或者熟悉redis，或者学会部署监控系统，日志系统。


附： 迭代回顾

每个迭代完成后，项目经理要组织产品经理以及技术经理在内的项目团队一起进行迭代回顾。

项目经理可以回顾下整个迭代过程，大家轮流发言，每个人都回顾一下他认为哪些是做的好的，哪些可以做的更好， 哪些需要在下个迭代中改变，具体有什么建议。

要注意的是，通过回顾，你会发现需要改进的点很多，都改过来变得很困难，所以，结束前，还是要跟大家一起商量出下个迭代优先要解决的TOP5。

迭代回顾特别重要，否则，你就会发现在下一个迭代中，团队还是在不断重犯同样的错误。尤其提醒的是，氛围也很重要，不要把迭代回顾变成批斗大会，因为我们的目标是为了在下一个迭代能够做的更好，而不是让大家自我否定，退缩，失望。