我们常说用户第一，以及注重实现用户价值，
一点都不假，
因为，技术细节是用户不关心的事情。
我们也很尊重用户，尽一切可能满足用户的需要，
想方设法的为用户着想，
第一时间帮用户解决问题。
这是一件值得夸赞的事情。
可是，我们到底应该把用户当做一个什么样的人，
大家可能会有不同的看法。
有的人认为，我们应该相信用户，尽量给用户提供更多的可能性。
而有的人则认为，
我们不该相信任何人，需要对用户行为加以限制。
究竟怎样做才是合理的呢？
本文就针对这个问题，尝试进行一些思考，斟酌一下利弊。
作品是一面镜子
我现在认可一个观点，
那就是，作品实际上反映了作者的处事态度和行为准则，
有什么样的作者，就有什么样的作品。
如果我们平时工作严谨，喜欢规矩做事，
那么做出来的软件，就更可能要求用户向我们一样，
不能恣意而为，需要受到一些限制。
反之，如果我们更喜欢自由，喜欢打破常规，
那么我们就更喜欢提供出灵活的解决方案，
让用户自由发挥。
因此，我们自己是什么样的人，就会做出什么样的软件。
不能强求。
或者换句话说，
要想改变软件，只能先改变自己。
是谁解决了问题
那么用户到底需要什么样软件呢？
我认为这取决于我们对解题的理解方式，
问题到底是怎么被解决的？
对问题的本身的探讨很有意思，
因为我们经常会忽略问题的主体。
这个问题是谁关心的，是谁的问题，谁最需要它被解决？
解决了它哪些人会受益？
其实，软件只是解决方案的一种，没有它问题不见得不能用其他办法解决，
有了它，问题也不见得能被很好的解决。
因此，对于问题本身来说，软件的作用不像我们想象中的那样重要，
问题也不是我们解决的，
是用户解决了问题。
我认为在这件事上保持谦卑，至关重要。
这是谁的问题
以前读过一本书《你的灯亮着吗？》，
它深入探讨了问题的本质，
其中有很多生动的小例子。
印象比较深的一个例子是这样的。
在日内瓦湖的山脉中，有一条很长的汽车隧道，
尽管隧道照明设施很好，但仍然需要预防在停电的情况下发生灾难。
于是人们在隧道入口处放了一个标识牌。
上面写着， 警告：前有隧道请打开车头灯。
但是问题来了，很多游客在返程时却发现自己的车没电了，
因为他们忘记关掉车灯了。
警察们被迫用上他们所有的资源，好让车启动起来，或者把它们拖走。
游客们也是怨声载道。
好了，现在我们就可以提问了，
这是谁的问题？
结果，不仅司机认为这是工程师的问题，而且可能连工程师也这么认为。
用户愿意解决问题吗
为了解决这个问题，工程师们可能会想出很多不同的办法，
例如，可以在附近建一个充电站，但是这要花很多钱。
或者，在隧道尽头再立一块标识牌，写上，关掉车灯。
但是这样的话，夜晚行车的人们也会关掉车灯。
所以，按照程序员们审慎的思维习惯，这个标识牌应该这么写，
如果这是白天，并且如果您的车灯开着，那么熄灭车灯；
如果天色已晚，并且如果您的车灯没开，那么打开车灯；
如果这是白天，并且如果您的车灯没开，那么就别打开；
如果天色已晚，并且如果您的车灯开着，那么就别关它。
等人们读完这标识牌，汽车早就飞驰而过，沉到湖底了。
这根本就不是一个可以接受的解决方案。
事实上，总工程师也没有把问题复杂化，
而是用了一种方法，“把问题当做他们的问题”，
工程师只是起了一点辅助作用。
他假设司机们非常愿意解决这个问题，但是需要一点提醒。
他还假设司机们不是那种彻头彻尾的傻瓜。
因此，工程师们所需要做的，只是在隧道的尽头加一块标识牌，写上，
您的等亮着吗？
这个标识牌使问题消失了，
如果人们的灯真的亮着，一个小小的提醒，
可能比那些复杂的解决方案都更有效。
方案能否被采纳
反观我们软件行业，框架的设计者们，
把用户当傻子的例子，也是屡见不鲜。
他们不让用户干这个，也不让用户干那个，
这样做貌似会防止用户犯错，
但实际上并非如此。
如果用户受到了限制，他们就会自己想办法，
绕过这些限制，用非常规的手段把问题解决掉。
不容易犯错的办法，不见得是用户乐意采用的办法。
所以，方案能否被采纳，与能不能解决问题，同等重要。
此外，由于种种原因，用户可能会被方案所绑架，
他们不得不使用某些软件，
这就造成了一些假象，让人们误以为自己做的还不错。
结语
总之，是工程师协助用户解决了问题，
而不是工程师自己解决了问题。
我们应该和用户站在一起，才能体会到问题发生的真实场景，
让我们认为用户是聪明人吧，他们不是笨蛋，
他们是合作伙伴，而不仅仅是软件的使用者。