前段时间看到两条 tweets 1, 2

@NalaGinrut: 我跟你们分享一点经验,任何正事(也就是所谓的做进去了),都是 boring 的,当别人告诉你他做的事情十分令人愉悦的时候,他还在面上。

@zhangjintao9020:前半句基本上是这样的。后半句的话,每个人获得成就感/快乐的点不太一样, 虽然 boring 但也不阻碍获得快乐(旅途中的风景也不错)

从我自己的情况来看,确实如此。

我小的时候有学美术,学的中国画。开始画一张新画时,最有劲的都是前半程。勾勒轮廓,调整姿态,布局整体,确定色调和情绪等等,这些都是能从整体上影响作品的因素。

可到了后半程,比如刻画细节,比如修正前半程的错误,就感觉没那么爽了,人没那么有耐心,手也不灵巧了。不过,真要说起来,就是这些后半程琐事,决定了一幅作品能否在细节上打动观众。我的老师当时就是这么跟我说的。

后来作为一个软件工程师,也染上了程序员的通病:从业时间一长,总有一堆原型项目,常规操作是这样的:

  1. 突然有了兴致,开启一个新项目
  2. 发现项目中一个组件应该独立出来
  3. 先把这个项目挂起,开始开发这个组件
  4. 发现组件通用性不够,开始覆盖更多使用场景(即使你的项目只用到了一个场景)
  5. 项目进展特别缓慢,有点懈怠,于是决定玩儿游戏或者看看电视
  6. 过了一段时间,对这个项目丧失了兴趣

An image to describe post

source

然后做着做着,就变得不想继续下去了。

做原型为什么令人激动

搞个项目原型总是让人兴奋。其中一个原因就是,原型系统能迅速得到反馈,让人开心不已

在软件工程里,弄个原型系统花的时间非常少。

这是因为,所有原型系统一开始都只是从某一天的「俺寻思」开始的,它们的目的就是展示某个新技术的原理,或者试验一下新点子的感觉。

另外,原型方案通常都是在一个孤岛上搭建的。系统的实现只满足一个小小的需求,跟真正的外界需求和用户隔离开来。也就是说,这些原型不需要对任何真实需求和用户负责,可以尽情忽略未来扩展的麻烦,只管满足当下的最小需求就行了。

所以,从「俺寻思」到项目第一次跑起来,时间真的很短,典型的「俺寻思」就是 Hackthon,经常一个晚上就够了。这样开发者们就能迅速享受到从「俺寻思」到「wah」的愉悦感。

但是正式的产品可就不一样了。要把它变成一个产品,就得投入大量时间和精力。

另一个原因我觉得是,相比制定稳妥的路线图,人们更容易陷入新技术和概念的炒作中

在公司的业务运作中,这一点也特别明显。

比如说七年前的「机器学习」,三年前的「区块链」,三个月前的「AI」,还有现在的 VR/AR。你在新闻上看到某大公司准备「ALL IN」某个领域——但实际上,可能就是在某办公室里,这个公司的领导听了半小时的播客,然后决定了这次「ALL IN」;或者是某员工在很短时间内通过原型快速验证了某项新技术的概念,然后自下而上地向高层汇报:为什么这项技术能改变行业规则,然后「ALL IN」

不管是怎么开始的,总之,大家会兴致勃勃地开始构建原型系统,这样做有很多好处:

  1. 在这个初期阶段,快就是好。所以根本不需要考虑任何生产系统需要的调查研究。
  2. 这会带来快速的内部成功,大家可以迅速庆祝公司的创新文化,所有人都会由衷鼓掌。
  3. 对员工来说,这是个既有趣又令人兴奋的「练习」。相比起日常工作,这是个很好的分散注意力的机会。

然后,当这些兴奋感逐渐消退后,项目就会停滞不前。咋办呢?

原型不够

回过头来,我认同文章开头的推文的观点:即很多事情,做进去了以后,都很 boring——至少 boring 的部分会长期、固定地占据一大块。

比如说,现在用来发文章的 Quail.ink。我是在 4 月 18 号决定要写 newsletter,然后四天后第一个版本就上线了。但真正上线的时间是 7 月 7 日,距离第一个版本上线已经过去了 2 个多月。

上线之初当然是非常不完善。直到现在,Quail 的 Todo List 依然非常长,有很多工作需要去做,有很多问题需要去解决。

这些要做的工作,有一些是一开始就制订好计划要做的。比如说支付购买内容、绑定自定义域名、数据导入导出等等。

更多的另一些工作,则是预期之外的:

  • 他们有的是新出现的问题和 Bug,需要解决。这类问题很常见,比如前段时间出现的了一个死锁问题导致一个进程无法正常工作,就需要检查然后修复。
  • 有的则是在之前规划中没有考虑到的部分。以自定义域名为例,之前本来想用 cloudflare 的 TLS for SaaS,后来发现不太合适。因此需要改变计划,用 acme 为每一个绑定的域名新增 Let's Encrypted 证书。这就产生了额外的工作量。
  • 另外还有相当多的工作,属于事务性工作,与具体的功能开发没什么关系。例如最近两个月访问量大了,之前没有做的负载均衡需要做起来 -> 负载均衡做了,那之前的单机 cache 都需要换到 redis ... 诸如此类的工作,属于用户们都感知不到,但是必须要做。

这些工作中的许多,尤其是最后一类工作——很无聊——经常地内心里并不想去做,但是不得不做——因为这是稳定服务和持续迭代必须付出的代价。

这还只是工程上的事。

作为一个产品经理,还得考虑未来要做什么,不做什么。所有那些非工程类的思考和决策,包括「后台编辑器要达到什么水平」、「AI 要整合到什么程度」这样的需求设计,还包括「作为核心用户的作者们关心哪些事情」这样的长期问题,都得考虑。

不要那么无聊

既然知道了无聊的原因,那就有机会让项目继续下去:

尽早宣告一下

现在很多独立开发者采用的「build in public」就是这个做法:尽早让大家知道你在做什么。

一方面可以得到第一手的反馈,另一方面——也是非常重要的一个原因——大家也能会鼓励你继续做下去。

之前我有个项目叫 Hotot。本来我最早只是想玩票的,但是突然被一个西班牙 Linux 媒体报道了,用户一下子就多了。我就很高兴地持续做下去,直到 Twitter 更改了他们的 API 策略

确定需求的存在

对于很多工程师来说,这个事情可能有些难。无论是宏观上的「这个事情值不值得做」还是微观上的「这个用户体验好不好」,都与理解用户和市场息息相关。

除了自学变成一个产品经理之外,还有一个简单的方法,就是只关注你所代表的那群人的需求。

了解自己肯定比了解别人容易得多。如果你对自己做的东西非常满意,那么也就意味着潜在地与你类似的人应该也会满意。确定这一方向以后,把自己为代表的这群人的需求满足到机制即可。

选择做与不做

折腾任何东西都是投资。写代码、设计需要时间和精力,服务器还需要金钱。所以既然是「投资」,就要考虑投资的合理性,即回报。

如果我打算创造一个新 App 或者服务,就需要证明这个「投资」是合理的。如果这个新的原型产品只能带来名义上的增量价值,看不到直接的经济回报,就需要确定它实际上能给我们带来什么。

当然,并不是所有原型产品都必须产生经济上的收入,也可能是为了验证概念或探索新领域而创建的。这些项目的目标可能是获取用户反馈、提供解决方案或推动技术创新。尽管它们可能不直接带来经济回报,但它们在其他方面可能具有价值,如吸引投资、建立声誉或为将来的商业化打下基础。

在这一观点下,选择一件事「做与不做」就很重要。你的这些决定,最终会得到:经济回报、项目的可行性验证、用户满意度、商业声誉等等。这些结果都需要能被量化,才能用于参与一件事「做与不做」的决策。


不过我觉得,不在乎有趣或者无聊,持续地长期地做一些正确的事情,把时间当作朋友而不是炮友,才能看到无聊的价值。