不经常写博客，今天突然想到想写一篇博客，算起来最近遇到很多事，虽然不知道该怎么解决，但是我会努力解决的。感觉今天心有点浮躁，感觉做程序是一件很美好的事，慢慢的发现给我想想的差距很大，不知道是我想的和别人差距，还是我根本不适合做管理，我换了是三家公司，本想着找一个很好的公司，能按照我想象的做下去，但是没想到的是和我想都是背道而驰，例如，我想一个项目开始做，就先要对整个项目有一个宏观的认识，至少要写一份文档，让客户看一下主题是不是正确，概括说明整个项目总体，让客户感觉到这个项目的主题就是这么弄的，但是很多项目都是拿到需求就开始写代码，设计数据库，编写边讨论，只要功能上实现了，就一切都搞定了，当客户看到的时候总是有这么火那么的不相同，客户感觉有种受骗的感觉。

   不知道该怎么说，我认为一个项目完成，应该是是从宏观上逐步细分，然后再根据细节看看技术上是不是能实现，或者说是一条一条理清客户的需求，一步一步落实，然后根据这些东西在选择需要去做什么，列出很详细东西逐步推敲决定，这样程序员在写代码的时候，就会有一个宏观的概念，不至于写一些浪费的东西，一个项目很多人开发或者单个人开发，如果不能从宏观上把我项目的主题，即使写出来了，功能实现了，客户也不会满意，而且程序员也会做许多重复的代码，例如一些大的功能，比如说查询了，所有的差不多应该都是相同的，不一样就是sql语句不一样或者是条件不一样，还有就是返回值，无非就是datatable、dataset或者是集合，所以这个东西如果有人已经写得非常好了，就不应该在别人去写这些东西了，因为别人写也无非是这样，如果把这些东西抽出来，写一个方法（清楚、简单、利于使用），别人用就行了，如果别人想调用，直接调用或者是继承这个方法类就行了，没必要每个人都要去写；其实项目也应该是这种思路，只有这些思路都理清了，不论是项目经理或者负责人在给程序员描述这些东西就方便了很多，如果大的细节逻辑都搞不清，即使实现功能，也会出现功能重叠和代码的重叠，这样就会出现浪费大量的工作量，也会让程序员知道自己做的东西在项目担当的什么角色，在写代码的时候知道什么地方自己不用费神的去写了，这样就可以减少不必要的时间，项目看起来也层次分明，在给客户写培训文档的时候就能很快说明，不然客户会经常的问你这些功能要怎么用，因为需求是经理根据每个人总结出来的，当每个人看到培训文档的时候，就会知道自己应该怎么做，避免了很多奇怪的问题出现；现在项目都是带有相对的服务，在给客户进行维护的时候，不仅方便多了而且改起来不会顾此失彼，这样客户就会更满意，相当于又为自己拉一个牢靠的客户，这样才能做的更远。

  不要顾及客户提出的需求多，主要是我感觉没能理解客户需求就急于实现功能，其实demo不重要，因为客户也不定对你的demo感兴趣，他们感兴趣的是你能不能给他们一个清晰的思路，让他们继续附加更多在系统中，但是更重要的是要让客户签字确认，每一个细节，因为每一个细节决定你的项目成功的关键，客户之所以挑剔，因为很多人没有跟着客户的想法去做，因为客户既然找到了你，其实就是想做好，做完美，如果做得很好，就可以提出后期的维护，个人感觉后期的维护远远要比做一个项目更重要，如果上面你都做很好，我想客户即使提出一些无理的要求，你也可以有办法拒绝，因为有书面的文档在，你给他们的事全套的分析说明和技术支持，除非他很变态，如果是这样，你就完全可以不做，因为如果做了，后期就会出现更多的问题。有些事我感觉舍弃远远要比得到要好，做好每一个软件，才能有更好的发展。