文章描述：细节魔鬼与精简团队.

细节是魔鬼。

这句话有两种解释，一种是细节有魔鬼般的魅力，所谓魔鬼身材便是；另一种解释是细节烦死人了，比鬼还烦人。

最近恰好有两件琐事，令我印象深刻。

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设计），不只只要一位决策者，最好也只要一两位参与者。保证产品执行力的前提不是人多打老虎，而是默契的团队构成。由于“默契”本身是一件非常难的事情，“精简人数”就成了保持默契最无效的方法。

要知道，产品设计中加入一些并非绝对必要的细节追求，这几乎是不可避免的；即便细节“绝对必要”，尺度把控也因人而异。谁没有一点点特性呢？为了避免特性不分歧导致的效率损失与细节过载，通常只能靠精简团队来实现，规避争论，用快速的举动力抵消潜在的失误率。互置信任的创业小队，在这一点上往往比权力分配盘根错节的大公司大团队更有优势。