用户笨还是程序员笨

今天很愤怒，快做好的功能由于一个功能缺陷而问起产品部门应该如何处置，说着说着把以前的所有定义都推翻了，表面看上去以前的很多工作都白做了，要重新开始做，抛开成本不考虑，抛开个人成就感不考虑，抛开责任不考虑，单从用户角度来分析。程序员抽象出来的东西是不是应该合情合理的呈现给用户，带领用户更容易的理解业务逻辑，还是应该把用户关在抽象层的外面。笨手笨脚的再抽象层和错误的表现层做一次无奈的转化呢？

 

吵架的时候我就想，自身的问题出在哪里？想了半天总结了一下，以便以后在写程序过程中避免这些不必要的不爽。

1 使用不熟悉的组件。乐观的估计了这些外来组件的可靠性。同志们都知道，中国的软件公司，小软件公司，一般是不注重质量的，强调快速开发。所以使用的两个外来组件成了项目进度的定时炸弹，不知道哪天会碰上不明确的问题。如果碰到了很有可能这项功能就废掉了。而这种小软件公司一般不会允许你对买来的组件进行高强度的测试。没那个闲工夫。这个以后一定要注意。

2 定位问题，一个功能有三四千行的时候应该是需要一个比较认真的架构的，而小的软件公司一般不会有明确的架构师概念，程序员自己就是架构师，这个定位没有深入到程序员内部来，导致程序员傻乎乎的在按照产品方案来做一些uml设计。这样在前期貌似很好的uml设计，到代码中期就会因为各种细节而不断扭曲。最总面目全非。而中间过程的痛苦性。想必各位也很有体会，上面的愤怒就是这中间的。所以呢，在产品部门很弱的情况下，程序员一定要把自己当架构师来使唤。不然后期的痛苦只有自己才能知道。

3 沟通问题，程序员的做设计一般都会在表面的东西上作一层抽象，去掉一些冗余的东西，改正一些错误的信息，弥补一些遗漏的信息。还会根据实际的组件能力，做适应性处理。一般情况下呢，负责任的产品部门能做最好的需求。其次能设计表面基本合理的东西出来，这样上面做抽象的时候会比较轻松，而有些不太负责的产品部门，只会做最基本的需求。也许是因为任务太多的原因，中国小软件公司就这样。这种情况下和产品部门的沟通是很有问题的。承认自己的沟通能力确实不高，有时候会使性子听别人把错误的东西讲完。然后从程序的角度说出自己的理解。往往令别人听不太懂。所以前期和产品部门，或需求部门的沟通实在是很重要。不然作出来的东西不是想要的东西那就最惨了。

4 能力，精钢钻和瓷器活的问题，估计任务的时候一定不要估计能把自己精钢钻磨损完的瓷器活量。这样就会天天加班。代码质量下降。没有成就感。会导致心情很郁闷。最后身体也不太健康了。这样损失真的是很大的。

 

郁闷的两三个月来总算能记下点东西。回到主题。

首先用户界面应该能基本反映事物的基本结构，所以应该认为用户是聪明的。认为用户是聪明的程序员才是聪明的，而认为应该给用户最表面的东西，不是很合理的东西而需要程序员在底层吭哧吭哧做适配的程序员是笨蛋。希望明天的pk能快速化解一些沟通上的矛盾。希望能给用户一个简单的合理的产品出来。

 

依然比较愤怒。