重构与复提产品有感

2月2日，二月份第一个工作日。老大道佳和同事阳仔来了，技术组的三人总算全部到齐。再加上辰光大师兄，讨论时总算有了许多技术成分加入。此时，对产品未来开发的开发变得有了冲击和富有信息量起来。期间，道佳和阳仔（其实阳仔能力很强）提到了代码重构的概念。自己之前也有所感悟，这次找到共鸣有些高兴。

关于重构

有前几篇日记的缺点做借鉴，这里分点列出我的想法，力避废话和漫无头绪。

重构是经常出现的

起因是，身为技术的我们接手的是外包团队的一期作品，随着更高产品需求的提出，代码自然做了一番又一番的增删改查，渐渐地，我们愈发察觉到推倒重来似乎比继续修改来得更长远和轻松。今天对员工权限模糊问题的讨论是压倒骆驼的最后一根稻草。在讨论时，道佳提到重构是程序员避不开的环节，所谓两月一重构。我认为很有道理，诚如辰光在之前所说，产品的商业模式是会随市场反响改变的。这样，阳仔的事例就很好解释了——他在之前的创业团队当过技术，写代码时，他说到“我写的代码只能用2个月，这两个月后恐怕需要你们找跟你们一起做下去的技术重新写一遍。”

重构来自新需求或新思想

产品在推出后，导向不可避免受到外界的影响。补丁打多了，衣服自然变得不适合穿。老版的代码经常跟不上方向的迅速变化，重构是最理想也是最有效的解决办法，治标且治本。另外，这里新思想是指对数据结构或身份权限等基本模型有了更深的认识抑或外界因素迫使基本模型做出适应（如用户量的庞大将考验数据表的设计），这次我们将要作出的重构一部分就是因为这个原因。

重构是产品与技术的平衡点

产品设计和技术开发的思路刚好是两个不同方向。产品设计讲究MVP（Minimum Viable Product ），意为产品的最初设计一定要抓住核心，把产品的主要价值展现出来即可。拿给用户反馈后，再看情况做后续设计。因为，这样在成本上最节省，且成功概率最大。“迭代”一词在这里是最佳的形容，推出=>反馈=>复推出，如此周而复始，雪球越滚越大。归功于互联网的快速，可以“小步快跑”的传统行业互联网化将有很美好的场景（可惜的是，汽车等传统行业做不到），在短期内滚成很大规模。因此，初期产品追求短小而精悍，很忌讳全面。

理想化的技术恰相反，毕竟只有对产品有了全面细致的思考，才能使保证产品在技术上的长时间可靠性。如，模型设计，数据表设计。这些正像大厦的地基，地基牢固，楼才搭得高。可是，绝大多数情况，产品等不了那么久，没有全面思考调研的时间，只能像上文提到那样，先做出突出主体的一部分。这样技术就不得不在新需求的压力下，对地基进行小范围修改，以保证产品的可靠性。可以想见，这样搭上去的楼注定不会牢固。

重构恰好是两者中的平衡点。重构给了技术喘口气的时间，也能满足产品方面的新需求。正是由于它的普遍存在性。很多公司其实是一边打补丁，一边给自己铺后路设计新技术架构的。

MVP与产品成功三内因

上文中也提到了，产品的设计是有讲究的。在初期设计时，一定要把握住MVP的思路，只呈现核心价值，用最小可验证产品证明它的可行性。微信就是个很典型的例子，1.0只推出了聊天功能，之后的摇一摇，朋友圈，支付等都是一点一点加上去的。充分的缓冲时间和较快的互联网产品周期，让它能稳步上升。它的内因是，未来无法预知，最小代价实验，随机应变是最放心的。好的产品经理不用识别未来，只要能识别好产品现在的走向就不错了。反过来看初期，若有的产品设计的面面俱到或是团队承诺已考虑到未来，多半走不远。

产品在设计上有成功的三内因。一，满足刚需；二，用户黏性；三，用户体验。这里以师兄提到的找朋友出去玩的app来讨论。

满足刚需

刚需是什么？就是在某种场景下，满足某一部分人的必需。以例子为例，它满足了在找不到熟人却想进行体育活动等时的需求。刚需最好别无取代，当有所取代时，可以尝试缩小用户群，提高针对性。

用户黏性

满足了刚需，就会有人用。但这还不够，足够的用户黏性才能保证产品活下去。黏性的最好衡量因素就是使用频次。以例子为例，休闲活动对于大多数人来说一周一到两次，这样的频次实在不算高。

用户体验

用户体验即产品价值。价值=值 - 价，只有用户使用产品时的显性+隐性花费小于得到的体验，才会被留下来。即产品大于用户的预期。它是用户黏性的保证。

写了这么多篇日记，似乎以产品为多了。道佳、阳仔过来后，但愿在技术上也能得到真知灼见。