关于自研的几点感悟
**关于自研的几点感悟**
**写在开始**
基于成熟套件的客户化开发，好比对毛坯房做软装，
只要不砸“ **承重墙** （封装代码、核心逻辑）”，即便是“农民工”来做也不会“塌房”。
基于技术底座的产品自研，好比基于浇筑完成的地基建楼，即便提供了“通用建材”跟“指导手册”，但是建楼对能力的要求，不仅仅是对建材的使用熟练度。
需要“ **有能力、有资质** ”的工程师把关并落实目标、整体设计、细节设计、施工、验收、改造、运营维护等各个环节的“ **方案** ”合理性。
毕竟软装不合适，可以打掉重装。建楼的设计缺陷，可能最终导致需要推倒重建（软件重构）。而对于因能力不足，导致设计不合理从而带来的重构的时间与资源成本，业主侧很难为“能力不足”来买单，常常最后还是得承建方自吞苦果。
因此，技术底座的自研项目，对于人员能力的要求不降反升，而且为了确保设计落地的一致性，以及局部设计变更对整体架构的灵活适配，更加需要满足能力资质的人员持续投入，及时化解“临时方案债”、“技术债”堆积，需要深度卷入业主参与过程环节的细节把控。
想要实现盈利，设计的合理性至关重要，包括不限于：减少过度设计、用户视角的设计、产品设计评审、最终用户的高保真评审、技术设计评审、代码review等
** 战术工具的迭代提升但并未降低对能力的依赖 **
从开箱可用的“开发脚手架”到高低融合的“低代码”，我们的战术工具一直在迭代发展，以期通过工具的全面来形成竞争优势。
所提供的能力，其价值主张定位在通过减少通用能力组件在研发侧coding工作量，缩短需求到实现在研发侧执行的时间，以期通过更快的需求交付来实现业务价值的提升。
但在实际项目落地中，coding环节往往是大量前序工作的最后成果，往往前序工作的不充分或者不合理，最终所导致的反复，带来成本往往超出工具对coding环节带来的效率提升。
这里我们发现：
**其一，从战略、方案到落地的衔接，需要高阶资源的持续投入**
如果我们按照传统的交付方式，高阶资源较少精力介入到落地环节，我们会发现负责落地的资源，因为视角高度不够，最终落地的产品设计思路上往往会被最终用户所牵引，变成了需求与功能的实现者，而非战略的落地者，最终的落地效果不一定符合项目所期望达成的目标。
因此为了确保落地环节与战略、方案设计的一致性，我们应该要求具有高度视角的资源，把关方案落地的细节，确保在实现过程中所落地的设计遵从方案环节的决策。
同时高阶资源的行业经验，业务经验以及产品设计思路的引入，能够有效减少产品设计环节因为信息不充分，理解不透彻等导致的频繁返工与改动。
**其二，领域设计，做好模型抽象，减少牵一发，改全身**
对于自研产品的领域设计，则更加要求产品本身对于业务理解能力，对于业务模型的抽象能力，特别是在一个公司不同事业线不同业务成熟度不同时，如何实现对不同管理精细化程度的业务的系统支撑。
这里我们会发现，由于存在很多时候，客户并不一定能够想的非常清楚，因此如果我们完全按照客户说什么，就做什么，很可能后续因为经验不足，考虑不周带来频繁的变更。所以，经验在这里就会非常有价值，对于业务常识的理解，对于业内best
practice的复用，能够有效减少设计不合理带来的改动。
那么在实际落地过程中，我们建议是要能完全梳理出客户的各项业务，包括业务流程、流程差异与管理成熟度。基于业务流程图，向上抽象为IT层面的对象与逻辑能力，面向抽象后的模型环节进行产品设计，而不再仅仅by单一流程进行设计。
**其三，技术设计，我们需要研发充分左移**
对于自研，由于我们所覆盖的业务越来越多样化，对于研发侧的要求，是需要充分理解业务深入业务，合理评估与技术工具的选型，同时建立面向问题解决与拥抱变化的视角，而不再仅仅是面向功能的交付。
举个项目上的例子来讲，有个场景是需要讲比较多的数据进行合并确认的，而由于研发在技术设计环节，并没有得到这个信息输入或者没有数据量的sense，并未考虑数据量的问题，给出了并落地了设计。测试环节，我们又没有做好压力测试与性能调优时，直到上线后，遇到了这个case，我们很难短期高效的解决线上需要。
这个时候我们的出发点应该是，应该如何合理的修改来支持这个场景，及时填补考虑不周到导致的用户使用困难，而不应该首先反应是能不能让用户不要这么做，这个东西不好改。
因此实际产品交付过程中，我们需要研发与产品一起，站在业务用户的视角出发一起解决问题。
** 从价值、投入产出比出发，而不是功能完备性出发，减少过度设计 **
我们很大一部分做产品的顾问，都有很强的套件背景。
这一方面是优势，建立在对ERP的充分了解基础上，对于业务核心流程的认知以及业财一体化的理解是比较深刻的。
另一方面也是劣势，很容易去对标套件产品来做产品设计，因为当自己不知道怎么去设计时，照搬头部产品确实是一种方案，但是这种照搬很容易导致项目超支以及最终事倍功半。
当我们一个百万级的项目，如果功能去对标一个世界级公司，超过30年持续投入所研发打造出来的产品时，注定这个出发点就使得你很难将这个项目做盈利，因为站在功能完备性角度，你的很多设计可能一年下来用不了几次，但是你的产品设计与研发投入，远远超过开发这个功能所带来的业务价值。
所以这就要求我们的产品经理需要有精益思维以及从价值出发，识别最小可用产品并基于业务的需求优先级进行依次实现。
这里再举个项目上的例子，当我们在总体方案中将订单变更作为一项规划的能力丢给产品经理进行落地时，我们的产品经理的视角是，原来EBS的订单变更是这样做的，我也照着来一套。但是如果我们再往前走一步，跟业务了解一下当前所存在的订单变更的场景，我们会发现，现在的客户在订单变更上只有变更价格跟订单不再执行终止的场景。此时我们发现，产品经理对订单变更增减物料场景，所做的一系列的设计，比如执行数量与可变数量的管控、客户信用、合同管控等一系列复杂的设计，即便我们开发了，会存在一年到头用不了一次的场景，而且我们的产品设计、研发与测试投入可能需要至少三四个人月。
那么从项目角度而言，如果每个领域都有这种三四个人月的投入，可能整个事情做下来是不盈利的。因此，如何把关设计的合理性，决定的是这个业务是否能够可持续。
** “专业”的分工 VS “全能”的顾问 **
在项目上有次我跟新入职的同学开玩笑的说：
你选择的这个岗位，随着项目的开展与阶段的推进，需要依次承担包括BA（业务分析）、PM（产品经理）、UIUE（视觉与交互设计）、QA（测试）、OP（运营），一个人需要具备人互联网行业五个岗位所需要具备的基础能力😏，除了研发coding的事情不需要你干，其他事情都需要你来承担。
如果站在锻炼个人能力角度考虑这个事情，似乎这是个还不错的锻炼机会。
但是如果这个项目是个总包项目，又很难到位足够的资源的背景下，这可能会带来更多的问题，特别是当你的精力被充分分散时，可能每个事情对于深度思考的时间要求，就很难保障了，因此为了更快的把堆积的工作解决掉，很多环节，会快速决策，先弄过去，有问题之后再说，这就往往会带来上线的外部失败。
我想互联网之所以划分了这些岗位，虽然从我们的视角之间所带来的沟通成本，似乎并没有很高效，但是毕竟存在就有着合理性，无论是从岗位专业能力上，或者是通过不同环节的相互check来减少单一人员的视角考虑的不全面。
至少从我的视角来看，当有限的时间内，既要深度思考做好产品设计、又要测试、还要运营响应问题时，我很难做到面面具到。
毕竟专业的人在专注地做专业领域的事情上的效率应该是更高的，从而能够减少对非工作时间的挤占。因此，我想自研项目在某些环节还是应该引入相关专业的人员承担对应工作的。
**E.N.D**
作者|审核：熊旭东
编辑：朱思聪
