Bruce Lee (617****327) 2012-05-11 15:25:15
现在客户就是不给你提量化的需求，我要这样的，好看的，性能要好
Bruce Lee (617****327) 2012-05-11 15:25:44
你还不能质疑，做出来，客户会说你这做的不行呀。。。
利昂 (26***185) 2012-05-11 15:25:55
这就是潘老师提到的"揣摩"，然后调研，然后原型法诱发、明确需求
Bruce Lee (617****327) 2012-05-11 15:26:08
实际中，很难
利昂 (26***185) 2012-05-11 15:26:13
肯定难
Bruce Lee (617****327) 2012-05-11 15:26:16
客户昨天说好，今天又说不行
潘加宇 (3504847) 2012-05-11 15:26:20
涉众只能提供利益，不是需求
书冩、悻畐 (4***535) 2012-05-11 15:26:25
老是。。做原型的属于哪一种啊。。
潘加宇 (3504847) 2012-05-11 15:26:28
这是基本概念问题。
利昂 (26***185) 2012-05-11 15:27:10
潘老师还说过一句很经典的话：电影剧本不是观众告诉导演的
潘加宇 (3504847) 2012-05-11 15:27:14
出现需求变更前，肯定是某种涉众的利益没有考虑到
Bruce Lee (617****327) 2012-05-11 15:27:14
需求分析很高深，没有对业务的深刻理解，很难把握客户真正的需求
利昂 (26***185) 2012-05-11 15:28:07
需求变更的背后，经常体现了不同利益群体的博弈
潘加宇 (3504847) 2012-05-11 15:28:21
所以，涉众利益的积累很重要，不能临时抱佛脚。而且涉足利益很稳定，可以用在多个项目中
Love~黛黛 (19**935) 2012-05-11 15:28:38
好像是前年还是大前年上过潘老师的课
Love~黛黛 (19***935) 2012-05-11 15:29:15
我们项目还没开始前，都会定好利益方及利益方声明
Love~黛黛 (19***935) 2012-05-11 15:30:06
项目管理是中层最头疼的事情
Bruce Lee (617****327) 2012-05-11 15:30:18
这个很重要
潘加宇 (3504847) 2012-05-11 15:30:30
@书写幸福：原型是需求的一种视图，用来和涉众交流涉众利益。
绿萝小绿萝 (53****338) 2012-05-11 15:30:52
其实，所谓愿景分析，对于大型项目非常重要
书冩、悻畐 (49****5) 2012-05-11 15:32:28
做原型是需求分析师做的？
利昂 (26***185) 2012-05-11 15:32:36
其实愿景这种前期阶段的工作，是不是该让售前顾问负责
绿萝小绿萝 (53****338) 2012-05-11 15:34:27
no，原型不是需求分析师做的
绿萝小绿萝 (53****338) 2012-05-11 15:34:39
原型是设计人员做的
潘加宇 (3504847) 2012-05-11 15:34:42
许多伟大产品的需求是通过观察得来的
潘加宇 (3504847) 2012-05-11 15:34:52
@书写幸福：是的。沟通的手段。原型，谈话，喝酒，上床，观察。^_^都是平等的
潘加宇 (3504847) 2012-05-11 15:35:16
原型是需求工件。界面是设计工件。不可混为一谈
潘加宇 (3504847) 2012-05-11 15:35:48
这些都是课上讲过的，现在又讲一遍，真是要倒啊。
利昂 (26***185) 2012-05-11 15:35:50
原型一般用在从业务序列图识别出核心系统用例后，通过原型可以引发遗漏的系统需求，原型一般不用设计师参与，是表达分析师理解的工具。当然，有例外，就是客户对原型要求很高
绿萝小绿萝 (53****338) 2012-05-11 15:37:40
有一个困惑：原型可以引导业务方完善需求；但是却也误导"开发人员"，当做界面。
潘加宇 (3504847) 2012-05-11 15:37:48
原型起到的功效是和某类涉众交流某个功能需求相关的涉众利益
潘加宇 (3504847) 2012-05-11 15:38:11
出发点是：挑错
利昂 (26***185) 2012-05-11 15:38:38
对对，原型就是让客户挑错的
潘加宇 (3504847) 2012-05-11 15:39:09
而且，大多数原型是针对功能需求的，并不针对非功能需求，业务规则，设计约束。。。
利昂 (26***185) 2012-05-11 15:39:22
如果发生开发人员误解，那只能说明项目管理不到位，或者开发人员自作主张....
书冩、悻畐 (49*****35) 2012-05-11 15:39:24
我现在就是在做原型，因为我是编码出身，老是以为在做界面。。。
利昂 (26***185) 2012-05-11 15:40:05
原型界面
潘加宇 (3504847) 2012-05-11 15:40:25
许多开发就会这个，就把这个当成唯一的手段，甚至认为是唯一管用的手段，是没有道理的
潘加宇 (3504847) 2012-05-11 15:40:38
许多开发团队
书冩、悻畐 (49*****35) 2012-05-11 15:40:47
然后跟跟客户去沟通。。。
绿萝小绿萝 (53****338) 2012-05-11 15:41:49
其实，我觉得，争论的焦点不是"原型"、"界面',而是谁在做。
绿萝小绿萝 (53****338) 2012-05-11 15:42:11
如果是前期需求阶段，技术人员投入较少，那么就是原型。
绿萝小绿萝 (53****338) 2012-05-11 15:42:53
到了项目中期，开发人员投入进来的时候，会改进原型，提出更好的交互设计方案，
绿萝小绿萝 (53****338) 2012-05-11 15:43:12
更接近于界面了。
断线的风筝 (9734209) 2012-05-11 15:43:18
原型也分的啊，如果包括页面设计风格和需求在内一起和客户沟通的化，基本上这个原型可以作为开发使用
绿萝小绿萝 (53****338) 2012-05-11 15:43:51
但是，前期投入的人员，并非交互设计的专家，
绿萝小绿萝 (53****338) 2012-05-11 15:44:06
需求人员的局限性，会让我们的系统，很烂
利昂 (26***185) 2012-05-11 15:44:22
哎，这事在中国大环境下不好解决
利昂 (26***185) 2012-05-11 15:44:29
牛b的UI设计师很少
-建涛- (122***07) 2012-05-11 15:44:38
举个实际例子：
我现在面临一个新项目，正在方案讨论阶段
用户一直使用excel做一些数据管理，数据设计，数据分析，现在觉得没法统一管理，想做个软件来弄，之前用户单位的信息化部门自己开发了一个，由于开发水平问题和用户习惯问题，没法用。现在问题重新提出来，还是要做个系统，我们给重新设计了一套方案，做了原型出来，原型基本上是按照excel的模式来做的。可用户看了之后觉得还是不习惯，用户自己提出新的方案，平时还要使用excel做，然后做个数据管理的程序解析excel之后，对数据进行管理。同时在excel里面做些二次开发，规范化excel的操作。
现在问题是：
1.用户没有意识到二次开发后的excel对用户操作本身就有了限制，不如以前一样自由。
2.在excel里面做数据就意味着会有用户不按规范做事，用户自己又不知情。excel对用户操作的约束不够强制。
3.用户如果做了非规范数据进去，在数据管理的程序里面会发生数据丢失，由于数据条目很多，用户将很难排查对照，最终的结果一定是系统不实用。
这些问题和用户说了，用户觉得，没问题，我们可以规范操作，其实我已经意识到，如果真的这样做了，这个系统是用不起来的。
我举这个例子想说明，用户往往会参与设计，干预设计，这个时候对软件开发方的考验是多方面的。屈从用户可能意味着项目失败，当然最后责任可以推给他，但对软件开发来说，是失败的。
利昂 (26***185) 2012-05-11 15:44:48
很多就把原型简单美化一下
断线的风筝 (9734209) 2012-05-11 15:45:26
不过我们原型基本上由ui和开发人员共同完成。呵呵
绿萝小绿萝 (53****338) 2012-05-11 15:45:54

幸福啊，你们还有专门的UI。
利昂 (26***185) 2012-05-11 15:46:16
得看用户方的项目负责人水平如何了
利昂 (26***185) 2012-05-11 15:46:39
都要开发系统了，还要坚持用excel的原始方式，那这个项目的出发点就有问题了
mousedogpig (511184101) 2012-05-11 15:47:44
用VBA开发呢？
利昂 (26***185) 2012-05-11 15:47:58
我曾经做过的一个电子政务项目就是这样，公务员们不愿意抛弃传统的使用习惯，但最终单位领导放话了：不合理的老习惯必须改，改的过程会痛苦，总有个习惯的过程，一定要接受合理的新事物
绿萝小绿萝 (53****338) 2012-05-11 15:48:03
我现在的做法是：
1、业务建模+需求分析（2、3人）
2、原型（6、7人）
3、技术建模+数据库设计
4、时序图
5、关键模块的活动图
6、形成详细设计文档
利昂 (26***185) 2012-05-11 15:48:31
后来还是在甲方领导的强力配合下，搞定了影响设计的涉众
绿萝小绿萝 (53****338) 2012-05-11 15:48:39
当然，我做原型的目的，是让"后进入的技术人员"，吃掉需求。
绿萝小绿萝 (53****338) 2012-05-11 15:49:35
需求是沟通业务和技术的桥梁，如何"吃掉需求"，非常重要。
绿萝小绿萝 (53****338) 2012-05-11 15:49:47
测试人员，靠写测试用例吃掉需求
利昂 (26***185) 2012-05-11 15:49:48
这个案例也说明一个问题，当涉及到影响设计的重大决策时，重点搞定关键涉众，从顶向下推
绿萝小绿萝 (53****338) 2012-05-11 15:50:01
开发人员，靠做原型，吃掉需求
-建涛- (122***07) 2012-05-11 15:50:13
这个项目还在尽量说服用户不用Excel,估计结果不乐观。
利昂 (26***185) 2012-05-11 15:51:15
这种项目就不用找一线用户纠缠，直接尽全力说服项目负责人就好，当然，如果负责人也顽固不化，那就没招了
绿萝小绿萝 (53****338) 2012-05-11 15:52:10
这种项目我也遇到过
绿萝小绿萝 (53****338) 2012-05-11 15:52:27
最重要的获得信任。
绿萝小绿萝 (53****338) 2012-05-11 15:53:01
让他们信任你，真的是想提供一个比原来更好的解决方案。而不是，怕辛苦所以不愿满足他们的要求。
绿萝小绿萝 (53****338) 2012-05-11 15:53:25
当然，获得信任的方法，就不像做技术那么朴实了。
-建涛- (122***07) 2012-05-11 15:54:50
涉众很少就几个人，设计数据很重要，所以几个人用的东西，也要花钱做系统。
项目负责人是信息化部门的人，他们属于服务单位，没有用户牛。加上之前他们自己开发的一套失败案例，更不敢和用户叫板。
涉众太少了，意见很集中也很统一，要是出于赚钱的目的，其实用户的方案更简单。不过就很容易成了一锤子买卖。
利昂 (26***185) 2012-05-11 15:56:47
信息部门的人只是项目的执行者，应该有个更高层的领导来发起项目，比如某个副总
绿萝小绿萝 (53****338) 2012-05-11 15:57:01
这个时候，用潘老师的"业务建模"方法分析，比较奏效。
利昂 (26***185) 2012-05-11 15:57:33
必要的时候需要高层发起人公开说说，为项目关键问题定基调
-建涛- (122***07) 2012-05-11 15:57:46
没有副总，呵呵，单位性质不一样。副总太牛了，不管这种小事
利昂 (26***185) 2012-05-11 15:59:05
这还是确定项目发起人的问题，或者说在甲方单位，是谁决定投这笔钱来做这个项目的
-建涛- (122***07) 2012-05-11 15:59:22
首先这对于用户来说是一个小项目
但对于实际问题来说，是很典型的用户习惯影响软件开发成败的案例。
利昂 (26***185) 2012-05-11 15:59:32
关键时刻这个人就必须站出来配合说话，为项目定基调，定范围
-建涛- (122***07) 2012-05-11 16:00:23
公家的钱，和私营企业不一样，民营企业相对还是很务实的
绿萝小绿萝 (53****338) 2012-05-11 16:01:02
操作习惯的改变，确实需要一个痛苦的过程。因此，做系统的同时，必须同时制定业务规范。
绿萝小绿萝 (53****338) 2012-05-11 16:01:18
否则，系统很难推广。
利昂 (26***185) 2012-05-11 16:01:56
信息化是改进业务流程的过程，不仅仅是买个软件用用这么简单，软件只是业务流程改进的工具
-建涛- (122***07) 2012-05-11 16:01:57
我以前所有民营企业客户，如果说明问题，甲方负责人一般都可以做出正确判断，这和个人水平，企业风格也有关系的，扯远了，呵呵
利昂 (26***185) 2012-05-11 16:03:03
所以ERP的失败率才很高嘛
-建涛- (122***07) 2012-05-11 16:04:36
对，软件对规范化是很好的，同时规范就意味着束腹。
再加上软件设计不合理，对需求了解不充分，出问题太容易了。
我身边现在也有这样的项目负责人，对用户提出的要求，都是能做，最后每个项目都烂尾
Bruce Lee (617****327)2012-05-11 15:02:05
做需求有前途，代码写来写去还是写代码的，需求做好了，可以做产品，产品做好了，可以做市场，市场做好了，就可以自己出来单干了
做需求多有前途呀
潘加宇 (3504847) 2012-05-11 17:32:32
需求就是发现可以卖的价值的技能，这个技能训练好了，受益终身啊。就算当公务员拍马屁给领导送个礼，也更能比竞争对手得领导欢心
@绿萝小绿萝(53****338)2012-05-11 15:04:12
写代码才是技术活
－－ 这个是必要条件，再加上一些其他技能，就能成为脱颖而出的"充分条件"。
－－我现在还一个星期平均有三天在改进内部用的系统的代码，还要每天教儿子编程20分钟呢