深圳-罗铭初 (5036**945) 2012-08-27 20:46:56
正在做领域模型，但我发现需求人员调研的对象是领导层，而领导们只关心如何管理，不关心做的过程，于是领域中很多概念都丢失了，需求人员就认为那些概念不用在系统中体现，拿回来的也就是那点被剥削得所剩无几的需求，当我问需求人员的时候，他们就说"跟用户确认过了，就是这样"，这样导致系统都只是用来录入结果，然后生成报表，完全体现不了如何做的业务逻辑。实用化程度一直不高。大家觉得这种情况普遍吗？
xj (3565**79) 2012-08-27 20:48:42
这是需求没有做好
深圳-罗铭初 (5036**945) 2012-08-27 21:00:58
做需求的人，大部分是实施人员转过来的，少部分是老开发人员转来的，实施人员对用户和领导的话唯命是从，不加斟酌。老开发人员根本不屑一顾我的问题。
深圳-罗铭初 (5036**945) 2012-08-27 21:01:22
我说的是我公司的现状
kevin (3075**697) 2012-08-27 21:01:55
实施人员搞个毛的需求
深圳-罗铭初 (5036**945) 2012-08-27 21:04:58
就是因为他们有接触用户最多这个优势
深圳-罗铭初 (5036**945) 2012-08-27 21:05:12
但是缺乏捕获需求的技能和方法
kevin (3075**697) 2012-08-27 21:05:27
细节
kevin (3075**697) 2012-08-27 21:05:33
忽略很多细节
kevin (3075**697) 2012-08-27 21:05:43
搞的都是大概的
深圳-罗铭初 (5036**945) 2012-08-27 21:08:25
就是，所以现在做出来的东西很多都说不通，以后一旦有变更，系统就会变得不伦不类，最后还是怪到开发人员头上
Evan-/kf (233**103) 2012-08-28 09:29:48
调研的对象搞错了吧
Evan-/kf (233**103) 2012-08-28 09:30:08
公司的领导有市场人员去搞定，而不是在开发需求的时候去拍马屁
麦子 (75695510) 2012-08-29 10:08:46
好的需求人员，实际上就是一个好的销售
潘加宇 (3504847) 2012-08-29 15:47:21
需求包括业务规则，如果这部分没有缺少，领域模型是可以建起来的
张志刚 (5475**213) 2012-08-29 15:49:52
缺少训练
潘加宇 (3504847) 2012-08-29 15:51:07
设计要抓住领域的内涵。设计源于需求，高于需求。需求是领域内涵这个体上长出来一朵可以卖的花。
海纳百川 (5094**965) 2012-08-29 15:54:40
设计源于需求，但是设计如何高于需求呢？需求是源泉，如果没有其他需求，那么设计怎么才能高于需求？如何知道设计的架构未来是有用的还是无用的呢？
cthily (67024**8) 2012-08-29 15:58:31
考虑扩展性。
海纳百川 (50***9965) 2012-08-29 15:59:33
怎么考虑扩展性？根据什么考虑？怎么知道设计的架构未来是这个方向的？而不是另外方向的？
cthily (670***28) 2012-08-29 16:00:45
大的方向都没把握好。还做什么。
海纳百川 (50***9965) 2012-08-29 16:01:38
大的方向也是会变化的，方向是有时限性的，不是说一成不变的，所以，仅仅是大方向是没有用的
cthily (670***28) 2012-08-29 16:04:10
什么事都要把握一个度。不能无限制在空想。
海纳百川 (50**9965) 2012-08-29 16:06:45
同意把握一个度，但是这个度的掌握是很难的，怎么知道这个度是合适的，而不是超前的，或者是短视的呢？大家有什么好的经验？
潘加宇 (3504847) 2012-08-29 16:08:22

潘加宇 (3504847) 2012-08-29 16:14:35

深圳-罗铭初 (5036**945) 2012-08-29 16:26:59
嗯，这时设计的价值就体现出来了，但设计的效果取决于对核心域的把握和抽象的能力，例如如果这个调温器它只能调节电阻发热温度，但是控制饭的温度才是电饭锅的核心所在，而饭的温度还取决于容器的导热性能（与材料、厚度等有关）以及电饭锅的结构（影响电饭锅内的热力环流）