人的状态是一阵一阵的，这段时间的状态属于不太想写技术，所以fofahub的那个系列我要晚几天再写，最主要的原因还是再一次出现了能力跟不上目标产生的极度痛苦。我感觉我应该跑一个深山老林静坐一段时间了，我个人再努力也解决不了研发能力跟不上的问题。

最近在内部几个团队的管理上投入了一些时间，形势所迫，我不得不把“清高”适当地放一放，不得不在一定时间内把“用户至上”改成“客户至上”。因为根据地还不够大，来了那么多的人口，山上的粮食就不够分了，需要有人突出封锁区，到外面再去开拓一片新的更大的根据地。

我们之前的开拓过程经过事实证明是正确的：做出技术上突出的产品，把核心功能做透做稳定，形成一种潜意识的认知。通过这种方式，我们很快得到了大量一线用户的使用和反馈，帮助我们沉淀了一些场景和认可。用户整体上对我们是很支持的，这些也变成了我们后续持续发展强有力的背景。这种成长过程只要给予一定的时间，就会一片带动一片，最终形成一个平台化的产品，持续不断地发展下去。

外部环境总是会经历一些突变的，中间发生了一些必须去正式的问题，最基本的就是疫情与外部技术压制下带来的经济动荡，这种动荡最直接的影响就是大家都没钱，都要勒紧裤腰带求生存。当我们提到生存两个字，首先都是物理上的，而不是虚拟数字上的。我们可以自欺欺人，但是盯着数字建设的整体投入，我预计未来的一定时间内，是一个预算打架的情况，不同行业都在争取同一份钱，就看谁的优先级更高了，而这种优先级是很容易被主观客观的因素发生变化的。

接下来的商业市场，要考虑的是帮助客户用技术省成本。比如之前雇了很多人每年投入了大量的硬件设备完成运维工作，同样的效果如果你能只用四分之一的成本就能完成自动化的输出（少量的人力），那么节约下来的就是收益。因为接下来的日子，客户的每一项预算都可能缩减了一半，如果还是只拼降低人工成本，那么大概率质量会拉垮，容易出事故。用户在控制成本的情况下对质量的要求并不会降低——能降低的很可能把网络安全部门整个裁掉了——所以大家要去证明的是两点：一是为什么我们是最佳实践，二是为什么我们的方案会比你现在的投入成本更低，能够让你把净支出变成净利润留下来。这两个问题恰恰就是技术爆发的原因。

带着这样的问题，我尝试到合部门去寻找答案，我想看看大家是怎么思考的。很不幸的是，我发现全公司所有的部门都处于团队工作极其饱和，处于缺一个人工作团队就会“崩溃”的边缘，“缺人“的口号呼声震天。事实上，我们的商业化产品开发周期长效率低，问题多，客户认知低，目前不是那种能够适应市场自主选择的好产品。我们的底层技术是有的，上层业务出了问题，公司要去集体思考的是：客户的痛点是什么？我们的方案是不是真的能够解决问题？是不是行业认可的技术最佳实践？是不是真的能够帮用户完成技术升级的同时明显降低成本？

大家忙是真忙，每天加班加点的状态我看着都心疼，忙着开发忙着交付，忙到没有时间陪家人，忙到非常整齐地抱怨“会太多了，太久了，太低效了”。会多倒是真的，我理解会议这种事情啊，小事才开大会，大事都是在抽根烟闲聊的功夫就定下来了，越小范围的沟通越高效越有建设性，大会基本上是通气执行或者统一意见的宣贯会。所以，我觉得会议是矛盾，但并非主要矛盾，我再沉下去一下，发现问题就逐渐明朗了起来。大家忙的是开发，这种开发是具体的可衡量的，是可以“用于交差”的最小集合，是一种“你不能说我不努力”的舒适区域，这种舒适区域几乎掩盖了一切我们想要的好的方向和结果。

你把一加一等于二做了一万次，你也学不会三乘以四这样的乘法；在机器学习的分类领域，你用一元一次方程的切割方法，永远切割不了多维度的立体曲线空间的点。我们就像带着红色眼镜的人，永远看不到绿色也想象不到绿色的样子。在我们固有的轻松的认知区域，我们把自己很快地拉进到了一个不思进取的环境。忙，累，过了一段时间，在没有明显输出的情况下感叹“太忙了导致没有进步了”，选择换一个环境休息。

人区别于其他生物的不同在于我们会思考会总结，现在我们的小学初中内容就是曾经多少万年人类缓慢进化总结沉淀下来的知识集合，短短几年内这些小学生就都学会了，门门满分我们也已经习以为常。我们的学习能力远超我们自己的想象，只要你能研究出来，不管多高深的技术或者哲学，很有可能在几十年后变成初中的基本课程内容。尤其是在中国，作为唯一一个没有断代的历史文明，我们的发展总是能找到答案的，那个答案就是哪怕掘地三尺，给我们几十年的时间，我们总是能完成从贫困到富裕的转变，这个国家最不缺的就是吃苦耐劳的百姓。

公司的问题是简单清晰的，大家习惯了过去这些年的“轻松”的日子，大家忽略了对发展的思考。作为技术型的公司，大抵上我们可以从三个方面来自我衡量：思考先行，测试先行，演示先行。我们最容易看到的就是开发先行，你说要做一个功能，一下午就给你交付。这种是最明显的劳力输出，只能表扬他勇气可嘉。为什么这么说？因为他没有了解清楚方向对不对，产品流程对不对，效果对不对。当然我们可以说，这些工作不都是领导安排的吗？我们只是执行啊，你们是不是戏有点多？

确实，大家的工作都是逐层往下分解的，到每个人手上的工作内容几乎就只是执行。只是我们不妨假设一下，我们的工作的客户可能就是我们的主管领导，那我们知道他的痛点吗？知道他想要交付的预期效果吗？知道即便按照他要求的做出来的效果就是行业最佳吗？事实情况是，在工作过程中我的问题不能往下走两层，几个问题下来大家都是迷惑的状态。大家不知道行业是什么样的，不知道好的技术以及好的产品应该是什么样的，也无法演示出来让人兴奋地效果。所以，不思考的小毛病就是大家集体等死，大毛病就是没有成就感你不快乐，一个不快乐的团队，总是随时面临着分崩离析的境地的，这种问题外部救不了，只能自救。

思考先行就是为了确保我们的方向是对的，知道目标在哪；测试先行为了确保我们对流程和预期效果是一致的，提升效率；演示先行是在开发之前就规划好我们应该如何去跟客户介绍，是一种能力的高度概括。基于这三种方法，我们就能在方向上一致，在流程上一致，在交付上一致，在预期效果上一致，才能做出真正满足客户预期的产品。反之，我们就在不断地返工，永远在改bug，永远在听抱怨。

队伍思想不统一目标不一致，人越多越误事。当务之急是先把研发团队给搭建好，知道如何定目标，如何切分计划，如何做优先级判断，如何做好时间管理，如何使用行业最佳实践来提升效率。必须做单元测试，代码review只要没有单元测试的就不能合并；所有开发前必须有issue管理纪律在案；任何设计讨论的结论必须有文档沉淀下来；所有产品前端必须完成CI的自动化打包测试流程……我很想把我知道的都告诉大家，有些技术实现真的不用重复造轮子，而是要学会快速纳为己用。

技术方面是有非黑即白的标准答案，而执行策略却不是，你考虑做哪些事情怎么做先做什么，都是没有标准答案的，成功与否完全取决于相对而言更满足行业发展大势。战略和战术都需要大家去思考，这才是真正让人白头发的困难之处。测试先行是让大家思考准备怎么用，演示先行是让大家思考准备怎么介绍，最难的就是管理者，要去思考为什么要做，以及怎么让大家形成高度一致的对方向的认可。

如果说今年我有什么心得体会的话，那就是铁了心明年我不能再去做主力研发了，我就是公司最大的技术障碍。如果不能让大家掌握思考的能力，那么未来这个公司注定也发展不起来。我对于研发的学习欲望要降低，降低到仅仅是一个个人爱好，而对于队伍的搭建与创新能力和思考能力的锻炼，才是我的重中之重。我希望未来的产品规划和研发是团队自驱动的（大家难以理解网络安全产品的卓越的方向这个问题会长期存在），未来我们的队伍能够协作办成一件大事，也能够再拆分办成很多件大事，那才说明公司成长了。