4 月 14 日，是 Markdown.app 的首发日，写下这篇文章的时候，刚好 12 天。
本文不涉及到Markdown.app 的相关数据，谈谈一些其它方面的想法。
成文前，非常犹疑，站在产品人的角度，而不是写作者的表达欲，我怀疑内容是否对读者有价值，因为我们彼此必然缺乏了背景性的共情。
说服自己成文的理由：如果有办法回到过去，我一定会把本篇邮给过往的自己。我希望他能明白 两个很简单的道理，虽然简单却能彻底让工作效率、产品的质量大幅提升。而且，因为太简单，简单到让人忽略了。
我记录下了此时写文章的状态，大半夜，使用自己的写作工具。边上的小花，是白天时，路边采的荒长的小野花 (其实是蒲公英)。写着写着，我又跑去修了两个刚发现的小 bug。
写字比写代码要舒畅多了，回想之前噩梦一般的 7 天，倒有点恍惚了。
App 发布日后的前一两天，回复了一百多条评论，回收了很多问题。接下来的 7 天里，每天都是凌晨后才睡下，有 3 、4 天是凌晨 3 点后才放下键盘。次日早晨八九点钟，又起来干活了。
7 天里，其中1 天打算把 Webview (性能有问题) 换成 WKWebview，这样基本上所有不应该出现的性能瓶颈都消失了。遗憾的是，失败了。苹果这么多年没有改进过 Webview 了，而 WKWebview (特别是桌面端的) 出了这么多年，苹果也没有进一步完善。这是一条走不通的路，好在此处的瓶颈并不是那般明显，只是又浪费了 1 天时间。
剩下的6天里，我代码的提交次数大约 150 次，而 Markdown.app 整体的提交量是 1000 次左右。整个过程，甚至还有些『勇莽』，为了提升性能，把整个主体视觉的骨架逻辑重写了；不恰当的比喻，就是已落成的房子，把钢筋替换一遍。会不会有问题？自然会有问题。或许得益于曾经趟过很多坑的经验，知道如何确保主体不崩，以及紧接着再进行一次修补，就会稳定下来。
几乎所有的时间，都被压榨出来了，这种紧张感，似乎很多年没有出现过了。
对于很多人来说，时间管理容易成为一个问题，对于独立开发者而言，因为太自由，问题容易变得更严重。
对我来说，『时间管理』已经弱化为用 MiniTodo 来完成，与其说是事务管理的工具，倒不如说是一个条目化的备忘录。可以看我现在的状态，它其实有些混乱的，却又无比实用，参考下图:
MiniTodo 我是发在 Mac App Store 上的免费软件
换句话说，几乎没有使用任何管理工具，也没有时间管理。管理是需要成本的，不想浪费这个时间。完成了的事情，就是可以清空的事情；未完成的，就是备忘之中的；至于优先级，脑海中有自己的安排。
此时，我们就是工作的机器人，没有感情的机器人，也不会疲惫的机器人，所以就不用再『管理』了。
把一个月的工作量压缩在 7 天里完成？这个论断并不容易成立。因为旁人并不清楚这过程中具体的工作量，就会无法共情；我觉得很累，但旁人并不会这么觉得。凭什么，你说要一个月的工作量就一个月呀，7 天就不能是正常的工期吗？
至于具体的工作量，并不重要，一切以结果论。这次真正刺激到我的是 为什么要压缩时间？ 换句话说，为什么要如何严格地遵守这次的 deadline？
在一般的团队协作中，正常工作的 deadline 是工期安排的基准线，它就像一个定时定点的班车，如果开走了，你的 需求 来晚了，不是十万火急那就等下一班吧。我们还会因为 deadline 的存在，有不少临时的对应方式。而我这次的经历，则完全不同，deadline 是终点线，不是基准线，整体的基准线是不考虑 deadline 情况下产品本身的需求。
deadline 如果是一条基准线，我们从开始的时候可以很有节奏地行走，快到终点时，再冲一冲就可以了，都是计划内的。而 deadline 只作为终点线，不再作为基准线的时候，它意味着我们从一开始直接就要冲刺，越到终点越要加速，完全无视事实体力，只考虑理想态，并且超越理想态。或许 Jobs 离开世界太久了，我们忘记了他曾经的现实扭曲力场，从这个角度来看，似乎更容易理解一些？
deadline 的中文翻译一般叫做 最后截止(时间)。deadline 对于独立开发者来说，它被确定的同时，也意味着要被打破，因为我们真的太自由了。『最后截止』听起来其实是很温和的，打破起来，我们并不会有太大的良心不安。
如果我们把 deadline 直译为 死亡线，是否更有冲击感？当你越过了这条线，就死掉了。是否更有恐惧的感觉？而，『恐惧』能不能在某个层面，被视为第一生产力呢？
比如独立开发者本身很容易面对很多问题，做什么产品？怎么活下去？看起来不像问题的问题，如果这两个问题解决不了，其实是独立不起来的。而这两个问题的答案，每个人都不一样，还有不少朋友在回答它们的时候直接失败了。如果换一个角度，我们用 死亡线 的概念去回答它们呢？是否会倒逼着自己去超越原本自我正常的极限呢？如果超越了，那么问题是否也就解决了呢？
最后的一个问题，到底什么原因逼得我必须遵守这次的 deadline？
我这次的 deadline 在 4 月 22 日。按照以往，肯定不会这么迅速，而是按照正常的节奏，走上大抵一个月的模样，可能每周作为一个小的阶段，保持迭代。什么原因让我这次如此急功呢，自我驱动吗？不是的，自我驱动还不至于把自己往死里逼。因为这个时间是某人定的，我没有拒绝的理由。
至于是谁定呢？用户吗？用户是有很大的力量，还不至于有这么大的影响力。所以，可以猜猜看？
其实，如果我违背了 deadline，也是没有关系，彼此理解，没有任何惩罚。而症结就出在这里的『没有关系』，这是我所不能违背的。
于是，刻意遵守，才有了这次印象深刻的反省。跟我以前在工作中遵守过的 deadline 都不一样，完全不一样，以至于才感觉摸到了它原本的状态。虽然说，这本也是很简单的道理。
拥抱用户的批评，是件正常的事情，但也有不少时候，反馈是不直接的，它来自于微博、Twitter。
『我们应该尽可能地去听取用户意见』，但并不容易，因为 听取 本身是要耗费不少时间的。还有时，也需要权衡，什么都听用户的，产品容易变得很奇怪。
以上两点，都是理所当然的事情。每个开发者有自己的秉性，也会采取符合自己的策略，甚至于不听任何的人意见，也不是什么问题。
这次，我也发现一些有趣的现象。
用户有时候充满怨气的抱怨，甚至绝望，只是因为他遇到了困难，他甚至都不知道要找开发者反应问题。
有时候他反应了问题 A，在沟通的时候，你其实会获得 B、C、D 其它问题。如果不更靠近一点，我们只能止步于解决问题 A 了。
比如，有人反应超长文本(40 万字)情况下的毫无反应，首先，这触及了 App 的性能边界，其次，也说明了我们自己在这个边界问题还没有对应。于是用了一部《圣经》作为测试的文档，把一些无关的重复计算逻辑去掉，最终超长文本的场景下，性能瓶颈仍然存在，但基本能做到勉强可用。为了避免这种不适用的场景，在 App 内也会对超长文本进行提醒。
比如，有朋友反应字体劝退，当时，我并不能理解这个点。作为产品经理出身，脑补的能力其实是很强的，只言片语之间是能补足用户的想法的，但『字体劝退』是什么意思，不得其意。或许只是默认的字体大小偏小一号？如果以往，过于依赖自己的『脑补』能力，这种显然不能理解的情况，一般是忽略，因为跟进的成本太高了。
后来跟进了，才明白其实是一个乌龙，而在这乌龙当中，我回收到了另外两个问题，URL Scheme 形式的链接无法点击、一种不适合 Todo Item 对待的列表项。
在尝试重现字体问题的时候，因为并无问题，所以并无所得。有趣的是，发现另外一个小 bug。
另外，还有一些细小的问题。比如 Markdown.app 的视觉主题是有随机机制的，原先在菜单栏中叫 尝试随机，使用者似乎会认为这个操作是从既定的主题中随机选取一个，于是后面就把它的名字改为 随机生成。只有听用户在说些什么了，我们才真正意义上站得离他们更近一些。
这次界面上调整的，比较大的是 偏好设置 的界面 (还存在优化空间)。
这部分的布局逻辑，是来自于我自己写的布局引擎，自动生成。因为设置项比较多，如果采用 macOS 常见的视觉风格，感觉也排不好，一多就显得烦乱，而且设置界面里的视觉元素也无法跟随整个视觉主题自动变化。
但偏好设置作为主体区域之外的视觉，从一开始我就知道它是粗糙的，风格可以有偏好，但是粗糙感是不以风格为转移的，看一眼就能看明白的事情。
偏好设置的粗糙感，从一开始就知道，但还是让它随着产品的初次发布就出去了。所以，针对它的优化，给了我很大的刺激。明明什么都懂，为何当时不处理？
论及原因，大家又是非常理解的: it works ……
开始时，这 (it works) 没有任何问题，只是慢慢自己习惯了，就会导致存在着的问题被忽视，我们总是在犯这样的错误。就比如说，我在调整自动布局算法的时候，垂直方向两个元素并没有右对齐，夫人就说了一句『没对齐』，我则是说『要对齐也不是不可以，只是这里的算法很复杂的，真不想弄，要不就这样吧……』
而实际上，只是一个 -= 写成了 += 的 typo 错误而已。
我们一定要把外部的视角、用户的建议摆在更高的高度，并非我们不懂，而是我们什么都懂，以至于我们即使错了也能找到开脱的理由。 所有人，都可以成为我们的参谋，参谋的角色并不是代替我们思考，而是以一个第三方的角度，帮我们更确定当下客观的情况。
什么叫离谱？不过是超出我们原定思维的产物而已。有些『离谱』是匪夷所思的，而有些『离谱』其实是隐藏的宝藏。
在诸多反馈中，经常出现的是希望提供一个所见所得的模式。我个人并不太喜欢这种模式，觉得就是另外一种轻量形态的 Word，因为自己是纯文本流派的，但是也不排斥。
如果是你，你如何判断呢？听从用户的吗？不同流派之间可能存在巨大的技术壁垒，值得吗？ 不听用户的吗？他们的诉求是有合理性的呀。
在这个过程中，我尽可能把自己的想法剥离出来，觉得也不是不可能。从 HTML 的角度来实现所见所得，是很天然的；而从 TEXT 的角度再去实现所见所得，有没有可能？如果能做到，那么稳定性、性能是有可能超过前者的。换一个角度去思考，我恍然大悟，Markdown.app 中本来就有一个地方用了这种 (实际文本与显示元素) 替换的逻辑，完全有可能在更多语法上实现所见所得的效果。
在 Markdown.app 中点击 H1~H6 标记可以伸缩其涵盖的段落
其实，还有一个反馈，要不要增加类似 Word 一样的(格式)工具栏呢？ 各种自问，还是接受不了。
或许也没有那么难接受，提供一个扩展，愿意添加一个工具栏，就添加一个工具栏。所以，未来真的发生变化，也不是没有可能。
但同时，原先让我感到有些困惑的地方，如果产品的底线并不是那般明确的，可以不断挪移，极端的说，如果做成另一个 Word，是不是也有合理性？保持足够的开放态度，答案是肯定，确实有其合理性。那我们是不是终将要丢失自我？
或许也不用有这样的担心。起码，在一个产品的初期，我们要抱着足够开放的心态，去聆听，或许在一些原本觉得『离谱』的想法中获得新的灵感也不一定。
我希望有些产品上，可以剥离个性。不是因为个性不好，而是因为个性是不稳定的。
所以尽可能去拥抱所有的批评。
另外呢，个性是不可能完全剥离的。这样，就足够了。
此内容由惯性聚合(RSS阅读器)自动聚合整理，仅供阅读参考。 原文来自 — 版权归原作者所有。