@NalaGinrut： 我跟你们分享一点经验，任何正事（也就是所谓的做进去了），都是 boring 的，当别人告诉你他做的事情十分令人愉悦的时候，他还在面上。
@zhangjintao9020：前半句基本上是这样的。后半句的话，每个人获得成就感/快乐的点不太一样， 虽然 boring 但也不阻碍获得快乐（旅途中的风景也不错）
从我自己的情况来看，确实如此。
我小的时候有学美术，学的中国画。开始画一张新画时，最有劲的都是前半程。勾勒轮廓，调整姿态，布局整体，确定色调和情绪等等，这些都是能从整体上影响作品的因素。
可到了后半程，比如刻画细节，比如修正前半程的错误，就感觉没那么爽了，人没那么有耐心，手也不灵巧了。不过，真要说起来，就是这些后半程琐事，决定了一幅作品能否在细节上打动观众。我的老师当时就是这么跟我说的。
后来作为一个软件工程师，也染上了程序员的通病：从业时间一长，总有一堆原型项目，常规操作是这样的：
- 突然有了兴致，开启一个新项目
- 发现项目中一个组件应该独立出来
- 先把这个项目挂起，开始开发这个组件
- 发现组件通用性不够，开始覆盖更多使用场景（即使你的项目只用到了一个场景）
- 项目进展特别缓慢，有点懈怠，于是决定玩儿游戏或者看看电视
- 过了一段时间，对这个项目丧失了兴趣
然后做着做着，就变得不想继续下去了。
做原型为什么令人激动
搞个项目原型总是让人兴奋。其中一个原因就是，原型系统能迅速得到反馈，让人开心不已。
在软件工程里，弄个原型系统花的时间非常少。
这是因为，所有原型系统一开始都只是从某一天的「俺寻思」开始的，它们的目的就是展示某个新技术的原理，或者试验一下新点子的感觉。
另外，原型方案通常都是在一个孤岛上搭建的。系统的实现只满足一个小小的需求，跟真正的外界需求和用户隔离开来。也就是说，这些原型不需要对任何真实需求和用户负责，可以尽情忽略未来扩展的麻烦，只管满足当下的最小需求就行了。
所以，从「俺寻思」到项目第一次跑起来，时间真的很短，典型的「俺寻思」就是 Hackthon，经常一个晚上就够了。这样开发者们就能迅速享受到从「俺寻思」到「wah」的愉悦感。
但是正式的产品可就不一样了。要把它变成一个产品，就得投入大量时间和精力。
另一个原因我觉得是，相比制定稳妥的路线图，人们更容易陷入新技术和概念的炒作中。
在公司的业务运作中，这一点也特别明显。
比如说七年前的「机器学习」，三年前的「区块链」，三个月前的「AI」，还有现在的 VR/AR。你在新闻上看到某大公司准备「ALL IN」某个领域——但实际上，可能就是在某办公室里，这个公司的领导听了半小时的播客，然后决定了这次「ALL IN」；或者是某员工在很短时间内通过原型快速验证了某项新技术的概念，然后自下而上地向高层汇报：为什么这项技术能改变行业规则，然后「ALL IN」
不管是怎么开始的，总之，大家会兴致勃勃地开始构建原型系统，这样做有很多好处：
- 在这个初期阶段，快就是好。所以根本不需要考虑任何生产系统需要的调查研究。
- 这会带来快速的内部成功，大家可以迅速庆祝公司的创新文化，所有人都会由衷鼓掌。
- 对员工来说，这是个既有趣又令人兴奋的「练习」。相比起日常工作，这是个很好的分散注意力的机会。
然后，当这些兴奋感逐渐消退后，项目就会停滞不前。咋办呢？
原型不够
回过头来，我认同文章开头的推文的观点：即很多事情，做进去了以后，都很 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 或者服务，就需要证明这个「投资」是合理的。如果这个新的原型产品只能带来名义上的增量价值，看不到直接的经济回报，就需要确定它实际上能给我们带来什么。
当然，并不是所有原型产品都必须产生经济上的收入，也可能是为了验证概念或探索新领域而创建的。这些项目的目标可能是获取用户反馈、提供解决方案或推动技术创新。尽管它们可能不直接带来经济回报，但它们在其他方面可能具有价值，如吸引投资、建立声誉或为将来的商业化打下基础。
在这一观点下，选择一件事「做与不做」就很重要。你的这些决定，最终会得到：经济回报、项目的可行性验证、用户满意度、商业声誉等等。这些结果都需要能被量化，才能用于参与一件事「做与不做」的决策。
不过我觉得，不在乎有趣或者无聊，持续地长期地做一些正确的事情，把时间当作朋友而不是炮友，才能看到无聊的价值。
