标签：
有点失落、迷茫，差点在上班的时候发了火。原因是之前离职的一位同事，在代码里不加注释，而且百般偷懒，致使很多应该的验证没有验证，很多应该考虑到的情况没有考虑。因为是老员工，我相比他来说是新员工。气势上总是差那么一点点的，不敢去质疑前辈们的代码。但是这样下去，项目的质量一直提升不上去，讲他还不能讲，对于整个项目管理来说这样的员工就是一颗定时炸弹。虽然是写了代码，恭喜还能跑，但是这是在浪费公司的资源，也是在浪费同事的时间。这样的代码以后维护起来，是要花费很大的代价的，是非常大的代价。然而现在已经是这种情况了，没有办法，只有错上加错，在慌乱的代码里东凑西补，使得项目更加难以维护。
另外一个原因，就是项目的设计。从公司的管理层面上来讲，管理是基于两种前提的：信任，不信任。在信任的前提下，企业会给足员工的发展空间，让员工去发展。但是就我所在公司与管理层的领导风格来看，是基于后者的。无论是基于信任还是不信任，其实都不是最主要的。就如同人性本恶与人性本善的悖论。关键的点在于，我们公司的产品设计人员是从程序员出身的，这一点就十分有必要说说了。
一个好的产品首先应该是一个好的消费者，其产品的设计应该是为用户服务的。技术干烦了，就转管理或者转产品设计人员。优势是有的，例如对产品的技术上可能了解的更为透彻，在产品的一些逻辑难点能够给予关键帮助。但是弊端也是显而易见的，就是程序员做久了，其审美能力的严重缺失，在乎数据、逻辑的正确性程度要远远大于界面的美观度页面的加载速度，也就是通常我们所讲的用户体验。其设计产品的时候过分关注与逻辑层面，而忽视用户层面。作为一名用户来说，我是不管你的这个数据是连接多少张表去查询出来的，也不管你攻克了什么难题，使用了什么牛逼的技术，你只需要在我需要的时候，将页面以我察觉不到的速度展示在我面前就行了，一切要以用户的角度去思考程序。其管理与设计要从大处着手，不能太过关注与某部分细节。
产品与程序分工不同，薪酬不同。所以如果做产品就不要再有程序的思维，以人的思维去考虑。程序思维可能让你拥有解决问题的能力，但是也限制了你设计产品的能力。
产品设计人员的沟通能力是至关重要的。程序员整日埋头敲代码，言语表达能力交际能力都不如专业的产品设计。你有一个牛逼哄哄的设计，你自己很清楚它能够达到什么样的效果，能够带来多少的利润。但是你表达不清楚，一切都是扯淡。跟你干活的程序员不知道，不知道你想要表达什么。以我做的产品为例，是关于大数据的整理加工。多表联查，数据之间逻辑异常复杂。我做的时候虽然明白数据与数据之间的逻辑，但是仅仅是明白，但是这些数据有什么意义呢，我是不清楚呢。就如同我荒废的大学时光，虽然每天都在上课，但是却浑浑噩噩度日。显而易见是非常低效率的。
好的产品设计一定要表达出来。你用不了声情并茂的讲演表达出来，那总可以用翔实的设计文档来描述吧。口述是万万不可的，人在说话的时候，逻辑的严密性是非常差的，而却不具备整理性。基本上是想到哪，说到哪。其中会遗漏很多的产品逻辑细节，这些设计人员是心知肚明的，就是忘记告诉你了。但是产品设计认为你们之间很有默契，你懂他。事实上，人与人之间言语的交流是非常低效的，据说不到50%。因此凡是产品设计一定要有文档，这是确定的必须执行的。
产品设计人员要将产品设计给程序人员讲解一遍，然后程序人员整理产品设计稿件给产品。再开一次会议来共同确认讨论结果，一定要确认好，程序做的产品是否是设计人员想要的产品。一流的设计，三流的执行，会做的不入流。三流的设计，一流的执行，做出来至少要比三流强。
最后一些话是想对自己说的。低头干活，抬头看路。做程序员的时候，要先把本职工作做好，但是不要把所有的精力都放在程序上，程序只是实现一种服务的方法。生活中有很多的乐趣需要去体验，我们还年轻，还要玩耍还要疯狂。所以写程序的时候，站在产品设计的角度去写程序，往往会有一种畅快的感觉。至于那些名词花哨的技术，身边牛逼哄哄的大牛，我们要学会视而不见，因为这些我们都终将学会，这些大牛我们终将超越。所谓大牛，无谓庖丁解牛，无它，惟手熟尔。
标签：
原文地址：http://www.cnblogs.com/roverliang/p/5227000.html
