应对复杂需求

　　有一个词语叫做「技术直觉」。那究竟什么是「技术直觉」呢？我觉得技术直觉除了和经验有关，还和一项能力相关，就是迅速脑补出需求落地时的场景，然后综合地判断可行性。对于技术的边界心中有数，并能迅速代入使用场景，这可能就是所谓的技术直觉了。

　　举个例子，做动态教学课件，是该用二维的还是三维的？首先要对二维三维制作的成本有了解，不是「二维与三维的制作成本比是1:2」这样的一个简单结论。因为三维制作的弹性很大，很粗陋的那种和二维差不多成本，但要达到能与二维匹敌的品质，成本就远远高于二维了。

　　对应到我们团队，现在的需求已经足够复杂，复杂到我们开发自己都开始玩不转了，写了各种 if-else 的唯一作用就是把简单的事情复杂化。为什么还要折腾业务小伙伴呢？同时，我也没有找到一开始就做到这么复杂的意义？请问，有一个技术人能站出来说出no吗？

　　那些一开始就设计庞大而复杂，有着各种各样的前提假设，也处理了各种各样的特殊情况，煞有其事地雕琢了一大堆东西。当你看完了整个设计，就剩不下多少脑力来质疑其中的疏漏了。

　　这种用堆砌复杂来掩盖无能，埋下复杂的问题隐患，然后再不得不用复杂的方案来解决，称为「该下地狱的产品设计」。其根源就是没有好好消化需求。

　　怎样找准产品需求？不是需求方说什么就立刻做什么，而是退后几步，从具体问题中抽身出来，换到全局视角重新审视，追根溯源找到需求的本质。

　　那么对于充满变数的业务，我们该怎样做设计？或者换句话说：「对于 to B 的产品，在真实需求还未从业务一线大量涌现之前，做产品设计需要注意什么？」

我的答案是：「少做限制，静观其变。」

　　有这样一个小故事：加州大学的一块圆形绿地周围环绕这几个建筑，起初绿地上并没有路，设计者没有急于铺路，而是观察了几个月让道路自己显现出来。学生们会穿过绿地，可能是走到某一个建筑去上课，也可能是干别的。绿地上有一些树木阻挡，不同时段的人流量也很难准确预估，未知量其实有很多。在这种复杂情况下，自然形成的道路会比预先设计出来的更贴近真实需求。草地上踩出来小路以后，设计师只需要铺上砖，问题就完美解决了。

　　即使你的设计给了用户很多个选择，其实也是做了限制。而做了限制后，用户的行为会受其影响，真实的需求反倒不容易显现出来。所以在这个阶段，什么都不做反倒是最好的选择。

　　然而真实需求从哪里来？从实践中来。 既然要从实践中发现需求，那第一要务就是让业务跑起来。这时候一定忍住，先不要加戏加负担，轻才能跑起来。