关于产品MVP,我觉得值得讨论的是当我们把产品给用户体验的时候应该是一个完整可能的版本还是部分可用的产品，
“简单”好，“不完整”不好。客户应该真正希望按原样使用该产品。不是因为它是复杂事物的 0.1 版，而是因为它是简单事物的 1.0 版。
近来看到一篇文章是一名连续创业者Jason写的，我觉得挺有意思的，站在用户角度考虑了MVP的缺点

原文链接: I hate MVPs. So do your customers. Make it SLC instead.

原文:

Product teams have been repeating the MVP (Minimum Viable Product) mantra for a decade now, without re-evaluating whether it’s the right way to maximize learning while pleasing the customer.

Well, it’s not the best system. It’s selfish and it hurts customers. We don’t build MVPs at WP Engine.

The motivation behind the MVP is still valid:

Build something small, because small things are predictable and inexpensive to test.
Get it into the market quickly, because real learning occurs only when real customers are using a real product.
Trash it if it’s a flop, or invest if it’s a seedling with potential.
MVPs are great for startups and product teams because they maximize validated learning about customers as quickly as possible. But it’s a selfish act.

The problem is that customers hate MVPs. Startups are encouraged by the great Reid Hoffman to “launch early enough that you’re embarrassed by your v1.0 release.” But no customer wants to use an unfinished product that the creators are embarrassed by. Customers want great products they can use now.

MVPs are too M and almost never V. Customers see that, and hate it. It might be great for the product team, but it’s bad for customers. And ultimately, what’s bad for customers is bad for the company.

Fortunately, there’s a better way to build and validate new products. The insight comes by honoring the useful attributes of MVPs, which are listed above, while also giving just as much consideration to the customer’s experience.

In order for the product to be small and delivered quickly, it has to be simple. Customers accept simple products every day. Even if it doesn’t do everything needed, as long as the product never claimed to do more than it does, customers are forgiving. For example, it was okay that early versions Google Docs had only 3% of the features of Microsoft Word, because Docs did a great job at what it was primarily designed for, which is simplicity and real-time collaboration.

Docs was simple, but also complete. This is decidedly different from the classic MVP, which by definition isn’t complete (and in fact is embarrassing). “Simple” is good, “incomplete” is not. The customer should have a genuine desire to use the product, as-is. Not because it’s version 0.1 of something complex, but because it’s version 1.0 of something simple.

It is not contradictory for products to be simple as well as complete. Examples include the first versions of WhatsApp, Snapchat, Stripe, Twilio, Twitter, and Slack. Some of those later expanded to add complexity (Snapchat, Stripe, Slack), whereas some kept it simple as a permanent value (Twitter, WhatsApp). Virgin Air started with just a single route — small, but complete.

The final ingredient is that the product has to be lovable. People have to want to use it. Products that do less but are loved, are more successful than products which have more features, but that people dislike. The original, very-low-feature, very-highly-loved, hyper-successful early versions of all the products listed in the previous paragraph are examples. The Darwinian success loop of a product is a function of love, not of features.

There are many ways to generate love. “Minimum” and “viable” are definitely not two of those ways. The current-in-vogue way is through design: Elegant UX combined with delightful UI. But there are other ways. The attitude and culture of the company itself can generate love, such as Buffer’s blog with its surprising transparency or MeetEdgar’s blog genuinely helping entrepreneurs or HubSpot’s blog which early on was at least as instrumental to their customers’ success as the actual product. Another way is through a deep connection to the psyche and work-style of customers, like Heroku who broke with marketing tradition by filling the homepage with command-line feature examples instead of benefit-statements, thereby connecting instantly with their geeky target customer:

These are the components of the correct alternative to the MVP: Simple, Lovable and Complete (SLC). At WP Engine we pronounce it “Slick.” As in: “What’s the ‘Slick’ version of your idea?”

Besides the above, there’s another benefit to SLC when you consider what happens with the next version of the product.

A SLC product does not require ongoing development in order to add value. It’s possible that v1 should evolve for years into a v4, but you also have the option of not investing further in the product, yet it still adds value. An MVP that never gets additional investment is just a bad product. An SLC that never gets additional investment is a good, if modest product.

Although not called SLC, there’s a popular meme in product circles that neatly encapsulates the idea of SLC in a diagram: The Modes of Transportation example from the Spotify product team:

A skateboard is a SLC product. It’s faster than walking, it’s simple, many people love it, and it’s a complete product that doesn’t need additions to be fun or practical. At the same time, you can evolve the skateboard by adding a stem and handlebars, to create a scooter — only slightly less simple, and definitely loveable and complete. Next, you could grow the wheels, add a seat and some gears, and you have a bike. Again, less simple but now you have a product with massive benefits of speed, distance, and energy-efficiency. Complete, but many accessories available if you choose.

Zooming into one of our examples above, Snapchat took an SLC progression similar to the transportation metaphor. The first iteration of the product was a screen where tapping anywhere took a picture that you could then send to someone else, at which time it disappeared. No video, no filters, no social networking, no commenting and no storage — simple, yet Lovable and Complete, as evidenced by its massive adoption. The insight of “no storage” was critical, but many people have theorized that the simplicity of the interface was also critical. The very fact that it was as simple as possible (while not sacrificing love-ability or completeness), caused its success.

Later they added lots of stuff — video, filters, timelines, even video cameras inside sunglasses. It’s OK for products to become more complex. Starting out SLC does not preclude becoming complex later.

With SLC, the outcomes are better and your options for next steps are better. If it fails, that’s OK, it’s a failed experiment. Both SLCs and MVPs will have that result because the whole point is to experiment. But if a SLC succeeds, you’ve already delivered business value and you have multiple futures available to you, none of which are urgent. You could build a v2.0, and because you’re already generating value, you have more time to decide what that should look like. You could even query existing customers to determine exactly what v2.0 should entail, instead of a set of alpha-testers who just want to know “when are you going to fix this?”

Or, you can decide not to work on it. Not every product has to become complex. Not every product needs new major versions every two quarters. Some things can just remain simple, lovable, and complete.

Ask your customers. They’ll agree.

看到了老板发的文章，特别有感触，中国的SaaS个性化需求太多，付费意愿低下也是影响 2B 企业战略的很大因素。导致很多企业服务厂商要给客户做大量定制。这个问题的原因是中国企业管理不规范，老板文化太重。

原文:

为什么中国的 996 干不过美国的 955

大概从 2019 年上半年开始，有一个问题一直困扰着我，在 2B 领域，为啥中国的公司如此努力的加班，但是在产品上还是不能跟国外的比？虽然我们公司不是加班很多，但是相比国外同类公司还是工作时长要长很多，我们最近为了赶持续部署产品上线，相关团队基本上是 997。腾讯云，阿里云，我了解到的情况也是加班比较多的，996 的情况不在少数。但是你看中美两国云服务的产品，显然国外的还是要比国内好一大截。把这个问题放大一点，在中美两国贸易战的背景下，“为什么中国的 996 干不过美国的 955？”。我们从三个方面来看这个问题。

一、中国 IT 从业者的素质到底行不行？

对比中国的一线城市，我觉得从业者的专业水平并不差。我十年前在硅谷工作，大量的印度大妈的 Title 都是 Principal Engineer，这大概也是我当初决定回国的原因之一。近几年，有大量工程师在中国工作一段时间后去美国的，以及在美国工作一段时间后回国的。我感觉在从业者素质方面，高端人才两边是差不多的。但是中国实在是人多，论数量，初级从业者肯定更多，所以在日常感觉上，国内的整体素质没有国外高，我认为在我们讨论的业务范围，这是一种错觉。

但是国内从业者在专业度确实是欠缺的。这点从简历就能看出来。中国即使有些很高级的工程师，看简历也是写的不合格的，从内容到格式都不合格。但是你去国外招聘，无论水平多烂，简历都是写的非常漂亮。国外在如何写简历这件事情上的培训是相当成熟的，值得我们学习。

另外在理解自己与公司的关系上，国内普遍带有更多情感，而国外更理性。这一点要展开就太大了，要从文化开始讲。但是无论如何，我认为这个差异只影响管理方式，不应该在产出质量上有大的影响。

二、中国的 IT 从业者是不是不够努力？

这个问题是显而易见的，但我还是想说一下。每次晚上 10 点左右，在公司楼下打车，滴滴告诉你排队 101 号，一线城市都这样，深圳科技园只是一个缩影。我们说 996，只是一个代名词，有可能是 10-10-6，但起码我从来没有见过民营 IT 企业是 955 的。除此以外，国内大量公司在非工作时间是要处理公事的，也就是公私没有那么分明。以至于企业微信每周都会给你一个报告，告诉你这一周最晚处理公事对话是几点。在朋友圈晒凌晨两三点的不在少数吧？

即使是这样，相比其他行业，IT 行业可能都是工作时间最短的。建筑行业，工厂制造业，基本上一年就休一个春节。中国这么多人，每个人每天都有 24 小时，中国这些年的 GDP 增长，就是这么靠堆时间堆出来的。但是堆时间的杠杆率越来越低了，所以 GDP 的增速下降很快。

三、中国 2B 公司的战略行不行？

产品做不好，如果不是人的问题，不是投入度问题，那大概只剩下方向问题了。我们先来看一组截图：

对比国内外几个云厂商的首页，其实问题还挺明显的。首页就是门面，代表了你的形象，代表了你想传递什么信息给客户。美国的厂商基本上是在讲产品和技术，而中国云厂商基本上是在搞促销，而且“吃相很难看”。我一直认为作为一个面向企业的专业服务商，参加双十一这样的活动就是一种耻辱。我从来没见那个美国的企业服务公司参加黑五。你看阿里云的首页在视觉观感上是不是越来越像淘宝？相由心生啊！这么搞如何塑造专业形象呢？没有专业形象，附加值就上不去，所以生意越做越苦逼。“IBM，Oracle，微软，Google，AWS，阿里云，腾讯云，华为云”这几个 LOGO 大家看到时候我相信内心的感觉是不一样的。我觉得这就是差距。

阿里这种强运营的做法，确实能获得更多客户，其他厂商也不得不跟进，就导致了现在局面：中国特色运营驱动的云计算产业。业务如果靠销售驱动，杠杆率最低，运营其次，产品最高。所以你去看销售驱动的公司，往往有很多人，但是人均产值很低，比如地产，软件外包。但是产品驱动的公司/业务，往往有超高人均产值，比如微信。再比如国外的 Atlassian（典型产品 JIRA），目前市值 276 亿美元，员工 3600 人，人均市值 920 万美元。这家公司没有销售。

我们在做绩效考核的时候有一句话：你考核什么你就会得到什么。再放大一点，“这个社会奖励什么，就会得到什么”。我想来想去，觉得这里的核心不是供给的问题，而是需求的问题。国内目前的 IT 大环境实质上是鼓励 60 分产品，不重视 80 分或者 100 分产品。花一份精力，可以把产品做到 60 分；花两份精力可以把产品做到 80 分；但是花 10 份精力才能做到 100 分。如果没有足够的正向激励，没有人会去做 100 分产品。所以中国市场上有很多 60 分产品，鲜有 80 分产品，没有 100 分产品。做过企业级项目打单，招投标的人想来都明白，能不能拿下客户，产品最多只有一半的因素。而且很多企业目前追求的是能用，并没有那么强烈的品质诉求。

这个问题说到底也不是 IT 行业的问题。我觉得更明显的是在建筑行业。中国 30 年时间盖了比别人 200 年还要多的房子，可以想象这个房屋质量。每次去老牌资本主义国家，看到人家的写字楼，虽然已经上百年，但那种品质感，国内少有。全球云计算领头羊 AWS 成立于 2006 年，刚才说的 Atlassian 成立于 2002 年。产品驱动就是前面的投入很大，时间很长。我们追赶追求短平快，品质也难以做好。

除此以外，个性化需求太多，付费意愿低下也是影响 2B 企业战略的很大因素。中国企业的个性化诉求太多了，导致很多企业服务厂商要给客户做大量定制。这个问题的原因是中国企业管理不规范，老板文化太重。但我相信这个问题正在改善，包括企业微信/钉钉在内的各种工具在倒逼中小企业的管理规范化，标准化。付费意愿也是，可以看到改善，但是依然很低。CODING 十个活跃用户里面，只有一个是付费的。如果产品你用了，仍然不付费，那企业只能想别的办法搞钱。

以上种种，导致了想要在国内这个环境慢慢打磨产品变得不可能，基本上会死在路上。所以只能逼良为娼，先污染，后治理。虽然中国企业可能投入的人更多，但是抛开工程师的素质不谈，同样多的人力做一个产品和同时做两个产品，差距还是很大的。中国的 996 干不过美国的 955 还是路径选择问题，两条路的杠杆率差距太大。

包括巨头云厂商在内的各个企业，我相信从老板开始，都很清楚做好产品是王道，但实践就是非常困难，把各大云厂商的收入构成扒开看一看就知道究竟有多少真正是产品带来的收入。既要速度，又要质量，还舍不得短期利益，真的可以兼得吗？最近在消费品领域出现了各种“升级”，国产高品质商品迅速崛起，这是新一代中产阶级的需求拉动的。我相信软件行业会出现类似的升级，“Made in China”形象的提升一定不仅仅在制造业。

背景
新项目打算做前后端分离，需要关注接口的响应时间，以便在出现问题时定位到是哪个接口，记得偶然看到获取多线程并发环境下该方法对性能可能会有影响，因此在项目前期做一个小测试。

过程

System.currentTimeMillis()在java中是最常用的获取系统时间的方法，它返回的是1970年1月1日0点到现在经过的毫秒数。 我们看以看到它在Java中的实现为：
public static native long currentTimeMillis();

native关键字说明这个方法底层是由C语言实现的，我们稍后在讲，先做一个简单的测试。

这次测试电脑配置为 Intel(R) Core(TM) i7-8550 16内存。测试很简单10000次for循环调用和多线程10000次调用，直接看结果：
单线程下10000次调用消耗时间为 6713300 ns
多线程下10000次调用消耗时间为 4968593100 ns

可以看到相差还是比较大的,在串行情况下这个api其实性能很好，但是在并发情况下回急剧下降，原因在于计时器在所有进程之间共享，并且其还一直在发生变化，当大量线程尝试同时去访问计时器的时候，就涉及到资源的竞争，于是也就出现并行效率远低于串行效率的现象了。所以在高并发场景下要慎重使用System.nanoTime()和System.currentTimeMillis()这两个API。

在搜索过程中我找到的一篇大家都比较信服的文章来解释为什么会这样，连接如下:
http://pzemtsov.github.io/2017/07/23/the-slow-currenttimemillis.html

​

文章很长，讲的很详细，甚至从汇编语言的角度讲了为什么会这样，有几个比较重要的观点：

• 调用gettimeofday()需要从用户态切换到内核态；
• gettimeofday()的表现受Linux系统的计时器（时钟源）影响，在HPET计时器下性能尤其差；
• 系统只有一个全局时钟源，高并发或频繁访问会造成严重的争用

HPET计时器问题在处理器层面已经解决
处理器系列以不同方式增加时间戳计数器：

对于奔腾M处理器（系列[06H]，型号[09H，0DH]）；对于奔腾4处理器，英特尔至强处理器（系列[0FH]，型号[00H，01H或02H]）；对于P6系列处理器：时间戳记计数器会随着每个内部处理器时钟周期的增加而增加。内部处理器时钟周期由当前内核时钟与总线时钟之比确定。英特尔®SpeedStep®技术过渡也可能会影响处理器时钟。

对于奔腾4处理器，英特尔至强处理器（系列[0FH]，型号[03H及更高版本]）；适用于Intel Core Solo和Intel Core Duo处理器（系列[06H]，型号[0EH]）；用于Intel Xeon处理器5100系列和Intel Core 2 Duo处理器（系列[06H]，型号[0FH]）；适用于Intel Core 2和Intel Xeon处理器（系列[06H]，DisplayModel [17H]）；对于Intel Atom处理器（系列[06H]，DisplayModel [1CH]）：时间戳记计数器以恒定速率递增。

解决思路

网上的解决方法有很多：

1. 维护一个全局缓存，使用单线程调度器器按毫秒更新时间戳，用到了 ScheduledThreadPoolExecutor，代码如下

   1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28

   public class SystemClock { private static final SystemClock MILLIS_CLOCK = new SystemClock(1); private final long precision; private final AtomicLong now; private SystemClock(long precision) { this.precision = precision; now = new AtomicLong(System.currentTimeMillis()); scheduleClockUpdating(); } public static SystemClock millisClock() { return MILLIS_CLOCK; } private void scheduleClockUpdating() { ScheduledExecutorService scheduler = Executors.newSingleThreadScheduledExecutor(runnable -> { Thread thread = new Thread(runnable, "system.clock"); thread.setDaemon(true); return thread; }); scheduler.scheduleAtFixedRate(() -> now.set(System.currentTimeMillis()), precision, precision, TimeUnit.MILLISECONDS); } public long now() { return now.get(); }

​
​

好设计是能影响用户非理性，改变情绪最终影响他的行为。
设计的高境界在于只影响不明说，用户不需要领会设计意图，但情绪已经被感染了，在情绪的作用下，按照设计者预定的轨迹，自然做出选择。