做需求如做人

这段时间到外面跑动，才发现传统程序员是典型的弱势群体。往往死板，不擅于沟通，不能变通地想问题成了比较常见的问题。其实做什么事儿到最后都是做人的问题。做人方面做得好，代码也能写得舒服。这里的舒服不止是说高效简洁，最后结果更是让所有人满意。

 

因为无论是用健壮的java来实现，还是用快捷的php，用语言都只是为了实现功能，都是为了更好的和计算机沟通。编程也是沟通的一个环节。如果我不能很好的表达自己的意图，老实如计算机，也许就会报Exception,waring,error.如果我不沟通好，客户会觉得老子花了这么多钱，你做这样的玩意儿给我，我赵日天第一个不服。甚至你很费力地做完你认为完美的功能，最后被推翻重做，没有任何人会怜悯你的无能。

我用自己举例，前段时间做一个很复杂的需求，横纵4种变化，根据组合算得一共4*4=16种不同情况要考虑，其中12种需要不同的数据库操作处理（Model）,每一种数据库操作还要过滤特殊数字并做特殊处理，这些还不算，还有每一次审核联动不同操作处理需要特别小心分析。我在公司简短的需求分析讨论中并没有认真地分析可行性，因为缺乏前期思考，我也没法提出什么不同意见或者反对。于是我硬抗了这个很二的需求。

我开始玩命地写代码，嵌套4层的if else让我也感觉想吐出点胃酸。我看着像半成品一样的需求文档，写一会儿想一会儿，跌跌撞撞完成了。测试的过程中测试妹子不断呼唤我的名字，就像在呼唤走迷路的小孩，频率之高让我也惭愧。在中间测试的过程中不断发现新的，没考虑到的情况，于是导致了“改，改，改”的循环。

最后是我累了，测试妹子累了，pm累了，大家玩命加班，还好我用的xdebug,不然手打断点会更纠结。

如果我懂得沟通，我首先会分析可行性，然后了解排期时间（那次排期我不是自己定），如果冲突大，那么要么改排期，要么简化逻辑流程，甚至说服运营那边直接砍了这个二逼需求。

后面我学聪明了，在做另外一个数据报表的时候，我发现用另外一个不完整的数据去过滤连表会造成怪异的显示，并且这么做的开发成本会变高。好吧，说人话就是：费力不讨好的做法，可以忽略那个要求。然后我努力去说服了pm，pm说服了固执认真的测试，最后受益的是所有人，功能快速上线，大家按时下班，我也快乐地去做后面更多的事儿。

做需求如做人，要变通。