这句话有两种解释，一种是细节有魔鬼般的魅力，所谓魔鬼身材便是；另一种解释是细节烦死人了，比鬼还烦人。
最近恰好有两件琐事，令我印象深刻。
2009年，我被邀请旁听博客新消息系统的策划讨论。有人提到，在消息中心内回复评论的时候，如果仅仅弹窗告知“回复成功”，很不友好，用户可能还要去日志下面确认是否回复成功。最好能和开心一样，回复内容直接挂在消息中心里边，和评论区块的样式一致。当时我也支持此观点。
这个想法被工程师从技术层面否决了，细节略过。最后达成的妥协方案是，回复内容可以挂在消息中心，但样式和评论区块(多级回复)不一致，只悬挂一级，相当于重新生成一条静态化的提示，方便你确认“回复已成功”。当然，这会耗用额外的研发时间。
那一年，新浪微博崛起，逐渐改变了整个中国互联网的生态。在微博消息中心回复评论，或在微博列表页转发内容，都只是弹窗提示成功。是否不够友好呢？是的，我自己经常多点击一次确认回复或转发结果。然而这丁点体验损失对新浪微博雄霸天下造成的影响是……零。既然如此，为什么博客当年要花费额外的研发时间去纠结这点细节呢？
第二件琐事关于Piictu，这款创新APP自5月发布以来，关注度不断提升，我试用几天后却出故障了，无论怎么发图都不能刷新。当时还讥笑Piictu对网络环境要求太高，忽然回过神来，难道是我测试“捣乱行为”时被系统拖黑了？注册新号一看，擦！新号果然正常。像这样对拖黑用户无任何提示，相信是大多数交互、用研、PM无法容忍之事，然而Piictu就这么理直气壮地干了。去咬它啊，Who care？
对此有如下几种常见诠释：
★细节派
-即便是微小的细节愉悦，也能给用户带来惊喜，并提升对产品的信赖感
-在激烈竞争中，核心体验容易同质化，这时细节就成为决定用户倾向度的天平
★大条派
-核心功能需要抠细节，非核心功能无此必要
-主干流程，频发应用情景需要抠细节，分支流程与偶发情景无此必要
表面看上去，这算是细节与大条的两党之争，其实不然。我们常常赞美“细节决定成败”，同时也常常咒骂别人抠细节太无聊，然而这两个极端常常从同一人的嘴巴里讲出来，仅时区不同，让你觉得他简直就是个神经病！换句话说，是否注重细节并不取决于个人偏好，关键是情景判断。不少业内人士在我的微博上对此评论道：
“产品是做给用户使用的，当然要以用户的需求为标准。以自以为是的标准做一款产品，无异于闭门造车。做产品，最起码要读懂人性。”
“产品首先应该是有用、能用的，然后才是易用、想用，现在很多人直接跳到最后2步甚至1步上了。尼玛都不想想这东西有没有用能不能用，搞个P的用户体验。”
“做产品调研时要发散再发散，想到各种可能的方向；做产品设计时要收缩再收缩，重点做最能吸引用户的功能。 ”
“产品体验往往会变成几个人埋头追求完美，用户都感觉不到。在大方向上把握用户真的需要的才比较关键。”
“细节决定成败，是在已经把基础做好的情况下。大面上都过不去，谈何细节。更何况，不是所有的细节都值得去反复推敲。”
这些话是不是都很有道理？
很可惜，所有糖水大道理并不能帮助我们解决实际的问题。在发生争执的时候，每个人都会认为，自己的观点最能够代表用户需求。即便对于何谓“核心功能、主干流程”达成共识，这部分哪些细节该抠，哪些不该抠，也会吵个热火朝天。什么才是“用户真的需要”？什么才是“值得反复推敲的细节”？两边恨不得拿起火箭炮豪快地轰杀对方。毕竟细节判断中的主观个性多于客观共识，如果每份争议都去做用户调研、数据挖掘、AB测试来解决，就会把产品设计变成一场漫长的，气呼呼的拉锯战。
如我发微博所说：“产品抠细节这种事情，如果是自己做呢，会自得于无微不至与用户关怀；如果是别人要求自己做呢，又会咒骂他无聊透顶，吹毛求疵。”
在此再一次回顾国外某科技大公司高管的经验之谈。他说“产品项目的效率很低的话，我就从小组中抽走一个人。还低？那就再抽走一个人。眼看着效率biubiu就提上来了。”是啊，都没人跟你吵架，掰腕子，对抠细节了，效率当然大有提升。
这则经验之谈的本意是，其实没有太多办法去解决细节中的“个性之争”，只好在保证主干正确的基础上，把细节决定权赋予意见统一的个人或派别。转化到产品项目管理中，参与制定细节的人越少，则进度越快；人越多，则意见越杂。两种截然不同的处理方法可能都是正确的，即便有对有错，效果差别往往也不大。但多种个性的冲突会导致决断效率低下，多种个性叠加又会导致产品需求过载――其中大部分对最终成败的影响为零。它们的存在意义仅在于，让设计者觉得这是融入了我的个性，我的风格，我的产品观的个人作品。仅此而已。
这多无聊啊……
换个角度来看，如果项目需要充分调动设计者的热情，让其全身心地投入，当然就得尊重他的个性。比如说乔老爷子一定要在mac电路板上刻个精美的logo，又看Google APP的Logo色阶颇不顺眼；又比如卡梅隆拍《泰坦尼克号》的时候，坚持购买昂贵的欧洲瓷器作为道具(摔碎)，说这样才气场和谐。显而易见，这些想法都很有点偏执在里边，但你如果限制了天才的偏执，也就无法发挥出他们伟大的创造力。对于凡人，亦是如此。
二季度以来，我一直在带队做相册APP。这是部门第一款移动应用，又涉及复杂的跨部门合作。谨慎起见，参与产品设计的除了我之外，还包括iOS与Android版本的PM各一，临时支援的交互与视觉设计师各一，再加上工程师也会提供意见。整个项目过程中充满了吵吵闹闹，各种产品观混战一团，虽然最后由我来拍板，但观点被否定的人往往不悦。
有一次，我对两个版本的PM说，其实我很少同时反对你们两位的想法。我反对M君的时候，W君多半支持我；我反对W君的时候，M君多半支持我。其中的对与错无关成败，大部分是体验细节上的个性判断罢了。但因为拍板的人是我，所以靶子也是我，给你们留下的共同印象就是，我是个压制你们发挥的(傻逼)(混蛋)(大反派)上司。枪口一致对外。
这二位偷笑。
我又叹了口气说，我级别比你们高，经验也比你们丰富，既然这个项目由我在一线带队，当然是我话事。大是大非的问题我们放开了争论无妨，细节分歧暂且全听我的，否则谁想做什么效果都往里边加，或者吵不出共识就拖着不动弹，这进度会像铅块一样沉。直到年底站稳脚跟，进入相对安全的发展阶段，再由你们各自独当一面，我退居二线。这岂不是很合理？
合理归合理，因为细节上的个性活跃，又常遭否决，85后年轻人的热情依然大受打击。其中一位跟我说，这就是份工作，哈，一份工作而已。
于是沉默，面无表情，内心有点后悔当初把摊子搞这么大。尤其在大家都没做过APP的时候，项目并不会因为人多而变得更安全，只会因为人多而意见混乱，进而执行力下降得厉害。在每一个产品面上(如APP设计)，不仅只有一位决策者，最好也只有一两位参与者。保证产品执行力的前提不是人多打老虎，而是默契的团队构成。由于“默契”本身是一件非常难的事情，“精简人数”就成了保持默契最有效的方法。
要知道，产品设计中加入一些并非绝对必要的细节追求，这几乎是不可避免的；即便细节“绝对必要”，尺度把控也因人而异。谁没有一点点个性呢？为了避免个性不一致导致的效率损失与细节过载，通常只能靠精简团队来实现，规避争执，用快速的行动力抵消潜在的失误率。互相信赖的创业小队，在这一点上往往比权力分配盘根错节的大公司大团队更有优势。
还有同行说，“产品经理应该更关注逻辑，没有必要在页面、交互上面钻牛角尖。”相当于将细节决定权完全赋予了交互设计师。这么做倒也不错，但要吻合几个先决条件：
1、交互设计师长期研究此产品，对用户群特征有较深了解
2、交互设计师长期参与此项目，能及时响应需求
3、交互设计师与产品经理有一定的磨合经历，配合上比较默契
4、交互设计师的才能可信赖
据我所知，符合以上四点的产品项目环境，在业内不足10%。信任感这种东西不是天上掉下来的，而是在适当的土壤中生长出来的。“土壤”本身多半取决于“体制”，个人的力量很难去改变。所以，更务实的方法还是精简团队，加强个人责任感并减少分歧。多多咨询听取意见没错，但在具体参与、决策的产品面上只安排少而精的人。产品设计的“群策群力”演变成“人多嘴杂”，屡见不鲜，又是何必喃？
正如我的一条微博所说：最好的合作方式是，在大局上想法互补，细节上各逞其能。最差的合作方式是，大局思路一致，结果盲点重合，然后在细节上吵得不可开交，各自都气呼呼地坚持“细节决定成败”。