再来谈如何提高效率

　　基于一些常见的统计工具，或者自己开发的统计工具，去统计用户的行为特征、行为链路，然后和自己的预期设想对比，和历史数据对比，和同行数据对比，看看哪里和自己的预期不一致，寻找问题点。找到问题点后，通过这个问题点的边界条件，去筛选目标用户，然后人工去分析这些用户的行为记录。人工的目的是强代入感，真正把自己代入到用户的体验中，理解用户的不满，理解用户的挣扎，理解用户在使用中的困惑和障碍，然后优化产品，从而满足用户需求。很多人做到了天天看统计数据，看数据分析报告，但是没有认真去溯源，没有代入感，得到的结论往往是片面的，不求甚解的。

　　欲速则不达

　　我以前性格就挺急的，有个事情没完成、有个项目没做好恨不得赶紧熬俩通宵就搞定。后来发现急也没用，有时候你觉得只差一点点的东西，其实差得还是蛮大的，路要一步步走，饭要一口口吃。急躁冒进，犯了兵家大忌，很可能会出大问题。

　　中国古谚，磨刀不误砍柴工，先把准备工作做好，再来谈如何提高效率。

　　1.一个创业公司，业务发展不错，流量开始起规模，然后服务器开始抗不住，老板着急，花重金请巨头专家会诊，方案开出，这架构各种不对，重构，从存储到数据结构到开发环境全部改造。

　　这样对吗？巨头专家说的方案不能说不对，但是创业公司，还没到巨头公司这个体量，再从人才储备和积累来说，也没有这么深厚的基础。更重要的是，干活的技术人员，其实并不知道自己的系统问题在哪里，就要重构系统，用我的理解，就俩字——乱来。

　　正解是什么呢？你要先让人家明白负载卡在哪里，系统问题在哪里，数据索引是不是ok？应用程序是不是有不合理不完善的地方？你说重构就都好了，这些都不重要？下次出问题继续重构吗？你要让这个公司自己有学会发现问题和分析问题的能力，先学会搭建运维的监控和数据跟踪，学会基本的调优思路和分析逻辑，然后把当前紧要的问题解决掉，让系统先满足当前的业务需求，留下做深度升级的缓冲时间，再来讨论重构与否的话题。这样，有了基本的问题分析能力和处理思路，是否重构已经不是关键的问题了。

　　这是我一个虚构的场景，但是现实中类似的事情还是蛮多的。一些小创业公司仰慕某些巨头的技术架构、技术专家，觉得照搬一个经过实践验证的完美系统架构就可以解决一切技术问题，其实你连基本的优化逻辑都没掌握呢，你搭建起来就能用好？异想天开！

　　2.之前分享一些积分里程的案例，有些人就跑来问一些资源，实话说，我还真知道一些不错的网站，里程兑换表的计算合理清晰到位，转让价格也合理，我也一直在用这些网站的服务，但是我并不会一上来就推荐给朋友，为什么呢？还真不是藏私，简单一句话，如果你没有了解这个里程兑换的流程和潜在的风险，没有对这个东西的运作模式有完整清楚的认识，看到一个这样的网站，很可能会误解其所提供资源的价值和意义，可能一开心就买了一堆积分里程，然后突然发现根本用不掉，换不出东西，然后坐看贬值，跑来埋怨，我就成骗子了。

　　这里的学习成本，对于有些人来说，其实挺高的，所以，没有明确理解其运作模式之前，不要来问，问了也白问；如果你真明确理解了，大概也不需要问了，自己搜一搜都能找到，我也是搜索到的，就是那些关键词。

　　如果你连去深度了解的愿望都没有，连搜索的目标都不知道，就希望别人给你提供现成的一揽子方案，对不起，傻瓜式的自助平台在这个领域真的没有，给你的一定不是你想要的。

　　这也是一个典型的例子，有些看上去不错的资源、工具、社交场合，你没到这个境界和理解力，非想要不惜一切冲上去，可能会发现，完全不是你预期的样子，也达不到你所期望的效果，就会大失所望。还是先要达到一定的基础，能理解的时候，很多之前可望不可求的东西，可能自然而然就获得了。

　　3.一个不错的平台，觉得搜索有优化空间，请专家去讲优化方案，但实际效果并不是很好。后来我反思了一下，问题还是步子有点大，先不谈优化方案，先做一个搜索效果评估的数据支持平台，能够实现对效果的自我鉴定和对比评估，这个东西做出来后，就能比较容易甄别现状中的坏案例，发现问题点，然后再谈优化方案，这样才是一个合理的步骤。

　　很多时候，为什么欲速则不达，是因为需要有一个扎实的基础，好的基础才是提速的关键，所谓磨刀不误砍柴工，古人早就明白了。

　　4.技术人员，很多人都想走架构师路线，走高大上的路线，刻苦学习各种新技术、新名词、新概念，但是你们知道一个架构师是怎么成长起来的？天天看外文资料、看最新架构方案、看巨头的开源项目就成架构师了？才怪。

　　一个架构师最多的工作是看自己的运维监控数据、服务器日志，看业务场景中瓶颈系统的源代码和数据结构，然后不断思考和调整，寻求可靠性、成本、扩展性、安全性综合最好的方案，来优化和升级现有系统，进而不断迭代，不断反思曾经犯过的错误，然后逐步成长起来。当然，在这个过程中，也会不断有目的地搜索其他开源系统和巨头的技术方?