开发人员应该更多的走近用户

    N年之前，由于总经理 对用户非常熟悉（总经理本身就是一个用户，后来开始做软件），开发人员只需要按照总经理的要求设计软件，这个软件就应该是好用的，事实上的确如此，因为用户比较喜欢我们那时的产品，而对于开发人员，只需要呆在家里，没有必要跑到客户哪里去了解什么需求，因为市场人员和服务人员就会反馈很多新的需求。
    现在不同了，总经理不再有时间告诉开发人员用户需求是什么，而且，对于很多的专业，总经理也不是特别熟悉，因此，如果开发人员再保持以前的工作方式，那可就麻烦了。
    最近几个月，我常常到客户哪里做一些接口工作，昨天又专门为了一个新软件的设计做需求调研。当时的最深的感触是开发人员必须经常与客户交流，这样才会有创新的思路， 与客户直接交流，而不是一直呆在家里编写代码。不与客户接触就脱离现实。用户的需求和抱怨就是我们的现实。
    开发上的很多思路都是与客户交流之后才出现的，用户就是开发人员最好的老师，世界上没有愚蠢的用户，只有愚蠢的设计。如果一个用户说：这个软件怎么这么难用？千万不要在内心里咒骂：这个家伙可真够笨的，很多人都会用，就你事多！软件设计师应该看到，客户的抱怨很可能就是一个机会。
    得到用户面对面抱怨的机会，对于开发人员来说，是很难得的，这是第一手的资料。因为不是所有的开发人员都有机会接触大量的客户，单纯从服务工程师哪里得到的信息都是打了折扣的，信息的传递环节越多，信息失真的程度也就越高。
    别指望服务人员和市场人员告诉你用户的需求，那仅仅是很不完整的一部分。
    我希望开发人员应该定期做一段时间的工程服务工作，然后再做一段软件设计工作。开发人员做服务，比单纯的工程服务人员，具有另外的优势：开发人员知道软件是如何设计的，知道软件设计的很多细节，对于很多深层次的技术了解的更多，解决问题可能会更彻底。
    软件的设计有时候靠的是一种对用户充分了解之后的感觉，没有过多的理论在里面。这种感觉只有与用户面对面的交谈的时候才会以最强烈的方式出现。
    我们开发部有10几个开发人员，大多数都没有看过用户的工作场所，更不用说与用户进行面对面的交谈了。尽管他们每个人都很优秀，但是编写的程序要么搞的太复杂，要么搞的太简单，就想严守一说的：生活很复杂，你把它搞简单了，或者说生活很简单，你把它搞复杂了。用户可能就需要那么几个简单的功能，结果我们给它搞了个庞大的系统，用户可能需要很多功能，但是我们给将用户的功能简化了，甚至是想当然的认为：这个功能没有什么用，不实现。结果用户使用起来就不是得心应手，就开始说：这个软件怎么这么难用？其实，用户就是指那个你认为没有用的功能。