困局
相信很多人经历的一些项目都进入过一个相同的困局：
- 组员有点屈：每天加班干，项目还延期
- 老板不满意：每次都延期，后果很严重
从事软件开发多年的老兵都知道，在一个软件项目的生命周期里，不可避免地会生产很多变化（人不一定一开始就知道自己要什么，人也不一定明天要的和今天要的一样，知道自己想要什么，也是个迭代过程。此外，信息从一个大脑到另一个大脑的过程中，必然会发生丢失或改变，这也是引发变化的一个原因），这必然会导致一些返工，严重时甚至导致项目的彻底失败。虽然变化无法完全预测，但是还是存在一些方法论，能使得将变化带来的问题降到可接受的水平，甚至将快速适应变化视为团队的核心能力。这里试提出一些方法，主要从需求分析可开发流程两个方面讨论：
需求分析
从大局出发
不谋全局者不足以谋一域，需求分析的最初阶段应该从大局考虑，不要迷失于细节，需做到：
- 了解主要干系人的期望
- 列出系统都有哪些模块
- 搞明白哪些是核心模块，哪些时辅助模块
- 搞明白模块和模块之间的关系
- 定义好术语
一个项目的成败与否取决于其结果是否能够满足主要干系人的期望，所以首先要搞明白主要干系人的期望是什么。比如：为什么要开发一个新系统，目的是什么？如果已有老系统，干系人希望新系统能够带来哪些老系统没有的东西。
然后就是对系统的整体把握，列出大致的模块划分，但是不能一视同仁地对待所有模块，应该搞清楚哪些是核心，哪些是辅助，这取决于主要干系人的期望是什么。这样在后续开发的过程中可以把精力和资源多分配在核心模块上。
最后就是术语，我觉这是软件开发中非常重要的一个因素，但是经常被忽视，以至于影响对业务的理解和团队成员之间的沟通。子曰：“名不正则言不顺，言不顺则事不成”。语言就是大脑对世界的建模，如果术语不统一，很可能会导致大家认识的偏差，比如某项目里的“后台用户”、“会员”、“内部用户”、“人员”等，鄙人觉得这几个术语看起来 很像，甚至在我们沟通的过程中时有混用，有事不免会引起一些误会。
如果能把术语确定下来，并且大家使用同样的术语，项目已经成功了一半，毕竟术语就是对需求的建模，有了一套清晰的团队术语，意味着项目的整个蓝图是清晰的，在诸位大脑里是基本一致的。术语不能仅停留在口头沟通上，应该在数据库表，代码变量命名上把它表现出来。如果一段业务很难抽象为一个简单的术语，需考虑业务是否太多复杂，是否可以分割等。我比较推荐团队维护一张如下图这样的术语表：
| 术语 | 英文 | 说明 |
|---|---|---|
| 后台用户 | user | 可以登录后台系统的使用者 |
| 会员 | member | 可以注册并登录手机端App的使用者 |
| 内部用户 | InnerUser | 本公司员工中的后台用户 |
| 人员 | person | 后台系统中XXX模块中的数据记录 |
术语定下来后，以下几个地方要务必使用：
- 口头沟通时
- 需求、设计文档中
- 代码中的变量（有时候用英文复数表示，如人员的集合用“people"，而单个人用"person"）
- 数据库表（建议用复数，如人员表用“people”）
详细的需求
详细的需求不必一定在开发完成之前全部做完，我觉得应该和开发保持一致，反复迭代，不断进化（下文会说到）。况且想在开始开发前就制定一份完美的详细需求是不可能的。 鄙人觉得我们的需求工作还可以从以下几点改进：
做好记录
可以简略地记录需求内容、提出者（提出着不一定是主要的干系人，需结合干系人的重要程度和功能的重要程度决定需求的优先级）、时间等，但不建议记录的非常详细（可通过口头沟通弥补细节，至于什么样的详细程度才能正好做到既能说明问题又不至于陷入文档灾难，那就是一门艺术了），起一个唤起记忆的作用就好，省的日后撕逼。
群策群力
一些关键需求尽量大家都互通一下有无，包括开发人员，测试人员和团队领导等。团队的目标是一样的，不应该把工作分的太分明，人人有份，只是大家擅长的不一样而已。比如有着丰富开发经验的程序员，也可以参与对需求的讨论，也许可以及早发现坑坑洼洼，及早填埋，需求是最关键的一环，应该群策群力，做到最好（当然，最后拍板还是需求分析师说了算，如果没有拍板人，可能会陷入无休止的争论），反倒是开发的重要性在其次，一般的业务，西二旗随随抓一个年轻人，都会写的。
分清楚方案和问题
干系人有时候会善于提出方案，不善于提出问题，而他提出的方案也许不是一个好方案，经验丰富的需求分析师或开发者应该通过方案看到问题，然后再根据问题寻找更优的方案，并说服干系人采纳。
开发流程
推荐使用敏捷开发方式，以小步快走的方式逐步发布功能，而不是一次性完成所有功能。具体方式为：
- 以2到3周为周期，发布一次可运行的系统
- 每个周期的末尾，邀请干系人试用，记录干系人的反馈
- 某个周期的工作任务包括开发新功能和根据上个周期的反馈修改系统
之所以要小步快跑，而不是等所有功能都做完再上线是因为一个软件系统更像是一个不断进化的生命体，而不像一个设计好图纸就可以开工的建筑物。这里有很多不确定因素，会伴随软件开发的整个过程，如：
- 需求分析师最初对业务的认识不够深入，容易忽略某些关键点，甚至理解错误
- 干系人在没有看到可以运行的软件前很难确切地知道自己到底要什么
- 干系人的想法会变
- 信息从干系人大脑到需求分析师大脑的过程中产生了丢失或改变
如果采用短周期逐渐交付可运行软件系统的方法工作可以解决如下问题：
- 及时发现和更正错误，不至于积重难返
- 及时响应来自干系人的变化
- 干系人在整个开发过程中都有对项目进度的把控感
总结
从更高的角度看项目的成败，其实最重要的是团队成员的士气。士气足，才可以讨论方法，士气衰，干啥都难。怎么保持士气？除了员工待遇，还可以考虑：
- 搞好团队气氛。定时搞点有意思的活动，比如大家轮流抽空做演讲
- 领导重视项目。比如召开项目启动大会，及时鼓励团队
- 别把人机器化。最好是让大家有权参与项目的方方面面，不要局限于某一个重复性固定工作
全文完。