在开始构建项目之前要满足一系列的先决条件：
- 问题定义
- 需求分析
- 项目架构
问题定义
首先要对项目要解决的问题做出清楚的陈述。通常我们讲的叫做“产品设想”、“产品定义”。这里我叫他问题定义。在做问题陈述的方法有很多，这是大部分产品经理的职责所在，作为一个项目的技术主导者或者仅仅作为一名实现产品经理伟大梦想的程序员，我们需要有能力去判断产品经理是否已经做好了产品定义。
问题定义只需要定义“问题是什么”或者“想要什么”，而不涉及任何可能的解决方案，需要的只是简单的陈述，简单来讲我们只需要它听起来像是一个问题。例如：“我们无法记录用户的浏览行为”或“我们想要记录用户的浏览行为”，这样的句子听起来像是一个问题或是一个产品的诉求，而像“我们需要通过在应用中打点的方式，记录用户的浏览行为”这样的描述则更像是一个解决方案，并且这样的描述实际上还有其他的问题，下文将会阐述。
问题定义应该尽量“客户”的语言来书写，而且应该从客户的角度来描述问题。通产不应该用缺乏共识的词汇和语言或者计算机的专业术语来陈述。这里“客户”会因为具体产品的不同而不同，外包项目的客户是“the boss”，自有产品的客户大部分是产品的用户，而“我们需要通过在应用中打点的方式，记录用户的浏览行为”很可能是某位运营的同学，而这里提到的“打点”并非一种恰当的陈述，我们可以换成大家都有共识的“上报”等共识度更高的词汇。当然，在某些情况下是有例外，例如：编译时间太长、部署工具Bug太多等等。
良好的问题定义的目的在于为所有参与其中的人都很够更小成本的理解问题，能快速的加入讨论，更假重要的一点则是能够确保我们将要解决的是不是一个“错误的问题”，否则要浪费太多的时间去解决“错误的问题”得不偿失。
需求分析
需求描述项目应该做什么，是达成解决方案的第一步。
明确的需求有助于确保是“客户”（上文中提到的客户）驾驭系统的功能，而不是程序员。需求明确，“客户”可以自行进行评审，并进行核准。否则，程序员就不可避免的会在编程过程中自行决定了需求（通常情况下程序员并不是出于主观意识决定的，那可能就是他对需求的理解）。千万要避免程序员去猜测“客户”想要什么。
明确的需求有助于避免争论。在开始编程之前，先把项目的范围确定下来，在程序员们在讨论“程序应该做什么”的时候，可以查看书面的需求解决分歧。
明确清晰的需求有助于减少编程开发之后的项目变更情况。如果在编码过程中发现了一个代码上的错误，可能你只需要修改几行代码就能解决问题，然后继续工作。但是如果在编码的过程中发现了一个需求错误，那就不得不停下来改变设计，使它符合更改后的需求。更有可能的是，我们可能需要扔掉部分旧的设计，并且因为要与已经完成的编码相适应，可能导致新的设计与项目之初进行同样的设计相比发费更多的时间。此外，还需要废弃那些受影响的代码和测试用例，然后花时间重写。
项目构建期间的需求变更
项目构建期间发生的需求变更往往很让人头疼，我们可以参照一下几种方式来处理
评估需求质量
如果需求不够好，那就需要先把它做好再继续。这期间可能会停止编码，但这通畅情况下是必要的。千万要避免做了反方向的火车。如何评估需求的质量可能各个团队都有自己的一套规则，下面只是参考：
需求的质量
- [ ] 需求是用用户的语言书写的吗？
- [ ] 每条需求都不与其它需求冲突吗？
- [ ] 是否详细定义了相互竞争的特性之间的权衡——例如，健壮性与正确性之间的权衡？
- [ ] 需求是否在详细程度上保持一致？
- [ ] 需求是否足够清晰，即使转交给别的小组去构建，他们也能理解？开发者们也这么想吗？
- [ ] 每个条款都与待解决的问题及其解决方案相关吗？
- [ ] 是否每条需求都是可测试的？
确保每一个人都知道需求变更的代价
“客户”尤其是产品经理想到一个新功能就会很兴奋。在兴奋的时候血液会涌向大脑，人会晕头晕脑，他会把你们开过的讨论需求的会议、做过的约定、以及完成的需求文档统统抛到脑后。最简单的对付这种新功能中毒患者的办法就是说：“咦，这个听起来不错哟。不过由于它不是需求文档里的内容，我会整理一份修订过的进度表和成本估计表，这样你可以决定是现在实施，还是过一整子再说。”“进度”和“成本”比咖啡和冷水澡都有提神，许多“must have”很快都会变成“nice to have”。
一个对“先做需求分析”的重要性敏感的团队，配合起来应该会更加有节奏感。
建立一套变更控制程序
很多时候产品经理可能还是比较顽强，激情不减，你肯能意识到潜伏着危机却没有拍板的权利，那一定要考虑团队建立一个正式一点的控制委员会，评审提交的需求变更方案。产品经理对功能的诉求，并不是一件坏事。问题在于方案变更过于频繁，会打乱团队的节奏，以至于跟不上进度。不能愉快的玩耍。
使用能适应变更的开发方法
选择合适的开发方法可能会尽可能的缩减开发周期，以便更快的响应“客户”需求。通常我们可以将大的需求变更尽可能的切分为小块，可以一步步演进式的交付需求。
放弃项目
如果上面没有一个办法可以奏效，需求特别糟糕还不稳定，那是时候考虑放弃这个项目了。
注意项目的商业价值
有一些需求作为特色功能看起来是不错的想法，但是当评估“增加商业价值”的时候觉得它是一个糟透了的主意。那么许多需求就会从我们眼前消失。
项目架构
To be continue...
网友评论