关于设计的可扩展性。

如果你弄一帮不懂技术、不知道软件怎么做的人去搞需求，那是你自己找死，不是别人要害你死。

如果你不能找到愿意担负这个责任的客户呢？
是不是就不做项目了？

你可以考虑用一个人作为客户代表。这个人充分了解需求之后可以来提供用户故事。但是“选择”的责任必须由客户来担，如果客户不愿意担这个责任，我看不出这项目还有做下去的必要。

呵呵，没有客户愿意担负责任只是说明风险很高，从商务角度考虑，只要客户肯提供足够多的费用就可以做了，高风险高收益啊。
当然做的人会比较痛苦……

请再读一遍《与熊共舞》。风险高是一码事，逃避风险是另一码事。

呵呵，好象有点扯远了，本来是说设计的扩展性，怎么变成风险管理了？

另外，不太明白你的意思，是说“不逃避风险，但是要控制风险”吗？

不逃避风险，要管理风险。
预先为每个风险提供解决方案，要时常去检查是否风险真的到了，要提前为快要变成现实的风险做出响应，而不是等风险真的发生了再去想怎么解决。

回到原话题，我的意思就是，客户可以表达不清楚，没关系，我们会整理他的需求，然后拿出明确的几种方案给他选择。比如客户JJYY说了半天对界面的需求，最后我整理出来了，告诉他说：“你可能在xxxx情况下需要yyyy的界面变更，如果我现在考虑zzzz的灵活性，那么项目时间需要延长mmmm天，但是到xxxx情况当真发生时则可以节约nnnn天。”现在他就一定得选择，究竟做不做zzzz。如果做，就意味着现在要给我mmm天；如果不做，就意味着发生xxxx时要给我nnnn天。他不能说一句“随便你”把这个责任推给我，我负不起这个责，出钱的客户必须承担这个责任，其他任何人都担不起。

呵呵，假设最终出钱的客户就是说了“随便你”，现在怎么办？

o6z会告诉你，首先你一开始就应该想办法避免这种客户，比如在协议里有些东西约束他。那么如果真的遇到这种客户又怎么办，我会把这个东西写到纸面：各种方案的利弊是怎样，客户授权我选择，我选择的方案是什么。然后这张纸拿去给客户签字。这其实对于项目本身不会有多少帮助，是我自己和开发团队的风险管理，到时候出了问题找不上我的麻烦。