Adobe布道师谈为什么要布道？

在采取行动说服别人接受我们的方案之前，必须问自己一个非常重要的问题：我们是在解决问题，还是在推行方案？如果是解决问题，那很好；因为对于团队来说，你是在治病救人。如果是推行方案，那最多只是一种中立的情况，通常不会有人欢迎。然而，实际上推行方案的情况却屡见不鲜。这又是为什么呢？

当你发现了解决方案，为之兴奋莫名之时，往往就会忽略一点，即你的目的是要解决问题。而且你还忘了大多数问题都不止有一个解决方案。结果，你专心致志地推行自己的解决方案，而这个解决方案可能并不适合要解决的特定问题。尽管你推荐的工具确实也是解决问题一个途径，但从团队的技术氛围、能力组合以及组织策略这几方面综合来看，很可能还有更好的方案可供选择。

之所以说要在推销方案前先努力想清楚问题所在，主要的原因有以下几个：

• 这样做可以先让自己弄明白到底是不是真的存在问题；
• 这样做可以强制你站在听众的角度来思考问题；
• 这样做可以让你拿出最适合听众的解决方案。

甚至，你都得问问自己，到底有没有需要解决的问题？在前面那个小故事里，确实还真有一个问题。也可能那个项目团队已经在用Grails了。如果遇到这种情况，你就必须扪心自问，Ruby on Rails能给那个团队带来些什么？说实在的，技术平台移迁就算花钱也花不了太多。此时此刻，最要紧是得搞明白，你是真的想帮团队成员提升工作效率呢，还是只是希望说服别人跟你一样成为某种新技术的粉丝。只有确定真的有问题，才能去弄清楚是什么问题，以及这个问题是否值得解决。

确定了真的存在问题之后，接下来就要考虑它是否值得解决，或者说值得你的团队兴师动众的到底是什么。也许团队要做的事太多了，而也许他们只不过要将这些难题都推给那些新成员，想让新成员在实践中得到锻炼；那些老资格的人则专注于模型和UI。在这种情况下，这个团队的解决方案反倒比你所预测的更有价值。你必须给自己推销方案换个更合适的理由，同时还必须考虑到，假如把难题解决了，那些失去锻炼机会的新成员又该怎么办。

此外，在问题存在一个现成解决方案的情形下，还必须清楚你要推行的是不是一个定制的方案。无论是干裁缝，还是在IT行业，定制的产品总是能要到更高的价钱。原因其实都一样，定制的方案是“量体裁衣”，本身就已经埋下了成功的种子。为团队专门量身打造一套合适的方案，可以减少推行过程中的摩擦，或者一些磕磕绊绊。