业务是发现问题（价值）并找到解决（实现）方法技术解决的是效率问题所以懂不懂业务考验的是知不知道问题或者价值在哪里，能不能找到解决方法或者实现路径。技术关注的是如何高效率的重现解决过程和实现路径，选型最关键。...

需求基线就是用版本对需求划一条线，说明这些需求已经确认，任何变更必须通过需求变更流程防止随意的需求变更导致交付失败

我们做系统设计的时候，如果碰到不合理的校验需求，一般会在设计上缩小逻辑控制到可以理解，而又不影响到业务流程的程度。根据自己理解加校验是大忌。原因是有些校验触发场景很特殊，客户按需求列表验收时很难注意到，实际上线后使用中发现，如果需要去掉就需要重新发版，要走整个验收流程。事实上，对于客户的需求，设计上只能尽可能的往合理角度上去靠，不会每个疑问点都找客户确认，要客户给方案，这是很low的。对于客户需求上的逻辑缺点，在系统设计上和操作支持上的宽容也是功夫。有些低级的问题，即...

不同角色如何实践敏捷开发？ 产品经理代表用户体验，会每天确认系统。新内容必须是用户可见！可操作（测试）！只说后台做了多少，而看不到的都是无用功！ 技术经理代表输入输出管控，必须确保每天有可供体验的内容输出，供产品经理确认敏捷开发的核心是一切必须以用户体验（输出）为中心前台团队是归技术经理还是产品经理管理？UI的布局、艺术与交互设计归产品经理（团队），功能开放步骤与接口挂钩（实现）归技术经理（团队）敏捷开发为什么还需要设计？敏捷...