今天在给客户做项目时,客户问了这个一个问题:“XXX模块每页最多显示XX条,你看看能不能改成更多(起码他肯定是想要显
示更多了。)”
有很多时候人可能陷入这个问题中去,会形成这种局面: 听了这个问题后便开始考虑“要不要显示更多条呢? 再显示更多条
合不合适呢?”最后给客户一个答案:“再多显示两条吧!” 而后客户公司的又一个老总不满意了:“每页显示太多了,减两条吧
!”。当这句话说出来后,程序员心里开始打鼓了:“靠,当初是你们公司提出要加两条,现在又要减...” 可反过来一想,我不
能埋怨客户啊,当初可是我自己说的“再多加两条”啊... 于是不得不忍气吞声,减了两条。 过了几天,另一个经理又来了......
初次遇到这个问题时,不妨用面向对象的思想来解决。
客户提出了以上问题,我们首先要做的不是陷进去想这个问题。应该先把这个问题封装成一个对象。封装过程中你会发现这个
问题有一个属性是“解决方”。然后当分析这个对象时你会发现这个问题“解决方”这个属性赋的值不应该是你,而是客户。即
解决方=客户; 。 然后你就会合理得写这个对象的执行方法:告诉客户“这是您的需求,需要您公司决定。你们公司内部先商量好
,告诉我最终方案。我再按最终方案修改。”
解决一个问题,先认清问题的本质(是否是需要你解决的),那么就需要创建一个对象(认清问题,解决问题)了。
示更多了。)”
有很多时候人可能陷入这个问题中去,会形成这种局面: 听了这个问题后便开始考虑“要不要显示更多条呢? 再显示更多条
合不合适呢?”最后给客户一个答案:“再多显示两条吧!” 而后客户公司的又一个老总不满意了:“每页显示太多了,减两条吧
!”。当这句话说出来后,程序员心里开始打鼓了:“靠,当初是你们公司提出要加两条,现在又要减...” 可反过来一想,我不
能埋怨客户啊,当初可是我自己说的“再多加两条”啊... 于是不得不忍气吞声,减了两条。 过了几天,另一个经理又来了......
初次遇到这个问题时,不妨用面向对象的思想来解决。
客户提出了以上问题,我们首先要做的不是陷进去想这个问题。应该先把这个问题封装成一个对象。封装过程中你会发现这个
问题有一个属性是“解决方”。然后当分析这个对象时你会发现这个问题“解决方”这个属性赋的值不应该是你,而是客户。即
解决方=客户; 。 然后你就会合理得写这个对象的执行方法:告诉客户“这是您的需求,需要您公司决定。你们公司内部先商量好
,告诉我最终方案。我再按最终方案修改。”
解决一个问题,先认清问题的本质(是否是需要你解决的),那么就需要创建一个对象(认清问题,解决问题)了。