市场导向还是技术导向

        不知道广大开发者在设计一个应用框架或技术框架、编写一个类或一个方法时有没有深刻的考虑过一个问题，
这个问题就是,你设计当前作品的目的是什么？你的作品在成型后是需要谁来评价的？是为谁服务的？这个问题
往往是我们平日明确知道却又容易遗忘的关键事项。
        我们常常在一个项目立项前的可行性分析报告中想着需求分析、在项目立项后需求调研时想着需求分析、但是
在应用架构设计、技术架构设计、及后续开发的代码编写和测试环节就忘记了两个字“需求”。
       “需求”实际上就是需要，传统的业务模式下工作的企业职员，他到底需要一个怎么样的工作环境？怎么样才能够使其更高效、更高质量、更低成本、更省力的完成工作，并使其感觉工作不是一种负担，那么就要考虑到设计的细节需求。现在架构师在设计系统时，需求分析一般是和企业客户的高管或中层领导进行业务流程、业务点的分析，但是很少与基层员工讨论用户体验，及业务点工作模式是否能使其接受，软件产品的最终使用者大部分都属于这个群体，在项目实施完成后做业务点逻辑修改也是这些群体提出的需求，为什么不在之前就重视该群体的业务点逻辑，这样可以省去很多实施成本。
         前段时间坛子潜水看到一句话，是烟草行业某个职员在被实施完企业局部信息化后说的，“企业不去信息化是
等死，企业去信息化是找死”。不知道各位同僚听了这句话后什么感觉，如果你是搞IT的，那么心肯定凉了一半哦，我本人也是做烟草行业，烟草行业的信息化供应商不缺乏国内一些软件大商，中软国际、东软、浪潮、用友等。但是据我所知，烟草客户对其应用软件的满意度估计你问他们的中层领导是问不出结果的，但是你可以去问真正在使用这些应用软件进行工作的基层员工，他们的答案才是有说服力的。难道你做为一个架构师、一个项目经理、一个开发人员，你只愿意听客户给你说：“不错，你们的软件不错!”然后你就得意扬扬吗？你就是一个合格的IT架构师、合格的IT项目经理、合格的开发人员了吗？！那你大可以去找他们的领导，只要验收了他们都会说你的东西好的，因为他们和你是一条绳上的蚂蚱。你应该在基层听那些从不被重视、并且提出问题和发牢骚也没有人理的声音，这些声音在我看来是多么宝贵，他们是可以真正让你更上一层楼的贵人，有些项目实施人员在现场为了自己那点点惰性，迟迟忽悠基层使用人员，强制性使其顺着系统的业务流程走，想办法消除其牢骚情绪，也不肯去做一些修改，当然有些修改可能涉及到底层架构，这他们也无能为力，当然有些牢骚是因为仓库保管员怕丢了自己的饭碗而使的小性子，但是，这才是你锻炼沟通能力的时候，你怎么能把小性子变成积极性，怎么能和架构师和开发团队进行沟通修改存在的问题。这才叫沟通，这才叫负责任，几个实施人员能做到。如果开发团队能够得到如上这种反馈并以积极的态度进行修改，那么我相信肯定会有一套比Microsoft Office受欢迎的企业应用系统。
         一口气说了这么多好累，今天先写到这。。。。。。