针对于“当客户说：你们先开发出来我再提需求”的一段回复。虽然因为只能不超过250个字的限制我分了4次贴了，后来想想，还是写成blog存一下好了。
这个问题我觉得我可以多谈两句
我一直以来都是在做行业业务软件，实际上也就是传统行业的信息化工作。看了一下回复，有几条说得都挺对的。我只是提一点我的看法。
1、行业业务有其自有的模型和流程，这些内容已经固化在用户的日常工作中了，更有的行业已经形成了相应的行业规范和标准，退一步说也有通用的业务流程和岗位职责规范。你不可能指望现场的用户手把手带徒弟似的把他的日常工作给你交代一遍，述职呢？在与用户沟通前，至少要将其标准的业务流程整理出来，形成原型或者演示系统。文章中的一开始“项目的要求是能够处理公司客服中心收到的各种服务请求，内容包括服务调度，设备跟踪，工程师的服务请求以及一些设计问题。”仅仅这几句话，功能模块和业务流程就已经交代得很清楚了，至少可以出一个演示系统。文章主角拿出来的这个演示只能说他对客户业务一点都不了解，或者只是为了嘲笑和讽刺客户。“别把客户当傻瓜”这是条铁律，你把他们当傻瓜，后果就是文章结束时的样子。
2、大多数人擅长的是挑毛病和批评，而作为一个程序开发人员，其价值是从无到有的创造。如果用户能够提出相对完整的需求，那他应该就是个产品经理或者需求分析人员，这只能说明软件开发公司本身业务上有缺环。这类软件的公司要么需要聘请相应行业中熟悉业务的人来作为顾问总结需求，要么就是企业能够浸入行业中，熟悉行业的规范和惯例。如果没有，那么必须给一个靶子，而且是靠谱的靶子让你的用户去挑错、攻击、提意见。凭空什么都没有，一张白纸或者拿着个用例表就去找人家谈，得到的反馈只能是文中那样的。我们之前做的一些软件基本上都是根据自身对业务的理解作出一个只有界面的原型，编一些数据，能够通过一个页面或者一个ppt，模拟软件使用过程，走一遍流程，让用户能够体验到实际使用软件的感受，然后他们的想法和思路就如泉涌一般出来了。这个过程是反复修改的过程，白天开会讨论，晚上整理需求，根据新需求修改页面。过程很辛苦，但开发的内容很切合。（当然，要做更好则要比现场客户站得更高，看得更远，但有些实际情况，没有客户的协助的不会明白的。潜规则太多）
3、“一把手工程”和人际关系的问题。文章的最后一句“然而，接下来的几个月里，他们都不理我”解释了这篇文章的立场。采取在最高领导面前羞辱你的客户是非常无知、幼稚的做法。很多做信息化的人知道，信息化被称作一把手工程。因为很多时候，信息化和传统工作方式在过度期间是并行的，用户既要采用传统的工作方式处理日常工作，又要配合你的开发新系统，收集数据，审核需求，学习一个并不成熟的系统的使用，在试运行期间又要把平时的工作在mis上再做一遍。工作量增加了却未必能有所收获。一些系统实施者认为这是用户懒惰，需要大领导施压，主抓才能解决。但稍微换位一下，要求各位程序员除了写代码之外还要把每一句都写上注释，包括if else，估计程序员们早就疯掉了。与其抱怨客户不配合，不如想想如何才能真正帮助他们更快更好的完成现有工作的同时，也将信息化工作向前推进。得到基层用户的肯定和配合，项目和产品才能更好的推进。不知道这个项目最后如何收尾，反正如果你得罪了财务部门，收款可能都是问题了。
4、诚如前几天的一篇文章中所说，程序员是一帮用逻辑思考问题的人，他们的思路很大程度上异于常人。普通人思考没这么严谨，逻辑更是稀缺之物，抽象思维简直超出了大部分人的脑力极限。因此，要做需求分析和用户沟通，必须跨过这个思维的藩篱，把自己当成客户和系统，甚至是开发人员之间的桥梁。只有能够自有在两种或者多种思维中游刃有余的人，才能去做这类工作，显然，文章的主人公还没有达到这种程度。
以上是我的一点看法。和机器沟通与和人沟通完全不是一回事。
原文地址：http://my.oschina.net/rodger/blog/291527
