加班除了客观原因，还有哪些是值得我思考的？

这会儿是晚上十点半，可以坐在床上了写点儿东西，很难得。
这周工作比较忙，周三、周四连着两天工作到凌晨三点。后几天也基本上满负荷工作。
工作量大是工作紧张的一个客观原因，还有其他的一些原因——为什么我们的产品在上线后显得手忙脚乱？
因为可能涉及到商业机密，这里不便描述产品的具体功能和流程，所以这里只围绕着三个点来做一些思考：
问题1：
问题描述：
为什么有些Bug能够经过产品人员、开发人员、测试人员到上线都不被发现，而上线后用户很快就发现了？
问题梳理：
做研发的人可能都会有经历，经常一些很简单的Bug却能够经过那么多人的手就那么“顺利的”
上线了，往往出现这种问题，不排除是人为不负责任导致的，但是一群人同时抱着不负责任的心态并最终导致问题发生的
概率应该不大。
我们这次产品不是新创产品，是因为公司业务升级以及系统重构进行的开发。因此一部分代码逻辑是可以直接复用的。
拿我们这次的一个Bug来说，项目上线时间是比较紧，但是越是时间紧的情况下，其实我们更是应该重点了解用户
之前在使用这款产品时最注重的是哪个功能点，这些功能点我们应该更重点的对待。但是在开发中，我们对所有的功能
是平等对待的，开发过程中我们大都是靠解读代码来分析原有业务逻辑，却大大的忽视了去跟用户沟通。事实证明，
在我们产品上线后，再最能提高用户工作效率的一个问题上我们出现了一个Bug，为了解决这个Bug导致的脏数据，我们
不得不安排了三个人一起工作了半天才得以把这些脏数据清洗干净。
结论：
在项目上线周期很紧的情况下，我们一定要对整个产品业务非常熟悉，同时要非常清晰的了解哪些需要重点对待，哪些可以
后续完善，哪些即使有一些问题用户也是可以容忍的。暂且分为：重要且影响范围大、重要但影响范围小、可以容忍三类。

问题2:
问题描述：
用户真正需要的是什么？
问题梳理：
对于用户真正需要什么这个问题，可以拿问题1的例子继续说，比如，在我们没有跟用户沟通前，我们为什么没有想到用户
会这样操作？这样操作能解决用户什么核心需求？我们出Bug的这个功能是一个批量处理的功能。显然，用户使用这个功能
是想提高工作效率。批量处理的基本功能仍然是处理数据，但是它相对于单条处理，在效率上明显提升。在正确处理数据的
前提下还能提高工作效率，肯定人人喜欢。了解到用户真正的需求后，我们就可以来界定哪些是重要且影响范围大的，从而
指定优先级了。优先级的划分不能完全听从用户，对用户而言，他肯定是希望你所有的功能都又快又好的帮他解决了。
结论：
每一个功能，我们除了需要考虑实现基本功能外，是否可以对用户有隐性的帮助，比如满足用户某些心理需求。
这些隐性的需求往往是用户最想要的。

3）B端产品的设计真的必须复杂吗？是否有可能像一些好的C端的产品那样简洁优雅？
这个问题比较大，也是一直在思考，但一直没有得到比较好的结论。所以这个点暂时不特别扩展说，欢迎有兴趣
的朋友来碰撞。下面简单的说一下我个人的观点：
1）B端的产品因其业务相对复杂，系统在设计并开发完成后往往需要对用户进行一些培训用户才能上手使用。相对复杂的使用
不仅影响用户的操作体验，也增加了研发出错的概率。那么怎么才能降低产品设计的复杂度呢？真正了解用户的诉求，才能
找到简洁的解决方案。
2）因为线下业务复杂导致工作时间长、效率低，这个时候用户往往寄希望有线上系统来帮他们提高工作效率。但是用户却不愿意改变，
在提需求的时候就是希望把线下“繁重而冗余”的流程搬到线上，这样系统上线了，最终却发现原本线下只要做一遍的事情线上还得再做一遍。
所以在设计产品的时候，个人认为，如何优化流程，并能够通过线上影响线下并最终优化整个工作流程才是一款好的B端产品。
正如很多优秀的C端产品，改变人们的线下的工作、生活习惯。B端的工作流程，正如C端的个人工作、生活习惯是一样需要互联网的方式来改造的。

以上是个人的一些拙见，写出来作为自己思考的一个记录。
晚安了，自己。

2016-04-10 晚